Service oriented architecture is a principle that allows businesses to manage their IT and business transformation in order to give themselves a competitive edge. It offers benefits including insight into the running of the entire business, seamless integration of systems and the cloud, and linking of front and back office systems.
However it’s defined, a key principle of SOA is that it should be independent of products, vendors and technologies. Each service is a discrete unit that can operate independently, but uses metadata to describe how it handles and exchanges information. The idea behind this is that a number of services can be combined together to form a larger, more complex application. SOA therefore needs to be built into the design to ensure that all of the service modules will work together.
First defined by Sun in the late 1990s to define a service (Jini) for discovering services over a network, SOA id still a relatively new concept.
In 2009 a group of industry experts published an SOA Manifesto which sets out its guiding principles and core values. In implementing SOA this specifies that enterprises should prioritise: business value over technical strategy, strategic goals over project-specific benefits, intrinsic interoperability over custom integration, shared services over specific-purpose implementations, flexibility over optimisation and evolutionary refinement over the pursuit of initial perfection.
The manifesto is, to date, the closest to an industry standard for SOA, though it doesn’t set out exactly what an SOA should look like. In most practical applications there are a number of layers which make up the SOA framework. These include consumer interfaces, business processes, services and operational components.
Because service oriented architecture splits functions into individual service units, these need to be made available over a network so that they’re accessible to users and can be combined to make up applications. This has much in common with other modular and object oriented development architectures where elements are separate and interchangeable, and with distributed computing architectures.
However, where these concentrate on the program code, SOA involves the delivery of the service and the business goals that it supports. A service is a building block that performs a particular task, it’s inner workings though are hidden from the outside, but it presents a straightforward interface to allow it to work with other services and the wider system.
This of course requires a common set of standards to be in use. Web Services Description Language (WSDL) is commonly used to describe services themselves. In addition Simple Object Access Protocol (SOAP) is used to define the communications protocols used to exchange information between them.
Because it’s heavily dependent on metadata, SOA needs this to be tightly defined too. The metadata needs to allow services to be defined and discovered and also maintain their integrity. It also needs to be in a format that can be easily managed by designers and developers.
Perhaps the most widely implemented example of SOA right now is in web services. These are the systems to allow machines to operate together over a network. They provide a common approach for publishing and using services over a local network or the internet. This is usually implemented using APIs to allow the various services to talk to each other.
This also satisfies software orient architecture’s principle of independence, as web services are designed to work together even if they’re running on a range of different software platforms and varied hardware architectures. The Java programming language is often used for web services due to its platform independence.
This has much in common with what is commonly called Web 2.0, making tools available for individuals and businesses to share data and collaborate over the internet. Indeed John deVadoss, director of architecture strategy at Microsoft has expressed the view that his company would like to bridge the gap between Web 2.0 and SOA, and the idea of a merger of the two concepts is also popular in the development community.
In practical terms, SOA can give businesses a more holistic view of their operation and therefore allow them to exercise greater control. It can also allow systems to respond more rapidly to changing demands because the architecture allows for the reuse of existing services in different combinations.
As well as greater flexibility, SOA offers the potential for reduced costs, particularly when integrating new services. It allows in-house developers to collaborate with platform suppliers and third-party software vendors to produce more effective solutions.
The biggest challenge in managing SOA implementations is ensuring the integrity of metadata. This is essential if multiple services are to work successfully together. This throws up issues with testing too, as services are separate and may be running on very different platforms it can be hard to apply a unified testing framework. There may be a vast number of possible combinations in which services could interact, and the addition of new features and services may make it hard to define a fixed datum point for tests.
SOA is also about much more than just software. It may involve enterprises having to look not just at their development processes, but also at their business processes. This may even extend to reviewing the whole supplier and customer relationship in order to make the most of SOA’s advantages.
Taken to its logical conclusion, SOA could lead to a worldwide pool of services, all available publicly for integration into business systems on what CBDI describes as a ‘service bus’. This will lead to greater agility as well as making it easier for businesses to collaborate by sharing common platforms. It will also help them comply with government and industry regulations.
Major suppliers including Microsoft, Oracle and IBM are already seeing SOA as a delivery framework for the future.