Enterprise Service Bus Evaluation as Integration Platform for Ocean Observatories

Transcription

1 Enterprise Service Bus Evaluation as Integration Platform for Ocean Observatories Durga pavani Brundavanam, Mississippi state university Mentor: Kevin Gomes Summer 2009 Keywords: Integration, Enterprise Service Bus, Observatory Middleware Framework, Apache Service Mix, Enterprise Integration ABSTRACT Enterprise Integration has been a popular issue for decades. Hand coding interfaces between applications are proven difficult to maintain because of the tedious work involved for every added application. The next alternative solution is to choose from one of the readily available platforms provided by many vendors. It is becoming increasingly important to formulate the best integration architectures possible. This project emphasizes the underlying issues that might come across if Enterprise Service Bus, which is one of the popular open source integration architecture, is chosen as integration solution for the existing Observatory Middleware Framework.

2 INTRODUCTION Many existing observatories have independent infrastructures that solve the issues of interfacing instruments and developing mechanisms for publishing the derived sensors data to their own constituents. However, to meet the challenges experienced for integrating the instruments, services and applications within each observatory or across observatories, an integration solution called Observatory Middleware Framework (OMF) was proposed. The objective of this middleware framework is to provide a generalized and secured medium to interface instruments across observatories. OMF is a joint collaboration of National Center for Supercomputing Applications (NCSA), Monterey Bay Aquarium Research Institute (MBARI), and University of California, San Diego (UCSD). Moreover, OMF informs the (Ocean Observatory Initiative) OOI program, which is intended to design a Cyber-infrastructure to manage resources of all ocean observatories. The capacity of services and applications an observatory can support has been drastically changed, which further increased the complexity of integration. Eventually, different architectures were introduced, among which Service Oriented Architecture, Event Driven Architecture, and Message Oriented Middleware were popular. However, the implementation of integration in an organization differs widely based on the complexity involved and the number of services it supports. The main objective of this project is to explore one of the popular open source integration platforms called Enterprise Service Bus (ESB) for OMF. ESB comes in many flavors among which Mule and Apache ServiceMix are widely used. An ESB combines a large set of open source message based technologies, known as middleware, which can solve various problems involved in integration. Enterprise Service Bus Architecture Observatory Middleware Framework has been implemented as the service oriented architecture, in which all the services have their own application layer. OMF internally has an instrument proxy that interfaces with the instruments, but in this case instrument proxy is also responsible for addressing integration issues. This type of integration solution is ideal for an organization that has very few applications. Even though instrument proxy of an application is burdened with the extra work to communicate with another application, it is practical until there are few applications with which each application needs to communicate. However, as the number of applications increases, the burden on each application increases. Unlike the Service oriented architecture shown in Figure 1(a), Enterprise Service Bus uses a bus model that acts like a message broker which reduces the number of point-to-point connections between applications as shown in Figure 1(b).The bus model provides a secure medium with which a wide variety of services can be united. Additionally, security, reusability, scalability and isolation of services are other prominent features provided. Essentially, ESB supports a wide variety of message-based, open-source technologies that make the above features Formatted: Font color: Auto Deleted: Figure 1 Deleted: Figure 1 Formatted: Font color: Auto

3 achievable. Schematic representation of Observatory Middle Framework using service oriented architecture and Bus model is shown in Figure 1 and Figure 1 respectively. Deleted: Figure 2 Deleted: Figure 3 Figure 1: Example Implementation (a) Using Service Oriented Architecture (b) Using Enterprise Service Bus Apache ServiceMix is built from the ground up to support the JBI specification (JSR 208). There are two types of basic components. These are Service Engines (SE s) and Binding Components (BC s) and are hot deployable at runtime. Binding components essentially performs normalization or de-normalization of incoming and outgoing messages, and uses remote protocols to communicate with services outside JBI environment. Service Engines provide logic inside the JBI environment. SE communicates with the outer world via a Binding component. Services inside the service engine are accessed using endpoints and each endpoint is addressed uniquely with the combination of service name and endpoint name. JBI components send messages between them using Normalized Message Router (NMR). NMR is responsible for delivering messages to the correct endpoints, and uses WSDL- based messaging model to meditate these message exchanges. JBI Components are containers into which other artifacts are deployed in order to configure them to provide, or to consume, particular services. A group of Service Units along with a jbi.xml file that describes their relationships and the target components to which these service units are deployed, is called Service Assembly (SA) and is a package (ZIP or JAR files). Installing any component to the current instance of the service mix is done in two ways; one method is to copy the installer zip in the hot deploy directory, or by using Ant tasks (or Maven). While running ServiceMix using the default architecture, the messages exchanged are routed through the non-persistent Normalized Message Router (NMR). Optionally,

4 ServiceMix can run its NMR on JMS flow, which uses ActiveMQ. ActiveMQ is the popular message broker that is delivered out of box by the ServiceMix. To use ActiveMQ in ServiceMix, ESBs are configured in such a way that they get reference to the ActiveMQ connection factory. This functionality is necessary to be able to receive and send messages through the JMS transport. An ESB provides many functions among which Message transformation, Message routing, and security are main focuses of this project. Figure 1 Implementation of Observatory Middleware Framework using Service Oriented Architecture Deleted: 2 An ESB supports a wide variety of applications, and each application can have its own message format. To make interactions among services with different message formats feasible, transforming the message format of a source service to the message format of a destination service is essential. For example, in Figure 1 the incoming messages are in SSDS format and the outgoing messages from the ESB are supposed to be in SensorML. Since the message format or the messages exchanged via the ESB are in XML format, the message transformation is implemented through the standard XSTL usage model. Service mix Saxon a standard JBI component for XSLT or XQuery. In this case the service unit consists of the xbean.xml file and a transformation document (.xslt file). Before writing the actual transformation file, the essential thing to do is to map the given xml files. Mapping may become messier if done manually. Essentially, software Deleted: Figure 4

5 tools are available to automate this, among which Stylus studio and Oxygen are verified to be useful at the time of this project. Figure 1 Enterprise service Bus acting as the common integration layer for two applications Deleted: 3 Another important feature of an ESB is message routing. This feature ensures that the incoming messages are routed to the intended destination. An ESB can route the incoming message to the destination based on many factors, and hence there are many methods of routing like content-based, message filter, recipient list and so on. Implementing these routing protocols can be simple or can be very complex. Once again, the routing method will be based on the complexity of that infrastructure. The ServiceMix EIP service engine is the ServiceMix container where many routing patterns can be deployed as a service unit. Also, Apache Camel is an alternative to servicemixeip. In a routing rule, a number of predicates are defined. If all predicates match the message is sent to the specified target. If no routing rule matches, the message is sent to the routing rule with no predicates, or default routing rule. Content-based routing is one of the powerful routing techniques, in which the destination address is not explicitly specified. Instead, the message received from the sender is

6 inspected for the appropriate keywords or properties and then based on the information retrieved, the destination details (endpoints), and eventually the necessary actions that have to be done to reach the destination, are determined. XPath is the tool that is used for content based routing. The router evaluates the received message against a predefined rule set and finally an appropriate decision is made based on the match. Servicemix-eip and servicemix-camel provides full set of Enterprise Integration Patterns, so they are ideal for performing content based routing. In more complex systems, a database can be used to create and maintain these rule sets. However, message routing or content-based routing needs to know the details of all the services and their connections ahead of time. What if a particular system has services/ devices plugged in to the system at runtime? In such cases this type of static routing algorithm fails. Dynamic routing can be defined as the most ideal routing protocol for most of the complex architectures existing today including Observatory Middleware Framework. Dynamic routing protocols in the ESB enable discovery of endpoints at run time. At this point in time, the Apache ServiceMix ESB does not implement any dynamic routing protocol. The final feature of an ESB that is discussed in this paper is Security. For each system there can be many users and services that can access it, Figure 1 Depicts the features like transformation, routing and security provided by Enterprise service Bus hence avoiding information leaks or hijacks to the network by means of various security protocols is important. Issues within the security are classified mainly into two levels, one as Authentication and Authorization, and the other as securing the transport of messages. In Apache ServiceMix, the transport protocol is implemented using HTTP(s). Moreover, a major drawback of this ESB is that other services don t implement transport security. For Authentication and Authorization, the steps carried out to ensure that the user of the service is legitimate are called Authentication. Once authenticated, ensuring that particular service or user has access to the resource or service it is requesting access for is called authorization. Specific endpoint URIs accepts HTTP requests, and then they are authenticated with the default servicemix JAAS login module. JAAS is the standard Deleted: 4

7 security framework of the Sun Java Environment and is good foundation for authentication and authorization in servicemix. Default configuration of JAAS login module is done in the conf directory; in addition, a properties module is used to configure the users and their rights for the ServiceMix container using userpasswords.properties, and group.properties files. Authorization rules are configured in security.xml file available in conf directory. As mentioned earlier, the ESB doesn t provide support for all transport protocols, so the security layer of Enterprise Service Bus for Observatory Middleware Frame work uses the one that is implemented by NCSA as shown in Figure 1 Conclusion Within each observatory, the ESB reduces redundant labor done by integrating individual applications. With a large set of open source tools included, it not only provides much valuable functionality, but also provides application isolation. However, using the ESB needs to implement a generalized security layer that can be utilized by all services on the bus. Deleted: Figure 4 Future Work The main objective of this project is to ensure that the ESB is the right integration solution for Observatory Middleware Framework. Many test classes that were written in Java are used to interface with ESB. At this point of time, none of the Instrument Proxy classes are moved to ESB. Therefore, the next obvious step would be to move essential functionalities like transformation from Instrument Proxy to the ESB. At later point in time, it would be helpful if the current security layer of OMF, developed at NCSA, could be replaced by a generalized security layer. Also, a dynamic routing protocol that enables determining endpoints at runtime, which makes plug in instruments and services feasible with the running system, is to be developed. References Tijs Rademakers, Jos Dirksen. Open source ESBs in action, example implementations in Mule and ServiceMix. Manning publications 2008 Apache ServiceMix, the agile open source ESB. The Apache software foundation. Available from World Wide Web: <