Canonical protocol pattern: Difference between revisions
Added citation |
m v2.05b - Bot T20 CW#61 - Fix errors for CW project (Reference before punctuation) |
||
| (27 intermediate revisions by 21 users not shown) | |||
| Line 1: | Line 1: | ||
'''Canonical Protocol''' is a [[ |
'''Canonical Protocol''' is a [[Design pattern (computer science)|design pattern]], applied within the [[service-orientation]] [[design paradigm]], which attempts to make [[Service (systems architecture)|services]], within a service inventory,<ref name='SI'>[http://www.whatissoa.com/p13.php Service Inventory] {{webarchive |url=https://web.archive.org/web/20100313072247/http://www.whatissoa.com/p13.php |date=March 13, 2010 }}</ref> interoperable with each other by standardizing the [[communication protocol]]s used by the services. This eliminates the need for bridging communication protocols when services use different communication protocols.<ref name='MD'>Matthew Dailey.[http://www.cs.ait.ac.th/~mdailey/courseware/index.php?action=getlecture&course_id=37&lecture_id=6 Software Architecture Design Service Oriented Architectures (Part II)] {{Webarchive|url=https://web.archive.org/web/20110724191904/http://www.cs.ait.ac.th/~mdailey/courseware/index.php?action=getlecture&course_id=37&lecture_id=6 |date=2011-07-24 }}[Online].Date accessed: 25 April 2010.</ref> |
||
==Rationale== |
==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 [[ |
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> going against the guidelines of the [[Service Composability Principle|Service Composability]] design principle. |
||
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. |
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> |
||
==Usage== |
==Usage== |
||
| ⚫ | |||
| ⚫ | |||
| ⚫ | The application of this design pattern requires choosing a technology architecture that provides a common communication framework so that all services in an inventory can communicate with each other using the same communication protocol. This depends upon how the services within a service inventory are going to be used. If the services are only going to be part of service compositions that always use a particular communication protocol (because of efficiency and security reasons), then all the services within that service inventory can be built upon such a communication protocol even if it is not the most widely used protocol. |
||
| ⚫ | |||
| ⚫ | 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 [[ |
||
| ⚫ | |||
| ⚫ | The application of this design pattern requires choosing a technology architecture that provides a common communication framework so that all services in an inventory can communicate with each other using the same communication protocol. This depends upon how the services within a service inventory are going to be used. If the services are only going to be part of service compositions that always use a particular communication protocol (because of efficiency and security reasons), then all the services within that service inventory can be built upon such a communication protocol even if it is not the most widely used protocol. |
||
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 based web services, the specific version of SOAP protocol needs to be agreed upon as well i.e. SOAP v 1.1 or SOAP v 1.2. |
||
==Considerations== |
==Considerations== |
||
| Line 17: | Line 20: | ||
In order to standardize on a communication protocol, the features of the protocol need to be compared against the service interaction requirements including security, efficiency and transaction support. In case of web services, for example, if a service composition requires explicit transaction support, then SOAP over HTTP would be a better choice than using RESTful services. |
In order to standardize on a communication protocol, the features of the protocol need to be compared against the service interaction requirements including security, efficiency and transaction support. In case of web services, for example, if a service composition requires explicit transaction support, then SOAP over HTTP would be a better choice than using RESTful services. |
||
In some cases, depending upon the technology used to build the service, it may be possible to support two different set of protocols in order to make the service accessible to different types of service consumers(Dual Protocols design pattern<ref name='DP'>[http://www.soapatterns.org/dual_protocols.php Dual Protocols design pattern]</ref>). For example, using [[ |
In some cases, depending upon the technology used to build the service, it may be possible to support two different set of protocols in order to make the service accessible to different types of service consumers (Dual Protocols design pattern<ref name='DP'>[http://www.soapatterns.org/dual_protocols.php Dual Protocols design pattern] {{webarchive |url=https://web.archive.org/web/20091214065529/http://www.soapatterns.org/dual_protocols.php |date=December 14, 2009 }}</ref>). For example, using [[Windows Communication Foundation|WCF]], the same service can be configured to use HTTP and [[TCP/IP]] protocols at the same time. |
||
When choosing a communication framework, the maturity, scalability and any licensing costs need to be taken into account as building services using a protocol that is going to become obsolete in the near future will impact the reusability of such services and would require considerable time and efforts in order to redesign the service. |
When choosing a communication framework, the maturity, scalability and any licensing costs need to be taken into account as building services using a protocol that is going to become obsolete in the near future will impact the reusability of such services and would require considerable time and efforts in order to redesign the service. |
||
== References == |
== References == |
||
;Notes |
|||
{{Reflist}} |
{{Reflist}} |
||
;Sources |
|||
* Erl et al,(2009).[http://www.amazon.com/gp/product/0136135161/ref=s9_simi_gw_p14_i1?pf_rd_m=ATVPDKIKX0DER&pf_rd_s=center-1&pf_rd_r=0FBSA23BKC0AXWVZ5Q9G&pf_rd_t=101&pf_rd_p=51471022&pf_rd_i=507846 SOA Design Patterns]. Prentice Hall. ISBN 0136135161. |
|||
* [[Thomas Erl]] et al., (2009).[https://www.amazon.com/dp/90136135161 SOA Design Patterns]. Prentice Hall. {{ISBN|978-0-13-613516-6}}. |
|||
== External links == |
== External links == |
||
* [http://www.whatissoa.com/ SOA Concepts] |
* [https://web.archive.org/web/20100312202708/http://www.whatissoa.com/ SOA Concepts] |
||
* [http://www.soaglossary.com/ SOA Terms Glossary] |
* [http://www.soaglossary.com/ SOA Terms Glossary] |
||
* [http://www.soapatterns.org SOA Design Patterns] |
* [http://www.soapatterns.org SOA Design Patterns] |
||
[[Category:Service-oriented (business computing)]] |
[[Category:Service-oriented (business computing)]] |
||
Latest revision as of 04:27, 9 December 2024
Canonical Protocol is a design pattern, applied within the service-orientation design paradigm, which attempts to make services, within a service inventory,[1] interoperable with each other by standardizing the communication protocols used by the services. This eliminates the need for bridging communication protocols when services use different communication protocols.[2]
Rationale
[edit]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 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 and communication overhead. This makes the services less of reusable and more difficult to compose,[3] going against the guidelines of the Service Composability design principle.
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.[4]
Usage
[edit]
Services developed using different communication protocols are unable to talk to each other.
Services developed using the same communication protocols are able to talk to each other and hence can be used in multiple service compositions.
The application of this design pattern requires choosing a technology architecture that provides a common communication framework so that all services in an inventory can communicate with each other using the same communication protocol. This depends upon how the services within a service inventory are going to be used. If the services are only going to be part of service compositions that always use a particular communication protocol (because of efficiency and security reasons), then all the services within that service inventory can be built upon such a communication protocol even if it is not the most widely used protocol.
The Canonical Protocol pattern by Thomas Erl answers the question: "How can services be designed to avoid protocol bridging?"[5] 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 based web services, the specific version of SOAP protocol needs to be agreed upon as well i.e. SOAP v 1.1 or SOAP v 1.2.
Considerations
[edit]In order to standardize on a communication protocol, the features of the protocol need to be compared against the service interaction requirements including security, efficiency and transaction support. In case of web services, for example, if a service composition requires explicit transaction support, then SOAP over HTTP would be a better choice than using RESTful services.
In some cases, depending upon the technology used to build the service, it may be possible to support two different set of protocols in order to make the service accessible to different types of service consumers (Dual Protocols design pattern[6]). For example, using WCF, the same service can be configured to use HTTP and TCP/IP protocols at the same time.
When choosing a communication framework, the maturity, scalability and any licensing costs need to be taken into account as building services using a protocol that is going to become obsolete in the near future will impact the reusability of such services and would require considerable time and efforts in order to redesign the service.
References
[edit]- Notes
- ^ Service Inventory Archived March 13, 2010, at the Wayback Machine
- ^ Matthew Dailey.Software Architecture Design Service Oriented Architectures (Part II) Archived 2011-07-24 at the Wayback Machine[Online].Date accessed: 25 April 2010.
- ^ Service Composition Archived March 11, 2010, at the Wayback Machine
- ^ Mauro. et al. 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. Archived March 28, 2010, at the Wayback Machine
- ^ SOA Patterns - Canonical Protocol Archived December 14, 2009, at the Wayback Machine
- ^ Dual Protocols design pattern Archived December 14, 2009, at the Wayback Machine
- Sources
- Thomas Erl et al., (2009).SOA Design Patterns. Prentice Hall. ISBN 978-0-13-613516-6.