was created or what platform it’s running on.

Another basic concept is abstraction, which is the concealment of protocols, data access layers, and even security mechanisms that play no role in what the service offers to the outside world. Without abstraction, multiple service consumers could not access the same service simultaneously.

Keep in mind future service aggregation as well. Individual services often become parts of composite services. For instance, a customer validation service may be part of a customer processing service, which is part of the inventory control system.

Such potential aggregation underscores that services should be limited in scope. If your needs are more complex, write more services, don’t overload a single service. You don’t want to deploy and reuse a big, fat service to leverage just 10 percent of its functionality.

Finally, services need to be designed based on standards. Although in the world of Web services this seems like a no-brainer, many developers and architects get sloppy with standards and limit interoperability.

 

Five steps to service design

This handful of simple steps provide a rough outline for service design. Note that they apply to designing a new service, rather than to retrofitting a legacy application (in which case your choices will probably be more limited):

1. Start by being very clear about the purpose of the service. What will the service do, and who is the intended user? Will it be accessed by humans, applications, other services, or all of the above? Directly or indirectly?

2. Determine the information to be bound to the service, including both metadata and schema. This means you need to understand how information is leveraged by the service and what functions require what data.

3. Stipulate the functions (methods) encapsulated inside the service — in other words, the behaviors you would like to expose. Define how each function breaks down using a traditional functional decomposition chart.

4. Build the interfaces into the service, both machine and human. Determine how the service will interact with the calling applications and through what mechanisms.

5. Last but not least, describe in detail how the service is to be tested. This is a very important and often neglected step, in which you lay out a test plan based on projected usage patterns. Define the test information, service invocation, and what qualifies as valid results.

What’s strange about this new, hot, and somewhat over-hyped space is the lack of comprehensive service design tools. Yes, you can find deployment, management, and development tools sold by large players such as BEA, IBM, and Microsoft. But for the most part, granular capabilities are poorly integrated with the big architectural picture as you design and build. Of the tools on the market, IBM Rational Software Development Platform and BEA’s WebLogic Workshop probably come closest. More will surely follow.

— Dave Linthicum

 

SOA management:

Governance plus intermediaries

Web service deployments can sneak up on you. One group publishes a service for processing payments, another exposes the API for key functions in the HR system, and before you know it, you’ve got dozens or even hundreds of services. But this isn’t an SOA — this is a mess. Management and governance are the business processes that turn that mess into an architecture that supports the business.

One of the key differences between services in a SOA environment and traditional IT applications is that services, as do products, have clearly defined functions and guarantees that target “consumers” — applications or users that draw on services inside or outside the enterprise. This arrangement has implications for publication, reliability, and flexibility — all issues that come under the broad header of “management.”

Services are published in a registry — or more likely, a repository that contains additional metadata. The repository is the system of record for the enterprise’s full range of services. It’s also a place where potential consumers of services can discover them and query metadata to learn about them. Finally, the repository is a point of control that allows the enterprise to manage versioning and ensure compliance with internal and external requirements.