Java Messaging Service (JMS)

and Enterprise Messaging Strategy

Author: Dan McCreary
Date: 7/20/2004
Version: 0.1
M

D Copyright 2004-2008 Dan McCreary & Associates 1

 Objectives
• Understand strategies for computer-to-computer messaging
• Understand how vendors attempt to lock-in customers using proprietary
communication APIs
• Understand why the Java Messaging Service (JMS) is becoming the
de-facto vendor-neutral messaging interface between J2EE systems
and how JMS helps avoid vendor lock-in
• Understand the differences between messaging systems
• Understand how messaging systems interoperate
• Understand how JMS fits in with other EAI architectures such as Web
Services, SOA, ESB, Multi-tier architectures, J2EE Architecture, JCA,
Microsoft BizTalk, RosettaNet
• Understand how future systems will interoperate
• Review references
M

D Copyright 2004-2008 Dan McCreary & Associates 2

 Messaging Strategy Overview
1. Support cost effective reliable messaging
between state law enforcement agencies
2. Allow messages to have guaranteed
delivery and be fully encrypted
3. Avoid vendor-specific APIs
4. Integrate with search and workflow
5. Be flexible for future standards
6. Make it easy for developers to use
M

D Copyright 2004-2008 Dan McCreary & Associates 3

 Vendor Lock-In
• Definition: When you spend a lot of time and money
building your products around a specific vendor's
solution.
• Vendor lock-in prevents you from moving your
application to another vendor or an open-source solution
– Vendor lock-in is Bad
– Portability between vendors is Good
• Successful Enterprise Architecture Strategies attempt to
minimize dependencies on any product due to:
– Excessive licensing fees
– Excessive support fees
– Vendor support for a specific product
– Vendor stability
M

D Copyright 2004-2008 Dan McCreary & Associates 4

 Application Portability
• To promote portability and
Application
prevent vendor lock-in,
whenever there is a choice
between a vendor-neutral-
industry-standard service
interface and a vendor
specific interface, always use
Vendor Vendor
Neutral Specific the vendor-neutral standard
Service Service
Interface Interface
unless you have a
Service
BUSINESS REASON to use
M
the vendor specific interface
D Copyright 2004-2008 Dan McCreary & Associates 5
 What is A Message?
• A communication between two things
(people, computers)
• Typical questions:
– Who was the message from?
Joe,
– What is the destination?
Lets meet f
or lu
the restaura nch at
– Was the message actually received by the
nt at 8. recipient?
- John – Was it understood? (what restaurant?, 8am
or 8pm?)
– Should it be acknowledged?
– Could it have been tampered with in transit?
– Who really sent it?

D Copyright 2004-2008 Dan McCreary & Associates 6

 Definition
Messaging: a method of communication
between software components or
applications
– E-mail is also messaging but it is person to
person
– In this tutorial, messaging is computer to
computer

D Copyright 2004-2008 Dan McCreary & Associates 7

 Messaging System
• A Messaging System is a peer-to-peer facility to allow any
number computer applications to communicate with each other
• A messaging application can send messages to, and receive
messages from, any other application
• Each client connects to a messaging interface that provides
facilities for creating, sending, receiving, and reading
messages.

Application Application

Interface Interface

D Copyright 2004-2008 Dan McCreary & Associates 8

 Messaging Clients
• A Messaging Client is a system that handles the communication
between the application interface and the physical network
• A client can be either an open-source product or a commercial
product
• Clients deal with issues such as how to send a message over an
unreliable network

Application Application

Interface Interface
Client Client

D Copyright 2004-2008 Dan McCreary & Associates 9

 Store and Forward
• Messaging clients deal with issues such as how to send a message over an
unreliable network with guaranteed security once-and only-once-delivery
so that messages can be part of reliable distributed transactions (ACID)

Unreliable
Unreliable
Network
Network

Application Application
Message Message
Interface Server Server Interface
Store & Store &
Client Forward Forward Client

D Copyright 2004-2008 Dan McCreary & Associates 10

 Java Transaction API
• Java Transactions are handled by the Java
Transaction API (JTA)
• The JTA makes it easy for Java programmers
to do complex transactions involving data on
multiple J2EE systems located over a wide
area network (WAN)
• JTA depends on Messages Beans (MBean)
and therefore JMS
• JTA makes ACID transactions possible
M

D Copyright 2004-2008 Dan McCreary & Associates 11

 ACID Test
• Atomicity – all or nothing – a transaction either
completely succeeds or it completely fails –
nothing in between
• Consistency – meet constraints of endpoints such
as non-duplicate ID numbers
• Isolation – each transaction has a consistent view
of the world
• Durability – once committed the transaction will
endure regardless of single component failure
M

D Copyright 2004-2008 Dan McCreary & Associates 12

 A Wire Protocol
• A wire protocol is an agreed upon standard
between two systems (potentially built with
different technologies) that defines how
they will communicate with each other
Format of messages "on the wire"

Examples: HTTP (web), SMTP (mail), SNMP (monitoring) and SOAP

M

D Copyright 2004-2008 Dan McCreary & Associates 13

 System Coupling
• TIGHT: Systems that are
System 1 System 2 very rigid in their
requirements
• System 2 MUST respond to a
Tight Coupling
message before System 1 can
proceed to the next activity
System 1 System 2
• LOOSE: Where
programmers just send a
message and can be assure
Loose Coupling
the infrastructure will do
whatever it needs to do send
the message
M

D Copyright 2004-2008 Dan McCreary & Associates 14

 Tightly Coupled Communications
System 1 System 2

Unreliable
Unreliable
Network
Network

• Sender needs a remote service and calls a remote procedure call

• The sending process “Stops” and waits for a reply
• Synchronous messaging – don’t proceed till we are synchronized up
• The sender will “freeze” if the network is down or the sender will have to
manually keep trying till the remote system is up and it gets a response
• Remote procedure call (RPC), Java Remote Method Invocation (RMI)
M

D Copyright 2004-2008 Dan McCreary & Associates 15

 Loosely Coupled Communications
System 1 System 2

Unreliable
Unreliable
Message Network
Network Message
Queue Queue

• Programmers just “fire and forget”

• There is no “blocking” of sender’s process
• System 1 just gets a reply message when the data request has been received
• System can transmit messages to remote systems even when the remote system is down or the
network has failed. Messages wait patiently in the queue till the network is back up.
• System administrators can monitor the message queues and be notified of congestions
• High priority messages can take precedence over large, batch transfers
M

D Copyright 2004-2008 Dan McCreary & Associates 16

 Application Program Interface (API)
• A formal set of interfaces definitions used by programmers
• Usually a specified in SPECIFIC language such as Java or C
• Java Messaging Service (JMS) is an API
• JMS was designed to be a wrapper API around existing
messaging systems

J2EE J2EE
Application Application
(JMS Client) (JMS Client)
JMS API JMS API
JMS Provider Messaging System JMS Provider

D Copyright 2004-2008 Dan McCreary & Associates 17

 APIs Promote Portability
Sun Certified J2EE 1.3+ • Applications DO
Application Server
Application NOT call an vendor
interface directly
• Applications call
JMS Interface
the industry
standard and let the
Vendor Interface
transport
Transport Mechanism
mechanism move
the data
M

D Copyright 2004-2008 Dan McCreary & Associates 18

 JMS is part of J2EE
Sun Certified J2EE 1.3+ • In order to be a Sun-certified
Application Server J2EE 1.3+ compliant, the
Application
application server MUST
support the JMS interface
(1.2 was only recommended)
JMS Interface
• Any object can use the JMS
API
• JMS is THE default
application server messaging
Transport Mechanism
interface
M

D Copyright 2004-2008 Dan McCreary & Associates 19

 JMS Details
• JMS is a Messaging API Specification
• Published and maintained by Sun
Microsystems
• First published in August 1998.
• Latest version is Version 1.0.2b
• See http://java.sun.com/products/jms/

D Copyright 2004-2008 Dan McCreary & Associates 20

 Goals of JMS
• Minimizes the set of concepts a
programmer must learn to use messaging
products (programmer friendly)
• Provides enough features to support
sophisticated messaging applications
• Maximize the portability of JMS
applications across JMS providers in the
same messaging domain
M

D Copyright 2004-2008 Dan McCreary & Associates 21

 Benefits of JMS
• Simplifies enterprise development
• Allows loosely coupled systems (systems
that don't block each other)
• Provides reliable messaging over an
unreliable network
• Promotes secure messaging between systems
• Messages between JMS systems can be
encrypted
M

D Copyright 2004-2008 Dan McCreary & Associates 22

 Vendors Passing JMS Compatibility Tests
• Macromedia
Part of the J2EE SDK
• Oracle Corporation
version 1.3. J2EE
• Pramati
Must licensees Sun • SeeBeyond
technology to be
• SilverStream Software, Inc.
certified (Novell)
• BEA Systems, Inc. • Sonic Software
• Hewlett-Packard • SpiritSoft, Inc.
• IBM • Talarian Corp.
• JBoss • TIBCO Software, Inc.
• Sun
M

D Copyright 2004-2008 Dan McCreary & Associates 23

 JMS is NOT a Wire Protocol
• The JMS API is promoted as a technology
for providing high-quality reliable
communication between components within
an enterprise, but not for business-to-
business (B2B) communication between
enterprises over the Internet
• JMS is an insulator for proprietary
messaging APIs
• JMS is not a router to router specification
M

D Copyright 2004-2008 Dan McCreary & Associates 24

 JBoss and JBossMQ
JBoss • JBoss has an
Application implementation of the
JMS interface
• JBoss has an
JMS Interface implementation of the JMS
transport service
• JMS isolates the
application from
JBossMQ dependencies of specific
transport systems
M

D Copyright 2004-2008 Dan McCreary & Associates 25

 JBossMQ
• Initially released as spyderMQ
• "clean room" implementation
– programmers given an interface specification
but have never seen similar systems – very low
risk of copyright infringement
• First release April 2000
• Active users migrated from standalone
spyderMQ to JBossMQ
M

D Copyright 2004-2008 Dan McCreary & Associates 26

 JBossMQ
• Full implementation of JMS specification
including:
– Point-to-point
– Publish-subscribe
– Durable subscribers
– JMS Application Server Facilities
– Global work units can be coordinated by
transaction manager

D Copyright 2004-2008 Dan McCreary & Associates 27

 When to Use a JMS Interface?
• The provider wants the components not to depend
on information about other components' interfaces,
so that components can be easily replaced
• The provider wants the application to run whether
or not all components are up and running
simultaneously
• The application business model allows a component
to send information to another and to continue to
operate without receiving an immediate response

D Copyright 2004-2008 Dan McCreary & Associates 28

 ISO Seven Layer Reference Model
• Seven layers of
Application
"Abstraction" that allows
Presentation
applications to
Session communicate with each
Transport other
Network
• Lowest level is the
physical wire
Data Link
• Internet Protocol is in the
Physical
M
middle
D Copyright 2004-2008 Dan McCreary & Associates 29
 Communication Occurs at the
Lowest Level
Application Application

Presentation Presentation

Session Session

Transport Transport

Network Network

Data Link Data Link

Physical Physical
M

D Copyright 2004-2008 Dan McCreary & Associates 30

 What is a "Common Language"?

Problem Solving

Conversation

Sentences

Words

Phonemes

Sound

D Copyright 2004-2008 Dan McCreary & Associates 31

 Computer to Computer

Service Level Agreements

Interface Definitions WSDL

XML Schemas

XML Tags

XML

Internet

D Copyright 2004-2008 Dan McCreary & Associates 32

 Publish/Subscribe Securely

Publisher 1 Publisher 2 Publisher 3

Criminal Justice Information Bus Authentication

Subscriber 1 Subscriber 2 Subscriber 3

D Copyright 2004-2008 Dan McCreary & Associates 33

 3 EAI Architectures

Presentation Presentation Presentation

Method Method Method

Data
Database Database
M

D Copyright 2004-2008 Dan McCreary & Associates 34

 Evolution of EAI

Share process

Share read-write data

Share read-only
data

D Copyright 2004-2008 Dan McCreary & Associates 35

 Why Share Process?
• Sharing data requires you to know who has
the right data: the synchronization problem
and the metadata problem.
• Sharing process allows you to avoid
rewriting code.
• Quality of data is dependant on the process
that validate it.

D Copyright 2004-2008 Dan McCreary & Associates 36

 Challenges: Share Process and Data
• Allow any application developer to easily
allow both user and programmatic access to
application services.
• Often requires developers to re-
conceptualize their applications as a series
of published services: e.g. Web Service

D Copyright 2004-2008 Dan McCreary & Associates 37

 EAI is Expensive
• Up to 30% of costs of
Initial License installing enterprise
Costs applications are related
to integration.
– Gartner Group

Integration Costs

D Copyright 2004-2008 Dan McCreary & Associates 38

 Asynchronous Messaging
• Ways that objects
communicate
• A service of the
underlying operating
system
• Allows programmers to
“fire and forget”

D Copyright 2004-2008 Dan McCreary & Associates 39

 Message Brokers
Use of a broker will reduce these integration costs
by one-third. During maintenance, when a single
change to an application can have a rippling effect
on several to several dozen interfaces, use of a
broker can reduce costs by two-thirds.“
- Gartner Group

D Copyright 2004-2008 Dan McCreary & Associates 40

 Message Queuing
• Message Oriented Middleware – Product
Classification
• IBM MQSeries - Product
• Microsoft MSMQ - Product
• Java 2 Enterprise Edition (J2EE 1.4)- J2EE
– Application Server Standard
• Java Messaging Service - JMS

D Copyright 2004-2008 Dan McCreary & Associates 41

 Messaging Benefits
• Messaging infrastructure guarantees reliable
delivery of a message
• Once and only once delivery
• Messages can have different priority
• Transactional control
• Transactions can be grouped together
• Support of “undo” – reversible operations

D Copyright 2004-2008 Dan McCreary & Associates 42

 Similar to E-mail

Header:
Header:
Outgoing To:
To: From:
From: Subject:
Subject:
Priority: Urgent
Priority: Urgent
Mail
Server
Body
Body

Recipients
e-Mail
M
Server

D Copyright 2004-2008 Dan McCreary & Associates 43

 When we send e-mail…
• Sender sends a message to the outgoing e-
mail server using a standard format ( e.g.
Simple Mail Transfer Protocol)
• Message is routed to receiver’s e-mail
server
• Message stored in e-mail server till the
receiver picks up the message
• Example of asynchronous processing
M

D Copyright 2004-2008 Dan McCreary & Associates 44

 Message Structure

Header
Header
Properties
Properties

Body
Body

D Copyright 2004-2008 Dan McCreary & Associates 45

 Object to Object Messaging

Header
Header
Properties
Properties

Body
Body

Message
Queue
M

D Copyright 2004-2008 Dan McCreary & Associates 46

 Header
• Identify message
• Destination
• Routing Information
Header
Header • Priority
Properties
Properties
• Timestamp
Body
Body • Reply to
• Message type

D Copyright 2004-2008 Dan McCreary & Associates 47

 Properties
• Added by the application
developer
• Application specific
Header
Header properties
Properties
Properties • Key-value pairs
– KEYWORD=VALUE
Body
Body
• Extensions for messaging
systems

D Copyright 2004-2008 Dan McCreary & Associates 48

 Body
• Message body
• Can contain arbitrary data
types
Header
Header – Text messages
Properties
Properties – Map (key-value pairs)
– XML
Body
Body – Serialized objects (Java)
– Binary data
– Empty

D Copyright 2004-2008 Dan McCreary & Associates 49

 Message Example

To:
To:My
MyEnterprise
EnterpriseService
ServiceBus
Bus
TransactionNumber=12345
TransactionNumber=12345
<?xml
<?xml version="1.0"?>
version="1.0"?>
<RequestedAction>Person
<RequestedAction>Person Search</RequestedAction>
Search</RequestedAction>
<Person>
<Person>
<PersonSurName>Jones</PersonSurName>
<PersonSurName>Jones</PersonSurName>
<PersonGivenName>Sam</PersonGivenName>
<PersonGivenName>Sam</PersonGivenName>
<PersonBirthDate>1980-12-31</PersonBirthDate>
<PersonBirthDate>1980-12-31</PersonBirthDate>
</Person>
</Person>

D Copyright 2004-2008 Dan McCreary & Associates 50

 JMS Modes
Sender

• One-to-one (aka Point-to-point) Message

– Send a message to a JMS Queue Queue

– One message reader

Receiver

Sender
• One-to-Many (aka Publish-subscribe)
Message
– Send (publish) message to a JMS Topic
Topic
– Enables many readers (subscribers)
– Also enables many-to-many subscription Subscriber Subscriber

D Copyright 2004-2008 Dan McCreary & Associates 51

 Required Header Types
• Automatic – automatically put in EVERY
message by the system
• Developer-Assigned – required headers that
must be set before a send()

D Copyright 2004-2008 Dan McCreary & Associates 52

 Automatic Header Information
• Destination – where to send the message (either a
queue or a topic)
• DeliveryMode – reliable or not
• MessageID – number that identifies the message
• Timestamp – date and time that send() was called
• Expiration – time to live in milliseconds – by
default is does not expire
• Redelivered – not the first try
• Priority – Should this message be expedited?
M

D Copyright 2004-2008 Dan McCreary & Associates 53

 Priority Messages
• The JMS API defines ten levels of priority
value
• 0 as the lowest priority
• 9 as the highest
• 0-4 are gradations of normal priority and
priorities
• 5-9 are gradations of expedited priority

D Copyright 2004-2008 Dan McCreary & Associates 54

 Developer Assigned
• ReplyTo – who should the receiver send a
reply to
• CorrlationID – how this message is related
to previous messages
• Type – The type of the payload – binary,
text, XML etc.

D Copyright 2004-2008 Dan McCreary & Associates 55

 Multi-Tier Architecture
Customer

First Name:

Presentation Last Name:

Phone:

Save

Control Window Controller

Process Customer Order

Persistence Database Adapter

Database
Database
M

D Copyright 2004-2008 Dan McCreary & Associates 56

 J2EE Container Architecture
• J2EE allows developers to
Container create "beans" that inherit
common characteristics
Bean • Everything inside a
container can have a
Bean
Bean
common set of
characteristics
Application Server
• Data, Communication,
Security
M

D Copyright 2004-2008 Dan McCreary & Associates 57

 J2EE Bean Types
User
• J2EE allows developers to
Container create "beans" that inherit
common characteristics
Session
Bean • Everything inside a
Message container can have a
Bean
Entity
Bean common set of
characteristics
Application Server
• Data, Communication,
DB Security
JMS Provider
M

D Copyright 2004-2008 Dan McCreary & Associates 58

 JCA: J2EE Connection Architecture

Container-Component
Container Contract
Application
ApplicationComponent
Component

Application Contract
Connection Pool
Manager System
Contract
Resource Adapter
Security
Transaction
Services
Manager
Manager
EIS-specific Interface

Application Server
Enterprise Information
System
M

D Copyright 2004-2008 Dan McCreary & Associates 59

 Bridges
Translation

Vendor A Vendor B
• Bridges translate from one vendor system into another
• Example IBM-MQ to/from MSMQ
• Some loss of information when headers do not have precise
mappings
• Allows interoperability
M

D Copyright 2004-2008 Dan McCreary & Associates 60

 JMS and Web Services
• Web service are similar yet different from
JMS
• Web services is vendor and language neutral
(works with Microsoft, C#, VB etc.)
• Web service can have semantically clear
published interfaces
• Web service are not inherently reliable and do
not offer standards for retransmission
• Built on SOAP which is extensible
M

D Copyright 2004-2008 Dan McCreary & Associates 61

 SOAP is a wire protocol for exchanging
messages

SOAP
SOAPDocument
Document • Any XML tags can be
SOAP Header
SOAP Body added to SOAP header to
tell the receiving system
how to transmit the message
• Security can also be added
• Must agree on what tags to
use
M

D Copyright 2004-2008 Dan McCreary & Associates 62

 Future WS-Reliable, WS-Secure
• New web-service standards to provide wire-
protocol reliable and secure web services
• Emerging standards from IBM, Microsoft,
TIBCO etc.
• Sun, Oracle have a similar standard WS-
Reliability
• Wait for standards to shake out before
adopting
M

D Copyright 2004-2008 Dan McCreary & Associates 63

 CriMNet Tiers
CriMNet Hub Server

CriMNet CriMNet CriMNet

Helper Services Communication
Engines Tier Tier
Natural
CriMNet website
Language
Interact Ÿ Registration
Translator
with the Request
Database Ÿ Locater / Query
Biometrics Request
Registration Ÿ Web Site

Registry Operations Console

Fax Server Servlets
(Unique ID’s) Ÿ Monitoring,
XML/XSLT Ÿ Reporting,
Association Ÿ Administration
Directory JSP w/Custom Tags
Services Services

Search Module Session

Manager
Custom
Query
Services Session
Controller HTTPS
Locator
Services
Request
Handler

CriMNet Rules
Processing
Database JMS Server
Client
Ÿ Browser (SSL)
Message Ÿ Custom App via
Processing Point-to-Point https

Registry Access
Security Publish
Logging
Logging
Config
Messaging
Profiles

Meta Data
Admin
. Other CriMNet Hub
.
Critical Data
.
Rules Interface with
Legacy systems
Archiving (e.g. local agencies)
Adaptor Operational
Systems

D From January
Copyright 2004-2008 2000 Macro
Dan McCreary Group Logical Architecture
& Associates 64
 BizTalk Architecture

Application
Application BizTalk Message
Adapter
Adapter
Transport
TransportEnvelope
Envelope

BizTalk BizTalk
BizTalkDoc
BizTalkDoc
Doc Doc
Header Header

Body Body

BizTalk
BizTalkServer
Server Internet
Internet BizTalk
BizTalkServer
Server

D Copyright 2004-2008 Dan McCreary & Associates 65

 BizTalk Constraints
• Protocols are proprietary to Microsoft
• XLang is only used by Microsoft
• All endpoints are MSMQ

D Copyright 2004-2008 Dan McCreary & Associates 66

 RosettaNet
Action • Agree on
Transaction bottom six
Process
Application
layers of OSI
Service
Agent
model
Message Handling • Subdivide
Transfer
Presentation application
Session Security layer into seven
Transport
Network
distinct layers
Data Link
M Physical
D Copyright 2004-2008 Dan McCreary & Associates 67
 JMS and ESB
"An ESB can be a sensible first step toward a
systematic Enterprise Nervous System because it
provides the basic connectivity backbone. It can
interoperate with a variety of disparate application
servers simultaneously, smoothing over technical
differences and also providing services for
communication and integration.”

Roy Schulte
VP and Research Fellow
M
Gartner Research
D Copyright 2004-2008 Dan McCreary & Associates 68
 References
• Best high-level book for
EAI architects using J2EE
– J2EE Connector
Architecture and Enterprise
Application Integration (by
Sharma, Stearns and Ng)

D Copyright 2004-2008 Dan McCreary & Associates 69

 JMS Textbooks
1. Java Message Service
by Richard Monson-Haefel and
David Chappell
Good explanation on how to use
JMS for programmers
2. Java Message Service API Tutorial
and Reference: Messaging for the
J2EE Platform by Mark Hapner,
Rich Burridge, Rahul Sharma,
Joseph Fialli, Kim Haase
3. Enterprise JMS Programming
by Shaun Terry
M

D Copyright 2004-2008 Dan McCreary & Associates 70

 JBossMQ
• JBoss Administration and
Development
by Marc Fleury, Scott Stark
• Chapter 4 has an excellent
chapter on JMS and JBossMQ
• Chapter 6 covers Transactions
• Chapter 7 covers Connector
Architecture
• (book only covers JBoss up to
2.4.x)

D Copyright 2004-2008 Dan McCreary & Associates 71

 Thank You!

Please contact me for more information:

• Enterprise Service Bus
• Native XML Databases
• Metadata Management
• Metadata Registries
• Service Oriented Architectures
• Business Intelligence and Data Warehouse
• Semantic Web
Dan McCreary, President
Dan McCreary & Associates
Metadata Strategy Development
[email protected]
(952) 931-9198

D Copyright 2004-2008 Dan McCreary & Associates 72