I've been receiving a lot of questions around service design, and I'm finding that those building SOAs are not focusing on this as a discipline.

First, services are not applications. They are small parts of an application. Nor are they subsystems, they are small parts of subsystems as well. Indeed, services are more analogous to traditional application functions in terms of design, and how they are leveraged to form solutions.

Each service has a specific purpose, and they are not complex nor naturally dependent on other services. Thus, they are easily abstracted into composite applications, in essence leveraging these services as if they are functions local to the composite.

Second, services should exist with a high degree of autonomy. They should execute without dependencies, if at all possible. This allows you to leverage the service by itself, and designing the service with this in mind, no matter how course or fine grained the service is.

With the movement toward SOA, and the use of services to assemble and integrate software, we have to pay particular attention to design. Indeed, services have many unique design principles, a bit different than traditional software systems (structured and object-oriented).

So, now that we understand the common design and testing patterns we must follow, the question is: How does one design a service? There are certain steps architects and developers can follow. Here are some suggestions.

First, you need to define the purpose of the service. What will the service do, and who is the intended user?
Possible Artifact: Service Definition Document

Second, you need to determine the information to be bound to the service, including both metadata and schemas. This means you need to understand how information is leveraged by the service, and what functions require what data. Typically, services are storing information outside of themselves, thus you also need to design the mechanisms for accessing outside data sources. Moreover, you need to define data policies here, including data validation constraints and dependencies.

Possible Artifact: Metadata and Schema Document

Third, you need to determine the functions (methods) encapsulated inside the service; in other words, the behaviors you would like to expose. For instance, if our service checks inventory it may expose:

CheckInvenotoryOnHand(product_ID)
CheckInventoryReorderPoint(product_ID)
CheckInventoryOnOrder(product_ID)

It's also at this step where we define each function, including how the function breaks down using a traditional functional decomposition chart. This means that we define the higher level functions by defining all lower level functions. Structure charts or decomposition diagrams are very helpful here.

Possible Artifact: Structure Chart

Fourth, we need to define any interfaces into the service; both machine and human. This means we need to determine how the service will interact with the calling applications, and through what mechanisms. While Web services define the mechanisms for both interface discovery and communications (e.g., WSDL and SOAP), we need to determine what those interfaces are and what they do. In many instances they map directly back to the functions, but not always.

Moreover, with the use of rich client interfaces, you may be interacting with a human through a portal-type interface. You need to define that here as well, including design of the user interface.

Possible Artifact: API Design, User Interface Design

Finally, we need to define how the service is to be tested, using the suggestions above. This is a very important but often neglected step where you define how those leveraging the service will test the service within the context of their usage pattern. You need to define test information, service invocation, and validity of results. Even performance profiling should be included in this step.

Possible Artifact: Test Plan

Posted by Dave Linthicum on September 28, 2006 05:59 AM