Title: SOA – a perspective of the handshake
Audience: Developers, Architects, Organizations, Business Consultants
In Scandinavia the handshake is commonly used in two situations. First as a formal greeting and secondly when a deal is struck. In order to understand the usage of a handshake in regards to Service Oriented Architecture(SOA), focus on the second one – When a deal is struck.
When two sides agrees, a set of terms and a contract is usually crafted to define the exact contents of this arrangement. Who delivers what, where and when. The first step of SOA is understanding this principle of who delivers what, where and when.
Some examples of the who, what, where and when are outlined in the below.
Who; an organization, a person, a service provider, a company.
What; version information in xml, system status from a web service, a physical package in the dimension of 20×20, 1000 rows of analyzed data.
Where; WWW, central database, reception.
When; hourly, daily, every 10th second, on demand.
Please note, that the above examples stretches beyond the normal defining of SOA, which is usually limited to software designs.
What makes this interesting is that this approach will save you time and despair when things are just not working together. Things are often not working together because they were not thought or designed with the other side in mind, this is completely normal. However having defined the four w’s, makes it a lot easier to integrate into these alien areas and comprehending them into a familiar context.
Lets bring back the handshake again. The term handshake has been used commonly within the service industries, were you deliver a service to another person. That can be either a customer or a colleague, make sure that you hand over your work properly, and insure the handshake. That is the exact same which is fundamental in SOA architecture, make sure you have a handshake between your services.
So fundamental thoughts in place, lets fold out a bit. As previously mentioned, SOA is primarily used in designing software applications. Loosely coupled, unassociated functions are very widely used terms in conjunction with SOA. As right as this might be, we should look at this much wider, open the possibilities and expand the perspective. Services exists in much wider terms outside the software world. Whenever a department interacts with another, they are performing a service, handing over processed requests, to other departments who again process these requests until they are handed over to some other company, which completes the service cycle within the first company. Looking at these service cycles using the SOA perspective, should aid in defining them and thereby improving them. Making it easier to integrate, to expand and reduce total service process cost.
So summarizing the above, service oriented architecture is an organizational direction, much more than a software architecture design pattern. Thinking your organization in services just makes it a lot easier to implement IT systems as well 🙂
SOA – a perspective of the handshake (located on Google drive)