| 词条 | Enterprise service bus | ||||||||||||||||||||||||||||||||||||||||||||||
| 释义 |
An enterprise service bus (ESB) implements a communication system between mutually interacting software applications in a service-oriented architecture (SOA). It implements a software architecture as depicted in the picture. As it implements a distributed computing architecture, it implements a special variant of the more general client-server model, wherein, in general, any application using ESB can behave as server or client in turns. ESB promotes agility and flexibility with regard to high-level protocol communication between applications. The primary goal of the high-level protocol communication is enterprise application integration (EAI) of heterogeneous and complex service or application landscapes (a view from the network level). OverviewThe concept is analogous to the bus concept found in computer hardware architecture combined with the modular and concurrent design of high-performance computer operating systems. The motivation for the development of ESB was to find a standard, structured, and general purpose concept for describing implementation of loosely coupled software components (called services) that are expected to be independently deployed, running, heterogeneous, and disparate within a network. ESB is also a common implementation pattern for service-oriented architecture. WorkingAn ESB applies the design concept of modern operating systems to independent services running within networks of disparate and independent computers. Like concurrent operating systems, an ESB provides commodity services in addition to adoption, translation and routing of client requests to appropriate answering services. The primary duties of an ESB are:
Ambiguous use of the term ESB in commerceThere is no global standard for enterprise service bus concepts or implementations.[1] Most providers of message-oriented middleware have adopted the enterprise service bus concept as de facto standard for a service-oriented architecture. The implementations of ESB use event-driven and standards-based message-oriented middleware in combination with message queues as technology frameworks.[2] However, some software manufacturers relabel their existing middleware and communication solutions as ESB without adopting the crucial aspect of a bus concept. HistoryThe first published usage of the term "enterprise service bus" is attributed to Roy W. Schulte from the Gartner Group 2002 and the book The Enterprise Service Bus by David Chappell. It should be noted that Schulte asserted that: "The most direct ancestor to the ESB was Candle’s Roma product from 1998"[3] whose chief Architect and patent application holder was Gary Aven.
ESB as software{{unreferenced section|date=October 2014|reason=reads like a bunch of short essays}}The ESB is implemented in software that operates between the business applications, and enables communication among them. Ideally, the ESB should be able to replace all direct contact with the applications on the bus, so that all communication takes place via the ESB. To achieve this objective, the ESB must encapsulate the functionality offered by its component applications in a meaningful way. This typically occurs through the use of an enterprise message model. The message model defines a standard set of messages that the ESB transmits and receives. When the ESB receives a message, it routes the message to the appropriate application. Often, because that application evolved without the same message model, the ESB has to transform the message into a format that the application can interpret. A software adapter fulfills the task of effecting these transformations, analogously to a physical adapter.[4] ESBs rely on accurately constructing the enterprise message model and properly designing the functionality offered by applications. If the message model does not completely encapsulate the application functionality, then other applications that desire that functionality may have to bypass the bus, and invoke the mismatched applications directly. Doing so violates the principles of the ESB model, and negates many of the advantages of using this architecture. The beauty of the ESB lies in its platform-agnostic nature and the ability to integrate with anything at any condition. It is important that Application Lifecycle Management vendors truly apply all the ESB capabilities in their integration products while adopting SOA. Therefore, the challenges and opportunities for EAI vendors are to provide an integration solution that is low-cost, easily configurable, intuitive, user-friendly, and open to any tools customers choose. Characteristics
¹ Some do not regard process choreography as an ESB function. For example, see M.Richards.[5] ² While process choreography supports implementation of complex business processes that require coordination of multiple business services (usually using BPEL), service orchestration enables coordination of multiple implementation services (most suitably exposed as an aggregate service) to serve individual requests. These solutions often focus on low-level ESB functions, such as connectivity, routing and transformation, and require coding or scripting to implement orchestration.[6] Developers operating at a project or tactical level, e.g., just trying to fix a problem, often gravitate toward lightweight service bus technologies, but there is often ongoing tension between these initiatives and an enterprise architecture whose goal it is to optimize infrastructure across multiple projects.[7] If the message broker, the ESB software, translates a message from one format to another, then as with any translation, there is the issue of semantics of the message. For example, a record can be translated from JSON to XML, but the same set of fields can be interpreted differently by different applications, specially in the case of the various corner cases that are usually known only to developers that have extensive experience with the application that is connected to the ESB. For the known corner cases the number of tests that cover all corner cases increases exponentially with every application that is connected to the ESB, because every ESB-connected application must be tested against every other application that is connected to the ESB. Key benefits
Key disadvantages
See also
Products{{See also|Comparison of business integration software}}Notable products include: {{colbegin}}
Books
References1. ^{{cite web |first = Raul |last = Lapeira |author = |authorlink = |title = ESB is an architectural style, a software product, or a group of software products? |url = http://www.consultoriajava.com/articulos/esb_arquitecture_software_product.jsp |work = |publisher = Artifact Consulting |accessdate = 2010-04-16 |quote = The first thing a ESB architect should have in mind is that as of 2010 there is no global standard for ESB. |archive-url = https://web.archive.org/web/20140808053149/http://www.consultoriajava.com/articulos/esb_arquitecture_software_product.jsp |archive-date = 2014-08-08 |dead-url = yes |df = }} 2. ^Curry, Edward. 2004. "Message-Oriented Middleware"{{dead link|date=September 2017 |bot=InternetArchiveBot |fix-attempted=yes }}. In Middleware for Communications, ed. Qusay H. Mahmoud, 1-28. Chichester, England: John Wiley and Sons. {{doi|10.1002/0470862084.ch1}}. {{ISBN|978-0-470-86206-3}} 3. ^{{Cite web|url=https://stackoverflow.com/questions/773503/difference-between-a-message-broker-and-an-esb|title=Difference between a Message Broker and an ESB|last=|first=|date=|website=|language=|access-date=2017-07-19}} 4. ^http://shop.oreilly.com/product/9780596006754.do 5. ^{{cite web | last = Richards | first = Mark | title = The Role of the Enterprise Service Bus (presentation) | url=http://www.infoq.com/presentations/Enterprise-Service-Bus | accessdate = 2009-06-04 | quote = I do not consider process choreography part of an ESB, if we consider an ESB as a high-speed messaging middleware. However, I do consider process choreography part of the ESB *platform*. Fortunately most ESB vendors separate out these major components into different products, but package them under a consolidated ESB offering. So, in the strictest sense of the word, no, I would not consider it as part of an ESB. It is a related capability.}} 6. ^{{cite web|last=Feraga|first=Matthias|title=How to: choosing between lightweight and traditional ESBs|url=http://blog.octo.com/en/choosing-between-lightweight-and-traditional-esbs/|publisher=Octo|accessdate=23 April 2014|date=6 Jun 2011}} 7. ^{{cite web|last=Fulton|first=Larry|title=Learn How to Embrace Lightweight ESBs|url=http://www.forrester.com/Learn+How+To+Embrace+Lightweight+ESBs/fulltext/-/E-RES43339|publisher=Fo2014|date=12 Sep 2007}} External links
|first = Adrien |last = Louis |authorlink = |author2=Marc Dutoo |title = Choosing between Routing and Orchestration in an ESB |url = http://www.infoq.com/articles/louis-dutoo-esb-routing |work = InfoQ |publisher = |location = |doi = |date = 2010-07-02 |accessdate = 2009-07-02 |quote = }}
4 : Enterprise application integration|Message-oriented middleware|Service-oriented (business computing)|Software architecture |
||||||||||||||||||||||||||||||||||||||||||||||
| 随便看 |
|
开放百科全书收录14589846条英语、德语、日语等多语种百科知识，基本涵盖了大多数领域的百科知识，是一部内容自由、开放的电子版国际百科全书。