2. M
D 2
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
3. M
D 3
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
4. M
D 4
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
5. M
D 5
Application Portability
• To promote portability and
prevent vendor lock-in,
whenever there is a choice
between a vendor-neutral-
industry-standard service
interface and a vendor
specific interface, always use
the vendor-neutral standard
unless you have a
BUSINESS REASON to use
the vendor specific interface
Application
Service
Vendor
Neutral
Service
Interface
Vendor
Specific
Service
Interface
6. M
D 6
What is A Message?
• A communication between two things
(people, computers)
• Typical questions:
– Who was the message from?
– What is the destination?
– Was the message actually received by the
recipient?
– Was it understood? (what restaurant?, 8am
or 8pm?)
– Should it be acknowledged?
– Could it have been tampered with in transit?
– Who really sent it?
Joe,
Lets meet for lunch atthe restaurant at 8.
- John
7. M
D 7
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
8. M
D 8
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
Interface
Application
Interface
9. M
D 9
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
Interface
Application
Interface
Client Client
10. M
D 10
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)
Application
Interface
Application
Interface
Client Client
Message
Server
Store &
Forward
Message
Server
Store &
Forward
Unreliable
Network
Unreliable
Network
11. M
D 11
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
12. M
D 12
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
13. M
D 13
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
14. M
D 14
System Coupling
• TIGHT: Systems that are
very rigid in their
requirements
• System 2 MUST respond to
a message before System 1
can proceed to the next
activity
• LOOSE: Where
programmers just send a
message and can be assure
the infrastructure will do
whatever it needs to do
send the message
System 1 System 2
System 1 System 2
Tight Coupling
Loose Coupling
15. M
D 15
Tightly Coupled Communications
• 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)
System 1
Unreliable
Network
Unreliable
Network
System 2
16. M
D 16
Loosely Coupled Communications
• 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
System 1
Unreliable
Network
Unreliable
Network
System 2
Message
Queue
Message
Queue
17. M
D 17
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
Application
(JMS Client)
JMS Provider
JMS API
J2EE
Application
(JMS Client)
JMS Provider
JMS API
Messaging System
18. M
D 18
APIs Promote Portability
• Applications DO
NOT call an vendor
interface directly
• Applications call
the industry
standard and let the
transport
mechanism move
the data
Sun Certified J2EE 1.3+
Application Server
JMS Interface
Application
Transport Mechanism
Vendor Interface
19. M
D 19
JMS is part of J2EE
• In order to be a Sun-
certified J2EE 1.3+
compliant, the application
server MUST support the
JMS interface (1.2 was
only recommended)
• Any object can use the
JMS API
• JMS is THE default
application server
messaging interface
Sun Certified J2EE 1.3+
Application Server
JMS Interface
Transport Mechanism
Application
20. M
D 20
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/
21. M
D 21
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
22. M
D 22
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
23. M
D
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
24. M
D 24
Asynchronous Messaging
• Ways that objects
communicate
• A service of the
underlying operating
system
• Allows programmers to
“fire and forget”
25. M
D
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
26. M
D
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
27. M
D
Similar to E-mail
Header:Header:
To: From: Subject:
Priority: Urgent
To: From: Subject:
Priority: Urgent
BodyBody
Recipients
e-Mail
Server
Outgoing
Mail
Server
28. M
D
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
30. M
D
Object to Object Messaging
HeaderHeader
PropertiesProperties
BodyBody
Message
Queue
31. M
D
Header
• Identify message
• Destination
• Routing Information
• Priority
• Timestamp
• Reply to
• Message type
HeaderHeader
PropertiesProperties
BodyBody
32. M
D
Properties
• Added by the application
developer
• Application specific
properties
• Key-value pairs
– KEYWORD=VALUE
• Extensions for messaging
systems
HeaderHeader
PropertiesProperties
BodyBody
33. M
D
Body
• Message body
• Can contain arbitrary data
types
– Text messages
– Map (key-value pairs)
– XML
– Serialized objects (Java)
– Binary data
– Empty
HeaderHeader
PropertiesProperties
BodyBody
34. M
D
Message Example
To: My Enterprise Service BusTo: My Enterprise Service Bus
TransactionNumber=12345TransactionNumber=12345
<?xml version="1.0"?>
<RequestedAction>Person Search</RequestedAction>
<Person>
<PersonSurName>Jones</PersonSurName>
<PersonGivenName>Sam</PersonGivenName>
<PersonBirthDate>1980-12-31</PersonBirthDate>
</Person>
<?xml version="1.0"?>
<RequestedAction>Person Search</RequestedAction>
<Person>
<PersonSurName>Jones</PersonSurName>
<PersonGivenName>Sam</PersonGivenName>
<PersonBirthDate>1980-12-31</PersonBirthDate>
</Person>
35. M
D
JMS Modes
• One-to-one (aka Point-to-point)
– Send a message to a JMS Queue
– One message reader
• One-to-Many (aka Publish-subscribe)
– Send (publish) message to a JMS Topic
– Enables many readers (subscribers)
– Also enables many-to-many subscription
Queue
Message
Receiver
Sender
Topic
Message
Subscriber
Sender
Subscriber
36. M
D 36
Required Header Types
• Automatic – automatically put in EVERY
message by the system
• Developer-Assigned – required headers that
must be set before a send()
37. M
D 37
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?
38. M
D 38
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
