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]
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 service less of a reusable and a recomposable [3] resource and goes 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]
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.
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.
The term Web service (WS) is either:
Service-oriented architecture (SOA) is an architectural style that supports service orientation. By consequence, it is as well applied in the field of software design where services are provided to the other components by application components, through a communication protocol over a network. A service is a discrete unit of functionality that can be accessed remotely and acted upon and updated independently, such as retrieving a credit card statement online. SOA is also intended to be independent of vendors, products and technologies.
Representational state transfer (REST) is a software architectural style that was created to guide the design and development of the architecture for the World Wide Web. REST defines a set of constraints for how the architecture of an Internet-scale distributed hypermedia system, such as the Web, should behave. The REST architectural style emphasises the scalability of interactions between components, uniform interfaces, independent deployment of components, and the creation of a layered architecture to facilitate caching components to reduce user-perceived latency, enforce security, and encapsulate legacy systems. REST has been employed throughout the software industry and is a widely accepted set of guidelines for creating stateless, reliable web services.
The Schools Interoperability Framework, Systems Interoperability Framework (UK), or SIF, is a data-sharing open specification for academic institutions from kindergarten through workforce. This specification is being used primarily in the United States, Canada, the UK, Australia, and New Zealand; however, it is increasingly being implemented in India, and elsewhere.
The Windows Communication Foundation (WCF), previously known as Indigo, is a free and open-source runtime and a set of APIs in the .NET Framework for building connected, service-oriented applications.
In software architecture, a messaging pattern is an architectural pattern which describes how two different parts of an application, or different systems connect and communicate with each other. There are many aspects to the concept of messaging which can be divided in the following categories: hardware device messaging and software data exchange. Despite the difference in the context, both categories exhibit common traits for data exchange.
A mashup, in web development, is a web page or web application that uses content from more than one source to create a single new service displayed in a single graphical interface. For example, a user could combine the addresses and photographs of their library branches with a Google map to create a map mashup. The term implies easy, fast integration, frequently using open application programming interfaces and data sources to produce enriched results that were not necessarily the original reason for producing the raw source data. The term mashup originally comes from creating something by combining elements from two or more sources.
Component-based software engineering (CBSE), also called components-based development (CBD), is a branch of software engineering that emphasizes the separation of concerns with respect to the wide-ranging functionality available throughout a given software system. It is a reuse-based approach to defining, implementing and composing loosely coupled independent components into systems. This practice aims to bring about an equally wide-ranging degree of benefits in both the short-term and the long-term for the software itself and for organizations that sponsor such software.
Open service interface definitions (OSIDs) are programmatic interface specifications describing services. These interfaces are specified by the Open Knowledge Initiative (O.K.I.) to implement a service-oriented architecture (SOA) to achieve interoperability among applications across a varied base of underlying and changing technologies.
The Governance Interoperability Framework (GIF) is an open, standards-based specification and set of technologies that describes and promotes interoperability among components of a service-oriented architecture (SOA). GIF integrates SOA ecosystem technologies to achieve heterogeneous service lifecycle governance and is supported by Hewlett-Packard Company and by GIF partners.
Service-oriented architecture library (SOALIB) is used to distribute reusable service-oriented architecture (SOA) software in a manner similar to other computing libraries. SOA consists of loosely coupled interoperable services which use messaging based on both Simple Object Access Protocol (SOAP) and Representational State Transfer (REST). A library in computing is a set of compiled modules which are tested and ready for reuse. A similar concept is used for SOA, in that whatever technology is used to develop the service can also be distributed in library form. A Java-based SOA library may be distributed in Web ARchive (WAR) or Enterprise Archive (EAR) file formats. C, C++, and .NET applications may be distributed as a shared object, a Dynamic Link Library, or as an executable file.
Service-orientation design principles are proposed principles for developing the solution logic of services within service-oriented architectures (SOA).
In the domain of the service-orientation design paradigm, the Enterprise Inventory is a design pattern by Thomas Erl that answers the question, "How can services be delivered to maximize recomposition?"; the application of this pattern results in a standardized enterprise-wide service inventory that fosters repeated service composition.
The standardized service contract is a software design principle applied within the service-orientation design paradigm to guarantee that service contracts within a service inventory adhere to the same set of design standards. This facilitates standardized service contracts across the service inventory.
The service reusability principle is a design principle, applied within the service-orientation design paradigm, to create services that can be reused across a business. These reusable services are designed so that their solution logic is independent of any particular business process or technology.
Domain Inventory is a design pattern, applied within the service-orientation design paradigm, whose application enables creating pools of services, which correspond to different segments of the enterprise, instead of creating a single enterprise-wide pool of services. This design pattern is usually applied when it is not possible to create a single inventory of services for whole of the enterprise by following the same design standards across the different segments of the enterprise. The Domain Inventory Design pattern by Thomas Erl asks, "How can services be delivered to maximize recomposition when enterprise-wide standardization is not possible?" and is discussed as part of this podcast.
Service layer is an architectural pattern, applied within the service-orientation design paradigm, which aims to organize the services, within a service inventory, into a set of logical layers. Services that are categorized into a particular layer share functionality. This helps to reduce the conceptual overhead related to managing the service inventory, as the services belonging to the same layer address a smaller set of activities.
In software engineering, Canonical Schema is a design pattern, applied within the service-orientation design paradigm, which aims to reduce the need for performing data model transformation when services exchange messages that reference the same data model.
Utility abstraction is a design pattern, applied within the service-orientation design paradigm, which advocates designing services that provide cross-cutting non-business related functionality, which can be positioned as utility resources to automate multiple business processes.
The Accelerator is a collection of development solutions for IBM i and Windows platforms using .NET Framework, and/or LANSA, technologies provided by Surround Technologies. The Accelerator development architecture is a tool for building Windows and Web apps within a structured framework.