Standardized Service Contract

Standardized service contracts are one of the key Service Oriented Architecture principles. They ensure that services that are in the same inventory of services are kept in compliance with contract design standards. The services in a Service Oriented Architecture are able to delineate their capabilities and overall purpose in the form of a service contract.

The standardized service contract principle basically requires that specific considerations be taken in to account when a service’s public technical interface is being designed. It simultaneously assesses the nature and quantity of content that shall be published as part of the service’s official contract. A lot of emphasis tends to be placed on particular components of service design. This includes the way that the services express their functionality, how policies are to be attached and asserted, as well as the way in which data types and models are to be defined.

A constant focus on ensuring the optimization of service contracts should be maintained. The service contract should also maintain granularity and be standardized in a way that ensures that endpoints established by services shall be governable, consistent, and reliable.

A service contract is an attribute of service oriented architecture that stipulates services in the form of a communications agreement that will be defined collectively by one or several service description documents. The modeling and design methods for Service Oriented Architecture applications has become known under the terms Service Oriented Analysis and Design and / or SOAD.

Service Oriented Analysis and Design is a method for the development of completely agile systems in a consumer producer model that will abstract implementation from processes, allowing that a service provider may be changed or modified without having any affect whatsoever on the consumer.

Simple Object Access Protocol, or SOAP based web services have evolved as the most common SOA implementation. There are, however, non-web service implementations that exist that provide similar benefits. Service Oriented Architecture’s protocol independence thus means that consumers can communicate with the service in a variety of ways.

Simple Object Access Protocol is a protocol for the exchange of XML based messages over computer networks. This is normally accomplished via the use of HTTP or HTTPS. Simple Object Access Protocol forms the basis of the web services stack. It provides a basic messaging framework that allows for more abstract layer to be built on.

There are many different kinds of messaging patterns within Simple Object Access Protocol. The most common one, however, is the Remote Procedure Call pattern. This enables one network node, known as the client, to send a request message to another node, called the server.

The server then immediately sends back a response message to the client. Simple Object Access Protocol is the XML RPC successor. Although it should be noted that Simple Object Access Protocol borrows its interaction and transport neutrality as well as its envelope from elsewhere, most likely from WDDX. Dave Winer, Mohsen Al Ghosein, Don Box, and Bob Atkinson first designed simple Object Access Protocol in the year 1998. It was backed by Microsoft, where Al Ghosein and Atkinson were employed at the time.

Simple Object Access Protocol was developed as an object access protocol. Currently, the Simple Object Access Protocol specification is maintained by the XML Protocol Working Group, a division of the World Wide Web Consortium. SOAP utilizes a web application layer protocol as a transport protocol. Some critics feel that this is an abuse of protocols, as this is not their designated purpose and thus they do not fulfill their role in a very proper fashion.

But supporters of Simple Object Access Protocol have made analogies to the successful utilization of protocols at other levels for the tunneling of other protocols. HTTP and SMTP are both valid application layer protocols utilized as Simple Object Access Protocol transport. The difference is that HTTP has gained a lot more acceptance owing to the fact that it works quite well with today’s World Wide Web infrastructure.

Simple Object Access Protocol, on the other hand, functions quite well with network firewalls. Simple Object Access Protocol can also be utilized through HTTPS, as it is the exact same protocol as HTTP at the level of application, only it utilizes an encrypted transport protocol underneath.

XML has been selected as the standard message format owing to its widespread utilization by a lot of big companies as well as open source development efforts. Moreover, there are a wide variety of freely available tools that can help ease the transition to a Simple Object Access Protocol based implementation.

Service Contract Components

A service contract should have the components below:

Header
- Name
- Version
- Owner
- RACI
  - Responsible
  - Accountable
  - Consulted
  - Informed
- Type – The type identifies the sort of service being employed. It aids in making distinct the layer that it resides in. Depending on what the implementation is, it will have a service type according to that. Service type examples may include process, integration, business, data, and presentation.
Functional
- Service Operations
- Invocation. Examples of the invocation might include REST, events triggers, and SOAP (see below for more on SOAP.)
Non Functional
- Security Constraints – The security constraints define who is capable of executing a service in terms of the individual partners or roles, as well as which invocation mechanism they are allowed to invoke.
- Quality of Service – The Quality of Service determines how high the allowable failure rate shall be.
- Transactional – The Transactional level determines whether the non-functional part will be capable of acting as part of a larger transaction. If so, then how will this be controlled?
- Service Level Agreement – The Service Level Agreement determines how much latency the service shall be allowed to have when it is performing its tasks.
- Semantics – The Semantics level designates the meaning of the terms utilized in the interfaces and descriptions of the service.
- Process – The Process component describes what the process is, if any exists, of the service that has been contracted.

SOAP

Simple Object Access Protocol is the XML RPC successor. Although it should be noted that Simple Object Access Protocol borrows its interaction and transport neutrality as well as its envelope from elsewhere, most likely from WDDX.

Dave Winer, Mohsen Al Ghosein, Don Box, and Bob Atkinson first designed simple Object Access Protocol in the year 1998. It was backed by Microsoft, where Al Ghosein and Atkinson were employed at the time.

SOAP utilizes a web application layer protocol as a transport protocol. Some critics feel that this is an abuse of protocols, as this is not their designated purpose and thus they do not fulfill their role in a very proper fashion. But supporters of Simple Object Access Protocol have made analogies to the successful utilization of protocols at other levels for the tunneling of other protocols.

HTTP and SMTP are both valid application layer protocols utilized as Simple Object Access Protocol transport. The difference is that HTTP has gained a lot more acceptance owing to the fact that it works quite well with today’s World Wide Web infrastructure. Simple Object Access Protocol, on the other hand, functions quite well with network firewalls. Simple Object Access Protocol can also be utilized through HTTPS, as it is the exact same protocol as HTTP at the level of application, only it utilizes an encrypted transport protocol underneath.

XML has been selected as the standard message format owing to its widespread utilization by a lot of big companies as well as open source development efforts. What is more, there are a wide variety of freely available tools that can help ease the transition to a Simple Object Access Protocol based implementation.

Standardized Service Contract