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.

For more complete information about compiler optimizations, see our Optimization Notice.

10 comments

Top
Laim H.'s picture

Great article. It would be nice if it placed some recommendations for software solutions that can be used at each level and how they are implemented (TCP message queue's, reliable multicast ect) . e.g. we use the Microsoft SOAP Toolkit 3.0 to interface to a Mesongo RMF driven ESB.

anonymous's picture

This has been the best article related to SOA & ESB I have come across.
Especially the way ESB has been explained.

anonymous's picture

it helped thanks

anonymous's picture

SOA gives us the flexibility, scalability and the required visibility if we implement SOA in our project and if it is a success. While selecting the SOA software for our project itself is an achievement and it should be presumed that we have succeeded 50%, the rest 50% of success certainly lies in the following five important aspects discussed below:
1. Selection of the proper SOA software vendor
2. Loose – tight coupling balance
3. Scalability Planning Management
4. Business Oriented Processes
5. Monitoring and governing the Entire Solution

thiamchunkoh's picture

Service Oriented Architecture (SOA) can be implemented with Open Enterprise Service Bus (Open-ESB) as Middleware (Message Oriented Middleware, MOM) using Web Services Business Proceess Execution Language (WS-BPEL) as Business Architecture and (WS-JSDL) for Job Submission Description language for Job Submission Computation (Work Flow Notation) executeed in High Performance Computing (Grid, Cluster or Cloud) SaaS (Software as a Service can also be implemented in Architectured Enterprise 2.0 consisting of Web 2.0 and using Parallel Computing as a benchmark and fundemental for High Performance Java API and High performance MySQL as RDBMS backend database application server while SMP, MPP for Web server procesing running under HTTP or HTTPS and TLS,SSL and PKI with proxy component on GSI (Grid Sercurity Infrastructure) without reinventing the e-Infrastructure on different IT Vendor technologies or programming language platform like JAVA EE, CORBA, DCOM, COM,OLE, RPC and DLL Library or other technologies Library component for interoperation with existing API or MPI methods

anonymous's picture

You may also want to look at the next generation XML parsing technology called vtd-xml to signficantly improve ESB performance for routing and xpath

anonymous's picture

The only explanation that made me understand the correlation among SOA, ESB, SOAP, JMS, WSDL, UDDI, and XML. Thanks man.

anonymous's picture

This explanation of ESB and SOA has been excellent! it was put forth in very simple yet strongly conveying manner.

anonymous's picture

We have tried these libraries for Intel-IT's ESB solution that uses BEA's AquaLogic. That resulted in 18% performance benefit in XSLT (266K XML file with a 6K style sheet).

anonymous's picture

Have you had any experience in using the Intel XML SW Suite to improve ESB performance?

Add a Comment

Have a technical question? Visit our forums. Have site or software product issues? Contact support.