Service Contract Components

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.

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 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. 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.

First Page: Standardized Service Contract