Since the SOA term was coined, many discussions raged on what a service
was from a business and technical perspectives. In this article, I offer
my views on the topic.
There are several categories of services.
Many leading SOA vendors and thinkers typically break them down into
Business and Utility types. A Business service represents a business
capability that is needed to complete a step within a larger business
process. Examples may include retrieving customer information, making
payments, or checking order status. Utility services represent a
technical capability that is business process agnostic. Examples are
e-mail, logging, or authentication services.
Services can be
combined together to create composite services. This is called
orchestration. An example of this can be a Money Transfer service that
needs to debit one account and deposit money into another one. Composite
services can also be categorized as Business and Utility. Best
practices and general orchestration guidelines as related to
orchestrations, atomic services, and their relationships will be
discussed separately.
Regardless of the type, a service is comprised of three components.
- Interface
- This defines how services are exposed and can be accessed by its consumers.
- Interfaces are not limited to Web Services and can be represented by any remote messaging protocol.
- Contract
- This
defines what services expect during the interaction with the consumer.
Message structures, relevant policies, and related security mechanisms
are all part of a contract.
- Contract defines a “legal” agreement on how the service and its consumers should interact.
- Implementation
- This is the actual service code.
A
service may have multiple interfaces. Different consumers may have the
need to access the service via different protocols. For example, a Java
consumer would like to access a service via a Web Service protocol while
a Mainframe application can only use MQ Series. Even though a service
may itself expose multiple interfaces, it is more effective to let the
ESB platform handle this. For more details about the rationale behind
this recommendation, see
“To ESB or Not to ESB?" post.
A
service may also have multiple contracts. I have recommended in the
past that for a service to be maximally reusable, it needs to implement
the Service Façade pattern (see
“SOA Façade Pattern” post and
“Service Façade” pattern). This pattern recommends that multiple different interfaces and contracts for the same service be created. The
Concurrent Contracts pattern also addresses this issue.
It
is important to understand that while the interface, contract, and
implementation describe a service as a whole, they are not closely tied
together. An interface is not dependent on the contract details and
should not be tied to the specific messaging structure. The opposite is
also true – the contract should not be tied to any specific
communication protocols. Additionally, the implementation should be
flexible enough to accommodate the potential for multiple interfaces and
contracts. Ideally, however, I would recommend that a service expose
only a single contract and interface and the ESB would take care of
exposing additional endpoints and facades as necessary.
