As we discussed earlier, SOA is an approach and tells us nothing about which technology to use to implement it. Each organization is free to choose the desired technology as long as it ensures the SOA principles.
The most common implementation is based on the following standards:
- XML: This is the extensible markup language we all know. It is the typical language used to model the organization's business entities; another option quite popular nowadays is JSON.
- HTTP(s): This is the protocol used to exchange information between systems.
- SOAP: Simple Object Access Protocol (SOAP), is based on XML and defines the structure that will be used to exchange information between systems. A SOAP message contains the following elements:
- Envelope: The top-level structure that includes everything else
- Header: Extra information related to security, how the message must be processed, and the quality of service
- Body: The data it sends to the producer, or the response that it sends to the consumer
- Fault: Information about the errors produced while processing the message
- WSDL: Web Services Description Language (WSDL), and it is the language for defining the contract of the service. In other words, it defines the input and output of the service black box without any attached vendor technology.
Putting all these standards together, we get the web service technology. Web service is a process that aims to interchange information with other systems. This information exchange is defined by a contact, which is built using the WSDL.
Web service technology will be the instrument that is finally used to build the business services we have been discussing in this chapter. It is important to note that at this point, we can fully define a business service using this technology, without tying it to any specific vendor or technology, such us Java, .Net, or Oracle.
At this time, we can finally introduce the central element of the SOA IT infrastructure ESB. The name is an analogy to the hardware bus we can find in a motherboard, which enables the communication between all components. In this case, as we discussed earlier in the chapter, it communicates software components transporting messages of data instead of communicating hardware components transporting bits of data.
The ESB is a middleware where the SOA services are deployed and published and are ready to be consumed by other systems that may be within the company, in another company, in another country, or even in another continent.
In the following diagrams, we can see an approach of the SOA infrastructure of our company:
In contrast with the spaghetti dish, we can see the following:
The ESB allows us to accomplish the SOA principles with the following features:
- Deploying, managing, and controlling the SOA services
- Synchronous communication between systems, where the consumer is waiting for the response in the same channel used to send the request
- Asynchronous communication between systems, where the consumers do not wait for the response in the same channel used to send the request
- Fire-and-forget communication, where the consumers do not need a response
- Services orchestration, which wraps business logic that involves several services into a single service
- Complex business services
- Security to ensure authentication and authorization of the consumers
- Quality of the service, such as message signing and encryption, reliable messaging, and throttling
- Applying enterprise integration pattern. You can find out more about it at: http://www.enterpriseintegrationpatterns.com.
- Standardized platform
- Protocol conversion
- Technology isolation
There are many vendors offering different implementations of the ESB in the market with different pros and cons, and with many different kinds of licenses. The ESB chosen for this book is the WSO2 Enterprise Integrator (EI) by WSO2.
As we can read on Wikipedia about the history of the company (https://en.wikipedia.org/wiki/WSO2):
Based on the experience of working with WSO2 products for more than five years, we have to follow how the company has grown and expanded due to its innovative culture. Along with this experience, we have witnessed the evolution of the WSO2 components since the successful early version of the ESB and DSS to the current ones, and the brand new WSO2 EI.
In the following chart from the WSO2 site, we can see the WSO2 vision of the SOA infrastructure:
Here, we can see how WSO2 ESB is the heart of the infrastructure and relies on the other components:
- WSO2 Data Services Server: This is a very successful component that lets you expose data from a very diverse source, such as web services or REST resources, in a couple of minutes without any code.
- WSO2 Message Broker: This is a message broker, as its name says, that supports the Publish/Subscribe model, Java Message Service (JMS), and Advanced Message Queuing Protocol among other features, which allows us to build complex business services.
- WSO2 Business Process Server: This a business process engine. Business processes are a higher level of abstraction called Business Process Management (BPM). BPM is based in business services that compose business processes, and supports BPMN 2.0, WS-BPEL 2.0 , WS-Human Task 1.1, and BPEL4People 1.1 standards.
The SOA component missed in the preceding chart is the UDDI registry. WSO2 offers this UDDI registry with its component called WSO2 Governance Registry; this component is more than a simple UDDI registry. It also provides a service catalog as well as a repository for the whole set of governance elements, such us policies, documents, schemas, and web services descriptors, for the SOA Governance.
As we said earlier, the WSO2 is a very dynamic company that tries to be cutting edge. The last component for SOA from WSO2 is the WSO2 EI 6. In this component, they put the most important SOA functionalities in just one component. Those functionalities were previously encapsulated in the following components:
- WSO2 Enterprise Service Bus
- WSO2 Data services Server
- WSO2 Message Broker
- WSO2 Business Process Server
- WSO2 Application Server
So, this brand new component offers a new vision of the SOA infrastructure:
We have already discussed all these components in the preceding figure about the WSO2 SOA infrastructure, except WSO2 Application Server. WSO2 Application Server, as the name says, is a Java application container for web applications, web services, and RESTful services. This container is called the Carbon platform. According to the level of this book, we will focus on the following WSO2 EI functionalities:
- Service Integration
- Data Integration
- Messaging
- Analytics
- Tooling
In the subsequent chapters, we will learn how to install WSO2 EI, create web services and data services, and how to test and manage them. We will also learn how to build services that use message queues, data services, and connectors to integrate with third-party applications.
