Oracle Fusion Middleware 10g R2 Oracle Enterprise Messaging Service. An Oracle White Paper October 2006

Transcription

1 Oracle Fusion Middleware 10g R2 Oracle Enterprise Messaging Service An Oracle White Paper October 2006

2 NOTE: The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle s products remains at the sole discretion of Oracle. Oracle Enterprise Messaging Service Page 2

3 Oracle Enterprise Messaging Service EXECUTIVE OVERVIEW As enterprise applications evolved from a client/server to an Internet computing architecture, and rapidly grew in complexity, many information technology departments deployed enterprise applications using a fragmented, piecemeal middleware infrastructure. The resulting middleware complexity represents nearly 50% of the information technology costs in organizations today. Further, 60% of organizations consider their enterprise application infrastructure an impediment to their ability to meet business requirements. Productivity and performance have suffered as users struggled with the applications built on these infrastructures. Therefore, enterprises require application infrastructure that delivers: (i) flexible applications (ii) adaptable business processes (iii) actionable business insight (iv) consolidated information management (v) collaborative online workplaces and (vi) better security and ownership experience. In response, especially to achieve flexible applications and flexible business processes, enterprises are evolving their applications from being monolithic, closed systems to being modular, open systems with well-defined interfaces. This trend in application architecture, called service-oriented architecture (SOA), represents a fundamental shift in the way new applications are designed, developed, and integrated with legacy business applications. Oracle Fusion Architecture, shown below, builds on SOA to address the broader set of identified needs by providing a blueprint for creating this next generation infrastructure: Access Collaborate Extend Collaborative Portals Analytics & Activity Monitoring Business Process Orchestration Manage Develop Enterprise Services Infrastructure Information Management Grid Computing Secure Application Services Process Services Data Services Oracle Enterprise Messaging Service Page 3

4 The key principles of this architecture are 1) model driven applications and business processes for highest productivity and customizability; 2) service and event enabled applications for maximum flexibility and reuse; 3) actionable intelligence to make decisions and optimize business operations in real time; 4) grid ready to deliver mainframe QoS on low cost hardware; and, 5) standards based, portable and pluggable in a heterogeneous applications and technology environment to enable seamless adoption. Fusion Architecture addresses some additional important customer concerns that SOA traditionally does not, such as how to leverage information to gain actionable insight; how to create collaborative workplaces linking people, processes, and systems; how to achieve better security through unified services and identity management; how to deliver mainframe QoS to services at run time; and, to do so on low cost commodity hardware. Oracle Fusion Middleware enables Oracle Fusion Architecture with a comprehensive, unified suite of standards-based middleware components that provides a comprehensive technology foundation an Application Platform Suite (APS). The architecture for Oracle Fusion Middleware is shown in the diagram below: INTRODUCTION The Oracle Enterprise Messaging Service (OEMS) provides an open and pluggable architecture to build, integrate, and deploy distributed and disparate applications in an SOA environment. In addition to being a standalone messaging system, OEMS forms the underlying messaging infrastructure for the Enterprise Service Bus (ESB) and BPEL Process Manager components of Oracle Fusion Middleware. Oracle Enterprise Messaging Service Page 4

5 OEMS meets the needs of your messaging and integration requirements reliability, scalability, security, seamless integration, and administration of local and remote sites all built on an open standards platform. Not only does it provide a platform for building new message based solutions, but it also provides the capability to seamlessly integrate with your existing message infrastructure through a pluggable framework built on open standards. Since message-based communication facilitates loose coupling of services in SOA, OEMS should be an integral part of your SOA infrastructure. The following sections of the paper will introduce the comprehensive suite of features the Oracle Enterprise Messaging Service offers to enable you to lower the cost and complexity of developing and integrating distributed applications. FEATURE FUNCTIONALITY The three key features of the Oracle Enterprise Messaging Service discussed in this paper are: 1. Single, standards-based API for messaging development and integration Java Message Service and the J2EE Connector Architecture 2. Quality of service choices for message persistence In-memory, file-based, or the Oracle Database 3. Seamless integration with non-oracle messaging systems WebSphereMQ, Tibco Enterprise JMS, and SonicMQ The Java Message Service 1.1 and J2EE Connector Architecture 1.5 open standards are supported. Ease of Development Proprietary API s often have a difficult learning curve and are costly to develop against since they take so much expertise and lock the customer into a vendor s interface. Oracle is dedicated to providing customers access to open standards for development and integration of their applications. The Oracle Enterprise Messaging Service exposes its functionality through the Java 2 Enterprise Edition (J2EE) standards; the Java Message Service (JMS) and the J2EE Connector Architecture (J2CA). OEMS supports JMS 1.1 and 1.0.2b as well as the J2CA 1.5 specification. This commitment to standards helps reduce the development time, cost, and effort required to build and maintain integrated and distributed applications. Oracle Enterprise Messaging Service Page 5

6 Figure 1: Oracle EMS Architecture Figure 1 illustrates the OEMS architecture and highlights JMS as the single interface to OEMS. It also describes the persistence choices and the various pluggable options a user has for integrating with non-oracle message systems. The OEMS JMS interface offers developers three Quality of Service choices for persisting messages. Depending on your requirement for message availability, reliability, and performance you can configure messages to reside in-memory, on the file system, or to be stored in the Oracle Database. You can easily reconfigure which quality of service you desire without having to worry about your JMS application code changing. This combination of a single, open interface and choice of persistence gives the developer unmatched flexibility when developing applications. OEMS offers a quality of service choice for persisting messages. Quality of Service Each organization and project has its own requirements for persisting message data. The Oracle Enterprise Messaging Service provides three easy to configure options for message persistence: 1. In-memory 2. File-based 3. Oracle Database Each persistence choice offers a unique set of properties for message availability and recovery, which are highlighted in Figure 2. For a lightweight solution you can choose to persist messages in-memory or to the file system while the Oracle Database offers a more robust persistence option. Oracle Enterprise Messaging Service Page 6

7 Figure 2: Message Persistence Choices If the persistence choice is the Oracle Database, then messages will be stored in the Streams Advanced Queuing (AQ) message system within the Oracle Database. A number of extensions to the OEMS JMS API are available to take advantage of features in AQ. Some of these extensions include XMLType data type support, message retention and history, along with RAC and TAF failover capabilities. OEMS offers a number of flexible options for integrating seamlessly with your existing non-oracle messaging infrastructure. PLUGGABLE INTEGRATION CHOICES While OEMS gives you the tools to develop distributed messaging solutions, there is also a comprehensive set of capabilities for integrating the Oracle platform with your existing non-oracle based message solutions. These seamless integration options give you the flexibility to determine which best meets your SOA requirements. If you are deploying message-based applications to the Oracle Container for J2EE (OC4J) which require direct integration to non-oracle JMS message systems, then the OEMS JMS Connector offers unmatched capability for accomplishing this type of integration. There is often a need for data to be passed back and forth between JMS Destinations, even if the Destinations are from heterogeneous message systems. Using the OEMS JMS Router provides guaranteed propagation of messages between any of the three OEMS persistence options and the supported non- Oracle JMS providers. Additional JMS Router functionality supports the ability to dynamically route messages based on the content of the JMS message. Both the JMS Connector and JMS Router are available in Oracle Fusion Middleware 10g R3. The Oracle Messaging Gateway (MGW) bridges non-oracle JMS providers with the Oracle Database 10g. Messages can be propagated between non-oracle Oracle Enterprise Messaging Service Page 7

8 message providers and Streams Advanced Queuing (AQ) in the Oracle Database through MGW. Enterprise Messaging Integration The JMS Connector As IT departments deploy distributed applications on J2EE platforms, it is often necessary to integrate these applications directly with existing messaging infrastructure. The JMS Connector provides the functionality required to access not only OEMS infrastructure but also non-oracle JMS providers. The JMS Connector is built on the J2EE standard, Java 2 Connector Architecture (J2CA). The JCA 1.5 version of this standard defines how JMS providers integrate with any J2EE application server. Oracle has written a generic version of a JMS JCA Resource Adapter called the JMS Connector. The JMS Connector provides two key functions for OEMS: 1. Integration path for the OEMS JMS in-memory, filesystem, and database persistence options. 2. Seamless integration between J2EE applications deployed to OC4J and non-oracle JMS providers. Figure 3 depicts the JMS Connector deployed within OC4J, enabling integration to either the OEMS JMS provider or any of the supported non-oracle JMS providers through Message Driven Beans (MDB) or any JMS enabled component. By integrating with the JMS Connector the OEMS JMS implementation, as well as the non- Oracle JMS providers, can take advantage of connection pooling, MDB s reacting to changing message load, dynamic monitoring, and management for better performance and resource utilization. A key benefit of the JMS Connector is full OC4J MBean integration with the supported non- Oracle JMS providers. While the JMS Connector is a Figure 3: JMS Connector generic JMS J2CA 1.5 resource adapter designed to work with any JMS 1.1 message provider, Oracle has tested and certified it with: 1. WebSphereMQ 6.0 & SonicMQ 6.0 Oracle Enterprise Messaging Service Page 8

9 3. Tibco EMS & Store and Forward The JMS Router The JMS Connector allows integration of JMS application code running in the OC4J container directly with non-oracle JMS providers. The JMS Router however, provides a different option for integration with the same set of non- Oracle JMS providers. Rather than direct integration of JMS code with non-oracle JMS providers, the JMS Router acts as a message bridge between the OEMS JMS Destinations and the non-oracle JMS Destinations. It is not uncommon to have a heterogeneous environment of mixed JMS messaging systems provide the underlying asynchronous communication between distributed applications in an SOA environment. In this environment, there is a need to move messages between JMS Destinations. The end points for this routing are often JMS systems provided by different vendors. The JMS Router can be used to propagate messages between these mixed JMS Destinations by simply configuring it to route messages between source and target JMS Destinations. Figure 4 shows the JMS application code enqueuing and dequeuing directly to the JMS Destinations while the JMS Router is the message bridge that propagates messages between the following supported JMS providers: 1. WebSphereMQ 6.0 & SonicMQ Tibco EMS & Support of SOA Figure 4: JMS Router Service-oriented architectures (SOA), by definition are loosely coupled with services connected fulltime, occasionally connected, or potentially not connected for some period of time. In environments such as this it is important that the disconnected services be capable of storing messages, or events in an event-driven architecture (EDA), for eventual forwarding to the proper consumer. The JMS Router plays an important role in the SOA environment by allowing message producing services to store messages for some period of time. The JMS Router detects when the consuming service is available and then begins forwarding the stored messages. In an SOA environment, it is also critical to have the capability to route messages or events based on the content of the data being forwarded. The JMS Router also supports content based routing. Oracle Enterprise Messaging Service Page 9

10 Content Based Routing The JMS Router is built to provide message bridging between two JMS providers but it can also be configured to route messages based on content in the JMS Header, JMS Properties, or in the body of a JMS message. This additional flexibility allows for increased options when building an SOA and EDA based environment. By configuring the JMS Router, you can forward the messages you want to a select set of consuming services. The Messaging Gateway is an extension of Streams AQ that allows for integration of non-oracle message systems directly with the Oracle Database. Message Integration with the Oracle DB The Messaging Gateway Customers often have a requirement to integrate data in their non-oracle messaging systems directly with the Oracle Database. The Oracle Messaging Gateway (MGW) is an extension of Streams Advanced Queuing (AQ) that allows for this seamless integration to take place. With a management interface similar to AQ, it is very easy for developers who are familiar with AQ to quickly and easily integrate with these non-oracle messaging systems. MGW simply needs to be configured to know where the source and target Destinations reside before it can begin propagating messages. Since MGW is part of the Oracle Database and AQ, it is able to guarantee the delivery of messages one time only to non-oracle message systems that support persistence. MGW supports bi-directional message propagation. Several other capabilities MGW supports are Oracle Database native message formats, automatic and user-defined message transformation, RAC failover support, and a management interface similar to AQ. MGW is certified with the following messaging systems: WebSphere MQ 6.0 & 5.3 Tibco Rendezvous 7.3 Figure 5: Oracle Messaging Gateway MSMQ. *It is planned in a future release of the Oracle Database that MGW will support Microsoft s Oracle Enterprise Messaging Service Page 10

11 Comprehensive management and monitoring of OEMS is available through the Oracle Enterprise Manager. MANAGEMENT AND MONITORING The ability to effectively administer your infrastructure and monitor realtime metrics in your SOA environment with distributed deployments is critical. The need to react to changing business and usage patterns, unexpected load, performance bottlenecks, and other unexpected events must be easily detected. Once the issue has been identified, the means to make the necessary configuration or deployment changes in response to these events must be intuitive. The Oracle Enterprise Manager (EM) offers a comprehensive and efficient tool for managing and monitoring the Oracle Enterprise Messaging Service. This single point of management and monitoring provides a Grid wide view of all JMS Destinations, Connection Factories, and the non-oracle message providers integrated with the JMS Connector and JMS Router. This single interface allows an administrator to configure OEMS across your distributed environment from one location. Figure 6: Oracle Enterprise Manager 10g Application Server Control provides a single interface for OEMS administration and monitoring Configuration and management changes to a production environment are often made in response to trouble spots detected in the distributed environment. Realtime metrics for OEMS are easily monitored through the Oracle Enterprise Manager. Figure 6 shows how the numerous metrics providing insight into the performance of OEMS are quickly viewed for making realtime troubleshooting decisions. Oracle Enterprise Messaging Service Page 11

12 CUSTOMER PROOFPOINTS Agile Software Corporation Agile Software builds Product Lifecycle Management (PLM) solutions for over 10,000 customers across a broad range of industries, including automotive, aerospace and defense, electronics, and consumer products, who want to build efficiencies and ensure regulatory compliance in their product lifecycle. Agile s requirements for messaging are very demanding. Needing a high performance and cost effective messaging platform that scales to handle thousands of users led Agile to choose the OEMS JMS file-based solution. OEMS JMS is used in a number of areas, including synchronizing cache across a cluster to sending notifications to users. According to Venkat Tipparam, Director of Engineering at Agile Software, The decision to use the Oracle Enterprise Messaging Service was an easy one. Oracle provides a high quality JMS implementation right out of the box and our experience with it has been very good. CONCLUSION Building, integrating, and maintaining distributed applications are often costly and time-consuming projects. These projects typically involve a combination of new development on a proven messaging infrastructure as well as integration with an existing heterogeneous messaging infrastructure. The Oracle Enterprise Messaging Service provides a comprehensive messaging environment built on open standards for developing, integrating, and deploying applications in a SOA based environment. This proven technology provides you the performance, scalability, and reliability numerous enterprise customers have come to rely upon. Oracle Enterprise Messaging Service Page 12

13 Oracle Enterprise Messaging Service November 2005 Author: John Lang Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA U.S.A. Worldwide Inquiries: Phone: Fax: oracle.com Copyright 2005, Oracle. All rights reserved. This document is provided for information purposes only and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission. Oracle, JD Edwards, PeopleSoft, and Retek are registered trademarks of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.