This chapter is from the book
This chapter is from the book
This chapter is from the book
Summary
When incorporating services into a business process, there are a number of ways in which a service user and service provider may interact. The synchronous request-reply style is perhaps the most common, but many business processes require asynchronous responses, subscription services, and unsolicited notifications as well. Determining the appropriate style of interaction requires an understanding of how the service will be employed in business processes.
Your choice of service access mechanisms directly impacts the ease with which you can access services, your ability to provide the different interaction patterns that may be required by the business processes, and the amount of work required to change the location of both service users and service providers. While direct or proxy-mediated access to services provides good support for synchronous request-reply, it makes implementation of other interaction patterns complex. Direct and proxy-mediated approaches are always dependent on the location of the service provider, and the use of interaction patterns other than synchronous request-reply makes them dependent upon the location of the service user as well.
Message-based service access provides more flexibility for interacting with services. It has no dependency on the location of the service users and providers, and it provides simple support for all of the service interaction patterns. It provides the most flexible service access.
Many services require some form of access control to manage who has access to which service. Access control can be implemented by the service provider, but this approach requires the modification of the service provider and can be expensive. Alternatively, access control can be implemented by either a proxy or a mediation service (an extended messaging service). Once again, the proxy approach is convenient for synchronous request-reply, but awkward for the other interaction patterns. The mediation service approach works well for all interaction patterns.
Accessing services may require the routing of service requests. The need for routing may arise from the need to distribute load across multiple service providers, the need to route specific requests to specific providers, or the placement of users and service providers at different geographic locations. Routing may also require some introspection into the message, the access of reference data, and the evaluation of routing rules. A mediation service provides a convenient architectural home for this functionality. Geographic routing generally requires the presence of mediation service components at each geographic location.
Services provide value when they are actually utilized in business processes. Combining services to form business processes is referred to as composition. Optionally, the resulting composite may, itself, be offered as a higher-level service.
The architecture of composites must be carefully evaluated for performance. Nested synchronous request-reply interactions can lead to excessive latency and unacceptable loads on back-end services. In such cases, architectural alternatives such as caching information in the composite may be more appropriate. Choosing such alternatives may impact the architecture of the back-end service as well as that of the composite, transforming a synchronous request-reply interaction between them into a subscription interaction. Thus, to achieve the service interface stability that is required to justify the service development cost, potential service usages must be thoroughly explored before the service is specified and implemented.
Achieving the benefits of a service-oriented architecture requires consistent decision making across many projects. The enterprise architecture group plays a key role not only in establishing standards and best practices for building services but also in ensuring that these guidelines are practical for routine day-to-day usage by project teams.