Content deleted Content added
→Rationale: "recomposable" is not a word in any dictionary. |
mNo edit summary |
||
| (One intermediate revision by one other user not shown) | |||
Line 2:
==Rationale==
Services developed by different project teams could be based on different communication mechanisms. As a result, a service inventory may end up having different sets of services, each conforming to a different set of protocols. When it comes to reusing services having different communication protocols, some sort of communication bridging mechanism is required. For example, services developed using [[Java Message Service|JMS]] messaging protocol are incompatible with services using [[.NET Remoting]], so in order to make use of these two types of services, some [[middleware]] technology needs to be in place that bridges the communication protocol disparity. Apart from incurring extra cost, the use of such a bridging technology adds [[Latency (engineering)|latency]] and communication overhead. This makes the services less of reusable and more difficult to compose,<ref name="SvcComposition">[http://www.whatissoa.com/p12.php Service Composition] {{webarchive |url=https://web.archive.org/web/20100311045214/http://www.whatissoa.com/p12.php |date=March 11, 2010 }}</ref>
In order to design a service inventory where all services are interoperable with each other so that they can be composed into different solutions, the application of the Canonical Protocol pattern dictates standardizing the communication protocols used by the services. When all services are using the same communication protocol, the requirement for a bridging technology is eliminated and the communication between services is more streamlined.<ref name='SODI'>Mauro. et al. [http://www.computer.org/portal/web/csdl/doi/10.1109/HICSS.2010.336 Service Oriented Device Integration - An Analysis of SOA Design Patterns.] [Online], pp.1-10, 2010 43rd Hawaii International Conference on System Sciences, 2010. Date accessed: 30 April 2010. {{webarchive |url=https://web.archive.org/web/20100328211319/http://www.computer.org/portal/web/csdl/doi/10.1109/HICSS.2010.336 |date=March 28, 2010 }}</ref>
Line 14:
The Canonical Protocol pattern by [[Thomas Erl]] answers the question: "How can services be designed to avoid protocol bridging?"<ref name="SOA Patterns.org">[http://www.soapatterns.org/canonical_protocol.php SOA Patterns - Canonical Protocol] {{webarchive |url=https://web.archive.org/web/20091214071205/http://www.soapatterns.org/canonical_protocol.php |date=December 14, 2009 }}</ref> The problem is that services that support different communication technologies compromise interoperability, limit the quantity of potential consumers, and introduce the need for undesirable protocol bridging measures. The solution is for the architecture to establish a single communications technology as the sole or primary medium by which services can interact. Therefore, the communication protocols (including protocol versions) used within a service inventory boundary are standardized for all services (see diagram).
One of the most mature and widely used communication mechanisms is provided by the Web services framework. Further to choosing a communication framework, the actual message protocols also need to be standardized upon. For example, whether web services are built using [[SOAP]] over [[HTTP]] or by simply using [[RESTful]] services. Similarly, when standardizing on SOAP
==Considerations==
| |||