The principles of service-orientation part 4 of 6: Service discoverability and composition [by Thomas Erl]
2006-06-01 15:17
519 查看
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. In parts 2 and 3 of this series we discussed how 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 c
4000
ause of service-orientation.
What's next
Many of the principles we've covered so far are focused on the design and utilization of the service contract. Service statelessness and service autonomy, the two principles we'll describe in our next article, deal more with what's under the hood, in that they promote specific design characteristics of a service's underlying logic.
This article contains excerpts from "Service-Oriented Architecture: Concepts, Technology, and Design" by Thomas Erl (792 pages, Hardcover, ISBN: 0131858580, Prentice Hall/Pearson PTR, Copyright 2006). For more information, visit www.soabooks.com.
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 c
4000
ause of service-orientation.
What's next
Many of the principles we've covered so far are focused on the design and utilization of the service contract. Service statelessness and service autonomy, the two principles we'll describe in our next article, deal more with what's under the hood, in that they promote specific design characteristics of a service's underlying logic.
This article contains excerpts from "Service-Oriented Architecture: Concepts, Technology, and Design" by Thomas Erl (792 pages, Hardcover, ISBN: 0131858580, Prentice Hall/Pearson PTR, Copyright 2006). For more information, visit www.soabooks.com.
相关文章推荐
- Business analysis and SOA part 2 of 6: Business service models and the entity-centric business service [by Thomas Erl]
- The principles of service-orientation part 3 of 6: Service abstraction and reuse [by Thomas Erl]
- Business analysis and SOA part 4 of 6: SOA delivery lifecycle and the top-down approach [by Thomas Erl]
- The principles of service-orientation part 1 of 6: Introduction to service-orientation [by Thomas Erl]
- Business analysis and SOA part 1 of 6: The benefits of business services [by Thomas Erl]
- Business analysis and SOA part 3 of 6: Process-centric business services [by Thomas Erl]
- Development and remote installation of Java service for the Android Devices
- The Realization of Linked Select by JavaScript and XML
- The efficiency by combination of Apache and Tomcat~
- Installation failed with message...It is possible that this issue is resolved by uninstalling an existing version of the apk if it is present, and then re-installing.
- Step by Step Installation of the Subversion 1.x Server for Linux and Solaris 8/9/10 (English)
- Java Web编程入门--错误信息“The method getUserById(int) of type UserServiceImpl must override a superclass”
- 微软的ERP路线图 The Greening of Microsoft (BY Robert L. Mitchell, IDG News Service,09/03/2005 16:50:01)
- 1.4 Dynamically change the look of an application by using view states,transitions and effects
- [论文笔记] Gradual Removal of QoS Constraint Violations by Employing Recursive Bargaining Strategy for Optimizing Service Composition Execution Path (ICWS, 2009)
- UTL_HTTP Call a Web Service and Pass Parameters as Part of the URL
- Changes in behavior of the SysPrep and RIPREP tools after you install Windows XP Service Pack 2
- [论文笔记] Leveraging the crowd as a source of innovation Does crowdsourcing represent a new model for product and service innovation? (SIGMIS-CPR, 2012)
- 11g check the status of daemons and resource in standby rac
- [论文笔记] Quality-of-service oriented web service composition algorithm and planning architecture (JSS, 2008)