I once wrote an article about SOA where I described the kind of perfect scenario to use your concept.
I will use a very similar scenario to talk about Enterprise Service Bus (ESB) from now on. What makes us think about the co-relation between the two concepts of SOA and ESB.
Many confuse the two thinking that they are the same thing, but make no mistake, it is not the same thing. What I can say at the outset is that ESB is responsible for most SOA functions, but not all.
Let’s go to the scenario:
You work for a company that provides an online payment API. This company makes this API available for free and thousands of people daily implement this API in their online applications.
As a consequence, your company will have numerous accesses to:
- Manage registration (CRUD);
- Enter a purchase made through your API;
- Register Payment, among other operations.
But assuming your API is being used by distinct (heterogeneous) technologies, how do you make your system understand what external applications are wanting to query your services?
This is where the concept of ESBs comes in. The Service Bus provides:
- Service-oriented integration,
- Service management and
- Brokering traditional scalable and reliable messages in heterogeneous environments.
It combines smart messaging with routing and transformation and monitoring and administration of services.
As ESB is a concept, there are some tools in the market that have applied this concept in some tools turning them into powerful working consoles and as an example we have:
- Oracle Service Bus or OSB (present in the Oracle SOA Suite);
- Talend ESB;
- IBM WebSphere Enterprise Service Bus;
- among others.
And what are these ESB concepts / activities or responsibilities?
1 – Web services support
ESB has the ability to invoke web services based on WSDL and SOAP, as well as other services such as Restfull using the http protocol.
Generally, we create a WSDL for the service that you want to expose in the ESB. Clients, instead of connecting directly to the service’s WSDL, connect to a WSDL (Proxy) exposed on the bus. This allows you 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, database, ERP tools, file interfaces.
Adapters can be used both in case the application does not provide integration via XML or SOAP, as well as in cases where a higher performance gain is desired by avoiding the run-time cost of translating to / from XML if the system directly supports serialization of objects.
3 – Invocation of Services
As a standard feature, ESB supports synchronous and asynchronous service calls, and sometimes callback. A service can be mapped to another service.
The way that services communicate is called Message Exchange Patterns (MEP). An MEP defines the message sequence in a service call or service operation, specifying the order, direction, and cardinality of the messages.
There are different types of MEPs:
- One-way: The operation receives a message but will not return a response.
- Request-response: The operation receives a message and will return a response.
- Solicit-response: The operation sends a request and will wait for a response.
- Notification: The operation sends a message but will not wait for a reply.
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 performing message routing, for example, from message content (using XPath to navigate the message), rule-based routing, and policy-based routing.
Some buses allow message queue control so that a message, when sent, is persisted and is 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 the data to be prepared to be trafficked between systems / services.
If a canonical model is being used, this is an important feature of existing in the ESB.
7 – Orchestration
Many ESB perform orchestration through a proxy service, which coordinates the execution of multiple services. Some buses delegate BPEL engine orchestration.
8 – Security
The service bus provides functionality to ensure the use of security policies in conjunction with Security Assertion Markup Language (SSL) and Security Assertion Markup Language (SAML8).
9 – Service Management
Services running on the ESB can be monitored, audited, maintained, and reconfigured. In the latter case, process changes can be made without the need to rewrite underlying services or applications, depending on the modifications required and existing services.
All the points mentioned above are of great importance, but I would like to reinforce two of them which are: Process of Transformation and Orchestration.
As for the Transformation process (for me one of the crucial points and great attention), it is the process in which you capture data from a source (sometimes a Service that wants to consume data or send data) and converts it to the format that its structure understands, “feeding the right field” of its structure.
For example, look at the image below for the transformation between two distinct WSDLs and note that 3 Source attributes have been “CONNECTED” to generate a single information.
This means that whenever there is a communication between these services this rule will be applied.
One way to avoid or reduce the need to do many transformations (in several services) in our projects is to use Canonical Modeling.
With the use of Canonical Modeling we can have, for example, an XSD (containing the schema used in the service) shared between Consumer and the Service Provider so that the communication happens effectively.
Thus, the bus translates the message to the expected format once and we have the advantage of having a standard XSD that can be provided to several consumers and not having to reinvent the wheel.
In addition to these factors, the fact that you pay close attention to the transformation process lies in the fact that when you link between attributes, you are taking data from one WSDL and playing into the other.
So the importance of knowing the business rule well, so that problems like these are avoided.
As for the Orchestration process, I believe that the definition depends very much on the business rule, as well as on the work methodology of the Project Architect.
For example, in some projects I work I usually leave all CRUD in BPEL and the orchestration in OSB since I can have resources such as:
Message Routing, Enrichment, Error Handling, Split Joins (which are fantastic tools for parallel message processing) among other things. So in some cases I already have to work by default this way.
However, there are projects that need to be developed in a different way, for example when we need to position the orchestration in the BPEL, where it is necessary to maintain a flow of atvidades printing
step by step how a particular business rule works.
Currently I work directly with Oracle products, so it is the tool that I point out to those who would like to design Serial Buses for their projects.
In the case of Oracle we have the Oracle Service Bus or OSB that is in the 12C version in the Oracle SOA Suite. The OSB has all of the features described above and more.
From now on, we will develop articles that will bring examples of best practices and how to use OSB in your projects.
For now, I’ll stop here.
Inquiries, please contact us.
Strong hug.
Eduardo Santana.
bufallos@bufallos.com.br