Oracle Fusion Middleware 10 g R2 Oracle Enterprise ... · PDF filemiddleware infrastructure....

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

Transcript of Oracle Fusion Middleware 10 g R2 Oracle Enterprise ... · PDF filemiddleware infrastructure....

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.