Upload
vuongdiep
View
233
Download
0
Embed Size (px)
Citation preview
Oracle Fusion Middleware 10g R2
Oracle Enterprise Messaging Service
An Oracle White Paper
October 2006
Oracle Enterprise Messaging Service Page 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 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:
CCooll llaabboorraattee AAcccceessss EExxtteenndd
AAppppll ii ccaatt iioonn SSeerrvviicceess
DDaattaa SSeerrvviicceess
PPrroocceessss SSeerrvviicceess
AAnnaallyytt iiccss && AAcctt iivvii ttyy MMoonnii ttoorr iinngg
CCooll llaabboorraatt iivvee PPoorrttaallss
BBuussiinneessss PPrroocceessss OOrrcchheesstt rraatt iioonn
EEnntteerrpprr iissee SSeerrvviicceess IInnff rraasstt rruuccttuurree
GGrr iidd CCoommppuutt iinngg
IInnffoorrmmaatt iioonn MMaannaaggeemmeenntt
DDeevveelloopp
MMaannaaggee
SSeeccuurree
Oracle Enterprise Messaging Service Page 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 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
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.
The Java Message Service 1.1 and J2EE
Connector Architecture 1.5 open standards
are supported.
Oracle Enterprise Messaging Service Page 6
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.
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.
Figure 1: Oracle EMS Architecture
OEMS offers a quality of service choice for
persisting messages.
Oracle Enterprise Messaging Service Page 7
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.
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
Figure 2: Message Persistence Choices
OEMS offers a number of flexible options
for integrating seamlessly with your
existing non-Oracle messaging
infrastructure.
Oracle Enterprise Messaging Service Page 8
message providers and Streams Advanced Queuing (AQ) in the Oracle Database
through MGW.
Enterprise Messaging Integration – The JMS Connecto r
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
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 & 5.3
2. SonicMQ 6.0
Figure 3: JMS Connector
Oracle Enterprise Messaging Service Page 9
3. Tibco EMS 3.1.0 & 4.3.0
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 & 5.3
2. SonicMQ 6.0
3. Tibco EMS 3.1.0 & 4.3.0
Support of SOA
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.
Figure 4: JMS Router
Oracle Enterprise Messaging Service Page 1 0
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.
Message Integration with the Oracle DB – The Messag ing 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
*It is planned in a future release
of the Oracle Database that
MGW will support Microsoft’s
MSMQ.
The Messaging Gateway is an extension of
Streams AQ that allows for integration of
non-Oracle message systems directly with
the Oracle Database.
Figure 5: Oracle Messaging Gateway
Oracle Enterprise Messaging Service Page 1 1
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.
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.
Comprehensive management and
monitoring of OEMS is available through
the Oracle Enterprise Manager.
Figure 6: Oracle Enterprise Manager 10g Application Server Control provides a single interface for OEMS administration and monitoring
Oracle Enterprise Messaging Service Page 1 2
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 email 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
November 2005
Author: John Lang
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
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 notic e.
This document is not warranted to be error-free, no r subject to any
other warranties or conditions, whether expressed o rally or implied
in law, including implied warranties and conditions of merchantability
or fitness for a particular purpose. We specificall y disclaim any
liability with respect to this document and no cont ractual obligations
are formed either directly or indirectly by this do cument. 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 regis tered trademarks of
Oracle Corporation and/or its affiliates. Other nam es may be trademarks
of their respective owners.