There are several ways of implementing a SOA integration, but let us focus on two.
- Web Services
Web services are the most common way to implement a SOA. They are based on protocols such as HTTP, FTP and SMTP. There are two main styles of web services, SOAP and REST.
The SOAP web services use a set of XML-based open standards such as SOAP, WSDL, and UDDI to provide a common approach for defining, publishing, and using Web services [1].
SOAP is a standard lightweight protocol for exchange of information in a distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing remote procedure calls and responses. SOAP can potentially be used in combination with a variety of protocols (HTTP, SMTP, etc.) [2].
The definition of the SOAP web service is in the WSDL (Web Services Description Language). A WSDL document describes network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate [3].
As data is exchanged in XML, some performance issues could arise if the number of messages is high, but is possible use SOAP with Web Services Security, a standard for signing and encrypting messages to a more secure information exchange [1].
The REST (Representational State Transfer) web services, in contrast with the SOAP services, can handle several data formats (XML, JSON, etc.); is based on the concept of “resource”. The service is a set of resources identified by the URI (Universal Resource Identifiers). These resources are invoked using HTTP GET, PUT, POST and DELETE (SOAP only uses POST) [4].
REST web services require little infrastructure support apart from standard HTTP. They are simple and effective because HTTP is the most widely available interface, and it is good enough for most applications. In many cases, the simplicity of HTTP simply outweighs the complexity of introducing an additional transport layer [5].
Choosing REST or SOAP will depend on an organization’s needs and constraints. Sometimes, it’s better use the enterprise capabilities that SOAP offers, or maybe one would benefit from a more performant and lightweight alternative such as REST [1].
Before addressing micro services, let’s talk about a platform associated to SOA and SOAP web services, the ESB (Enterprise Services Bus).
The ESB is a standard platform that combines messaging, web services, data transformation and intelligent routing to connect and coordinate the applications universe with transactional integrity in an SOA. An ESB provides a highly distributed integration environment that spans beyond the reach of hub-and-spoke architectures, and a clear separation of business logic and integration logic such as routing and data transformation. An ESB forms an interconnected grid of messaging hubs and integration services, with the intelligence and functionality of the integration network distributed throughout [6]. With ESB is possible the substitution of one service implementation by another with no effect to the consumers of the service. This requires both the service interfaces that are specified by SOA standards and that the ESB allows consumers to invoke services in a manner that is independent of the service location and communication protocol that is involved [7].
Figure 1. SOA and ESB
The ESB appears as a solution to many of the integration problems. But because is technology agnostic and its features, as well as the services it provides, can be added incrementally, if the organization is very large it will be reflected in the ESB, turning it very complex and heavy, stripping it of so much of its effectiveness and performance.
- Micro services
The term “micro service” is relatively new. It was discussed at a workshop of software architects near Venice in May 2011 to describe what the participants saw as an emerging common architectural. In May 2012, the same group decided that the term “micro services” cover this new emergent trend and is considerate one form of SOA [8].
A “micro service” is a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often a HTTP resource API. These services are built around business capabilities and independently deployable and scalable. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies. They are componentized, one main reason for using services as components is that services are independently deployable, and so they can be independently changed [8].
Figure 2. Micro services
Applications built from “micro services” use an approach that is designed as “smart endpoints and dumb pipes”, they aim to be as decoupled and as cohesive as possible receiving a request, applying logic as appropriate and producing a response and REST is preferred. The two protocols used most commonly are HTTP request-response with resource API’s and messaging over a lightweight message bus. The infrastructure chosen is typically dumb, and uses smart endpoints that are producing and consuming messages, explicitly avoiding the use of an ESB. They decentralize data management, adopting one database for each service. With companies like Amazon, Netflix to adopt “micro services”, this integration style could be the next step of SOA [8].
Ricardo Santos
EAI Consultant and IoT Evangelist at Polarising
References
- Service-Oriented Architecture and Legacy Systems, http://www.infoq.com/articles/service-oriented-architecture-and-legacy-systems
- Simple Object Access Protocol (SOAP) 1.1, www.w3.org/TR/2000/NOTE-SOAP-20000508/
- Web Services Description Language (WSDL) 1.1, https://www.w3.org/TR/wsdl
- Ramanathan, R.: Service-Driven Approaches to Architecture and Enterprise Integration. IGI Global (2013)
- Service-Oriented Architecture, http://www.xml.com/pub/a/ws/2003/09/30/soa.html
- Chappel, D. A.: Enterprise Service Bus: Theory in Practice, O’Reilly Media, Inc.(2004)
- Acharya, A., Bishop, S., Hopkins, A., Milinski, S., Nott, C., Robinson, R., Adams, J., Keen, M., Verschueren, P.: Patterns: Implementing an SOA Using an Enterprise Service Bus, IBM (2004)
- Microservices, http://martinfowler.com/articles/microservices.html
Figure 2 – http://martinfowler.com/articles/microservices.html
