Lawrence Wilkes and Richard Veryard
CBDI Forum
April 2004
Summary: Discusses several principles of good service architecture and design in terms of their impact on agility and adaptability. (17 printed pages)
Introduction
Loose Coupling
Service Provider and
Service Consumer Perspectives
Design Principles
Abstraction
Generalization
Standards
Compliance
Granularity
Granularity Varies Across Application
Tiers
Provide Alternative Services; Use Aggregation and
Composition
Architectural Considerations
Conclusion
References
When designing business software, we should remind ourselves that the objective is delivering agile systems in support of the business; not Service Orientation (SO). Rather, SO is the approach by which we can enable business and technology agility, and is not an end in itself. This must particularly be borne in mind with references to Web services. Achieving the agility that so often accompanies Web services is not just a consequence of adopting Web service protocols in the deployment of systems, but also of following good design principles. In this article, we consider several principles of good service architecture and design from the perspective of their impact on agility and adaptability.
Web services provide a powerful framework by which we can deliver more agile solutions. However, we must combine their use with principles of Service Orientation that ensure that agility requirements are met. We can see parallels with the adoption of component technologies and Component Based Development (CBD). Components promised benefits such as reuse and an open market in components, which together would drastically reduce the time to deliver new systems. However, while component technologies like Microsoft COM have been widely adopted, most organisations saw little reuse and the open market in components failed to grow to anywhere near the level predicted. IT did get other benefits from componentisation of course; such as improvements in system scalability and the ability to replace components as needed, but many of the claims we saw being used to justify investment in componentization were not realised.
Why was this? Well, while component technology was a great framework for reuse, developers didn't put the effort into making sure the components themselves were actually designed for reuse by another project. Typically, the effort needed to understand what an existing component did and adapt it for a new requirement outweighed the effort to simply build a new one that fitted the requirement perfectly from scratch; except of course that consequently the new component wasn't reusable by the next project either, and so the cycle continued. In other words, while many organizations adopted component technology, they didn't adhere to the principles of CBD.
We now face a similar challenge with services. We can predict that Web service technology will be widely adopted, but to what extent will they be based on the principles of SO? And if they are not, will the promise of Web services be realised—particularly for the business?
Loose Coupling is one of the mantras of Web services. No discussion of Web services seems complete without some reference to the advantages of looser coupling of endpoints (applications) facilitated by the use of Web service protocols.
The principle is that by using a resource only via its published service and not by directly addressing the implementation behind it then;
Figure 1. Decoupling applications and technology through services
The concept of coupling applies within the business itself regardless of any IT systems, between the software applications, and at the technology layer. Figure 1 illustrates that coupling takes place at a number of levels.
At the Technology Layer we are concerned with integration at the platform and network level. For example how do you connect J2EE to .NET? Considering integration technologies at this level might involve distributed computing or messaging products.
At the Application Layer we consider how applications are connected to other applications; for example connecting Seibel with SAP. Enterprise Application Integration (EAI) technology is the common approach at this level. Web service protocols may enable loose coupling at the technology layer, but not necessarily in the application layer. For example, use of Web services provided by a packaged application such as SAP might remove technology dependencies in comparison to use of their BAPI interfaces that use component technologies. But the Web services exposed are still the same SAP specific interfaces and are not decoupled from the application. Consequently the service consumer is still tightly bound to SAP regardless of the use of Web services.
We therefore need a separate Business Service Layer that abstracts the service away from both the technology and the application. With this we can then support the business with a Business Process Layer that interoperates at the business service layer with customers and sales (concepts that do not change) and not directly at the application layer with SAP with Seibel (implementations that do change).
However, some of the loose coupling benefits of services and Web services for B2B integration might seem irrelevant if the business has for example entered into a multi-year contract to use a single supplier. Even so, at the end of the contract the business does not want to be held to ransom by a supplier who knows that the tight coupling with their systems is now a constraint on change. This is why we need to design SOA against a business requirement for specific forms of adaptability. You should not assume that all forms of loose coupling at the different levels are automatically valuable to all organizations.
Service agility can be seen from both the perspective of the service provider and the service consumer. Table 1 considers some of the agility requirements of both and the general service design principle that could satisfy them. The service consumer's real objective is normally to receive maximum value at minimum cost and risk. For a service offered on a commercial basis, risk can be reduced by aligning the payment of services with the benefits received—this should be achieved by some form of pay-per-use but only if the service and its commercial terms are properly designed. Risk is also reduced by the ability to switch service provider to gain tactical or operational improvements in price or service level.
Table 1. Balancing Service Provider and Consumer Needs
| Service Consumer Objectives | Design Principle |
|---|---|
| Reduce effort to use new services. | Precise specifications.
Standardized services. |
| Choose alternative instances of services type. | Services well abstracted from implementation.
Standardized services. |
| Service provider Objectives | |
| Reduce demands from new consumers for additional features. | Coarse grained, abstracted services that meet a wide range of service requests. |
| Compose New service from existing ones. | Fine grained, generalized services that can be composed in a variety of ways. |
| Reduce impact of changes to service Implementation. | Services well abstracted from implementation. |
| Provide service in new and unforeseen context. | Generalized services. |
| Provide service to as broad a range of consumers as possible. | Coarse grained, and generalized services. |
One might expect that the service provider's objectives are a mirror of this—deliver maximum value at minimum cost and risk. Service value is maximized by making the service easily available to as many potential users as possible, in as many use-contexts as possible. Cost is reduced by the economics of scale, as well as having an efficient response to new service demands. Risk is reduced by spreading the service across a wide variety of different uses and contexts, so that demand peaks and troughs are smoothed, and by using virtual (utility or grid-based) resources to handle variations in demand levels. If service consumers each want to use a service in a different way it makes more sense for the provider to try and deliver a generalized service that enables this.
These objectives all have implications of the design of the service from the provider's perspective. However, there also may be a conflict of interest. For example, the service provider might deliberately seek to reduce the agility of the service consumer to use alternatives by locking them in to inflexible service designs.
In this section we examine in more detail some f the design principals that have so far been mentioned in passing such as abstraction, and understand how they contribute to agility.
The principle of Abstraction is normally used in the context of ensuring that a service is independent of a specific implementation and other detail. As discussed earlier, Web services provide a high degree of abstraction from the service Implementation by using standards-based protocols rather than the native interfaces of the underlying technology. One of the principles of Service Orientation is to focus on what a service does, not how it does it.
To enable agility, we use abstraction to:
Some of these can be seen as similar to principle of encapsulation in object and component technology. However, the goal is not just to hide detail behind an interface, but also abstract that interface away from the implementation technology and any other implementation specific features to reduce coupling.
When building a new component, this abstraction can be built into the services from scratch. The component might offer implementation-based services that are used within the component and the sub-assembly of highly related components around it where tight coupling should not be an issue (though use of Web services protocols might still be desirable for other reasons such as dynamic addressing of the component for scalability), whilst a more abstracted business service is exposed externally. As illustrated in Figure 2, a process component is a common way to architect this. The business service exposes operations at the order level, not the individual object level.
Figure 2. Component exposes abstracted business service
The purpose of this is:
Figure 3. Process Component provides a facade across existing implementation
More often perhaps in the current climate, the business service is going to be implemented by a number of existing applications. As shown in Figure 3 the same pattern still applies, with a new process component abstracting the business service away from the implementation-based services offered by the packaged applications. Again the implementation-based services are still published so they can be composed into other services for different business requirements.
Agility can also be improved not just by abstracting the service away from the underlying implementation but also by taking a more abstract view of the business concepts in the service so that they can be used in a broader context. For example the use of a party information service instead of separate ones for customer information, supplier information, and so on. The benefit being that new party types can be accommodated without having to deliver a new service each time. The difficulty however is that each of these types is likely to have specific data or operations that are not common to the others, which means we also have to consider the use of generalization.
The principle of generalization is to broaden the application of a service so that it can be used in a wider range of scenarios, including unexpected ones, removing the need to build a specific service for each new requirement.
Figure 4. Generalized service separates common from specific
The goals of service generalization to enable agile systems include:
These first two statements might appear contradictory. However, this reflects a two stage process to deliver agile services. First, decompose the service to find the fine grained parts both common and specialized; and then compose them back together to form a coarse grained service. Clearly this can also be considered an aspect of granularity which is discussed later.
An objective of using generalization to deliver a coarse grained service would be to reduce the number of services that need to be exposed and maintained. It can reduce the maintenance that is necessary when a service consumer want to use the service in a new context, or realizes that they need some additional information from the service that they have not used before.With foresight, the generalized service can already provide this.
Depending on the particular requirement, generalization might be at the operation or the message/document level. It could be two separate services as shown in Figure 4, or the document might contain two message structures, one of which conforms to the common view.
The downside to this is that it could become a performance bottleneck, and be burdened with irrelevant data in relation to specific usage. Again it depends on the specific scenario. If you want to provide a service that returns information at the customer level, then returning the balances for all the customer's accounts in one go would reduce traffic, and simplifies the service request. However, if the requirement is purely to return the balance for a specific account, why incur the overhead of collecting and returning information on all of them from various back-end systems?
Compliance with domain standards might not be seen as a matter of principle, but as a matter of convenience. A key reason that standards help with adaptability is that they have considerable inertia and take a long time to change. So the standards provide a helpful pattern/framework for identifying certain aspects of the requirements as common and slow-changing. Standardization leads to commoditization, which may be attractive to the service consumer because it enables agility through the ability to choose from multiple providers who all conform to the same standard. Similarly it might enable a service provider to enter an existing industry by simply conforming to existing standards without the need to create new service types.
However, slavish conformance with standards might be seen as stifling agility, and an innovative or foolhardy company might well choose to deviate from industry standards in order to increase flexibility or to offer a differentiated service. Compliance can include adoption of standards in the published interface for:
Compliance should also imply a commitment to maintain service in line with the evolution of those standards. Standards are likely to be set at a vertical industry level by a suitable industry body, for example ACORD in the insurance industry. Some have broader applicability such as the Uniform Code Council standards for product coding. The advantages of Standards compliance include:
Granularity refers to the scope of functionality provided by a service. It has become best practice to recommend that Web services should be coarse grained. This is in part a reflection of the fact that the initial view of Web services was of a resource that would be deployed across the Internet with a slow and unreliable connection. As such, using a small number of coarse grained messages would reduce the number of transmissions and increase the likelihood of a message arriving and a transaction being completed whilst the connection was still available. Although the quality of connection is improving all the time, this remains good advice when delivering Web services for external use across the Internet. However, there is now much wider internal use of Web services where the network is faster and more stable. A higher number of fine grained services and messages might therefore be acceptable in this situation. Some of the benefits and challenges of granularity are presented in Table 2. There is no rule that services should all be coarse grained, or fine grained. The ideal is that they should be right grained for the specific usage scenario.
Table 2. Contrasting fine and coarse-grained service operations
| Coarse Grained
Benefits |
Challenges |
|---|---|
| All data contained in single request. | Complex data. Large message size. Complexity of dealing with potentially multiple data errors in different parts of the service request. |
| Can reduce need to manage state as the message carries complete context | Could lead to false sense of state. Data valid
on previous submission becomes invalid on later resubmission.
Need to revalidate all the data with every resubmission. |
| Self-described and self-contained. Carries complete context of request. | Might be geared towards a specific scenario and not reusable in others. |
| Fine Grained
Benefits |
Challenges |
| Small messages containing simple data. | Might need to address way state is managed
between messages.
Recovery of failed executions if the network is unreliable. |
| Individual services can be composed in other
services.
Run time flexibility. Individual services are requested only in response to the business process flow. |
Consumer will need to understand precise
sequencing of service requests and overall process.
Complex description in terms of sequencing, pre/post conditions, etc. Individual services have no context on its own. |
| Might reflect the current implementation too closely, and impacted by changes to implementation. | |
| Performance overheads. Increases network traffic and overheads of dealing with multiple service requests. |
In an article in the previous issue of the Journal we introduced layers of service abstraction with coarse grained business services that were composed from finer grained implementation-based services (that are a straightforward translation of the existing interfaces into Web services). Web services can however be exposed at any application tier. Vendors have made it straightforward to expose Web services directly from any database, object or component. Application package vendors might expose Web services at a number of different tiers in their applications. At each of the following tiers illustrated in Figure 5 there will be different levels of granularity:
Figure 5. Service operations change granularity across application tiers
Figure 5 illustrates that as you get closer to the requesting application the services become coarser. At the database and object tiers, then fine grained database and method calls will be implemented in native platform technologies giving scalability and performance. Decisions regarding the granularity of these are the domain of the developer.
In this example, Systems A and B are implemented in different technologies. As such Web services are used to remove technology dependencies. These Web services are also abstracted away from the implementation so that the implementation can change with minimum impact on the service. Because System A and B are distributed on the network, coarser grained services are used to reduce traffic. However, as they are still behind the firewall, the overheads of authentication and encryption are not apparent. We can refer to these as internal services. To enable reuse, these internal services are not too coarse grained so they the same service can be used in different contexts (see generalization above).
Although organizations will not want to proliferate the number of different Web services needlessly, due to development and management overheads; there is no reason to limit the provision of the service to a single Web service at a fixed granularity. For example, a business service could be exposed as a single coarse grained Web service for use by third parties, and also as a set of fine grained services for internal use, or by closer business partners. This would provide a best of both worlds solution. There are two ways that this ideal solution could be achieved. Either by simply providing a parallel Web service of the same facade, or by reusing the existing Web services and aggregating them into a new coarse grained one.
Figure 6. Delivering varying granularity of services
Figure 6 illustrates that services can be delivered at a number of different granularities to suit different requirements. Service consumer A might be within the same organization and have high speed reliable transport available. While, service consumer B is a third party accessing the systems across the public Internet.
Clearly there is additional cost in taking this approach. However, the following benefits can outweigh this cost:
A similar approach applies with generalized services. Fine grained generalized services are composed into coarser grained services that are specialized towards a specific requirement. This approach also assists with abstraction, as the coarser grained services hide the fine grained object interfaces.
As well as adopting the above design principles we can consider some specific elements of a SOA with a view towards increasing agility.
A widely adopted strategy to SOA is to reuse existing applications by wrapping them and exposing service interfaces. Though this is an excellent way to get off the ground quickly, it might have drawbacks with regard to longer term agility somewhere down the track.
The essence of an SOA is that the service must be implementation independent—that is, the service consumer should not have to understand the specifics of the implementation model. The problem with wrapping what already exists is that the original application is almost certainly not going to make this transparency easy at either a functional or non functional level. For example, monolithic implementations do not support the agility vision of Web services because:
The structure of the service Implementation should not be of any consequence to the service consumer, but it still remains important to the service provider for well understood component benefits of maintainability, scalability, and so on. Moreover, a service Implementation that is not well componentized may impact the agility of service consumer who finds they are unable to use alternative services in some areas, because of the internal dependencies in the implementation as illustrated in Figure 7. How quickly in this example could you implement a business decision to outsource the logistics operation and use the Web services provided by the external logistics company to continue to satisfy your customers requests for delivery information? How would you redirect an individual Web service when the internal dependencies in the ERP package still remain?
Figure 7. Avoid internal dependencies
Even with a componentized implementation, developers of course still need to follow CBD best practice and ensure that dependencies are through the use of published services and interfaces, and not for example by still directly accessing the database of another component just because it is convenient.
Ideally there would be very clear alignment of the business services, the business objects and the software components that implement them at traceable level of granularity so that the response to change at any level has the minimum impact on the rest.
In the real world though, this alignment is often not present. Fortunately, services help to provide an excellent transition path from existing monolithic or poorly structured implementations. By wrapping the implementation with well designed Web services you can then replace the implementation and remove internal dependencies as shown in Figure 8.
Figure 8. Using services to migrate existing applications
Finding the business justification for the final step in this transition is not always easy. Many will stop at stage 2 when they have the facade that delivers on the more immediate need to expose the business services in place. However, it should be understood that aspects of business agility, not just technical agility remain compromised by the continued use of a poorly structured implementation.
In a SOA, we can introduce a number of what we term 'articulation points' around which we can introduce flexibility for both the service provider and consumer.
Figure 9. Articulation points
Figure 9 illustrates some numbered articulation points at which the following decisions can be made:
Agility is served best by separating these articulation points out of the applications at each endpoint so that neither the decision process nor the result is hard-wired into the code. In the process illustrated here, the application always fires off a request to the same logical service, but the actual endpoint is resolved by points 1 and 2. We can use these articulation points as described in the following list:
There are a number of approaches to implementing each of these articulation points. While a simple script and perhaps some look-up table might suffice in some instances (and such a capability might well be built into the web server for example), often a more complex solution, or one that provides for greater flexibility and can be driven by multiple business rules, is required. Options include implementing some form of service broker which performs straightforward switching and routing, or a service facade that may include more complex functionality. For agility, the important consideration is how these points are designed into the SOA and not left to the developer's at implementation.
The concept of a facade should be familiar to most. Whether in the context of a building or software, the basic principle is the same; to expose a different external view by hiding that used internally by the underlying implementation. An obvious role for a Web service facade is to act as a wrapper, converting the underlying implementation technologies into Web service protocols such as SOAP and WSDL. As discussed in the previous section, the facade can be used to help migrate legacy applications. The facade can also be used to perform many other functions in a SOA such as a level of process orchestration, or Web service management.
In the context of agility, a facade can be used to deliver some of the design principles discussed so far,
A service broker provides a switching or routing mechanism. This takes the address of the incoming request and routes it instead to another. The WS-Addressing protocol standard is particularly applicable here as it provides a framework for the addressing of service requests that enables their routing to be determined dynamically. As well as capability within the web server, the service broker can take many forms such as:
As can be seen in the previous discussions, there is no single solution to each articulation requirement. The products available, or those built in house can often perform more than one function and serve many articulation points.
In addition, some of the products, notably orchestration engines and WSM tools, perform other functions besides those required here. You would be unlikely to acquire one just to perform straightforward brokering functions as this would not be a very cost effective option. Acquiring these is often an organizational not a project level decision. However, when justified for their full functionality, it would make sense to put apply them to both simple and complex articulation requirements - although this must be balanced against the highly optimised and efficient processing a simpler switch can deliver in high throughput situations.
Many vendors' presentations on Web services will commence with the obligatory statement of the business problem reflecting the need for agility. However, there is a big gap between this need and the Web service technology that is subsequently presented as the solution. While Web services are an essential enabler, delivering business agility is more a consequence of thorough analysis of the business need with agility in mind and careful design of the solution that is architected for agility using the approaches outlined here.
Desirable as agility might be, delivering on the principles outlined in the report may not be straightforward as the following obstacles need to be overcome.
If businesses are to become more agile then they must address these issues. Business leaders cannot continue to bemoan the IT department's apparent lack of responsiveness to change when its own practices can create the above obstacles. Similarly the IT department must also play its part in designing agility into their solutions and not delegating it to the IT vendor's latest 'magic bullet'.
This article draws from the following CBDI Journal Reports that provide greater depth on this topic:
About the Authors
Lawrence Wilkes, Technical Director and Principal Analyst, CBDI Forum, is a frequent speaker, lecturer and writer on Web Services, Service Oriented Architecture, Component Based Development and Application Integration approaches. Lawrence has over 25 years experience in IT working both for end user organizations in various industries, as well as for software vendors and as a consultant. Lawrence can be reached at lawrence.wilkes@cbdiforum.com.
Richard Veryard, Associate Analyst, CBDI Forum, is a consultant and writer specializing in the management of technology, and the technology of management. He has worked in the software industry for many years, with special focus on the development and deployment of products and processes, across a wide range of industries and sectors in many countries. He has written several books on modeling and management, and has published and presented widely. He is a regular contributor to CBDI, and is currently Deputy Chair of IFIP WG 8.6, an international working group on the Diffusion, Adoption and Implementation of Information Technology. Richard can be reached at richard.veryard@cbdiforum.com.