A service may be defined as an implementation of a well-defined, self-contained, and independent business functionality that has the capability of accepting one or multiple requests, and returning one or multiple responses using a well-defined standard interface. A service is independent of the technology on which it is implemented; so the interface to the service should be platform independent. A service should also have the capability to be discovered dynamically and called at runtime. A service provides business functions as service operations to the service consumer.

A service is a unit of design, implementation, and deployment artifact that is used for implementation of enterprise architectures. A service is defined using a verb. For example, validate a customer's credentials; this describes the business function it implements. A service implementation defines a service interface in either an RPC style or a messaging style. Although the former uses service invocation techniques, the latter executes a service operation as defined in the service semantics.

The service provider is a network-addressable entity that provides the service. Note that in SOA, a service provider can also be a service consumer.

The service consumer is the entity that consumes (or uses) the services provided by the service provider by locating the service in the service registry, binding to the service, and then executing the service methods. A service consumer is also known as the service client or simply the client.

The service registry is a network-based repository of published services. At runtime, this registry is used by the service consumers to locate a service and bind to it. The advantages of using a service registry includes:

The service contract is a specification that denotes how the service consumer would interact with the service provider for a particular service. The following figure illustrates the relationship between service contract and its implementation

Relationship between service contract and service implementation

The service proxy is a reference to the service at the service consumer's end—it is provided by the service provider to facilitate the service method calls. A service consumer or service client uses this proxy to invoke one or more service methods.

The service lease is a predefined duration that denotes the lifetime of a service. This implies a time after which the service would no longer be valid. Note that, as and when this time period elapses, the service consumer should request the service registry to grant a fresh, new service lease so that the service consumer can regain access to the service and execute the service methods.

Service providers and service consumers communicate through messages. So, messages are the medium of communication between service providers (that is, the providers of the services) and service consumers (that is, the consumers of the services). Note that such messages are essentially made available in a predefined XML format. In addition to the XML format, it can also be in the JSON format or any other format upon which both the service provider and consumer mutually agreed upon. The figure given below shows that a service communicates with another through the usage of messages

Services communicate with one another using message exchanges

The service description is a specification that contains the information that is necessary to invoke a service. Such information may include the parameters, the constraints, and the policies that define how the service should be invoked.

Advertising and discovery are two of the most essential properties in SOA. Although the former relates to the capability of a service to publish its description so as to be located by the service consumers, the latter relates to the capability of the service consumers to discover the published services from the service registry and then invoke them as (and when) necessary.

Call-based distributed systems have one of the following architectural styles:

Object Oriented Architectures deal with object instances, and communications are implicitly stateful. State information is stored on the server side. Each access to an object instance involves a round trip communication.

SOAs revolve around a service and the endpoint it exposes. SOAs are stateless and scalable easily because of their stateless nature. The REST architectural paradigm treats all entities in the world as connected resources and re-uses the existing HTTP infrastructure. The ability to cache requests, ability to perform stateless interactions, scalability, simplicity, agility, and flexibility are some of the benefits of this architecture. However, lack of references, lack of tools support, and lack of a proper standardization are the disadvantages of this architecture.

A service does have an interface, and can be referenced during its lifetime. It doesn't necessarily have a state. Each service has an interface description that defines the message and payload formats. A service can be discovered and dynamically bound. It is modular, self-contained, interoperable, addressable, and locatable via a network. A service can also be composed of other services. The following figure illustrates the relationship between service consumer, service provider, and a service broker.

Relation between service provider, service consumer, and service broker

Services are made available to the clients (service consumers) by publishing the services in a repository named Service Broker (Registry). The Service Consumer (service client) locates the service, uses a service proxy, and then invokes one or more service methods using the service proxy instance The following figure shows how a service consumer talks to the service registry.

The service consumer talks to the service registry and the service provider using a service proxy

ROAs are stateless, and revolve around a resource. Each resource is identified using a URI. You can always have multiple copies of the same resource. In Resource Oriented Architecture, requests are usually stateless: there is no link among one request and the next. Resource lifecycle is managed using verbs, that is, HTTP, PUT, HTTP, DELETE, and so on.

REST services are easier to implement than SOAP-based SOA. Also, REST services provide a support for better caching, lightweight requests and responses, and reduced network traffic.

REST constraints are design rules applied to the REST architectural style. We will explore more on these design constraints in the next chapter.

These REST constraints are:

SOA and ROA are two distinctly different architectural paradigms. In the former, a service is what is given importance. However, in the latter, resources are given importance. So, verbs are given importance in SOA, while nouns are given importance in ROA. In ROA, the common verbs used for resource life cycle management include PUT and DELETE. We will explore this later in this book.

The key REST principles are given as follows: