Service Orientation in Enterprise Computing
Mike Burner
Microsoft Corporation
July 2005
Applies to:
Service Oriented Architecture (SOA)
Summary: Discussions of service oriented architecture are all too often exercises in miscommunication. At least two very distinct perspectives on SOA have emerged—that of the developer building enterprise solutions, and that of the portfolio manager tracking the effectiveness of the organization's IT assets. This brief article attempts to disambiguate these perspectives to allow development and operations to work more effectively together. (5 printed pages)
Contents
Introduction
SO Versus SOE
Business Benefits
Service Design
Support for Services
Conclusion
Introduction
Imagine you are a baker talking to a baked goods distributor. To you, the bread business is about getting the right ingredients, tracking rising times, and ensuring consistent quality of your product. The distributor takes all that for granted; she cares about packaging, delivery schedules, and shelf placement. The two of you sort of use the same language, but somehow the word "loaf" has different connotations for you and her.
Discussions of service oriented architecture (SOA) tend to follow this unfortunate pattern. Depending on your perspective—that of a developer or that of a technology portfolio manager—you each have mostly-compatible but disturbingly divergent conceptions of SOA. You both agree you can make bread with it, but your bread is judged by its utility and hers is judged by its role in the product line.
SO Versus SOE
In an attempt to resolve this tendency towards miscommunication, let us refer to the portfolio manager's perspective as the service oriented enterprise (SOE), and the development perspective as service orientation (SO).
There is some skepticism among technologists towards the term "SOA." It is sometimes depicted as used to mean just about anything, and has therefore lost any real meaning. While the term has been abused by some vendors trying to jump on the buzzword bandwagon, much of the resistance to the term arises from the confusion between SO and SOE.
The point of convergence between these perspectives we will term the service model. The service model is a set of standards and guidelines for how messages may be routed between technology assets to form solutions that achieve business benefit. An asset whose interfaces comply with the model is termed a service. While services may be exposed and consumed using a variety of service models, recent investments by the global technology community in XML, SOAP, and related Web services standards suggest that strong preference should be given to a model that builds on that foundation.
From the solution perspective, SO is a set of patterns and practices for developing individual services and solutions that leverage the service model to permit integration across diverse systems. A service encapsulates the idiosyncrasies of its operating system and proprietary protocols, permitting access to its business logic and information using standard protocols and highly conventional interfaces. Behind the stable interfaces, implementations may be continuously evolved and improved without adversely affecting solutions that consume the service.
From the portfolio perspective, the service-oriented enterprise is an approach to factoring, integrating, and managing an organization's technology portfolio that employs the service model as the basis for developing and operating distributed business systems. It extends the "universal" service model with a set of organizational standards that focus on reusability, consistent message handling, and the delivery of the operational (also called non-functional) requirements of the organization's service and solution portfolio. Service by service and solution by solution, the organization builds its technology portfolio. An effective SOE effort guides this incremental development to create a platform-independent solution framework that makes subsequent development faster and more consistently manageable.
Keeping in mind the interests of both developers and portfolio managers, Microsoft is committed to developing the standards, guidance, tools, and technology needed for developing cross-platform service oriented solutions using Web services.
Business Benefits
The business benefits of SO begin with more effective integration—integration across business systems, integration across workgroups, integration across geographically distributed subsidiaries, and integration across value chains. SO permits managed, rational access to mission-critical information and capabilities, eliminating the need for human gatekeepers and clerks to manually protect and broker these resources. SO leads to the development of more dynamic solutions—solutions that more completely link the actors in a business process and that more effectively respond to the context of the business process instance.
The service-oriented enterprise can deliver the additional business benefit of rationalizing the organizational technology portfolio. The decomposition and modeling of business processes can identify redundancies and gaps in your support for business automation. This disentanglement of business capabilities can enable sensible sourcing decisions, such as moving aspects of inventory management to a logistics supplier. The resulting alignment between services and business capabilities can clarify business ownership of technology assets, fostering better portfolio maintenance over time.
The scope of an organization's service architecture is defined by business need, and may be expanded as those needs evolve. Most organizations can identify a few key business processes for which reengineering along the principles of SO make good economic sense (especially to achieve better integration across a complex value chain). Many organizations will choose SO as the basis for new development, and will use façade services to provide access to existing systems on an as-needed basis. A few organizations will see business value in aggressively re-architecting their entire technology portfolio, but a more incremental approach is possible and typical.
Service Design
Another point of contention is the degree to which SO replaces object orientation (OO). In a real sense, SO is an evolution of distributed object technologies, but SO does not (yet?) replace OO for local manipulation. In fact, most service provision and consumption is coded using object models and OO best practices. When designing services and service consumption, however, the developer must step outside of OO practices to consider the goals and costs of the service invocation.
A "contract-first" approach should be used for service design. The service provider should focus on the messages that the service will accept and produce, paying attention to the platform-independence of the message schemas, and the composition of those messages from formal and de facto standard elements. The object model used by the service developer should derive from the service contract, not the other way around. Services should offer consumers a logical "business" interface (such as ValidateAddress), that delivers sufficient value to justify the cost of invocation (which is high on the public Internet but may be lower on private networks). A reference starting point for guidance on service design is Don Box's paper describing the four tenets of service orientation.
There are several key considerations that must be addressed when consuming services, either in solutions or in intermediate value-added services. Foremost among these is considering the cost of service invocation and making appropriate sourcing decisions. It is clearly a poor choice to use a remote service to perform simple integer arithmetic. When multiple services offer varying service granularities over similar capabilities, consider both the contracts and service level agreements they offer (for instance, choosing between a service that can return the current value of one security versus a service that can return a list of values in a single call). Developers should employ asynchronous communication to support reliable message delivery and to cope with indeterminate latency. Latency may be extreme in solutions that orchestrate the sequenced contributions of a group of people.
Each well-designed service and service-oriented solution becomes part of the organization's technology portfolio, components in the service-oriented enterprise. The hallmarks of a successful SOE are rigorous service factoring, a thorough, forward-looking integration strategy, and a common, coherent approach to the management and governance of services and solutions.
Services should be factored for optimal exploitation by the solution portfolio. Usually this means achieving the highest possible level of reuse. A favored approach to factoring services is to align them with the component steps of the organization's business processes—decomposing to the finest granularity required by any business process, and providing aggregated services to support common access patterns of coarser granularity. If a bank has twenty-two applications that need to score consumer credit, the ScoreConsumerCredit service should be designed to support all twenty-two. Multiple implementations of the same business capability introduce business irregularities, increase maintenance requirements as business rules evolve, and raise the cost of doing business in the long term. Factoring for reuse can be tricky, including considerations of context-sensitivity (ScoreConsumerCredit may have different requirements depending on the geographical context of the transaction) and "service inheritance," where one service extends the contract and business value of a second service. When designing new services, research existing business component models for guidance. Expect to refactor and version deployed services over time.
The service architecture's integration strategy should seek to support access to the broadest possible collection of technology assets. The more assets that are incorporated into the service model, the more solutions can be built on top of it. A popular implementation approach is to leverage the integration investment represented in commercial message bus technologies. Message buses generally employ a "pluggable" approach to communicating with diverse specialized systems, and typically offer a collection of off-the-shelf connectors for the more common of such systems.
Consistency of access includes consistent approaches to configuration, exception handling, and statistics gathering. The service architecture should specify a set of interfaces and standard procedures that must be implemented by all services to support the manageability and governance of both the services and (where applicable) the underlying business systems. To permit the incorporation of vendor-supplied services into the organization's service portfolio, organizational management standards should comply as closely as possible with standards supported by the relevant vendors.
Support for Services
An effective SOE requires a coherent strategy for the run-time support of this well-factored, well-integrated, well-managed service and solution portfolio. Key infrastructure requirements of a service architecture include (but are not limited to):
- Identity and role management—To map organizational and extra-organizational value chain participants to auditable identities, and optionally to map those to named roles for purposes of improved authorization management.
- A messaging pipeline—To provide consistent support for, and management of, messages being routed between solutions and services, including the enforcement of security policies.
- An entity model—A well-factored portfolio of XML schemas that describe the business entities to be manipulated by the services and solutions.
- A discovery strategy—For both service interfaces and entity definitions, usually supported by a directory or indexed repository.
- An eventing engine—For routing exceptions and status messages.
A source of ongoing debate revolves around where the service architecture ends and the solution portfolio begins. SO, for example, is not prescriptive about process orchestration: several valid approaches may be used to create and manage process instances that invoke services to achieve business value.
Conclusion
Microsoft sees service orientation as an effective means to the real end: creating dynamic connected systems that link employees to business processes, and businesses to value chains. For a more thorough discussion of the benefits, challenges, technologies, and best practices of service orientation, please refer to Service Orientation and Its Role in Your Connected Systems Strategy.
Không có nhận xét nào:
Đăng nhận xét