|
|
2. IntroductionIntroduction to ESBThis document introduces the general concept of an Enterprise Service Bus (ESB) and the Java Business Integration (JBI) specification, followed by a discussion of ServiceMix, an open source ESB implementation based on the JBI standard JSR 208. The ProblemEnterprise networks commonly deploy disparate applications, platforms, and business processes that need to communicate or exchange data with each other. The applications, platforms and processes have non-compatible data formats and non-compatible communications protocols. If an enterprise needs to interface with external systems, the integration problem extends outside of a company, encompassing its business partners' IT systems and processes as well. In recent years, there have been several technologies attempting to solve these problems such as Enterprise Application Integration (EAI), Business-to-Business (B2B), Service Oriented Architecture (SOA), and Web Services. These solutions addressed some of the integration problems, but were proprietary, expensive, and time-consuming to implement. These solutions range from expensive vendor solutions (high cost, vendor lock-in) to home-grown custom solutions (high maintenance, high cost). The overwhelming disadvantages of these solutions are high cost and low flexibility due to non-standard implementations. The ESB ApproachA standards-based ESB solves the integration problem without the drawbacks of the other solutions. The purpose of an ESB is to facilitate application and process integration by providing distributed processing, intelligent routing, security, and dynamic data transformation. In an ESB these services are infrastructure services so each application does not have to implement these requirements independently and in a proprietary manner. The ESB addresses the disadvantages of existing solutions by creating a standard infrastructure for integration. Point-to-point solutions, where each of n components requires n-1 interfaces for full communication, are replaced by a bus solution where each component requires a single interface to the bus for global communication. An ESB provides distributed messaging, routing, business process orchestration, reliability and security. It also provides pluggable services and, because of the standard bus, these pluggable services can be provided by third parties and still interoperate reliably with the bus. Attributes of an ESB integration infrastructure are:
As an integration infrastructure, the ESB provides a number of functions including:
An ESB also supports requirements such as security, orchestration, and transactionality. These exist in "hard-wired" integration methods, but are not available automatically in a service-oriented architecture. One of the key requirements for the ESB is to give loosely coupled, service-based integration methods a level of enterprise-class reliability and security. A newer requirement for ESBs is the ability to allow not only loosely-coupled requests found in a service oriented architecture, but also to provide the infrastructure for an Event Driven Architecture (EDA). SOA and EDA provide complementary functionality. In EDA an event triggers a message to be sent to other applications that are decoupled from the application that triggered the event. This is an asynchronous operation as the recipient applications may receive or pick-up their messages at a later time, whereas the SOA messaging model is typically synchronous in nature. What is Java Business Integration (JBI)?The Java Business Integration spec (JBI) is a Java-based standard that defines a runtime architecture for plugins to interoperate via a mediated message exchange model. This mediated message exchange model was simply adopted from the WSDL 2.0 spec's message exchange patterns (MEPs). Messages between components are mediated by the Normalized Message Router (NMR). The NMR serves as an intermediary for routing messages amongst plugins, no matter where that component resides. Plugins do not communicate directly with one another; they only communicate with the NMR. This provides location transparency for the plugins. JBI ComponentsThe plugins mentioned above come in two flavors, binding components and service engines. Sometimes it makes more sense to refer to them simply as bindings and engines. Binding components and service engines are generically referred to as JBI components. JBI components are deployed to the JBI environment and simply run in memory waiting for a configuration (more on this below in the section named Using JBI Components). Binding ComponentsA binding component (BC) has two purposes:
BCs are used to communicate outside the JBI environment. Examples of remote protocols provided by BCs include HTTP/S, JMS, FTP, SMTP, XMPP, RMI, CORBA, etc. ExamplesSome examples of binding components in ServiceMix include: Message NormalizationMessage normalization/denormalization is the act of converting a message from/to a protocol-specific format into a format for the JBI environment. This normalization is performed by BCs involves converting all messages into a NormalizedMessage. A normalized message consists of the following:
There is no canonical message format for JBI. Messages simply must be normalized to meet the criteria above. Service EnginesA service engine (SE) provides some type of logic inside the JBI environment and only communicates with the NMR. If a SE needs to communicate outside the JBI environment, it must send a message to a BC (via the NMR). Examples of SEs include rules engines, BPEL engines, XSLT engines, scripting engines, EJB continers, etc. ExamplesSome examples of service engine components in ServiceMix include:
Using JBI ComponentsJBI components are most typically provided to you with the JBI container and they provide support for some of the most common protocols and engines. In order to make use of these components as an application developer, you must provide a configuration for each component you want to use. Configurations are implementation specific but the packaging is defined by the JBI spec. Each component configuration must be packaged as a service unit (SU) (see What is a JBI SU and how do I create one?) and each SU must be wrapped in a service assembly (SA) (see What is a JBI SA and how do I create one?). These are simply ZIP/JAR files that contain a XML descriptor named jbi.xml that is used by the JBI environment. For those folks who are familiar with Java EE development, these ZIP files are similar to WARs and EARs. Should I Create My Own JBI Components?Upon first encountering JBI, some folks assume that they need to begin writing their own components. You might, in fact, need to do this, but understanding why you would need to do this is an important first step. To understand why, read the following FAQ entry: Why ServiceMix?There are many vendors that provide ESB solutions, but there is no universal agreement as to the best design or architecture for an ESB. ServiceMix has a design that is based on the JBI (JSR 208) specification in order to create a standards based ESB and the ServiceMix ESB combines the functionality of both a Service Oriented Architecture (SOA) and Event Driven Architecture (EDA) to achieve an agile, enterprise ESB. As previously stated, ServiceMix is an open source ESB and it is based on the Java Business Integration (JBI) standard. These two factors, open source and open standards-based, allow for low entry cost, maximum flexibility, reuse, and investment protection. Low entry cost is a result of the open source model, which allows developers to leverage the work of the development community when implementing components to plug into the ESB, or using the ESB as an integral part of a larger solution. Flexibility results from the fact that any number of third party vendors supply components and bindings that conform to the JBI open standard specification can be supported. These components and bindings not only interoperate with each other and external applications via the ServiceMix ESB, but can easily be replaced with alternate components that provide the same or enhanced services. Reuse and investment protection also results from the adherence to standards. Not only can developers swap out ESB components, or use components in another JBI-standard ESB, but they can swap out the entire ESB and still use the standard plug-in components. As an agile ESB, ServiceMix allows plug-in services which can combine to create a service oriented architecture. ServiceMix allows services to operate in an event driven way as well. In other words, the services are decoupled and listen on the bus for service requests. The bus is responsible for quality of service (QoS) features such as message persistence, guaranteed delivery, failure handling, and transaction support. ServiceMix supports event driven architecture for events occurring both internal and external to the bus. In other words, JMS binding components can listen for the arrival of messages, i.e., the "event" on topics or queues which are external to the bus, while other components can listen for messages on the normalized message bus. While decoupled (EDA) operation (as described in the previous two paragraphs) is more appropriate for the scalability and reliabilty required for high transaction production environments, synchronous request/response communication found in SOA implementations, is also supported. Thus, ServiceMix effectively combines SOA and EDA for the development and deployment of composite enterprise applications. Background to ServiceMixBackgroundThe Enterprise Service Bus (ESB) - which can be defined as middleware that brings together both integration technologies and runtime services to make business services widely available for reuse - offers the best solution for meeting today's enterprise application integration challenges by providing a software infrastructure that enables SOA. However, there are currently a number of different vendors that provide ESB solutions, some of which focus purely on SOAP/HTTP and others who provide multi-protocol capabilities. Because these vendors span the horizon from big enterprise generalists (app servers), to mid-tier enterprise integration providers, all the way to smaller, ESB/integration specific-providers; there doesn't seem to be an established consensus regarding the key requirements for an ESB. As application architects, we have often thought about what requirements would define an ESB designed specifically to cater to the needs of an agile, enterprise integration model. In building for these specific requirements, we realized that we actually needed to develop a new type of ESB, hence the ServiceMix project. Characteristics of an Agile ESBThe main criteria we were looking for in our ESB are as follows: Standards basedWhile standards-based support is marketed by many ESB vendors, the support is provided externally, requiring developers to work with proprietary APIs when directly interacting with internal APIs. ServiceMix was designed with the requirement to eliminate product API lock-in, by being built from the ground up to support the Java Business Integration specification (JSR 208). Our agile ESB needs to use JBI as a first class citizen, but also support POJO deployment for ease of use and testing. FlexibleAnother characteristic of an agile ESB is the flexibility with which it can be deployed within enterprise application integration framework: standalone, embedded in an application component, or as part of the services supported by an application server. This allows for component re-use throughout the enterprise. For example, the binding for a real-time data feed might be aggregated as a web-service running within an application server, or streamed directly into a fat client on a traders desk. An agile ESB should be able to run both types of configurations seamlessly. To provide rapid prototyping, an agile ESB should support both scripting languages and embedded rule engines, allowing business processes to be modeled and deployed quickly. ReliableOur ESB needs to handle network outages and system failures and to be able to reroute message flows and requests to circumvent failures. Breadth of ConnectivityAn agile ESB must support both two way reliable Web-services and Message Oriented-Middleware and needs to co-operate seamlessly with EIS and custom components, such as batch files. ConclusionWe also wanted our agile ESB to be vendor independent and open source, to promote user control of source code and direction. An added benefit of this is not only the zero purchase cost, but the total cost of ownership will be reduced where users are actively contributing and maintaining our ESB. We rapidly came to the conclusion, that as there was no single product that would adequately meet our needs, we would have to just go Features OverviewServiceMix is lightweight and easily embeddable, has integrated Spring support and can be run at the edge of the network (inside a client or server), as a standalone ESB provider or as a service within another ESB. You can use ServiceMix in Java SE or a Java EE application server. ServiceMix uses ActiveMQ to provide remoting, clustering, reliability and distributed failover. ServiceMix is completely integrated into Apache Geronimo, which allows you to deploy JBI components and services directly into Geronimo. ServiceMix is being JBI certified as part of the Geronimo project. ServiceMix has been integrated with other J2EE application servers including JBoss and JOnAS, with more to follow. Books, Articles and other readingsJust have a look at Books and Articles; they list several works. In case you are aware of other good resources, please drop a notice (see Contributing). |
