Service Oriented Architecture (SOA) is a paradigm that makes it relatively easy to create distributed, heterogeneous systems that work together. To achieve collaboration, an infrastructure, a utility, is needed that transmits the client’s request to the service provider and, if necessary, the response back to the client. Today, the technological basis for this utility seems to be XML, SOAP, UDDI, and Web Services (WS) in general. Business processes can be built from Web Services as elementary steps (and described in BPEL – Business Process Execution Language), which can themselves be represented as Web Services. The principles of interconnecting the above-mentioned components, the utility that can be built from the components, and the computer systems that implement them are called Service Oriented Architecture (SOA). Today, all major players in the IT market (e.g. IBM, Microsoft, Sun, Oracle) have come up with their own SOA systems, promising to solve problems of large-scale IT systems (e.g. e-commerce, e-government, etc.) that span across organisations and distances. In many places and domains (from health to finance) around the world, attempts are being made to integrate complex IT systems on an SOA basis using the tools mentioned above. Assuming that the market is likely to remain diversified in the long term, and that interoperating users will choose different SOA products, it can be concluded that the key to the widespread adoption of the architecture is the interoperability of systems from different vendors. However, this does not only imply direct interconnectivity between vendors’ tools, but also raises issues at different levels of abstraction. These include technical, semantic, organisational, and in some cases legal interoperability issues.
In addition to Web Services architecture, we have significant experience in RESTful services and AMQP-based microservices.
