Focus on service
SOA stands for Service-Oriented Architecture. In other words, an architecture of software products or IT systems designed specifically to provide services. This all sounds very nice, but what kinds of services are we talking about here?
In fact, it could be any type of service. The main thing is that every system involved – whether on the intranet or the Internet – offers an interface via which users can access its services.
There are no general rules governing exactly how the service is accessed, but the way in which each individual system communicates needs to be clearly defined. And of course, the great thing about SOA is that there can be a service that exists solely to call up multiple other services – irrespective of whether those services are made available by the same system, or by a completely different company on the other side of the world.
Examples:
In principle, a service might simply perform a particular calculation – e.g. adding together a+b, to take the most basic example. We feed in the two values and the service returns the total. A sensible example would be a service that calculates the distance and remaining travel time between two postcodes. Another service might deliver the geo-coordinates for a particular address. Yet another could also take an address as an input and run a credit check based on the surrounding neighbourhood.
These are examples of what would be public services – but services of this kind can naturally also be deployed within a company to check the stock levels of a particular item (for example). Then we would no longer need to know which database we needed to query – we could simply call up the relevant service and obtain the inventory data.
If we have several such services, we can also bolt a new, more complex service on top that calls up a whole sequence of individual services and delivers a final result at the end. This gives rise to a whole network of services, in which complex services call up other, simpler ones, and are themselves used by even more complex services in turn. And this network can be distributed across the entire world, all while end user entering a query somewhere on their monitor remain oblivious.
Requirements and benefits:
A service that is part of an SOA is subject to certain requirements. It must:
- provide a certain level of functionality
- be accessible externally (i.e. via a network)
- be usable as an independent unit – or in other words, it needs to be stateless
- be accessible via a clearly defined interface that is independent of the type of user
- have a separate implementation that is encapsulated from the outside world, so that this plays no role in using the service
- and at least in theory, it must meet a few other criteria that aren’t necessarily important in practice
These requirements – especially the encapsulation and the clearly defined interfaces – offer a few benefits. Let’s assume (for example) that there is a service within the company which returns the stock level for a particular item number via a web service interface (one of the many ways in which SOA services can be called up). At the moment, we simply have a small wrapper around a database query. It takes the item number as an input, runs a select statement on a particular database, and then returns the inventory value. Now we have a change to the inventory management process – SAP has been introduced, so we can’t simply look at the tables anymore. Instead of that, however, we can now go through the RFC interface on SAP and find the inventory value for the item number.
If we formerly connected directly to the database and fired off a statement every time we ran a query of this kind, there would now be a great deal of work involved in converting everything to SAP/RFC. Instead, all we need to do is to reimplement the service. The code gets completely replaced, but the external interface remains unchanged. And lo and
behold, by making a single centralised change that nobody would even notice, we can neatly switch all our queries from the old IMS to the new SAP system.
That’s exactly how it looks from the perspective of the service user. If the service was previously accessed using old, cobbled-together C++ programs and the company switches to a modern standard software package, that package only needs to be capable of calling up a web service in order for the user to continue using the same interface as before. Because services in an SOA typically use standard protocols such as SOAP, they can be accessed and used via a wide range