SOA? ESB? What is all this?
Lots of nice articles have been published on the net on both Service Oriented Architecture (SOA) and Enterprise Server Bus (ESB). This topic is being discussed quite heavily for last few years but started gaining weight as ESBs started getting more and more matured. To start this series, I am planning to put together information which I found to be very useful when I started working on this project. Some of this information has come from other blogs, company websites (JBOSS, IBM, Cape Clear, BEA, Microsoft etc.). I am planning to add my experiences when we carried out performance analysis of one of the ESB implementations.
According to definition in Wikipedia, Service Oriented Architecture (SOA) is a computer systems architectural style for creating and using business processes, packaged as services, throughout their lifecycle. SOA also defines and provisions the IT infrastructure to allow different applications to exchange data and participate in business processes. SOA seems to have its roots in how Business people view IT. They tend to view IT in terms of business functions they support and tend to break it along the verticals like Ordering, Manufacturing, Delivery, Customer Relationship management etc. According to them these functions talk to each other in order do the work.
But wasn’t this happening already? Enterprise Application Integration (EAI) was evolved to solve this problem. In a typical EAI solution, one application would send a message to other application regarding event/change that other application needed to know and other application in turn would respond to this change. Lot of intelligence was built on top of this simple messaging in order to help routing of these messages, making sure that the data is delivered in the format the applications understand. (Fig. 1)
This solution resolved the issue of tight coupling that was introduced due to earlier point to point integration solutions but also presented some new challenges. The first one was there was no standardization among the EAI vendors. This means that if applications in manufacturing domain are integrated using one EAI solution and Delivery domain is integrated using other vendor, they still will not be able to communicate with each other. Customer would be locked in to a particular vendor. More importantly there was no way for the applications to describe themselves or discover the data they need.
This is where Service Oriented Architecture (SOA) started to play a role. SOA significantly improved the interoperability. In a typical SOA environment, there is a service provider and service consumer. In order this to work, there also needs a mechanism so that they can communicate with each other and also describe and discover themselves (Fig.2)
W3C has defined open standard for web services in order to make SOA work. A web service uses XML based Simple Object Access Protocol (SOAP) for communication between service provider and service consumer. Service provider exposes the services it provides as interfaces defined by Web Service Definition Language (WSDL). Universal Description, Discovery and Integration (UDDI), a platform-independent, XML-based registry, is used for looking up the services.
Enterprise Service Bus (ESB) provides an infrastructure to implement this SOA concept. Instead of going back again to point to point integration to implement SOA, ESBs extend knowledge gained in EAI work that simplifies the integration and flexible use of business components. ESBs facilitate standards based integration but are not limited only to do a web services based integration e.g. the messages are not required to use only http protocol for communication. A service consumer can send his request using http protocol but the service provider provides data using JMS. The ESBs make this communication possible. In general, they support message based transport like in EAI and also provide describe and discover facility for service provider and service consumer. Although WSDL is used to describe the interfaces, UDDI based registries are not very common yet.
ESBs also provide mechanisms for security, mechanisms for implementing some level of service level agreements (SLA), routing and transformation capabilities all of which vary to some extend from vendor to vendor.
Fig. 3 shows the typical ESB architecture.
No comments:
Post a Comment