The Prospects of SOA
Service Oriented Architecture better know as SOA is an architectural paradigm which makes the software applications expose their functionalities in the form of services to their users. The principles of SOA dictate that it should be inter-operable. SOA puts forward the use of open standards in order to achieve this goal. These open standard help the software application to communicate with each other in a language which is understandable to both ends i.e the sender and the receiver.
SOA is generally targeted for enterprise level applications where the buyout of products and technologies is varied and unpredictable. The benefits of SOA to enterprise can be easily realized in situations where enterprises refrain to stick to a particular vendor and still want their applications to communicate within themselves.
Why Enterprises Seek SOA
AnÂ article from JavaWorld targeting the 6 burning questions for SOA states that
When you have a SOA environment, the same business service may be used in 10 different way.
The statement is enough to explain why enterprises are aggressively trying to leverage the use of SOA in their applications. This is because enterprises use a large number of applications for their various needs and these applications being different in nature and implementations cannot be easily modified to be used collaboratively.
Flexibility poses a drawback for the enterprises in deciding which product to go for and further down the line makes them more vendor dependent. Vendor dependency is the major hindrance for any organization since the more they stick to a particular vendor the more stringent becomes the matter for enhancements unless the vendor makes an attempt to do it on their behalf. The article mentions also that:
You canâ€™t look at this for short-term benefit because in fact the real gain happens when change happens.
Change management is the ultimate test of the time in software development. Yet all the changes cannot be visualized during application design. It make the application vulnerable in the event of large changes which arise when business policies change. The mergers and acquisitions which happen in an organization on a frequent basis puts forward the biggest problem on their application integration. This causes a domino effect in the enterprise applications since the upgrade should be echoed in each and every inter-dependent module.
SOA brings in the plug and play nature to enterprise level applications. Any modules which adhere to principles of SOA are well equipped for changes and new changes thus can be easily incorporated within the applications within a less span of time. The reason for this is that SOA advocates that an application should be mapped to a business perspective rather than a technical perspective and hence the application should resound business architecture and not the technological architecture. The benefits of SOA can be understood from a statement made in the article as:
When we started that the cost of bringing on a new partner was anywhere from $40,000 to $50,000, now itâ€™s down to $3,000 or $4,000.
Where are thou architects?
Though the benefits from SOA is evident we can see many organizations failing to get the driving force for SOA implementation. The reason of this failure is simple i.e lack of expertise. In a regular scenario for software development the business requirements are taken by the technical team and then they are implemented as business components in the business tier. But this tier is tightly coupled with the underlying technology and platform. This is because the business requirements are implemented by first deciding which technology and platform should it be based on and then the requirements are visualized in the form of technical components. This starts the progression of platform and vendor dependency.
SOA on the other hand, advocates the need of a business architecture and not technical one. For designing such an architecture is it utmost important that the technical team also has business expertise which is not commonly found in current scenarios. Hence for making an impact with SOA in any organization the business and the technical team should work hand in hand, without which, once again it would be heading the path for future problems even with an SOA architecture. For this a technical person must mature himself in the business domain he is working for.
Price for Independence
SOA is based on open standards which means that any service can communicate with another service residing anywhere in the world when both are SOA compliant. To develop such services vendors make tools which help in having rapid development activities for making services. Such vendors include some of the big names as in IBM, BEA, TIBCO, Microsoft, etc. Such tools are most of the times expensive. The expenses incurred for an enterprise for implementing SOA is sometimes more than expected. In the article, West says :
SOA has open standards that you build to so that you can use these vendor products more or less interchangeably. Microsoft has a more Microsoft-centric approach toward Web services.
It is not only with Microsoft but with all the vendors. The concepts like ESB (Enterprise Service Bus), SDO (Service Data Objects) and SCA (Service Component Architecture) have arisen by the advent of SOA but these concepts are still vendor dependent. That means even if you have implemented SDO’s in a BEA product you cannot blindly import them in a product of IBM and also a TIBCO ESB cannot communicate with an IBM ESB.
Vendors somewhere down the line always look to provide vendor dependent implementations in the name of optimized techniques. This hampers an organization if it on the lookout of options in the market. By making them again sticking to a particular vendor is just like the good old phrase “old wine in an new bottle“. Such internal dependencies make the expenses for an organization too large to handle when changes comes into picture. This often comes in as a lack of expertise of practitioners of modular designs in the field of SOA.
There are probably 15 vendors that offer a solid enterprise service bus, but industry efforts in managing data are less mature.
Security and Complexity
SOA is not a technology. It is a revolutionary business oriented concept for enterprises. But for implementing SOA, a technology overhaul is needed. This makeover includes, gaining proficiency in architectural designs and modeling business components as services. If we take into consideration the current implementations done for SOA by web services then we see XML as the medium of communication. XML is by nature heavy for communicating on a network. Making use of XML for all the requirements will definitely push the need to increase speed of transfer and ultimately cause the organization to perform and net-ware upgradation. This is not feasible in all circumstances.
If we take the security aspect of SOA then we are likely to face a lot of unanswered questions. The questions include:
- Implementing the monitoring policies of services
- Should there be a one point regulator for the services
- How to overcome the case of a service denials
- How to Optimize the data transfer for avoiding bottlenecks
Sure there are a solution or two for all the above problems but they come at the cost of heavy layering of your tiers. Security aspects like SAML and XACML make services more heavy and complex. In the article David Jacobs says,
“Since each application in a SOA is composed of many individual software components, a failure anywhere in the network can bring down an application.”
Sure computers are super but what about network? There is still no guarantee of networks performing with 100% guarantee. We have managed to leverage the computing power to a respectable amount and server performance through faster processors and clustering respectively. But SOA is a true distributable architecture which depends heavily on the one and the most important backbone i.e network. Big Enterprises can have SOA efficiency with the purchase of lease lines and third party security providers.
We can see that the total cost of SOA implementations considering all these aspects comes to a huge sum. SOA is still in its premature stage and getting it spread across into all kinds of businesses and applications will take time. We still need to see more implementations so that it can grow and become more established in all aspects. In other words a full fledged SOA implementation is still far from reality!