Enterprise Service Busses and related concepts like Service Oriented Architectures are increasing in popularity. Businesses are facing new challenges and networking, inter- and intra enterprise cooperation and collaboration are getting more and more crucial for being ahead of the competitors.
Enterprise Service Buses are providing a necessary, high- scalable and flexible IT architecture for integration, an improved communication, and reducing complexity at least in theory.
The major goal of this project seminar is to examine the practical use of ESB. The first part of this documentation will provide the reader with some theoretical foundations on the Enterprise Service Bus, integration paradigms and some required functions of Enterprise Service Buses.
The following section will then focus on one specific Open Source ESB – the Apache ServiceMix that will be presented briefly. Its main functions and concepts will be examined in detail. Furthermore the setup of a generic development environment, debugging principles and tools will be described.
The following part is the development of an explorative case study that illustrates important features and characteristics of an ESB in a practical way. The focus is to illustrate the routing and messaging capabilities of Apache ServiceMix. Based on an everyday example, the message flow in a restaurant, we are trying to demonstrate development principles, analyze useful patterns and also illustrate common pitfalls and challenges.
In the final part, lessons learned and some generic recommendations for possible applications of ESBs are presented. The project team is observing that ESB is a highly important integration model especially in Service Oriented Architectures. Furthermore for some single and clearly defined scenarios the functions provided by Open Source ESBs are already satisfactory. On the other hand side, ESBs are still emergent, there are a lot of instability, complexity and a lack of development tools. The recommendation is to clearly evaluate ESB and also optional other solutions before its practical application in a real world scenario.
Table of Contents
1. Introduction
2. Foundations of Enterprise Service Buses
2.1. Enterprise Integration
2.2. EAI vs. ESB
2.3. Simple ESB example
3. Functional requirements for an Enterprise Service Bus (ESB)
3.1. Message Exchange / Routing Facilities
3.2. Message Transformation
3.3. Protocol Transformation
3.4. Security
3.5. Quality of Service
3.6. Management and Monitoring
3.7. The architecture of an ESB
4. Apache ServiceMix
4.1. Decision for ServiceMix
4.2. Components of JBI compliant ESBs
4.3. Functionalities of Apache ServiceMix
4.4. Summary of ServiceMix
4.5. Installation of ServiceMix
4.6. Development Environment
4.7. Deployment Environment
4.8. Debug Environment
5. Case Study: Future Restaurant
5.1. Description of the Case Study
5.2. Architecture
5.3. Messages
5.4. Components of the Case
6. Conclusion
7. Attachments
7.1. Documentation of Apache ServiceMix
7.2. Useful Links
7.3. Web Service development: Bottom- Up Approach
8. Literature
List of Figures
Figure 1: Point-to-point integration (Source: [Horn, Thomas])
Figure 2: Enterprise Application Integration (Source: [Horn, Thomas])
Figure 3: Enterprise Service Bus (Source:[Rademakers, Dirksen 2008, p.7])
Figure 4: Point-to-Point Model (Source: [Breest 2006, p. 9])
Figure 5: Publish-Subscribe Model (Source: [Breest 2006, p. 9])
Figure 6: Service Container (Source: [Breest 2006, p. 9])
Figure 7: Functionality of Service Containers (Source: [Breest 2006, p. 12])
Figure 9: Provider and Consumer (Source: [Rademakers, Dirksen 2008, p. 63])
Figure 10: Normalized Message Router (see: [ServiceMix Homepage 2009])
Figure 11: Structure of a Service Assembly
Figure 12: Hotdeploy archive structure
Figure 13: Debugging properties for Eclipse
Figure 14: Traditional Workflow in a Restaurant
Figure 15: Improved Workflow
Figure 16 . Message Flow through ESB components
Figure 17: simple-sa.zip Directory structure of the restaurant case
Figure 18: SEDA message flow (Source: http://ServiceMix.apache.org/nmr-flows.html)
Figure 19: ServiceMix components and request message flow
Figure 20: Routing Slip/ Bean scenario
Figure 21 . Custom Content Based Router
List of Tables
Table 1: Dimensions of the ESB definition
Table 2: Routing Functionality of ESBs (referring to [Rademakers, Dirksen 2008, p. 69])
Table 3: The most used JBI SEs provided by ServiceMix (referring to [Rademakers, Dirksen 2008, p. 66])
Table 4: Most used Binding Components provided by ServiceMix (Referring to [Rademakers, Dirksen 2008, p. 66])
Table 5: Message Exchange Pattern (Referring to [Rademakers, Dirksen 2008, p. 60])
Table 6: Routing Patterns supported by the EIP service engine provided with ServiceMix (referring to [Rademakers, Dirksen 2008, p. 69]
Table 7: The main components of the JBI specification (referring to [Rademakers, Dirksen 2008, p. 65]/ .[Binildas 2008, p. 40])
Table 8: Environment variables for JAVA, ANT and ServiceMix
Table 9 Support Links for Loggin
Table 10 CXF Components ServiceMix
Listings
Listing 1: jbi.xml Service Assembly (snippet)
Listing 2: ServiceMix console output for debugging
Listing 3: servicemix.bat options for debugging
Listing 3: log4.xml - Log (snippet)
Listing 4: example.xml Example order message
Listing 5: cxf-bc-su/COS.wsdl Customer Order Service WSDL (snippet)
Listing 7: cxf-bc-su/xbean.xml Configuration for straight through Request COS (snippet)
Listing 8: cxf-bc-su/xbean.xml Configuration for Request/Response CTS (snippet)
Listing 9: cxf-bc-su/wsdl/COS.wsdl Sample WSDL File COS/CTS (snippet)
Listing 10: cxf-se-su/xbean.xml Configuration for Request/Response CTS (snippet)
Listing 11: COSPortTypeImpl.java JAX-WS annotation for COSService (snippet)
Listing 12: simple-routing-su/xbean.xml Splitter and KOCService invocation (snippet)
Listing 13: cxf-KOC-bc-su/xbean.xml Configuration for Kitchen Order Client (snippet)
Listing 14: CXF-servlet.xml Configuration for Kitchen Order Web Service (snippet)
Listing 15: simple-jms-su/xbean.xml JMS Service Uni (snippet)
Listing 16: simple-bean-su/xbean.xml Bean BC (snippet)
Listing 17 ps.component/ErrorHandlerComponent.java Error Handler implementation (snippet)
Listing 17: simple-validation-su/xbean.xml Validation component (snippet)
Listing 19 simple-routing-su/xbean.xml Recipient List (snippet)
Listing 20: simple-routing-su/xbean.xml Pipeline (snippet)
Listing 21: simple-routing-su/xbean.xml Content-based Router(snippet)
Listing 22: simple-routing-su/xbean.xml XPath Splitter (snippet)
Listing 23: simple-xslt-su/xbean.xml XSLT transformation (snippet)
Listing 24: simple-xslt-su/resources/foods.xsl XSLT File (snippet)
Abbreviations
illustration not visible in this excerpt
1. Introduction
Enterprise Service Busses and related concepts like Service Oriented Architectures are increasing in popularity. Businesses are facing new challenges and networking, inter- and intra enterprise cooperation and collaboration are getting more and more crucial for being ahead of the competitors.
Enterprise Service Buses are providing a necessary, high- scalable and flexible IT architecture for integration, an improved communication, and reducing complexity at least in theory.
The major goal of this project seminar is to examine the practical use of ESB. The first part of this documentation will provide the reader with some theoretical foundations on the Enterprise Service Bus, integration paradigms and some required functions of Enterprise Service Buses.
The following section will then focus on one specific Open Source ESB – the Apache ServiceMix that will be presented briefly. Its main functions and concepts will be examined in detail. Furthermore the setup of a generic development environment, debugging principles and tools will be described.
The following part is the development of an explorative case study that illustrates important features and characteristics of an ESB in a practical way. The focus is to illustrate the routing and messaging capabilities of Apache ServiceMix. Based on an everyday example, the message flow in a restaurant, we are trying to demonstrate development principles, analyze useful patterns and also illustrate common pitfalls and challenges.
In the final part, lessons learned and some generic recommendations for possible applications of ESBs are presented. The project team is observing that ESB is a highly important integration model especially in Service Oriented Architectures. Furthermore for some single and clearly defined scenarios the functions provided by Open Source ESBs are already satisfactory. On the other hand side, ESBs are still emergent, there are a lot of instability, complexity and a lack of development tools. The recommendation is to clearly evaluate ESB and also optional other solutions before its practical application in a real world scenario.
2. Foundations of Enterprise Service Buses
This part of the Documentation shortly outlines the foundations of ESBs and provides theoretical background on Integration models.
2.1. Enterprise Integration
The main task of Enterprise Service Buses is the integration of heterogeneous and distributed applications inside or across enterprises.
State of the art integration of cross-company and intra-company applications often is time-consuming, expensive and hard to manage. To integrate different applications, there are several approaches and concepts:
2.1.1. Point-to-point integration model
In the point-to-point integration model each application is connected directly to cooperative applications or clients. This leads to tightly coupled application systems that are considered unreliable, insecure and hardly manageable. For each application a custom integration solution has to be implemented.
illustration not visible in this excerpt
Figure 1: Point-to-point integration (Source: [Horn, Thomas])
A change in one application leads to potential n-1 changes, whereas n is the number of connected applications. A study published by Gartner [2002] states that in enterprises, the maintenance and management expenses of the point-to-point links in place needs on average 35% of the overall IT Budget.
2.1.2. Enterprise Application Integration (EAI)
The successor of the point-to-point integration is an EAI approach. This type of integration is also called hub-and-spoke model and uses a centralized EAI broker to exchange messages between the several applications. [see Rademakers, Dirksen 2008, p. 4f]. The main advantage of the point-to-point model is the ability to connect applications through a central message broker or Middleware. The main disadvantage is its centralized architecture and the lock-in to specific vendors.
illustration not visible in this excerpt
Figure 2: Enterprise Application Integration (Source: [Horn, Thomas])
2.1.3. Service Oriented Architecture (SOA)
A new more decentralized approach to integration is Service Oriented Architecture (SOA). The main theoretical foundations of SOA are services that are communicate and exchange data. A service is provided by an application called service provider and consumed by another application called service consumer to support more complex business processes. The services are usually stored in a repository and can be bound dynamically. Woolf [see Woolf 2005] describes two significant challenges for SOA:
1. How does the consumer find the provider of the service it wants to invoke?
2. How can consumers invoke services quickly and reliably, despite the fact that distributed or networked applications are usually slow and unreliable?
Facing this challenges a new approach, the Enterprise Service Bus (ESB) has evolved
2.1.4. The Enterprise Service Bus (ESB)
An Enterprise Service Bus (ESB) is a decentralized messaging infrastructure and often associated with SOA. Since ESB is an emerging concept, there is currently no universal definition for ESB in the academic and professional world.
In literature, there are several opinions what an ESB generally is. Breest [see Breest 2006, p.20] introduced three categorizations to foster a general discussion about ESBs.
1. ESB is an approach “on doing things”
2. ESB is a generic product type
3. ESB is new architecture principle
Gartner on the other side defines ESB in the following way.
"An Enterprise Service Bus (ESB) is a new architecture that exploits Web Services, messaging middleware, intelligent routing, and transformation. ESBs act as a lightweight, ubiquitous integration backbone through which software services and application components flow." [Gartner 2008]
Definition by Forrester:
"Infrastructure software that makes reusable business services widely available to users, applications, business processes, and other services. EBSs achieve this goal by mediating between services. An ESB helps enterprises obtain the value of SOA by increasing connectivity, speeding change, and providing greater control over use of the important resources it binds." [cited through Breest 2006, p.11]
As a conclusion, we have categorized the ESB definition of the literature into four different dimensions.
illustration not visible in this excerpt
Table 1: Dimensions of the ESB definition
2.2. EAI vs. ESB
If you follow the definition above you may recognize that some of the principles that are encapsulated in the ESB are central themes of Enterprise Architecture Integration (EAI), too. In fact ESBs have a lot in common with EAI.
One main difference is the shift from the hub-and-spoke communication to a bus model. In contrast to the hub-and-spoke model, ESBs are using a distributed, decentralized bus, also called normalized message router (NMR) as underlying technical architecture. In this case, functionality is provided by physically separated applications. Furthermore ESB are great adopters of open standards like JMS, XML, J2EE and WS for product implementation. [see Rademakers, Dirksen 2008, p.5f.].
An ESB includes integration functionality, workbenches and a management environment. It provides adapters for many kinds of protocols and applications, therefore new applications are easy to adapt. Every application can be connected, the ESB just need to adopt the Message format of the connected application. An adapter can be implemented to transform the native message format of the application in order to comply with the standard message format of the ESB (jbi:message). After the protocol integration, the ESB can use all other deployed services in order to perform business logic and interact with the application. [see Rademakers, Dirksen 2008, p.6f.]
2.3. Simple ESB example
To explain how an ESB works the following part will introduce a simple scenario:
illustration not visible in this excerpt
Figure 3: Enterprise Service Bus (Source:[Rademakers, Dirksen 2008, p.7])
One application wants to invoke a method of a legacy application. Both are connected to the ESB. For invocation, the requesting application sends an XML (or SOAP, JMS) request to the ESB. After processing the incoming message, the ESB routes the message to the target service, makes a message transformation to the native format of the legacy application, invokes the method and returns the response to the demanding application (again after a transformation back to XML). Furthermore, the ESB provides other functions in the background, for example security, transaction and connectivity functions.
From a business perspective the main benefits of ESB is the facilitation of application integration, from different sources, domains and platforms. This flexibility supports the demand in more agile, flexible and business process supporting applications. In addition, in a long term view, ESBs are considered to reduce the total costs for maintaining and managing IT systems. [see Rademakers, Dirksen 2008, p. 6]
3. Functional requirements for an Enterprise Service Bus (ESB)
Due to the fact that there are several definitions and different approaches describing an ESB, its features could not be uniquely defined. In the following part, we are introducing some standard requirements for an ESB. Please be advised that the features below may have other names in other ESB products.
3.1. Message Exchange / Routing Facilities
A central functionality of an ESB is to provide message exchange or routing facilities. ESBs replace existing approaches like direct synchronous method invocation (for example SOAP over HTTP or remote method invocation (RMI)) by an indirect asynchronous message exchange. In the indirect asynchronous approach the ESB takes care of routing the messages to the right recipient. In general there are four techniques to route and monitor messages through the bus.
illustration not visible in this excerpt
Table 2: Routing Functionality of ESBs (referring to [Rademakers, Dirksen 2008, p. 69])
Open Source ESB Page | 8
3.2. Message Transformation
Applications, providers and consumers have different message format requirements. ESBs have to be able to transform the messages according to the needs of each role and application and enable a format independent exchange. For example, one application connected to the ESB via SOAP might communicate with its counterpart using EDI, another application might use the ebXML standard. The ESB usually uses XML as internal message format so all incoming messages have to be converted to XML, outgoing messages into the applications target format (in this example EDI and ebXML). The format transformations are realized through XSLT. [see Mierzwa 2008, p.12]. The most common format converters (adapters) are already provided by the ESB.
3.3. Protocol Transformation
The transformation of protocols is a very important requirement for integration solutions. The transport protocol conversion logic is implemented in the ESB using different protocol adapters. An ESB has to be able to transform incoming transport protocols in many different outgoing transport protocols by default. The number of supported protocol types can be increased using 3rd party adapters or implementing custom adapters. [see Rademakers, Dirksen 2008, p. 14]
3.4. Security
Due to the fact that the ESB is handling a big number of applications and is dealing with critical business information it provides ways to authenticate users and authorize incoming messages. Another important feature is encryption of the outgoing messages to prevent unauthorized access. [see Rademakers, Dirksen 2008, p.18]
3.5. Quality of Service
For assuring the execution of composite application it is necessary to have Service Level Agreements (SLA) to call another service if the required service is out of order or not accessible. This is a critical requirement for Service Oriented Architecture since composite applications are depending on its single services and distributed applications are usually slow, unstable and unreliable. [see Woolf 2005]
3.6. Management and Monitoring
A management environment is necessary to maintain and manage the ESB. That means administrate and deploy the services, manage the size in queues and monitor the message sizes and the running Web Services. Furthermore in a business environment, it is critical to monitor the fulfillment of Service Level Agreements. [see Rademakers, Dirksen 2008, p. 19f]
3.7. The architecture of an ESB
The main challenge for an ESB is to connect different applications and services. For that reason the ESB has
- to be compatible to several messaging systems (e.g. JMS, ActiveMQ)
- to transform the protocols and messages of the services (HTTP, SOAP)
- to route the messages to the appropriate application endpoint
- to be flexible to integrate custom components and customs protocols Two critical components of an ESB are:
- Message Oriented Middleware (MOM) that routes the messages through the message backbone
- Service Container (SC) that handles services and provide connectivity to the outside world
Both concepts will be covered in the following two paragraphs.
3.7.1. Message Oriented Middleware (MOM)
The MOM is a "highly distributed network of message servers" [Breest 2006, p. 4] and is the backbone of an ESB. It replaces direct communication channels by virtual communication channels. Previous tightly coupled point-to-point paradigms using synchronous remote method invocation (RMI) have changed to loosely coupled indirect interactions via asynchronous message exchange.
In an ESB environment, Messages are the most important communication technique and represent transactions from a theoretical point of view. They consist of a header (contains identification and routing information), a body (the message payload) and properties (application specific values). The Messages are sent via a message oriented middleware that consists of a network of multiple message servers and a number of clients. The MOM routes the message through the bus using “send and forget” or “store and forward” mechanisms. The “store and forward” technique implies that each message is stored on the outgoing message service and will only be deleted after the target service confirms the reception of the message. Several clients are connected to the message servers and run inside a service container, which translate messages into service invocations.
The MOM establishes virtual channels between the connected Web Services. These channels can be realized as a Point-to-Point model or as a Publish-Subscribe model.
illustration not visible in this excerpt
Figure 4: Point-to-Point Model (Source: [Breest 2006, p. 9])
Using a Point-to-Point model a virtual channel between two applications can be described as:
1. The sender sends a message to a queue that is managed by the message server.
2. The message server stores the message temporarily
3. Message receiver (connected to the ESB) fetches the oldest message. If there are multiple message clients only the first gets the message)
illustration not visible in this excerpt
Figure 5: Publish-Subscribe Model (Source: [Breest 2006, p. 9])
Using a Publish-Subscribe model, virtual channels between multiple applications can be implemented.
1. The publisher (sender) publishes the message under a certain topic.
2. The message receiver(s) subscribes the topic and every receiver gets all messages from the topic. The message server manages the topics and for every subscriber a private queue.
3.7.2. Service Container
The Service Container supports applications in:
- Providing business functionality as loosely coupled business services.
- Connecting to the queues and the topics of the MOM.
- Transforming incoming messages into service invocations.
- Establishing communication across protocols and message formats.
- Identifying resources uniquely. The Business services that are represented by an ESB endpoint have an unique address location for referencing from other components.
- Managing messaging (send, receive) between various clients. For that reason the Service Container makes use of entry and exit points.
- Received messages are queued in the entry point queue.
- Send messages are dispatched to the exit point.
- Triggering events and calling the service method, that executes defined operations
illustration not visible in this excerpt
Figure 6: Service Container (Source: [Breest 2006, p. 9])
Besides the handling of receiving and sending messages the Service Container can have other capabilities that are shown in Figure 7.
illustration not visible in this excerpt
Figure 7: Functionality of Service Containers (Source: [Breest 2006, p. 12])
4. Apache ServiceMix
In the practical part of the project report we are using the ESB Apache ServiceMix. We will first outline decision criteria for our choice, some specific foundations and the most important features. Finally we will conclude with the setup of Apache ServiceMix and a generic development and deployment environment.
4.1. Decision for ServiceMix
For the explorative case study and the proof of concept the team decided to evaluate the Apache ServiceMix (SM) ESB.
The major reasons for this decision are based on the functional evaluation by TheServerSide [see TheServerside.Com 2008] and an evaluation of Open Source ESBs [see Buchholz, Hohloch & Rathgeber 2007] from University of Stuttgart. Since the products are very volatile and are subject to changes, we were also analyzing a random sample of the available documentation, tutorials, forums and books as indicator for our final choice.
In this context, since the case study was not bounded to functional requirements besides JBI compliance in general we decided for Apache ServiceMix against Sun’s OpenESB due to the following reasons:
- According to Rademakers and Dirksen OpenESB lacks of message routing and enhancements [see Rademakers, Dirksen 2008, p. 26f].
- ServiceMix is well known and strongly used in the industry [see Buchholz, Hohloch & Rathgeber].
- The documentation, How-to’s and additional material seem to be better than in OpenESB (especially the book of Rademakers and Dirksen, 2008)
- ServiceMix is considered as more flexible than OpenESB (e.g. it is easier to work with various application servers) and numerous other components. A lot of Apache Components (for example Camel, CXF etc) are already shipped with the initial ServiceMix distribution [Buchholz, Hohloch & Rathgeber].
4.2. Components of JBI compliant ESBs
In the section below we are explaining JBI and the most important JBI components like Service Engines (SE), Binding Components (BC), Normalized Message Routing (NMR), Service Unites (SU) and Service Assemblies (SA).
4.2.1. Java Business Integration (JBI)
ServiceMix bases mainly on the Java Business Integration (JBI) specification that was established in 2005. JBI defines a standard for business integration and describes a platform that is using multiple independent components.
JBI provides an environment for pluggable components that interact via a messaging infrastructure. Using plug-and-play components JBI enhances flexibility and reusability, because JBI compliant components have to work by default in all other JBI environments. Hence, open source projects (for instance CXF for Web Services) can be easily added. Also proprietary and customized software can be easily plugged in.
4.2.2. The Normalized Message Router (NMR)
The various JBI components are linked to a Normalized Message Router (NMR) by delivery channels.
The NMR is the core of an ESB and mainly establishes the communication between different components. Providing this, the NMR has to normalize the in- and outgoing messages in order to prevent format incompatibilities between the interacting components. Apache ServiceMix NMR uses jbi:message format (based on XML) for internally exchange messages across components.
Components in a JBI environment can act as service consumers or service providers. Consumers consequently can look up this service-description for a certain service endpoint and retrieve operations, messages etc. that are offered. As an illustration of the service lifecycle please refer to the illustration below.
[...]
- Citar trabajo
- Harald Frank (Autor), Lukas Feuerstein (Autor), 2009, Evaluating the messaging and routing functions of an Open Source Enterprise Service Bus, Múnich, GRIN Verlag, https://www.grin.com/document/135070
-
-
-
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X.