1 / 80

Messaging Fundamentals

Messaging Fundamentals. Ted Neward http://www.tedneward.com. Objectives. Understand the basics of messaging-based communication what messaging is how messaging works Recognize when to use it what messaging offers what complications messaging presents

isi
Télécharger la présentation

Messaging Fundamentals

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Messaging Fundamentals Ted Neward http://www.tedneward.com

  2. Objectives • Understand the basics of messaging-based communication • what messaging is • how messaging works • Recognize when to use it • what messaging offers • what complications messaging presents • Learn some of the patterns around messaging • message-exchange patterns • architectural communication approaches • See some concrete messaging plumbing

  3. The Goal • Applications need to talk to one another • no violations of the "Once and Only Once" rule • processing sometimes needs centralization for correctness • processing sometimes needs distribution for scale • either way, machines need to talk to machines • The traditional answer has been RPC • "make it look like a function call" • define an interface (for compilation type-safe requirements) • write server-side implementation • tools generate the plumbing necessary between the two

  4. RPC Programming Model

  5. The Problem • RPC can't solve all communication issues • What if the network connectivity is flaky or periodically out? • traveling salesmen, dial-up connections, wireless … • What if we get huge burst loads? • "the Slashdot effect" • What if we need to scale out? • "today Duluth; tomorrow, the world!" • What if we need to offer priority to certain clients? • "It's the VP on port 34865, and he's in a hurry…" • What if we need transactional semantics when communicating with multiple recipients? • "When it absolutely, positively has to be there" • What if we evolve? • "We didn't know we needed it when we wrote the spec!"

  6. The Issues • RPC enables easy communication, at a cost: • request/response communication • for every request, we expect a response • block caller thread until response is received • servers and servants must be available and well-known • RPC proxies typically "pin" against a given server • servant object must be up & running to answer • if server or servant dies, RPC proxies will fail • proxies and stubs are compile-time constants • strong binding/typing makes programming easier • but makes evolution/change harder • RPC exposes behavior

  7. A Solution: Messaging • Strip the veneer off RPC • RPC == request message + response message • break the messages apart, treat them independently • allows for different message exchange patterns • request-response • fire-and-forget • solicit-notify • request-async response • Messaging exposes data • instead of creating contracts based on interfaces (RPC) … • create contracts based on message types (Messaging) • Note: seductively similar to RPC • "On a NewCustomer message, create a new customer…" • strive for context-complete communications

  8. What is messaging? • Anatomy of a MOM system • Message = headers (routing info) + payload • Delivery can be asynchronous • Format is unspecified (loosely bound) • Destination = named message repository • Decouples message producer/consumer • Allows for easier redirection/change of call flow • Runtime = variety of delivery semantics • Reliable, transacted, prioritized, deadline-based, publish-and-subscribe etc • Provides one or more channels to deliver messages

  9. Messaging System Examples • File transfer • Messages: files • Destination: filesystem subdirectory • Runtime: operating system • Shared database • Messages: data tuples • Destination: database tables • Runtime: database • JMS/MSMQ • Messages: byte, text, object, stream, map • Destination: queues (point-to-point), topics (publish-subscribe) • Runtime: MOM support • SOAP • Messages: SOAP XML format • Destination: (depends on transport) • Runtime: Axis, WebLogic, etc

  10. Why use messaging? • Benefits of a MOM system • Use messaging for flexibility • Use messaging to smooth out burst loads • Use messaging for system integration

  11. Why use messaging? • Use messaging for flexibility • Application now has many more data flow options • Fire-and-forget, multicast, disconnected, load-balancing, flow control, priority routing, etc • Permits more granular processing logic • Routing Slip [EAI] "routes a message consecutively through a series of processing steps when the sequence of steps is not known at design-time and may vary for each message" • Content-Based Router [EAI] "handles a situation where the implementation of a single logical function (e.g., inventory check) is spread across multiple physical systems" • Permits easier maintenance and evolution • change message format without recompiling uninterested clients • "flow" data from one side to another without modifying intermediate peers • Avoid concurrency deadlocks (due to blocking on RPC response)

  12. Why use messaging? • Use messaging to smooth out burst loads • queues can fill up with messages waiting to be processed • processors/consumers pull messages as fast as possible • if processor nodes can't keep up... • add more processors • wait for the burst load to disperse over time

  13. Why use messaging? • Use messaging for system integration • messaging doesn't require agreement on type system • message is the type • no agreement on "object semantics" necessary • messaging doesn't require strongly-bound APIs • messaging can bridge several systems (Java, .NET, etc) • XML is absolutely perfect for this • other data representations (CSV, NDR, plain text) work too • messaging's flexibility permits easier integration • Message Translators [EAI] permit transmutation of message • Message Routers [EAI] enable processing workflow

  14. Why use messaging? • Complications of a message-based system • communication is with queues, not objects • bidirectional communication requires at least two queues: one for the request message, one for the response • no sense of conversational state • sequence—messages may arrive out of order • synchronous communication requires addt’l work • no sense of "object identity" • messages come to queues, not objects • disruption of the usual "client-server" approach • more like "producer-consumer" or "peer-to-peer" • For request/response communication, stick with RPC!

  15. Simple Messaging Sometimes you've just gotta get back to basics

  16. Simple Messaging • Messaging systems have long been a part of enterprise systems • batch file processing (file == message) • email (email message == message) • database (database tuple(s) == message) • Plus a few new ones have cropped up in recent years • instant messengers (instant message == message) • HTTP request (request body == message) • When combined with XML (or SOAP) as data payload... • Make use of these! • in essence, project the RESTful model on the other parts of the systems in your enterprise

  17. REST • Representational State Transfer (REST) • doctoral thesis of Roy Fielding (Apache chair, 2000) • "Using elements of the client/server, pipe-and-filter, and distributed objects paradigms, this ['representational state transfer'] style optimises the network transfer of representations of a resource. A Web-based application can be viewed as a dynamic graph of state representations (pages) and the potential transitions (links) between states. The result is an architecture that separates server implementation from the client's perception of resources, scales well with large numbers of clients, enables transfer of data in streams of unlimited size and type, supports intermediaries (proxies and gateways) as data transformation and caching components, and concentrates application state within the user agent components."

  18. REST • In other words… • REST takes the position that the Web as it currently exists is all we really need—why reinvent the wheel? • URIs provide unique monikers on the network • HTTP provides commands and request/response • HTML/XML provides content format • a RESTful model seeks to establish "resources" and use the basic CRUD methods provided by HTTP (GET, POST, PUT, DELETE) • find an Employee: • GET /employeeDatabase?name='fred' • returned content body will be employee data • creating a new Employee: • PUT /employeeDatabase • content body is the employee data • modify an existing Employee: • POST /employeeDatabase?name='fred'

  19. REST • "Resource Modeling" • goal of RESTful system is to model the data elements • addressable resources (via URIs) • uniform interfaces that apply to all resources • manipulation of resources through representations • stateless self-descriptive messages • 'representations'—multiple content types accepted or sent • in essence, we're organizing a distributed application into URI addressable resources that provide the full capabilities of that application solely through HTTP • this is a complete flip from traditional O-O • objects encapsulate data behind processors • REST hides processing behind data elements/structures

  20. REST • There's something to be said for this model • consider the World Wide Web: • well-established, well-documented, "debugged" • no new infrastructure to establish • payload-agnostic • well-defined solutions (HTTPS, proxies, gateways) • obviously extensible (WebDAV, explosive growth) • platform-neutral and technology-agnostic • it's hard to argue with success!

  21. REST • Advantages • REST provides "anarchic scalability" • assumes there is no one central entity of control • architectural elements must continue operating when subjected to unexpected load ("the Slashdot effect") • REST allows for independent deployment • hardware/software can be introduced over time w/o breaking clients (the power of the URI and DNS) • not all participants need change/evolve simultaneously • REST returns us to simplicity • it's all URLs, HTTP, and HTML/XML; nothing else

  22. REST • Disadvantages • REST depends a great deal on underlying technology • HTTP uses simple name/value pairs for headers • this leaves out complex headers (a la WS-Sec) • REST requires a loosely-bound API • “interface genericity” • no metadata constructs to key from • REST requires more work on your part

  23. EMail Access • Simple Mail Transfer Protocol (SMTP) • Internet standard for the better part of a decade • Post Office Protocol (v3) (POP3) • Internet standard for storing and allowing user email download • widely supported, particularly for web-based email systems (Hotmail, Yahoo! mail, etc) • Internet Mail Access Protocol (v4) (IMAP4) • Internet standard for storing and accessing email • more sophisticated than POP3, less widely supported • All are straight text-based protocols

  24. EMail Access • JavaMail • "provides a set of abstract classes defining objects that comprise a mail system." • targets three kinds of developers: • "client, server, or middleware developers interested in building mail and messaging applications…" • "application developers who need to 'mail-enable' their applciations" • "service providers who need to implement specific access and transfer protocols" (using JavaMail to contact pagers, for example) • Java enterprise developers are a little bit of all three!

  25. EMail Access • System.Web.Mail • specifically geared towards sending SMTP mail • Assembly: System.Web.dll • MailMessage: encapsulates the message itself • Most properties self-descriptive (To, From, etc) • Attachments property allows for mail file attachments (MailAttachment objects) • custom headers added via Headers property • SmtpServer: static class encapsulating access to SMTP server • Send sends message to SMTP server • Note: no SMTP authorization capability; be careful when setting this up to avoid creating an open-relay server(!) • No POP3/IMAP support in .NET 1.1

  26. EMail Access • Example: Sending mail MailMessage msg = new MailMessage(); msg.To = "orderprocessing@mycompany.com"; msg.From = "webfrontend@mycompany.com"; msg.Subject = "Order-4512345112"; msg.Body = "<order> ... </order>"; msg.Headers["X-OrderPriority"] = "Normal"; // could use normal email Priority header, if desired msg.Attachments.Add( new MailAttachment(@"C:\docs\foo.pdf", MailEncoding.Base64)); msg.Attachments.Add( new MailAttachment(@"C:\temp\input4512345112", MailEncoding.Base64)); SmtpMail.SmtpServer = "localhost"; SmtpMail.Send(msg);

  27. Other Access • File Transfer Protocol (FTP) • simple file transfer from one machine to another • well-known/understood security implications • authentication • ports & firewall accessibility • Java: Apache Commons Net • .NET: Support coming in Whidbey FCL • Straight sockets: TCP, UDP • Java: java.net.* • .NET: System.Net.Sockets

  28. Java Messaging System (JMS) Messaging-Oriented Middleware, Java style

  29. JMS: Java Messaging Service • Specification for messaging in Java • currently at 1.1 • package javax.jms.* • Captures essence of messaging • Synchronous or asynchronous operation • Loosely- or strongly-coupled operation • Point-to-point and publish-and-subscribe • Guaranteed or fast delivery • Transacted send/receive • Prioritized delivery • Deadline-based delivery • Delivery filtering

  30. Modes of operation • JMS defines two modes: • point-to-point: consumer "takes" message • publish-subscribe: consumer "copies" message • APIs are syntactically and semantically similar • both sets inherit from common base classes

  31. JMS Queues • Point-to-point:

  32. JMS Topics • Publish-subscribe:

  33. Programming Model • Mostly identical for both P2P and PubSub: • Factories obtained from JNDI for bootstrapping • Connections: physical connection to JMS provider • Sessions: thread-scoped context for sending/receiving msgs • Destinations: obtained from JNDI representing the endpoints • (Examples are all P2P; see docs for PubSub equivalents) • Factories and Destinations called Administered Objects • intended to be set up by sys admin, not programmers • some JMS providers offer programmatic API

  34. Programming Model

  35. Programming Model • Creating the Connection: • look up ConnectionFactory, create Connection • call start only after all setup is complete: race condition! • one Connection instance per JVM is usually enough String qfname = "jms/MyQueueConnectionFactory"; // Names chosen by system administrator // when setting up the JMS provider Context ctx = new InitialContext(); QueueConnectionFactory qfac = (QueueConnectionFactory)ctx.lookup(qfname); QueueConnection qcon = qfac.createQueueConnection(); // later, after everything else is set up qcon.start(); // we start receiving messages now

  36. Programming Model • Establishing the thread-scoped Session: • created from Connection • only safe for this thread—synchronize accordingly! • should messages be run under transactional (JTA) semantics? • do you want to acknowledge message receipt manually? QueueConnection qcon = ...; // from previous QueueSession qsession = qcon.createQueueSession(false, // transacted? Session.AUTO_ACKNOWLEDGE); // acknowledgement mode

  37. Programming Model • Look up the Destination • again, go back to JNDI • name of the Destination selected by administrator • typically prefixed by "jms/" (not required) Context ctx = // from before String qname = "jms/MyQueue"; // Name chosen by system administrator when installing // JMS software and configuring initial deployment Queue queue = (Queue)ctx.lookup(qname);

  38. Programming Model • Senders: Create a Producer • scoped and tied to the Session (and Queue) that created it • use this Producer object to do the actual message-send QueueSession qsession = // from before Queue queue = // from before QueueSender qsender = qsession.createSender(queue);

  39. Programming Model • Messages • 3 parts: headers, properties, payload • headers are for JMS usage • properties are for app usage • payload is the actual data

  40. Programming Model

  41. Programming Model • Senders: Create a Message • use the Session to create one of five kinds of messages: • ByteMessage: payload viewed as a byte array • TextMessage: payload viewed as a String • ObjectMessage: payload viewed as a Serializable object • StreamMessage: payload viewed as a DataOutputStream • MapMessage: payload viewed as a java.util.Map

  42. Programming Model • Senders: Create a Message ByteMessage bm = qsession.createByteMessage(); byte[] data = ...; bm.writeBytes(data); TextMessage tm = qsession.createTextMessage(); tm.setText("hello"); ObjectMessage om = qsession.createObjectMessage(); MyObject obj = new MyObject("foo", 7, 2.5); om.setObject(obj); StreamMessage sm = qsession.createStreamMessage(); sm.writeString("foo"); sm.writeInt(7); sm.writeDouble(2.5); MapMessage mm = qsession.createMapMessage(); mm.setInt("num1", 7); mm.setString("name", "foo"); mm.setDouble("num2", 2.5);

  43. Programming Model • Senders: Send the Message • use the Producer object to send the message • delivery mode: • PERSISTENT: msg remains in queue • NON-PERSISTENT: msg clears if nobody receives it • priority: 0 (MIN) – 9 (MAX) value • time to live: when will msg automatically clear Message msg = // from before QueueSender qsender = // from before qsender.send(msg); int priority = 0; long timetolive=0; qsender.send(msg, DeliveryMode.PERSISTENT, priority, timetolive); int priority = 9; long timetolive=10*1000; qsender.send(msg, DeliveryMode.NON-PERSISTENT, priority, timetolive);

  44. Programming Model • Receivers: Create a Consumer • use the Session object to create the Consumer • scoped to the Session and the Destination QueueSession qsession = // from before Queue queue = // from before QueueReceiver qreceiver = qsession.createReceiver(queue);

  45. Programming Model • Receivers: Receive Messages (Synchronously) • poll for messages by blocking in receive on Consumer • returns generic Message object; downcast as necessary while (true) { Message m = qreceiver.receive(); if (m instanceof ByteMessage) { byte data []; int len = ((ByteMessage)m).readBytes(data); } else if (m instanceof TextMessage) { StringBuffer sb = ((TextMessage)m).getText(); } else if (m instanceof ObjectMessage) { MyObject obj = new MyObject(); obj = ((ObjectMessage)m).getObject(); String s = obj.getFoo(); int i = obj.getNum(); } }

  46. Programming Model • Receivers: Receive Messages (Asynchronously) • register a MessageListener with the Consumer • NOTE: onMessage calls will be on separate threads qreceiver.setMessageListener(new MessageListener() { public void onMessage(Message m) { try { if (m instanceof StreamMessage) { StringBuffer s = m.readString(); int n = m.readInt(); double d = m.readDouble(); } else if (m instanceof MapMessage) { // . . . and so on } } catch (Throwable t) { // Divert message to Dead Letter queue? } } });

  47. Programming Model • Receivers: Selectively receive messages • use selector to filter messages before consuming • properties used to set predicate criteria • uses subset of SQL-92 syntax (predicate clauses) • full set of relational and boolean operators available • JMS Spec, section 3.8 // Sender code TextMessage tm = qsession.createTextMessage(); tm.setText("hello"); tm.setStringProperty("name", "fred"); qsender.send(tm); // Receiver code QueueReceiver qr = qsession.createReceiver(q, "name='fred'"); TextMessage tm = (TextMessage)qr.receive(); StringBuffer data = tm.getText(); // tm.getStringProperty("name").equals("fred"), guaranteed!

  48. Programming Model • Request/Response messaging • use Requester to simplify send/block-for-response pattern • creates TemporaryQueue (or Topic), sets JMSReplyTo • receiver extracts JMSReplyTo, posts response there // Rosencrantz.class: QueueRequester qreq = new QueueRequester(qsession, queue); TextMessage tmin = qsess.createTextMessage(); tmin.setText("Hello"); TextMessage tmout = qreq.request(tmin); // blocks // Guildenstern.class: Message msg = ...; Destination reply = msg.getJMSReplyTo() TextMessage tmout = qsess.createTextMessage(); tmout.setText("Hi yourself"); QueueSender qs = qsess.createSender((Queue)reply); qs.send(tmout);

  49. Transactional Programming Model • Group messages into atomic units • delivery guaranteed under ACID conditions • transacted session (specified at creation) scopes messages • can integrate with JTA (distributed transactions) • no transactional call flow (from sender to receiver) • on commit, all messages delivered, consumed messages ack'd • on abort, all messages discarded boolean tx = true; int ackmode = Session.AUTO_ACKNOWLEDGE; QueueSession qsession = qcon.createQueueSession(tx, ackmode); TextMessage tm = qsession.createTextMessage(); tm.setText("hello"); qsender.send(tm); tm = qsession.createTextMessage(); tm.setText("world"); qsender.send(tm); // Calling qsession.commit() here would send both messages // Calling qsession.abort() here would discard both messages

  50. Microsoft Message Queue (MSMQ) Messaging-Oriented Middleware, .NET/COM style

More Related