List of Figures

Chapter 1. The world of open source ESBs

Figure 1.1. The point-to-point model describes an environment where applications are integrated with a unique and custom-made integration solution.

Figure 1.2. An application landscape using an ESB to integrate the applications

Figure 1.3. Here’s a typical example of an application with a three-tier architecture. The application logic is divided into three layers, which can be distributed over multiple physical servers to improve scalability and performance if necessary.

Figure 1.4. Here’s an example where integration between multiple applications is necessary. The call center application needs a single-client view from the ERP, CRM, and COBOL applications.

Figure 1.5. The architecture shown in figure 1.3 is extended with an integration layer that provides the logic needed to integrate with other applications.

Figure 1.6. Here we introduce an ESB to the call center architecture. The ESB provides functionality to communicate with the three back-end applications and to route the message to the right backend application.

Figure 1.7. The ESB can use several options to configure and store the location of the CRM client information service. A common option is an XML file configuration, but there are alternatives, such as a database or a service registry.

Figure 1.8. In this example a client application sends a JMS message to the ESB. A JMS adapter accepts the JMS message and forwards it to the file adapter, which writes the content of the JMS message to the file system of a legacy application.

Figure 1.9. An ESB provides the capability to transform the message format of an incoming message to the format expected by the target application. In this example the ESB transforms the SOAP message to an EDI message by using a message transformer.

Figure 1.10. Message routing involves the logic to determine the target endpoint(s) for an incoming message.

Figure 1.11. In this example of message enhancement, an order message with a client identifier is sent by a client application. The ESB retrieves the customer details from the CRM database using the client identifier with message enhancement capability.

Figure 1.12. Security involves the confidentiality, integrity, and availability of messages sent over the ESB. This example shows an implementation of confidentiality via an authentication mechanism.

Figure 1.13. The ESB is a central product within the environment and therefore monitoring and management capabilities are vital.

Figure 1.14. Overview of the functionality provided by Mule. The figure shows some examples of open source frameworks that can be integrated with Mule, including CXF and ActiveMQ.

Figure 1.15. Overview of the functionality provided by Apache ServiceMix

Figure 1.16. A schematic overview of an SCA component as defined in the SCA specification. A component provides services to other components and uses references to invoke other components.

Figure 1.17. A hello world example with an ESB that polls for new files in the inbox directory and writes the polled files to a directory named outbox.

Figure 1.18. The directory structure of the unpacked Mule distribution

Figure 1.19. An overview of the directories within the ServiceMix distribution

Chapter 2. Architecture of Mule and ServiceMix

Figure 2.1. This figure illustrates the main concepts of the Mule ESB that enable it to process incoming messages to the proper target applications.

Figure 2.2. This example shows the use of the main concepts of Mule. A CSV file is sent to Mule with an FTP server, and Mule transforms the message to XML and sends it on to the payment system.

Figure 2.3. An overview of the main parts of a Mule configuration file. This figure also shows that Spring beans can be easily integrated in the Mule configuration.

Figure 2.4. An example of stacked transformations, which shows how a message is transformed in two steps. First, the default JMS transformer is executed, and then an XSLT transformation converts the incoming message into a different XML format.

Figure 2.5. A high-level overview of the JBI specification with a focus on the component-based architecture

Figure 2.6. A high-level JBI container showing the most important concepts: the normalized message router, the service engines, and the binding components

Figure 2.7. This JBI container example shows service engines (SEs) and binding components (BCs) linked to the normalized message router via a delivery channel (DC).

Figure 2.8. XSLT SE with a number of services (XSLT style sheets) deployed

Figure 2.9. An overview of the communication between a consumer and a provider for an In-Out message exchange, including the communication with the normalized message router.

Figure 2.10. An overview of the publication and consumption of services via the normalized message router. A provider publishes a service on the NMR and a consumer can consume this service.

Figure 2.11. An overview of the service unit and service assembly concepts for a JBI container. A service assembly can consist of multiple service units.

Figure 2.12. Overview of a number of service engines and binding components provided by ServiceMix

Chapter 3. Setting up the Mule and ServiceMix environments

Figure 3.1. A schematic overview of a customer service bean and a customer DAO class implementation. The customer DAO class is injected into the customerDAO property of the customer service bean.

Figure 3.2. An example of how JiBX maps the elements of an XML message to a Java object

Figure 3.3. An example that shows how JiBX maps a structure element to a Java class

Figure 3.4. The important concepts of the JMS specification. The JMS classes that are common when developing JMS-based functionality are shown as well.

Figure 3.5. Import an existing project into Eclipse using the Import wizard.

Figure 3.6. Select a project to import from the file system.

Figure 3.7. A file-based integration scenario that will be used to show the Mule development environment with Spring, JiBX, and ActiveMQ

Figure 3.8. Mule services and endpoints required for the implementation of the integration scenario

Figure 3.9. We use this scenario to show how ServiceMix can work together with Spring, JiBX, and ActiveMQ.

Figure 3.10. The binding components and service engines used in the implementation of our example

Chapter 4. The foundation of an integration solution

Figure 4.1. The service assembly for the simple logging example consists of two service units, and the simple-bean-su consists of the SimpleComponent logging implementation.

Figure 4.2. Project structure for the simple-sa service assembly used by the ch4-examples Ant build file to create the distribution that can be deployed to ServiceMix

Figure 4.3. Schematic explanation of a message flow, which is the intermediary between a service consumer and a service provider

Figure 4.4. An overview of the message flow for the book price case study that involves communication with the Amazon and Barnes & Noble bookstores. The example shows a customer that requests the cheapest price for a specific book represented as an ISBN.

Figure 4.5. An overview of the Mule configuration of the request flow for the book price case study. The incoming message is logged and forwarded to two endpoints by the multicasting router.

Figure 4.6. Overview of the response flow for the book price case study. The two response messages from Amazon and Barnes & Noble are logged and aggregated into one message. Then the prices are compared and the lowest price is sent back to the customer.

Figure 4.7. The request flow implementation of the price case study with ServiceMix. The incoming message is logged and forwarded to the Amazon and Barnes & Noble endpoints.

Figure 4.8. Transformation of the ISBN message incoming format to the message format as expected by the Barnes & Noble bookstore

Figure 4.9. The response flow implementation of the book price case study. The incoming book quotes from Amazon and Barnes & Noble are logged and aggregated. Then the lowest price is calculated and sent back to the customer.

Chapter 5. Working with messages

Figure 5.1. An example of a fixed router that moves the message from a messaging infrastructure to a web service

Figure 5.2. An example of the use of a content-based router with a car insurance request. The insurance request is routed to the car insurance application based on the insurance type element value.

Figure 5.3. The Apache Synapse architecture, showing the different layers and Axis2 foundation

Figure 5.4. Example of content-based routing without domain logic using the WS-Addressing Action header element. The WS-Addressing Action header value defines a keyword that can be used to select the target endpoint for the insurance request message.

Figure 5.5. The incoming message from the messaging layer is validated against an XSD. When the message is invalid, it will be forwarded to an invalid message queue. When the message validation succeeds, the basic flow is processed.

Figure 5.6. The JBI components needed to implement a validation example with JMS input and output queues. The ErrorHandlerComponent is a custom-developed bean component that forwards the response message to the proper JMS endpoint.

Figure 5.7. A message flow that transforms an incoming JMS message to the message format as defined in the WSDL of an external web service

Figure 5.8. A message flow example showing the usage of default transformers within Mule. In this example, the default JMS transformers are shown that transform the JMS message type to a Java object, and vice versa.

Figure 5.9. The service units that will be implemented in the ServiceMix weather example. We use a JMS message to invoke the weather web service. The web service response will be transformed with the Saxon component, and the transformed message will be forwarded to a JMS output queue.

Chapter 6. Connectivity options

Figure 6.1. Our example uses the ESB to read a file from a directory and write it to a different directory.

Figure 6.2. This JMS example shows how to use the ESB to consume a message from a JMS queue and produce the message for another JMS queue.

Figure 6.3. This JMS example shows how to use the ESB to consume a message from a JMS queue and send the message to a JMS topic. Then the ESB implements three topic subscribers that each forwards the message to a JMS queue.

Figure 6.4. An example showing the ServiceMix JMS functionality for consuming messages from a JMS queue and producing messages for a JMS queue

Figure 6.5. Use the ESBs to read a record from the database and write the contents as a file to a directory.

Figure 6.6. Use the ESBs to read a file from the file system and store its contents in the database.

Figure 6.7. The elements of a WSDL file used to configure the JDBC binding component

Figure 6.8. We read a file from the file system with the ESB and forward the message to a mail server using SMTP connectivity.

Figure 6.9. We receive an email from a mail server using the ESB with POP3 connectivity and send the email message to the file system.

Figure 6.10. We can receive an email message with the Mule configuration we implemented.

Figure 6.11. We read a file from a local directory and send the file to an FTP server.

Figure 6.12. We read a file from a directory on a FTP server and write its contents to a file in a local directory.

Figure 6.13. We read a file from the file system and use the message to invoke a method on a remote EJB.

Chapter 7. Web services support

Figure 7.1. An overview of a WSDL version 1.1 file, showing the various parts that together define a web service description

Figure 7.2. The data model used in the Company web service implementation. The Company object is used in the operations of the web service.

Figure 7.3. An overview of Mule hosting our generated web service that delegates to the Java implementation

Figure 7.4. ServiceMix configuration for top-down web services showing how the CXF binding component calls the CXF service engine

Figure 7.5. Example showing signing and encryption of a message

Chapter 8. Implementing enterprise-quality message flows

Figure 8.1. Mule offers component and connector exception strategies.

Figure 8.2. An in-out message exchange with a fault response message. The normalized message router (NMR) ensures that the messages are sent between the binding components and service engines in the JBI container.

Figure 8.3. When a fault occurs in an in-only message exchange, the normalized message router doesn’t know how to route the fault message.

Figure 8.4. A one-way message flow implementation that uses the Camel component as an error-handling mechanism for the invocation of the bean component

Figure 8.5. A simple example of how authentication can be implemented within Mule. A security filter will check the user credentials against an in-memory list of users.

Figure 8.6. LDAP authentication implemented in Mule. Via HTTP, a request message with security context is consumed by the adapter, and the HTTP security filter validates the credentials against an LDAP server.

Figure 8.7. The initial contents of the Apache Directory Server shown in the Apache Directory Studio tool

Figure 8.8. Use this information to add a new role, named users, to the Apache Directory Server.

Figure 8.9. A simple example of a message flow that will authenticate an incoming HTTP request and forward the message content to a bean component, which in turn will log the security context and message content

Figure 8.10. Example of an XA transaction that involves a JDBC and a JCA resource. In this example, the JCA transaction fails and therefore the global transaction is rolled back.

Chapter 9. Implementing a case study using patterns

Figure 9.1. An overview of the six Enterprise Integration pattern categories from the book by Hohpe and Woolf. Each category focuses on a different aspect of a typical message flow.

Figure 9.2. An example of a design diagram using the Enterprise Integration patterns. The complex integration problem domain can be described in a simple diagram with the use of only six patterns.

Figure 9.3. Message exchanges between the actors in the restaurant table reservation case study. In this example, the hotel guest reserves a table at The Royal Duck restaurant.

Figure 9.4. The message flow design diagram of the first part of the restaurant table application, using a number of Enterprise Integration patterns to visualize the integration solution

Figure 9.5. This message flow diagram shows the design of the table-confirmation message exchange. Only confirmations that haven’t timed out are accepted by the ESB. A content-based router eventually sends the confirmation message to the correct restaurant application and an acknowledgment to the TV application.

Figure 9.6. This is the database model for the restaurant-reservation case study; it enables the persistence of reservations. The Reservation table stores the restaurant reservation responses, and the Restaurant table holds the three restaurants with timeout values.

Figure 9.7. The publish-subscribe implementation in the Mule message flow definition. Three topic subscribers are defined; they invoke the restaurant beans that simulate the restaurant reservation applications.

Figure 9.8. JBI components that are needed to implement the publish-subscribe functionality for the table reservation integration solution in ServiceMixBecause you’ll use in-out JMS consumers, which consume messages from the inquiries.in topic and produce messages to the reply-to queue specified in the JMS ReplyTo header, you don’t have to use the pipeline EIP component.

Figure 9.9. The ServiceMix message flow and the involved JBI components for the implementation of the confirmation message handler

Figure 9.10. A developer machine environment that needs to test message flows developed with Mule and ServiceMix. The Ant build files are provided as part of the source code distribution of this book.

Figure 9.11. The messages that need to be sent from and received by the JUnit test case. With the JUnit test case, the reservation application is simulated.

Figure 9.12. An example of a production environment consisting of the open source integration products necessary for the case study. The important artifacts needed by the administrator are shown as part of the administrator machine.

Chapter 10. Managing and monitoring the ESB

Figure 10.1. A design diagram showing the Wire Tap pattern being applied to the reservation example from chapter 9. All messages to the Lakeview restaurant service are also sent to the channel specified by the wire tap.

Figure 10.2. How the Message Store pattern is implemented using a custom auditor in ServiceMix

Figure 10.3. A screenshot of the webdav view of the eXist database where the messages are stored

Figure 10.4. Detour pattern added to the restaurant reservation example

Figure 10.5. Connecting JConsole to Mule

Figure 10.6. JConsole, showing the JMX property for the detour filter. With JConsole, you can enable and disable the detour filter.

Figure 10.7. All the components and layers in JMX

Figure 10.8. JConsole startup screen

Figure 10.9. All the available MBeans for Mule

Figure 10.10. JConsole showing all the attributes of the DuckRestaurantService Mule service

Figure 10.11. JConsole showing all the methods of the DuckRestaurantService

Figure 10.12. JConsole showing all the operations of the JMSConnector

Figure 10.13. MC4J startup screen that you see when you start MC4J for the first time

Figure 10.14. The MC4J connection wizard

Figure 10.15. MC4J view of all the MBeans available in the MBean server

Figure 10.16. MC4J showing the average processing time for the DuckRestaurantService Mule service

Figure 10.17. MC4J showing the total number of messages received by the DuckRestaurantService Mule service

Figure 10.18. Mule Galaxy, showing the contents of a Mule configuration

Figure 10.19. Mule HQ monitors various endpoints and the platform’s available memory.

Figure 10.20. Connecting JConsole to ServiceMix

Figure 10.21. JConsole showing all the management options from ServiceMix

Figure 10.22. JConsole showing the operations exposed by the AdminCommandService

Figure 10.23. JConsole showing the operations exposed for the DeploymentService

Figure 10.24. JConsole showing the exposed methods of the LogService

Figure 10.25. MC4J connection wizard with values set for ServiceMix

Figure 10.26. MC4J monitoring inbound messages for the file-binding component

Chapter 11. Implementing a process engine in the ESB

Figure 11.1. Integration architecture that includes a process engine and an ESB. The process engine is responsible for managing the state of the process, and the ESB is responsible for technical integration aspects like routing, transformation, and connectivity.

Figure 11.2. An abstract overview of the Process Manager pattern. The process manager orchestrates the involved services based on a process description.

Figure 11.3. The current booking process for a scuba diving trip, which involves a lot of communication between the hotel receptionist and the other parties in the process

Figure 11.4. The high-level design of the process to book a scuba diving trip, which automates most communication with the involved parties. The hotel receptionist remains responsible for communicating with the hotel guest.

Figure 11.5. The initial message that is needed to start the process and the final booking message that is returned by the process, which holds the necessary information for the scuba diving trip

Figure 11.6. The message exchange between the process engine and the involved parties: respectively, the diving agency of choice, the lunch service, and the taxi service

Figure 11.7. The process engine orchestrates the diving agency and the lunch and taxi service invocations while using the ESB as a connectivity layer. The ESB implements the functionality to route the messages to the correct service endpoints.

Figure 11.8. A schematic overview of the relationship between nodes and transitions. Nodes can have multiple leaving transitions; a transition always has one node as its destination.

Figure 11.9. The basic nodes you can use to define processes with jPDL. The difference between a state and a task is that the latter involves human interaction.

Figure 11.10. The hello world example in the jPDL designer

Figure 11.11. The properties view of the jPDL designer, where you can define the handler class to execute custom logic

Figure 11.12. The message exchange between the jBPM process instance and the ESB services. The jBPM transport connector that is provided by Mule is used to implement the message exchange. Only one of the diving agency states is shown, because the other two agencies use the same invocation model.

Figure 11.13. The process definition for the scuba diving booking process as designed with the jPDL Eclipse plug-in, which is provided by the jBPM project

Figure 11.14. The properties view of a transition leaving a decision node. This example shows a script expression that checks whether the diving interest is equal to Wrecks or Caves. If the expression evaluates to true, then this transition is executed.

Figure 11.15. The properties view of the InvokeSharkDivingAgency state, which shows the configuration of the action handlers executed for this state

Figure 11.16. The primary WS-BPEL 2.0 language constructs, which you can use to define processes. These elementary elements can be nested within the sequence and flow control elements.

Figure 11.17. A hello world process, designed with the BPEL designer plug-in of the Eclipse BPEL project. The process copies the name of the incoming message to the response message with the prefix hello.

Figure 11.18. The properties view of the client-partner link defined as part of the hello world process definition. Notice that the role defines that an external partner will invoke the process.

Figure 11.19. The properties view of the Assign activity that is used in the hello world process. In this example, you copy the input variable to the output variable with a hello prefix by using an XPath expression.

Figure 11.20. JBI components needed to implement the scuba diving process case study. This design diagram also shows the interaction and part of the component implementation.

Figure 11.21. The WSDL interface you need to define for the scuba diving process. The message definition corresponds to the message design from section 11.3.

Figure 11.22. The WS-BPEL implementation of the scuba diving process in the Eclipse BPEL Designer. The WS-BPEL process diagram includes a smaller diagram of the partner links and variables.

Figure 11.23. An example of the initialization of the scubaDivingRequest variable in the AssignDivingValues activity of the scuba diving process

Figure 11.24. The definition of a condition for an If activity. This example checks whether the diving interest equals shark, to determine the correct diving agency to invoke.

Appendix A. ServiceMix 4.0

Figure A.1. The new architecture of ServiceMix 4. The architecture is described from three viewpoints: the developer view, the technology view, and the kernel view.

Figure A.2. The lifecycle of an OSGi bundle. The first state of an OSGi bundle is always installed, and from that state an OSGi bundle can eventually be started.

Appendix C. Graphical tool support

Figure C.1. The New Project wizard in Eclipse, showing the Mule Project wizard that’s provided with the Mule IDE 2.0 Eclipse plug-in

Figure C.2. The Mule IDE configuration canvas and palette. The palette includes components and inbound and outbound routers, which are the fundamental elements of a Mule configuration.

Figure C.3. Mule IDE canvas showing the hello world example you just created

Figure C.4. The New wizard in Eclipse shows you how to create a new integration patterns diagram.

Figure C.5. The design canvas and palette of the Enterprise Integration Diagram plug-in

Figure C.6. The result of the routing example you implemented in the EID canvas

Appendix F. The Swing test client

Figure F.1. The Swing test client, showing the available test configurations on the left. Depending on the connectivity configured in the examples, you’ll see Send and Receive tabs on the right side of the screen.

Figure F.2. The Eclipse Ant view showing the Ant build files for this book’s Mule examples

Figure F.3. The Swing test client panel that you can use to send a message to a message channel—in this case, a JMS queue

Figure F.4. The Swing test client panel that you can use to receive a message. If you double-click any of the received messages, the message’s content is shown.