All I needed to know about SOA I learned in Kindergarten…
If this term is new to you, or you want a different spin, it’s time everyone in IT Architecture should know at least a little about SOA – Service Oriented Architecture. SOA (service-oriented architecture) has become a buzzword in the early 2000′s and now is mainstream, and here is my take on it and where the industry currently sits with it.
Service Oriented Architecture is an Architecture for Adaptive spanning layers within an application. OK – let me try one you can use to explain this to your boss – SOA is a collection of services that communicate with each other. The services are self-contained and do not depend on the context or state of the other service. They work within a distributed systems architecture.
Most definitions tout it’s benefits, agree that it’s a good thing, and that Web Services is a SOA. SOA involves publish, find and bind. SOA is fundamentally an interoperability or spanning architecture. The architecture is really about the lines, not the boxes. The lines are the interoperability component.
The trend in the industry is all the talk about the lines, but unfortunately we’re still short of boxes. Some of the large ERP appications claim they are designed on an SOA, and use services to connect with partners and vendors, but very little has materialized. Check very carefully when analyzing the architectures and applications to see what is truly available and what is waiting for someone else to build!
Cutting the kindergarten talk for a minute, what I am saying is that to understand SOA, you would look to learn about interoperability. This is based on network concepts such as protocols and intermediaries.
By also saying that we are short of boxes, I mean that there are few services ready for prime time, but you can be sure that most software companies have their developers heads down trying to develop them.
One architecture project of which I have been a part of lately has been designed with at least one third of the functionality to be delivered by the “promised” Q4 delivery of the services. We are already using the main product which was architected to include the abilities for SOA. Smart. In your jobs as architects – this is the model that you should now be following – model the lines to handle services and the boxes will take care of themselves later. You are architecting IN the ability to change, adapt and plug & play.
SOA is a general purpose way of defining all processes as services that are delegated to service providers via generic envelope-based service interfaces. The generic interfaces describe the interactions between providers and service consumers in terms of identifiers, formats and protocols.
Generic interfaces are dynamically bound to an array of specific network and endpoint service-provider technologies which are coordinated by service intermediaries. It’s essentially all about an application level interoperability network.
I would suggested visiting the link at w3c.org for more information:
Picking the right SOA is a topic unto itself but there are two leaders WSA – the web services architecture driven by W3C as well as GXA – the global XML Architecture, driven by IBM and Microsoft.
WSA is more mature at this time, but that becomes irrelevant if the services (or boxes) that you want to use aren’t ready for prime time yet