Jms intro

491 views
299 views

Published on

Published in: Education, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
491
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
23
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Jms intro

  1. 1. M D 1 Java Messaging Service (JMS)
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 24. M D 24 Asynchronous Messaging • Ways that objects communicate • A service of the underlying operating system • Allows programmers to “fire and forget”
  25. 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. 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. 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. 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
  29. 29. M D Message Structure HeaderHeader PropertiesProperties BodyBody
  30. 30. M D Object to Object Messaging HeaderHeader PropertiesProperties BodyBody Message Queue
  31. 31. M D Header • Identify message • Destination • Routing Information • Priority • Timestamp • Reply to • Message type HeaderHeader PropertiesProperties BodyBody
  32. 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. 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. 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. 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. 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. 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. 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

×