TN_1110: Using Systems to Represent Services in a Service-Oriented Architecture (SOA)

Bill Gibson, Program Manager
Microsoft Corporation

SOA is a much discussed architectural model for developing loosely coupled distributed systems. While exactly what defines an SOA is still debated, there is general agreement that it is fundamentally an architectural pattern based on interoperable Services that communicate using messages. However, what exactly is a Service? The much-debated four tenets of SOA define desirable characteristics of a service:

1. Service boundaries are explicit.

2. Services are autonomous.

3. Services share schema and contract not types.

4. Service compatibility is based on policy.

While these may be desirable characteristics, they do not follow simply from choosing to use HTTP/SOAP or implementing applications using the ASMX programming model. Service orientation is an architectural pattern and a Service is an abstraction within that pattern. Services need to be designed deliberately. In this note, the term ‘Service’, with an upper case ‘S’, is used to refer to this architectural pattern or an implementation of it.

It is not the purpose of this note to take a position on the four tenets. Instead, this note demonstrates how a Service is a special case of an (application) system as defined in the System Definition Model (SDM). We’ll show how Services can be designed and composed using the System Designer to create potentially large-scale service-oriented systems. We will see how using a system to represent a Service can help make the boundaries of the Service visible (and thus more explicit). This can also highlight the Service's dependencies on other Services, helping you gauge and adjust the degree of autonomy achieved in your design.

This proposition is considered from the perspective of the four tenets.

Service Boundaries are Explicit

This first of the four tenets talks to the need to explicitly identify the communications that flow across the boundary of a Service. The exposed surface area of a Service should be well-understood and defined by explicit contracts. Great care should be taken in the design of contracts to ensure they are well-factored and insulate the Service consumer from implementation details of the Service. However, equally important in the definition of explicit boundaries is considering what lies inside and outside the Service. Ideally, it should not be possible to interact with a Service or access its resources through any back doors.

Most Web services programming models provide an explicit service implementation construct, for example, a class annotated with Web service-related attributes. However, they offer no means to reason about the more abstract notion of a Service as a configuration of possibly multiple service classes or to consider other implementation elements or resources that are essential to the Service. In effect, the programming model lets you define fragments of the boundary. However, you have assemble these into a full Service definition yourself.

So let’s consider the notion of a system in SDM and see if that can help. A system is a configuration of resources. In addition, a system can selectively expose the behavior of its members to other systems via endpoints. If we use a system to represent a service, the system boundary becomes the service’s boundary, and we can explicitly include those applications and subsystems that fall within the boundary. We can also specify exactly which of their endpoints are exposed by the system and thus, the Service. Using a system makes it easy to think about a Service more abstractly, and avoid muddling the architectural entity with the lower-level programming constructs from which it implemented. Using a system allows you to easily extend the definition of the Service over time by adding additional members to the system and exposing additional endpoints. For example, you could deliver the first version of a Service using asmx technology and later extend the Service using the Windows Communication Platform (WCF) (WCF was formerly known as Indigo).

The encapsulation provided by a system is enforced if the overall architecture is designed as a composition of systems and client applications using the System Designer. The System Designer and the SDM model require that all system to system communication is defined using exposed endpoints only.

Furthermore, the System Designer allows you to design a service from the top down as well as from the bottom up. If you design from the top down you can think about the exposed behavior of the Service before committing to the specifics of its implementation design. For more detail, see Top-down System design.

Services are Autonomous

The second tenet is based on the premise that Services should be deployed and managed independently. Once Services are deployed, you cannot assume you will know who uses them, so they should be designed with the expectation of long lifetimes and should be resilient to changes in their environment. This implies they should not rely on detailed knowledge of the implementation of other Services as Service implementations may change independently over time.

Using systems to design Services allows service-providing applications to be composed with other interdependent applications or systems to maximize autonomy. Using systems to design Services will highlight dependencies on other Services, which will appear as explicit consumer endpoints on the Service. Each dependency can be investigated, and, if appropriate, the referenced application or system can be included within the boundary of the Service.

Figure 1 A system used to represent an autonomous Service

In the example in Figure 1, a system is used to describe the CatalogService. It encapsulates three ASP.NET applications and a database, but exposes only the Web service endpoints. The CatalogService can now be included in higher-level systems as a single logical entity that exposes the Product Management, Catalog and Product Pricing endpoints.

Services Share Schema and Contract, not Classes

The third tenet talks to the need to minimize coupling between Services and their consumers. Services should communicate with messages. The only knowledge they share is the schema of the message—the client should not have or need any knowledge of the implementation of the message in the Service. By sharing schema and not implementation classes, the Service implementation can be changed over time without impacting its clients.

If the Application Designer is used to create consumer endpoints on client applications from the WSDL exposed by a service endpoint, the application and Services are coupled only by the exposed contract and message schemas and not by any shared knowledge of implementation classes. This same loose coupling is then inherited by systems composed from these applications.

Service Compatibility is Based on Policy

The fourth tenet talks to the value of enabling Services and clients to determine compatibility at run time based on published policies. At this time, run-time policy is outside the scope of the System Designer and confers no additional benefit.

Creating Service Systems

To create a Service system, first create or reverse-engineer applications that expose Web services endpoints using the Application Designer. Then, select the application(s) that expose the behavior you want to offer from the Service and select Design Application System. Give the system a name, using the suffix “Service” is suggested to indicate its intent. In the System Designer, select each Web service endpoint and choose Add Proxy Endpoint to expose it across the Service boundary. You can then create higher-level systems that compose your Service with other Services, client applications, and systems to create your overall distributed system design.

Summary

The System Designer can be used to create systems that represent Services and to compose these into larger scale service-oriented systems. Using systems to represent Services helps visualize Service boundaries and ensure Services are autonomous.

References

For a discussion of the four tenets of SOA see http://www.bpminstitute.org/articles/article/article/the-four-tenets-of-service-orientation.html.