The popularity of Web services preceded that of service-oriented architecture (SOA). As a result, their initial use was primarily within traditional distributed solutions wherein they were most commonly used to facilitate point-to-point integration channels. As the maturity and adoption of Web services standards increased, so did the scope of their utilization.
With service-oriented computing comes a distinct architectural model that has been positioned by the vendor community as one that can fully leverage the open interoperability potential of Web services, especially when individual services are consistently shaped by service-orientation. For example, when exposing reusable logic as Web services, the reuse potential is significantly increased. Because service logic can now be accessed via a vendor-neutral communications framework, it becomes available to a wider range of service consumer programs.
Additionally, the fact that Web services provide a communications framework based on physically decoupled contracts allows each service contract to be fully standardized independently from its implementation. This facilitates a potentially high level of service abstraction while providing the opportunity to fully decouple the service from any proprietary implementation details. As explored in Part II, all of these characteristics are desirable when pursuing key principles, such as Standardized Service Contracts, Service Reusability, Service Loose Coupling, Service Abstraction, and Service Composability.
For example, transformation avoidance is a key goal of Standardized Service Contracts. As explained in Chapter 6, this principle advocates the standardization of the data model expressed by the service contract so as to increase intrinsic interoperability by reducing the need for transformation technologies. As illustrated in Figure 3.23, services delivered via disparate component platforms still require the transformation of technology regardless of whether data types are standardized. Services expressed through Web service contracts have the potential to avoid transformation altogether.
Figure 3.23 Three common data exchange scenarios demonstrating the effect of transformation avoidance.
Use the following table of contents to navigate to chapter excerpts.
SOA: Principles of Service Design
Home: Service-oriented computing and SOA: Introduction
1: Design fundamentals: Design characteristics
2: Design fundamentals: Design principles and design paradigm
3: Design fundamentals: Design pattern and design pattern language
4: Design fundamentals: Design standard
5: Design fundamentals: Best practices
6: Introduction to service-oriented computing
7: Service oriented architecture
8: Service compositions
9: Understanding service oriented computing elements
10: Entity services
11: Web services and service oriented computing
12: Service inventory blueprints
13: Service-oriented analysis and service modeling
14: Service-oriented design
15: Goals and benefits of service-oriented computing
16: Increased intrinsic interoperability
17: Increased federation
18: Increased vendor diversification options
19: Increased business and technology domain alignment
20: Increased ROI
21: Increased organizational agility
22: Reduced IT burden
|ABOUT THE BOOK:|
|SOA: Principles of Service Design is dedicated to service engineering and establishing service-orientation as a design paradigm. This hands-on manual for service design establishes concrete links between specific service-orientation design principles and the strategic goals and benefits associated with SOA. Purchase the book from Amazon.com.|
|ABOUT THE AUTHOR:|
|Thomas Erl is the world's top-selling SOA author, Series Editor of the "Prentice Hall Service-Oriented Computing Series and editor of The SOA Magazine. His books have become international bestsellers and have been formally endorsed by senior members of major software organizations such as IBM, Microsoft and Oracle. He is the founder of SOA Systems Inc., a company specializing in SOA training, certification and strategic consulting services with a vendor-agnostic focus.|
This was first published in February 2008