There are many different styles of applications that are written today. But lately we have seen a paradigm shift where the concept of “Software as a Service” is really been taken seriously. If you are an IT professional chances are 9 times out of 10 you must have heard of the term “Services Oriented Architecture”. What the heck? And you are like “Yeah, I know what that is and you go on … You make an application that consumes a web service!! Bingo!! ” No that’s not what SOA means’s is a new software development model or “An architectural style” where the business layer instead of integrated in the code is rather orchestrated :S . Confused already?? What I have realized over a period of time in the Software Market, whenever a new technology comes don’t jump into that technology and just know the couple POWER Words to horrify your bosses. I bet you 10 to 1 that Mr. John Doe or whatever!! Standing by the coffee machine and boosting about that “New technology” knows little about it.The key idea is to write software as a service ( It may be a web service or a windows service , a service within the enterprise accessible to you from your browser or a service that is published on the internet with a valid WSDL).If you notice the companies that have made it really big during the past year e.g. Google , Amazon and EBay I think the primary reason of their success lies with adopting the new software development paradigms and quickly able to deliver business rules with their service orientation.
So ok!! You want to know what exactly a Services oriented Architecture is. It’s a new software development paradigm which is suitable for applications with distributed processing capabilities .How it helps business?
Information technology is the backbone of nearly all major businesses. Nearly all major businesses today are Information technology driven. Any change in the business rules or business process (ways in which business is conducted) implies a change in the legacy system infrastructure. This change is sometimes difficult to implement as business logic or business rules are implemented as software code. The legacy systems lack the interfaces and are not designed to integrate / interpolate with newer systems, thus the company looses profitable business and a huge factor is the extent to which the legacy systems can be made scalable. We need a new paradigm of Agile Software development where we need to extract the business logic from the actual implementation and expose the data to other applications for quick integration. The idea is to design software architecture around a set of services which are loosely coupled, scalable, reusable and easily integrated. The architecture is called “Services Oriented Architecture” where software can be implemented as a set of loosely coupled and highly cohesive services that may be used by a number of internal / external applications.However, with its advantages there are upfront development costs (time and money) associated with changing the architecture of the software infrastructure and it depends on the nature of the business, the role of IT in the business and the different costs that are required to change the legacy systems whether the company want to adopt the new applications paradigm or not. With that said, it does provide lots of incentives once implemented properly including higher integration options, existence of business process as configurations, higher reusability, a higher degree of compliance with standards , increased cohesion within the sub system and decreased dependencies between subsystems Common misunderstandings:Certain level of misinterpretations and misconceptions about Service Oriented Architecture prevail .The primary misconception of this software architecture building methodology is due to a key technology the Web services. The service oriented architecture and the applications that follow SOA are often confused with just the Web services. Some of the common misconceptions are listed below:
Any application that uses Web services follows a Service Oriented Architecture.
An application that uses a Web service might follow a Service Oriented Architecture or it might not. It depends on the application’s own design, architecture and design considerations that determine its architecture.
SOA is same a re – branding Web services:Many people think that Services Oriented Architecture is nothing more than a marketing term which might be interchanged with Web services. The important concept they are missing over here is SOA is another Software Architecture that results in the functionality being distributed to many independent Services to better process Business processes.
Adopting a Services Oriented Architecture Ensures everything can interoperate:It is not necessary that any application that is developed as per the SOA artifacts would be able to interoperate or integrate necessarily with any other component / application or legacy systems. However SOA gives a high emphasis to increase the degree to interoperability by standardizing the Services produced using SOA.
If you can use a web service with your application you can easily develop applications based on SOA. SOA is the same as distributed computing with Web services. Pitfalls: If there were no potential hazards, problems and everything was ideal with implementing SOA perhaps all the enterprise software today would have been based on Services Oriented Architecture. It depends on the type of functionality, nature of components, exposed interfaces, degree of reusability and working of an application that determines it architecture. Some of the common pitfalls are mentioned below:
Designing and implementing an application like traditional distributed architectures:SOA is a relatively newer agile application development paradigm. Many of the new Services that implement SOA are designed just like a legacy application that followed a distributed architecture. This would involve Remote Procedure Calls, non standardized definition of services and an improper definition of the function boundary resulting in an increased degree of dependency and lowering the functionality contained in the Service.
Not making XML the foundation of application architecture:This also has something to do partly with standardization. All applications that follow SOA should conform to certain standards, the foundation of which is XML.Contemporary SOA cannot be achieved if the internal and external interfaces of the Service don’t use XML as a basis. e.g. A key enabling technology in the Services Oriented Architecture are the Web services. Web services are described using a WSDL (Web Services Description Language) which is XML based. Other than that the BPEL (Business Process Execution Language) and some other key components are also XML based.
Ignoring the Performance Requirements of a Service:Usually due to the communications overhead performance of applications or Services following contemporary SOA can be below the required level of performance. The message processing time for the service should be reduced by optimizing the code , reducing the number of request / response and it should be made sure that the Service meets the required response times and performance criteria. This can be done by extensive testing (Stress testing) for various input / output conditions. Not making the services secure:
SOA is most likely to be used as architecture for distributed applications. SSL (Secure Socket Layers) is not the security consideration here. The application designers should also consider the WS-Extensions and security frameworks provided by other vendors in order to provide a standardized software design that follows SOA principles.
Now you would ask hey hey hey!! Wait a second: S!! How BPEL, ESB, grid computing and the Business Intelligence do fits in? What the heck are these J I would be happy to explain if you have that in mind.For now just like John Doe who is standing by the coke machine hehehehe understands that BPEL is the Business Process Execution Language, ESB is the Enterprise Service bus and Grid Computing hmmm has many concepts for virtualization? Technically speaking these all are layers of the Architecture we discussed about called SOA and how these are written , mainly in XML yes business rules with xml is BPEL. ESB is where the services are available on one on many services. It can be taken as the medium where the services reside on the www. If you have any questions / suggestions / queries / ideas in your mind do post your comments. Thanks Note: I have taken the concepts of these pitfalls and disadvantages from a book on Services Oriented Architecture(Concept Technology and Design) by Thomas Erl