Service Oriented Architecture in Practice: Infrastructure
Service Oriented Architecture, as discussed in more depth in this post, is an approach that helps systems remain scalable and flexible as they grow, and it also helps to bridge the gap between business and IT.
This approach consists of three main elements:
services: on the one hand, they represent independent business functionalities and, on the other, they can be implemented with any technology on any platform;
One Specific infrastructure: bus call and corporate services (ESB - Enterprise Service Bus), which allows combining services in an easy and flexible way;
Policies and Processes: deal with the fact that large distributed systems are heterogeneous, under maintenance and have different owners.
SOA accepts that the only way and maintaining flexibility in large distributed systems is to support heterogeneity, decentralization and fault tolerance.
Very often, this architecture is only partially explained and installed. The introduction of just one infrastructure like Web Services can help up to a certain level of complexity, but it is not enough to guarantee scalability. All architecture, services, infrastructure, policies and processes must work in their entirety for successful implementation. Implementing SOA is not easy, it requires time and effort to get the technology team engaged.
An important part of SOA is the infrastructure that allows you to use services in productive system environments. In this case, it is the Corporate Service Bus (or ESB - Enterprise Service Bus). There are different opinions about the role and responsibilities of the ESB, and this is because there are several different technical approaches to carrying out a bus.
This structure is called the technical backbone of the SOA environment.
The bus allows consumers to call services offered by suppliers. Depending on the organizational and technical approaches used to implement the ESB, this may involve the following tasks, in which they may have to be taken to different hardware and software platforms, and even to different middleware and protocols:
- Provide connectivity;
- Data transformation;
- Routing (intelligent);
- Deal with Security;
-Deal with reliability
-Dealing with service management;
-Monitoring and logging.
The main role of ESB is to promote interoperability, and because it integrates different platforms and programming languages, a fundamental part of this role is data transformation.
Let's imagine the following scenario:
You work for a company that provides an online payment API. Your company makes the API available free of charge to thousands of people, who daily implement this API in their online applications. As a consequence, your company will have numerous accesses for:
- Manage registration (CRUD);
- Register a purchase made through your API;
- Register Payment, among other operations.
But, assuming that your API is being used by different (heterogeneous) technologies, how to make your system understand what external applications are looking for when consulting your services?
That's where the bus concept comes in. He offers:
- Service-oriented integration,
- Service management and
- Brokerage of scalable and reliable traditional messages in heterogeneous environments.
It combines intelligent message exchange with message routing and transformation, as well as service monitoring and administration.
And what are these concepts / activities or responsibilities of the ESB?
Typically, ESB provides more than just connectivity.
1 - Support for Web Services
ESB has the ability to invoke web services based on WSDL and SOAP, as well as other services such as RESTful using the HTTP protocol.
Generally, we create a WSDL for the service to be displayed on the ESB. Customers, instead of connecting directly to the service's WSDL, they connect to a WSDL (Proxy) exposed on the bus. Thus, you are able to have a connection that allows you to handle routing and transformation logic within the bus.
2 - Adapters
They are used to connect applications that do not support the SOAP or XML interface, such as packaged applications, databases, ERP tools, interfaces via file.
Adapters can be used both in case the application does not provide integration via XML or SOAP, as well as in cases where a greater performance gain is desired avoiding the cost in runtime of translating to / from XML, if the system supports directly object serialization.
3 - Invocation of Services
The standard feature of ESB is to support synchronous and asynchronous service calls, and sometimes callback. One service can be mapped to another service.
4 - Measurement and Protocol Independence
Many buses allow different communication protocols to be used during the path of a message.
5 - Routing
Buses provide different ways of routing messages, for example, from the message content (using XPath to navigate the message), routing based on a rules service and routing based on policies.
Some buses allow message queue control so that a message, when sent, is persisted and not lost. This is the principle of message-oriented mediators
(or MOM - Message Oriented Middleware), such as MQ and JMS.
6 - Transformation
Data represented in XML can be transformed using XSLT and queried using XQuery and XPath. These technologies allow to prepare the data to be transferred between systems / services.
If a canonical model is being used, this is an important feature of existing in the ESB.
7 - Orchestration
Many ESBs perform orchestration through a proxy service, in which they coordinate the execution of multiple services. Some buses delegate orchestration for BPEL engines.
8 - Security
The service bus provides functionality to ensure the use of security policies in conjunction with policy assurance points, SSL and SAML (Security Assertion Markup Language).
9 - Service management
Services running on the ESB can be monitored, audited, maintained and reconfigured. In the latter case, changes to the process can be made without the need to rewrite underlying services or applications, depending on the necessary modifications and existing services.
One way to avoid or reduce the need to make many changes to our projects is to use Canonical Modeling. Using Canonical Modeling, we can have, for example, an XSD (a schema used in the service) shared between the Consumer and the Service Provider for communication to take place effectively.
All the points mentioned above are of great importance, but there are two that are worth highlighting: Transformation and Orchestration Process.
The Transformation process (one of the points of great attention), is the process in which you capture data from a source (sometimes a Service that wants to communicate with your web service) and convert it to the format that your structure understands, “Feeding the correct field” of its structure.
The transformation is inherently part of the bus in an ESB distribution. Transformation services that are specialized for the needs of the individual applications connected to the bus can be located anywhere and accessible from anywhere on the bus. Because data transformation is an integral part of ESB, an ESB can be thought of as a resolution of impedance mismatches between applications. That alone can be difficult, especially when performance issues come into play. The usual approach is to introduce a specific format to which all individual platforms and APIs point. For Web Services, this format is typically SOAP (SOAP is a message transfer protocol in XML format for use in distributed environments. The SOAP standard works as a type of framework that allows interoperability between different platforms with personalized messages.)
Another fundamental task of ESB is routing. There needs to be a way to send a customer service call to the supplier, and then send a response from the supplier to the consumer (other messaging standards exist, but this is what is technically necessary)
The other responsibilities of an ESB are usually extensions of a central task of providing interoperability, if the mechanisms for handling these tasks are an integral or even an inherent part.
Therefore, ESB - Enterprise Service Bus - allows software developed in different technologies and languages to work together. With it, complex integrations of your company's large systems become much simpler and completely manageable. This bus makes system services more easily available to users and other applications, accelerating integration processes.
Josuttis, Nicolai, 2009 “SOA in Practice: The Art of Distributed Systems Modeling”, 2009