Get Social

SOA is not necessarily ‘Web Services’.

A service oriented architecture could be implemented in many different ways. One implementation might be a client-server application, where services are independently deployed to the SOA platform and accessed by client programs. Think of 20 cash register operators at Wal-Mart (the client programs) and a server running a set of cashier related services in the back room somewhere. This might all be implemented in Java.

Another implementation of a service oriented architecture might involve traditional ‘Web Services’ implemented using SOAP (Simple Object Access Protocol) and WSDL (Web Service Description Language). Imagine Amazon.com providing software services to their business partners and UPS providing services to Amazon.com. In this scenario, Amazon.com might have implemented their system using Java, whereas UPS implemented their system in .NET. This is the value of ‘Web Services’ - SOAP and WSDL enable these heterogeneous systems to communicate with one another. The SOA part of this scenario lies in the fact that new services can be deployed and consumed independent of the existing services currently deployed. SOA enables this loose coupling which is quite valuable from a business standpoint, as I discussed before.

So service oriented architecture is not necessarily coupled to ‘Web Services’. It’s more of an architectural style.

Why should anyone care about SOA?

Service Oriented Architecture (SOA) is the idea that business functions can be built in such a way that it becomes easy to produce or consume any service by loosely coupling services from consumers (and from each other). If you have an operational service that currently accepts standard purchase orders, it should theoretically be easy to build and deploy a new service that compliments the existing one. For example, perhaps your users want the ability to change the quantity of supplies ordered before the order ships. In theory it should be very easy to create and deploy such a service along side the existing purchase order service. Additionally, it should be easy for system integrators to integrate with the new service, and thus users of the service can use it much sooner.

You might be thinking, who cares? Well, here’s why it’s important. Enabling loose coupling of services makes software cheaper to produce and consume. Many companies have spent many millions of dollars on maintaining and/or modifying very tightly coupled systems. By enabling loose coupling and standardizing on certain technologies, companies can produce services more rapidly. Also, companies that consume those services can integrate with newly created services more rapidly, thus enabling their use much more rapidly than was previously possible. This has the downstream effect of providing value to users more quickly, which can generate economic activity.

So who cares about SOA? You should if you want to deliver value to your users as quickly as possible.