The public review of the manuscript for "SOA Design Patterns" has concluded !
Thank you to all that participated. 234 reviews were received and over 30 new patterns have been contributed, increasing the size of this book by over 50%. The second draft of the manuscript is currently in development.
SOA Design Patterns by Thomas Erl
For more information visit: www.soapatterns.com
Related Publications
Read the article "Introducing SOA Design Patterns" from the June 2008 SOA World Magazine (High-Res PDF).
PLEASE NOTE
The content on this page is from the first draft of the manuscript for the upcoming book "SOA Design Patterns" by Thomas Erl. This version of the manuscript was authored in September, 2007. Since then, the manuscript has undergone significant content and structural changes as a result of an industry-wide review in which hundreds of SOA practitioners participated in addition to SOA vendors and experts from the design patterns community.
You are welcome to use the information on this page for research purposes, but you should assume that most of it will change in the final release of the "SOA Design Patterns" book.
Note also, that as a result of an industry-wide call for participation from December 2007 to February 2008, over 30 new design patterns have been contributed to this book. As they become finalized and are incorporated by the author, concise descriptions will be published on this site, and full descriptions with examples will be made available in the final, printed book.
Due to the volume of new content and changes, the release of the "SOA Design Patterns" book has been postponed to October, 2008. To learn more about the book, visit www.soapatterns.com. To be notified of updates to this site, use the notification form.
Chapter 5: Basic Service Inventory Design Pattern Language
How can services be designed to avoid protocol
bridging?
Problem
Services that support
different communication technologies compromise interoperability, limit the
quantity of potential consumers, and introduce the need for undesirable
protocol bridging measures.
Solution
The architecture
establishes a single communications technology as the sole or primary medium
by which services can interact.
Application
The communication protocols
(including protocol versions) used within a service inventory boundary are
standardized for all services.
Impacts
An inventory architecture in
which communication protocols are standardized is subject to any limitations
imposed by the communication technology.
Table 5.10 – Profile summary for the Canonical Protocol pattern.
Problem
Each service exists as a standalone software program. When
these programs need to exchange information, they have to form a connection
using a communications technology. When programs are designed to use different
communications technologies, they are incompatible and cannot exchange
information without involving a separate program that can translate one
communications technology to another (as per the Protocol Bridging pattern).
Building services with different implementation technologies
is not uncommon, but allowing services based on different communication
technologies to exist within the same architecture can result in some severe
limitations. For example, groups of services based on the same communication
framework are likely to be delivered as part of the same project. The day any
of these services needs to be pulled into a new composition consisting of
services delivered by a different project (and using different communication
protocols), incompatibility issues could make their connectivity and reuse
challenging and perhaps impossible.
Figure 5.42 – Different groups of services (likely
delivered via different projects) establish communication boundaries through
the use of incompatible communication protocols.
Solution
The technology architecture is designed to limit enablement
of cross-service interaction to a single or primary communications protocol or
protocol version. This guarantees technological compatibility across services.
Figure 5.43 – Though still delivered by different
projects via different vendor platforms, these services conform to one
centralized communications technology, making them technologically compatible.
Note:
This design pattern advocates the standardization of protocols used for
inter-service communication only. Traditional protocols, such as those used to
communicate with proprietary components or databases are not affected by this
pattern as long as they remain part of the logic encapsulated by services.
Application
To ensure that all services an inventory architecture is
intended to support can effectively interact and be repeatedly recomposed
requires that a centralized communications technology be carefully chosen.
The most common communications framework that fulfills this
role is the Web services platform because it establishes an XML-based protocol
that is widely supported, yet still vendor-agnostic. However, even when using
Web services, this design standardization pattern must still be applied to
overcome possible protocol disparity resulting from the mismatch of protocol-related
versions. For example, the WS-I Basic Profile is likely to be a key part of
applying this pattern as a means of ensuring technological compatibility among
the various versions of Web services technology standards.
Alternative communication option that can also be explored
within controlled environments. For example, less vendor-agnostic protocols can
be chosen, as long as all services within an inventory are standardized to conform
to their use.
Note: When
applying this design pattern to Web services, any Web services-related industry
standards and technologies associated with inter-service communication are
affected. This can include WSDL, XML Schema, SOAP, WS-Policy, and various WS-*
standards. This pattern does not dictate how these technologies are applied, only
that their use – and, in particular, their version – are
standardized.
For example, this design
pattern is not concerned with the data model established by a Web service
contractÕs XML schema or the content of a contractÕs WS-Policy assertions. It
is focused on the requirement that all services are, in fact, using XML schema
and WS-Policy to express their data models and policies and that services use
the same versions of these industry standards. The Canonical Data Model and Canonical
Policy Standardization patterns are focused on
Figure 5.44 – All parts of the Web service contract are
affected by this design pattern.
Impacts
A key consideration of standardizing on one communications
protocol is the longevity of the protocol technology. If there are any concerns
that vendors may discontinue or abandon the technology, the associated risks
would need to be taken into account.
Whichever protocol is chosen, service interaction throughout
the resulting technology architecture will be constrained by whatever
limitations this framework imposes. Therefore, the maturity and overall
adequacy of the communications technology must be carefully assessed.
Note: This
design pattern could be considered a specialized implementation of the Canonical
Resources pattern in that it is very much about standardizing technology across
an inventory. However, it is singled out here because a communication protocol more than just an architectural
extension. It represents the fundamental means by which all parts of a
distributed solution work together and therefore is a part of the architecture
that deserves special attention.
Relationships
The Canonical Protocol patternÕs architectural focus
naturally results in relationships with other architecture-centric design
patterns, such as Vendor-Agnostic Context, Canonical Resources, and the
Enterprise Inventory and Domain Inventory patterns.
However, perhaps the most important relationships this
pattern has is with Service Messaging and Messaging Metadata. By standardizing
the medium by which services exchange business and activity data, a foundation
for service interoperability is established. This then directly supports
Capability Recomposition.
Figure 5.45 – The Canonical Protocol pattern proposes
an inventory-wide design standard that solves foundational interoperability issues.
Case Study Example
Case study content is not available on this Web site.
