Service

OASIS (Advancing Open Standard for the Information Society http://www.oasis-open.org) defines a service as a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description. A service is provided by an entity (the service provider) for use by others, but the eventual consumers of the service may not be known to the service provider and may demonstrate uses of the service beyond the scope originally conceived by the provider.

A service is accessed by means of a service interface, where the interface comprises the specifics of how to access the underlying capabilities. There are no constraints on what constitutes the underlying capability or how access is implemented by the service provider.

Thus, the service could carry out its described functionality through one or more and/or manual processes that themselves could invoke other available services.

Web Service

The current Web is mainly a collection of information but does not yet provide support in processing this information, i.e., in using the computer as a computational device. Recent efforts around UDDI, WSDL, and SOAP lift the Web to a new level.

Software applications can now be accessed and executed via the Web based on the idea of Web Services. Web Services significantly increase the Web architecture's potential, by providing a way to automate the communication between distributed applications and the discovery or execution of remote services.
Web Services connect computers and devices using the Internet to exchange data and to combine data and processes in new ways. Web Services can be completely decentralized and distributed over the Internet and accessed by a wide variety of communication devices.

Note: More about services can be found in the Reference Model for Service Oriented Architecture OASIS Standard (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm).

Service Oriented Architecture

Definition

Service Oriented Architecture (SOA) is a computer system's architectural style for creating and using business processes, packaged as services, throughout their lifecycle. SOA also defines and provisions the IT infrastructure to allow different applications to exchange data and participate in business processes. These functions are loosely coupled with the operating systems and programming languages underlying the applications. SOA separates functions into distinct units (services), which can be distributed over a network and can be combined and reused to create business applications. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services. SOA concepts are often seen as built upon, and evolving from older concepts of distributed computing and modular programming.

The following guiding principles define the ground rules for development, maintenance, and usage of the SOA:

• Reusability, granularity, modularity, composability, componentization and interoperability
• Compliance to standards (both common and industry-specific)
• Services identification and categorization, provisioning and delivery, monitoring and tracking

Infrastructure

A vision of the standard SOA infrastructure is given is the following figure :

This infrastructure is composed of the following modules:

• A message delivery bus, also named the Entreprise Service Bus (ESB)
• A service orchestration engine (BAM - Business Process Management)
• A service container (such as SCA – Service Component Architecture)
• Monitoring Tools (BAM – Business Activity Management, SAM – Service Activity Monitoring)
• Management Tools
• …

The Entreprise Service Bus

Definition

The key item for integration of services within an SOA is the ESB. The goal of an ESB is to provide virtualization of the enterprise resources, allowing the business logic of the enterprise to be developed and managed independently of the infrastructure, network, and provision of those business services.

An ESB must provide a standard and flexible access to the services to the application developer. The service consumer must be as independant as possible from:

• The communication protocol between service consumer and provider. The service consumer must be able to access to the service via HTTP but also via FTP, JMS, JCA, SMTP, RMI, etc…
• The service deployment technology. A Web Service, .NET component, an EJB or a simple Java class may be accessed by the service consumer in the same way.
• The service localisation.

The ESB may also allow the service developer to deploy its services whatever the technology or the protocol he chose to develop the service.

Ideally, the bus must:

• Support the Web Service Description Language – WSDL (WSDL 1.1 http://www.w3.org/TR/wsdl and WSDL 2.0 http://www.w3.org/TR/wsdl20/) as the universal service description language. This is true even if the service is not a Web Service (an EJB for example).
• Interact with clients and services through heterogenous protocols:
  • Not WS-* based (e.g. HTTP, JMS, .NET, …)
  • WS-* based (e.g. SOAP, WS-RM, WS-Adressing, …)
• Provide several modes to call services (synchrone, asynchrone, …)
• Trace the service calls
• Secure message exchanges
• Host local services (SCA)
• Provide management facilities
• …

Most of the ESB are based on a asynchronous messages approach. It means that, whatever the protocol used from the consumer to the ESB and from the ESB to the service, the ESB internally transform these calls to messages. Next, it insures the routing and transmission of the message to the service in a transparent way from the service consumer and the service provider. The routin gis generally based on the message header (cf WS-Adressing), but a more advanced routing can be based on the message content (message payload). Furthermore, the routing phase can be done with or without acknowledgement, with or without delivery waranty, …

Architecture

The following figure introduces the functional modules that are needed to satisfy the previous objectives.

• The message transporter insures the transmission and the message security between the various servers/hosts which are taking part in the consumers and providers deployments.
• The protocol mediators (Service Access) are used by the ESB to support various communication protocols between itself and the service consumers and providers.
• The routing engine insures the messages to be routed to the good recipient based on rules.
• The transformation engine insures the syntaxic message conversion between two protocols. It can also provide a semantic message conversion between the consumer and the provider.

Calling a service

The following figure illustrates the difference between a simple service call and a service call through the ESB:

The client call is outed from what can be called a virtual service to the real service through the ESB following these steps (example between parenthesis) :

1. A message is sent by the client to a virtual service. This service is linked to the ESB container by an adapter (ex: A JMS client posts a JMS message to a Topic, the new message is detected by a listener).
2. The adapter transforms the incoming message to an ESB internal message and sends this message to the routing engine (ex: The JMS message is transformed to the internal ESB format).
3. The routing engine selects the ESB service to call (ex: This can be based on the message content or by rules defined at configuration time).
4. The internal message transporter transports the message (with or without security, hopefully with security…) to the right application server node (ex: if the ESB is distributed over several nodes, the transport layer is in charge of sending the message to the wire).
5. Once received by the transporter, the message is going through the router and transmitted to the right adapter which is linked to the real service.
6. The message is transformed to the output format by the adapter (ex: The internal message is transformed to a SOAP message).
7. The adapter sends the message to the service (ex: the SOAP message is sent to a Web Service).
8. If the real service returns a response, this response is sent back to the service client through the ESB…

The main question is why do we need to add an ESB as mediator instead of calling the service directly? Here are some good reasons (this is not an exhaustive list) :

• The client application does not have to wait the service response.
• The call can be securized by the ESB without any modification on the service side.
• The consumer delegates the service choice to the ESB. This really decouples the service consumers and providers.
• Decoupling service can hide the real service which will be called to the external service consumer. This contributes to securing access to the information system.
• The ESB offers features like monitoring (and more) which are not provided by simple solutions like standard Web Service calls.
• Service Level Agreement (SLA) can be defined between client and service. SLA is a part of a service contract where the level of service is formally defined (for example, limit the number of request per second or define the maximum response time which is accepted on the user point of view).