Enterprise service bus offers streamlined integration

The enterprise service bus as a concept has increasingly gained currency in the IT marketplace, even as vendor camps have squabbled over what exactly an ESB is. As a result, many organizations remain uncertain about the need for and role of an ESB in their IT infrastructures. Is an ESB just gussied-up message-oriented middleware, or is it a genuinely new approach to integration?

In response to client inquiries regarding the definition of an ESB, Mike Gilpin, an analyst at Forrester Research Inc., published a report that described the technology as“software infrastructure that enables service-oriented architectures (SOA) by acting as an intermediary layer of middleware through which a set of reusable business services are made widely available.”

An ESB typically has some sort of “bus” messaging technology, such as Java Message Service or IBM’s MQSeries, and support for Web services standards. The standards support is designed to let enterprises map data from disparate systems, route messages, ensure that services are delivered in the correct order and enforce security rules automatically by using XML instead of changing code in the interfaces of services.

The ESB has evolved to meet users’ demands for a way to integrate applications that’s easier than traditional enterprise application integration (EAI). EAI systems require coding to link applications and can cost as much as 10 times more. Enterprises are looking to ESBs to provide the runtime infrastructure for making loosely coupled applications work. If you have a bunch of services doing different things, an ESB can compose them together. It allows you to run these processes over a long period of time. This bus must be very reliable, meaning that it can guarantee that your message has been received.

The largest group of companies using ESBs are those that need Web services for integration with existing message-oriented Common Object Request Broker Architecture (CORBA) or other integration technologies. Companies want to move toward a service-oriented approach, but they can’t throw away the investments they have made so far.

About 25% of companies using ESBs are replacing existing EAI platforms with the technology. They are saying that EAI was oversold and it didn’t fulfill all their expectations. If it turns out that 80% of their requirements are satisfied by one of these lighter-weight ESBs, they are using them.

Then,how it works?The heart of a ESB is an enterprise messaging backbone that can asynchronously transport data as messages. The messaging core could be proprietary messaging-oriented middleware, MOM technology based on JMS, MOM based on the WS-Reliable Messaging standards, or generic messaging engines. Each of the applications or services connected by the ESB becomes a service endpoint. The ESB provides a layer of abstraction from underlying protocols and defines a process flow that allows individual services be invoked across the transport layer.

企業服務總線提供完美的集成

盡管廠商們對ESB究竟是什么樣還存在著爭議，但企業服務總線(ESB)作為一個概念在IT市場日益受到追捧。結果，很多機構對是否需要ESB以及ESB在其IT基礎設施起什么作用仍未確定。不知ESB到底只是一個被炒作起來的面向消息的中間件，還真是集成的新方法?

Forrester研究公司的分析師Mike Gilpin在回答客戶有關ESB定義的詢問時，發表了一篇報告，將此技術描寫成“通過起到中間件的中間層作用而實現面向服務架構(SOA)的軟件基礎設施，通過這樣的中間件，就能廣泛利用一套可重復使用的商業服務?！?/P>

通常，ESB擁有某種“總線”傳輸技術(如Java Message Service(JMS)或者IBM的MQSeries)，以及支持Web服務標準。支持這種標準是為了讓企業映射來自各個異型系統的數據、路由消息，確保以正確的次序提交服務，以及利用XML代替改變服務界面中的程序代碼以自動實施安全規則。

ESB的進步已能滿足用戶對集成應用程序的需求，該集成方法比傳統的企業應用程序集成(EAI)更為容易些。為聯接應用程序EAI需要編程，其成本也要高出10倍之多。EAI系統企業正期待著ESB能提供運行時基礎實施，以便使松散耦合的應用程序能工作。如果你有很多做不同事情的服務，那么ESB能將它們組合在一起。這就能讓你在一段很長的時間內運行這些進程。此總線必須非?？煽浚簿褪钦f它能保證收到你的消息。

利用ESB最大的公司團體是那些需要用Web服務集成現有面向消息的CORBA(公共對象代理體系結構)或者其他集成技術的公司。公司需要朝面向服務的方法轉移，但是他們不能扔掉已經投入的投資。

大約25%使用ESB的公司正在用此技術替代現有的EAI平臺。他們說對EAI的宣傳過頭了，它未能達到預期。如果結果表明某個輕便的ESB能滿足他們80%的要求，他們就用。

那么，它是如何工作的?ESB的核心是企業消息傳輸主干，它能異步地將數據作為消息傳送。這種傳送的內核可以是專有的面向消息中間件(MOM)，如基于JMS的MOM技術、基于WS-Reliable Messaging標準的MOM、或者一般性的傳信引擎。由ESB聯結的每個應用程序或服務成為了一個服務點。ESB提供了基礎協議的抽象層并定義了進程流，它允許在傳輸層上調用各個服務。