|
|
| Continuing our exploration of service-orientation, we now focus on two principles that tend to receive much less attention than they deserve. When it comes to service design, so much of the spotlight is on enabling design characteristics most commonly associated with SOA marketing terminology, namely loose coupling and reuse. While certainly important, if not critical to achieving the long-term goals of SOA transition projects, there is more to consider. Abstraction and the strategic use of service contracts represent two additional principles that, to a large extent, support the realization of reusable, loosely coupled services. But, even the most reusable service is not useful if it cannot be found by those responsible for creating potential consumers. Furthermore, even the most loosely coupled services will have limited reuse potential if they cannot be assembled into effective compositions. This is where the principles of service discoverability and service composition come into play. Service discoverability The characteristic of discoverability essentially helps avoid the accidental creation of redundant services or services that implement redundant logic. Because each service operation provides a potentially reusable piece of automation logic, the metadata attached to a service needs to sufficiently describe not only the service's overall purpose, but also the functionality offered by its individual operations. This service-orientation principle is related to, but distinct from, discoverability on an architectural level, in which case service discoverability refers to the technology architecture's ability to provide a discovery mechanism, such as a service registry or directory. These extensions effectively become part of the overall infrastructure in support of SOA implementations. On a service level, the principle of discoverability refers to the design of an individual service so that it becomes as discoverable as possible, regardless of whether a discoverability product or extension actually exists in its surrounding implementation environment. The reasoning behind this is that even if there's no need for a service registry because there simply isn't enough of a service inventory to warrant one, services should still be designed as highly discoverable resources. That way, when a service portfolio grows in size, the evolutionary governance of those services can be better managed because each service is equipped with sufficient metadata to properly communicate its purpose and capabilities. Service composition As service portfolios grow in size, service compositions will become an unavoidable and increasingly important design aspect of building service-oriented solutions. The main reason this particular principle is so important is because it ensures that services are designed in such a manner so that they can participate as effective members, or controllers, of these compositions. The requirement for any service to be composable also places an emphasis on the design of service operations. Composability is simply another form of reuse and therefore operations need to be designed in a standardized manner (and with an appropriate level of granularity) to maximize composition opportunities. A common SOA extension that underlines the relevance of composability is orchestration. Here, a service-oriented business process can be expressed through a composition language, such as WS-BPEL, essentially classifying the process itself as a service composition represented by a parent process service. Either way, the need for a service to be highly composable is irrespective of whether immediate composition requirements exist. Composition discoverability Each of the principles we explain in this series has relationships with others. Service composability, for example, is a characteristic that is influenced by the extent to which several other principles are collectively applied. Even discoverability ties into effective composition. A fundamental rule of service abstraction is that a service can represent any range of logic from any types of supported sources, including other services. If services encapsulate others, we have a composition. To build an effective composition, the service designer will need a means of finding the most suitable services to act as composition members. Furthermore, once the composition is completed and deployed, potential consumers of the service representing the composition will benefit from an awareness of its existence, purpose, and capabilities. Discovery supports and enables both of these scenarios, thereby furthering the cause of service-orientation. ref: Principles of Service Oriented Design - http://msdn.microsoft.com/en-us/library/bb972954.aspx SOA Principles - http://www.soaprinciples.com/ Principles of Service Orientation - http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1165286,00.html
| 
