Web services and SOA, intimate enemies
I recognize that the title of this entry is somewhat exaggerated, I know. I intend to illustrate the good and frequent relationship that SOA has with web services, and how dangerous it is to confuse that good relationship with a relation of composition or belonging, as if they were connected concepts.
In this entry we will try to mark the border between web services and SOA, although in many sites, and for many professionals, both go hand in hand. It is certainly common to use web services to implement SOA services, but it is important to be fully aware that it is not necessary. And using web services to define SOA, or to define SOA services, just creates confusion.
What are web services? At this point it is easy to find the definition online, for example this one. As you can see, web services are the last step in finding a way to interconnect information systems over the internet to share data, regardless of their technologies, platforms, location, etc. For this purpose web services are very indicated to be able to use the http protocol on tcp on port 80, which is so to speak the standard way that uses the internet to connect us all.
Another novelty introduced by web services was the concept of “contract” between the systems involved, a technological level contract, specified by the Web Service Description Language (WSDL). This new feature made it possible to ensure that both parties were fully aware of the interface, operations, and parameters published by the web service provider and provided a certain level of encapsulation.
Therefore, web services seem the best technology choice to interconnect remote systems over the internet and thus to exchange data.
Let’s recall again the central idea that is in the web services: making certain information available outside a system. But when we talk about the SOA strategy, we are not talking about the same problem, we are not in the same scenario.
The problem of interoperability for an organization is not only about communicating remote systems of different platforms connected to the Internet, nor to publish certain information abroad. The problem of interoperability consists mainly in sharing processes within an organization, not just outside. In fact, it is rash to worry about external interoperability to an organization, if internally, in its systems map, the problem is not solved yet. And within an organization, web services make less sense than on the internet. In theory, if the data you want to publish will not be available to the world (on the internet), it does not make much sense to publish it through a web service.
It often happens, however, that even within an organization, it is very complex to manage the accessibility of different information systems. If the organization is large, complex and geographically large (and especially in the public sector), it is very likely that its information systems use the advantages of web services to interconnect their systems without too many complications, and taking advantage of the use of its WSDL.
This dynamic also implies a kind of malpractice in companies providing ICT and in the organizations themselves, mixed with a lack of global vision. When designing an information system you must never forget that it is a piece of a larger system, the organization itself, and that the fundamental thing is that this macro system works optimally.
With the new century there has been a proliferation of web services as a means to solve the integration needs among information systems within an organization. A proliferation very often uncoordinated and without global guidelines, mixed with many other technological solutions (embedded applications, access to databases, replicas of tables, files by ftp, etc.), which inexorably leads to our favorite pasta dish.
Let us now recall two disadvantages of web services as a technological integration solution in an organization:
- If a web service is not available at any given time, the systems that invoke it will receive an error. This obviousness can not be afforded in an organization that seeks to solve the problem of interoperability.
- The web services are published by a system (web service provider), which responds in a reactive way to the invocation from another system (web service consumer). This invocation occurs when the latter needs the information published by the former. This pattern, known as “request-response”, introduces synchrony in communication, and therefore a transactional coupling between the web service consumer system and the web service provider system. If the provider is not listening at the moment the consumer invokes it, the process fails, with the consequent risk of inconsistency in the information. And if the provider modifies the web service, consumers should modify their invocations.
For the first problem, SOA uses the ESB. ESBs provide standard facilities for setting up retry policies that reduce the risk of unavailability of the destination messaging system, and thus fulfill one of its basic commitments, the guarantee of delivery.
For the second problem, the SOA strategy relies on the EDA approach. With this approach the roles of provider and consumer SOA services are exchanged regarding the role of provider and consumer of web service. First because they are different things, and second because the orientation to business events introduces the maximum decoupling through asynchronous messaging at the transactional level, so that the information systems do not have to wait to see what the other system does.
In an SOA strategy (using EDA) that uses web services to implement business and infrastructure services, systems that publish web services to receive messages associated with a business event are the consumers of the service, and the information system that Communicates the event through the corresponding message is the service provider, and for this invokes a web service published by the ESB. Both the invocation to the ESB by the service provider and the invocation by the ESB to the consumers of the service are carried out in different threads, uncoupled, leaving in the ESB the responsibility to validate the message, transform it, map it and guarantee its delivery Through the policies of retries that are determined. In a next entry we will better detail some typical communication patterns that fit in this scenario, it is an interesting matter.
- In a web service, the system that publishes it is the provider , and the systems that invoke it are consumers . A system provides a technological solution to a number of consumers.
- In an SOA service, the provider invokes a web service published by the ESB , and it invokes web services published by consumers of the SOA service . A system provides a business event to a number of consumers, using as a technological medium web services or any other valid technology solution.
The most interesting thing we want to point out is that within an organization the implementation of SOA services does not have to be through web services. Other technologies such as MQ queues, files, etc. can be used. In fact sometimes is the most successful (or the only thing that is viable).
SOA has to remain independent of any technological issue, in order to have the greatest capacity of implantation, dynamization and transformation of the map of systems of an organization, and to transcend any technological change that may condition strategic decisions in the future.
So, when you find articles, blogs, publications about SOA, which relate directly to web services, remember mentally add your tagline: “or any other valid technology solution.” This widespread commitment to associate web services with SOA creates confusion about what SOA really is, about the leading role of governance, very ahead of technology. This is why I chose this title for this post: web services work well in an SOA strategy, but the idea that they are the same is too widespread, and that does not help.
They are something like … intimate enemies.