Service-Oriented Architecture: Chapter 13: Thirty best practices for integrating Web services. Pt. 1. | 5

Service-Oriented Architecture: Chapter 13: Thirty best practices for integrating Web services. Pt. 1.

13.2.4 Service interface designer

Designing a Web service is a separate task from its actual development. A service interface designer is responsible for ensuring that the external interface of all Web services is consistent and clearly representative of the service's intended business function. The service interface designer typically will own the WSDL document, to which developers will need to supply the implementation code. The service interface designer can also be in charge of all SOAP documents to ensure a consistent message format as well.

Typical responsibilities:

  • WSDL documents

  • SOAP message documents

  • interface clarity

  • interface extensibility

  • interface standards and naming conventions

Typical prerequisites:

  • a background in component design

  • high proficiency in WSDL and SOAP

  • a proficiency in business analysis

  • a good understanding of the organization’s business scope and direction

13.2.5 Categorize your services

“Use XWIF service models to classify and standardize service types.”

Every Web service is unique, but many end up performing similar functions and exhib

iting common characteristics, allowing them to be categorized. This guide refers to service categories as service models. A number of service models are described throughout this book, each with a specific purpose and a list of typical characteristics. Use these as a starting point, and customize them to whatever extent necessary.

Here are some examples of how using service models can be beneficial:

  • you can apply specific design standards to different service models

  • the model type instantly communicates a service’s overall role and position within an architecture

  • models can be aligned with enterprise policies and security standards

  • service models can be used to gauge the performance requirements of service-oriented applications

13.3 Best practices for designing service-oriented environments

13.3.1 Use SOAs to streamline business models

“Service-oriented designs open up new opportunities for business automation. Rethink business models to take advantage of these opportunities.”

If you find yourself amidst the technology surrounding Web services, don’t lose sight of one of the most significant benefits this new design platform can provide. By offering a more flexible, interoperable, and standardized model for hosting application functionality, SOAs provide an opportunity for you to rethink and improve your business processes.

For instance:

  • A service-oriented architecture within your organization will increase the interoperability potential between legacy systems. This will allow you to reevaluate various business processes that rely on multiple applications or data sources.

  • An array of generic business and utility services will provide a number of ways to automate new parts of your business centers.

  • Services can integrate with EAI solutions to deliver new business processes that, in turn, integrate existing business processes.

To learn more about service-oriented business modeling, see Chapter 14.

13.3.2 Research the state of second-generation specifications

As more and more legacy application logic is expressed and represented within ser-vice-oriented environments, the demand increases for Web services to support a wider range of traditional business automation features.

The IT community responds to these demands by improving and sometimes replacing technical specifications. The feature set of the Web services framework continues to grow, driven both by standards organizations and major corporations, many of which collaboratively produce specifications that address new functional areas for Web services to utilize.

“Approach the choice of each second-generation specification as a strategic decision-point.”

If you are building serious service-oriented solutions, you will be working with sec-ond-generation specifications. Before you begin creating dependencies on the features offered by one of these standards, you need to ensure that:

  • it is sufficiently stable

  • it is supported by your current platform vendors

  • there is no emerging specification poised to take its place

  • support for the standard is (or will be) provided by middleware or development products you are considering

Don’t make the mistake of classifying the selection of these specifications as a purely technical decision. It is a strategic design decision that will have implications on your architecture, technology platform, and design standards. (To stay current with Web services standards, visit www.specifications.ws.)

13.3.3 Strategically position second-generation specifications

“Design your SOA with a foreknowledge of emerging specifications.”

Regardless of whether you are planning to incorporate the features offered by some of the newer second-generation Web services specifications, you should make it a point to research the feature set provided by these standards. This will allow you to identify those that may be potentially useful.

Those you classify as being significant or relevant can be positioned within your future-state enterprise architecture. This is a key step in evolving a service-oriented environment.

It is also important that you make this information publicly available to your project teams. Architects will approach the design of application logic differently with a foreknowledge of how the role a future technology may affect their application designs.

Created: March 27 2003
Revised: February 21, 2004

URL: http://webreference.com/programming/soa/1