Aspects of a service

Services have the following aspects: a service implementation, elementary access details, and a contract.

Service implementation

A service implementation is the core business logic, which you might write in EGL or in any other programming language. The terms “service” and “service implementation” are often used interchangeably; service implementation is used when the focus is on the details of the business logic.

Elementary access details

Elementary access details include the location, which is the address of the service implementation, and the binding, which identifies the protocol that formats a message at the start of transmission and unformats the message at the end of transmission. For Web services, the protocol is Hypertext Transfer Protocol (HTTP). Formatting occurs when the invocation message originates at the requester; unformatting occurs when the message arrives at the service location. Formatting also occurs if the service issues a response; in that case, unformatting occurs when the response arrives at the requester.

The location of a service is set when the service is deployed. The requester detects the location in the following ways:
  • You can embed the details on service location in the business logic of the requester, but this usage is inflexible. If the service location changes, you must recompile and redeploy the requester.
  • In most cases, the service location details are provided by configuration files at the site where the requester is deployed. This usage is more flexible because the configuration files can change during the years when the requester is in use, and the requester can access the service even if the service is deployed to a new location.
  • In some cases, location details are passed to the requester at run time or the message is redirected by the SOA runtime software. These usages are flexible but add complexity that is not required for most purposes.

Contact

A contract describes the intended behavior of a service and is independent of the implementation details. A contract has two elements: a service interface and a Quality of Service.

The service interface includes a description of the data that can pass between a requester and a service and details about each operation that the service provides. The interface includes information about the messages and answers questions such as “What is the format of a message (for example, two strings and an integer)?” and “What are the restrictions on content?” The interface also includes details about the message exchange pattern, which indicates how the requester and service interact. The interface indicates whether the service always responds to the requester.

Some aspects of the service interface are implicit in the service interface. For example, a service might provide a stock quote but return an error message if the submitted stock symbol is invalid.

An interface is an aspect not only of a service but also of a high-level design for the service. Typically, the interface precedes the implementation and is said to implement the interface.

The second part of the contract is the Quality of Service (QoS), which is a set of interaction rules that go beyond those implied by either the elementary access details or the service interface. QoS includes the following issues:
  • Reliability: for example, what percentage of time is a service promised to be available?
  • Security: for example, what ensures that a specified requester is authorized to access a specified service?
  • Coordination: for example, can the service revise database changes that were made but not committed (made permanent) by the requester?
  • Runtime update of message content or destination: for example, can a message be reformatted at run time to allow transmission to a computer that uses a different protocol?

Notice

In this topic, most of the material about services is from Enterprise Web 2.0 with EGL (MC Press, 2009; http://www.mc-store.com/5107.html).


Feedback