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
Message = headers (routing info) + payload (data)
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
atom of transmission; nothing bigger or smaller
delivery guarantees
at-least-once
at-most-once
once-and-only-once
transmission can often be transacted w/other messages
payload: user data (opaque to messaging system)
typically a byte-array at heart
but some systems may provide structure on top of that
headers: message meta-information
some may be recognized/used by system (sender, receiver, etc)
some may be user/application-centric
Sender/ReplyTo: actor sending/producing the message
Recipient: actor receiving/consuming the message
Subject: descriptor of the content (often for filtering)
TimeToLive (TTL): message expiry (with or without delivery)
Priority: abstract measurement of delivery
descriptor of message target
queue name
mailbox descriptor
which may or may not be tied to an actor directly
messages may "persist" at a destination
mechanism/infrastructure for message delivery
typically requires explicit connection/participation
often configured apart from participant use
batch file processing (file == message)
email (email message == message)
database (database tuple(s) == message)
instant messengers (instant message == message)
HTTP request (request body == message)
When combined with XML (or SOAP) as data payload...
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
simple file transfer from one machine to another
well-known/understood security implications
authentication
ports & firewall accessibility
create applications that "spin" on the FTP incoming directory
when a new file is created, launch, create a lock file, process
when that file is finished, delete the lock file and the message
TCP/IP: "point-to-point, guaranteed delivery"
UDP/IP: "broadcast, non-guaranteed delivery"
either way, client opens socket, listens, acts on connection
up to developers to define message format
for best interop purposes, keep it textual and simple
XML and JSON are best candidates here
"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."
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'
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
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!
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
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
JMS defines two modes: point-to-point, and publish-subscribe
APIs are syntactically and semantically similar
differences are in how consumers consume messages
both sets uses inherited common base classes
When we say "point-to-point", we mean...
a message is consumed by one consumer
multiple producers may be able to send to a single Queue
depends on provider details; most will
multiple consumers may be able to consume from a Queue
depends on provider details; most will
When we say "publish-subscribe", we mean...
a message is consumed by 0..n consumers
multiple producers may be able to send to a single Topic
depends on provider details; most will
multiple consumers will consume from a Topic
depends on provider details; most will
message doesn't go away until all durable subscribers receive() it
When we say "subscribers can be durable", we mean...
they will be "remembered" by the plumbing when messages are delivered to the Topic
they will receive messages even if they are not currently alive to receive them (later delivery)
durable subscribers are frequently administered
or create a durable subscriber with createDurableSubscriber()
unsubscribe with unsubscribe() (important!)
duplicate subscribers not allowed
Messages can be of several different formats
raw bytes
text
a series of ordered primitive values (a tuple)
a Serializable Java object
a map of name/value pairs (of primitive values)Any other formats can usually be managed given the above
SOAP: over text
NDR: over raw bytes
An (incomplete) list of JMS providers:
Open source: ActiveMQ, OpenJMS, JORAM
Special-purpose: DropboxMQ, Somnifugi
Big vendors: Weblogic, IBM (MQ), Oracle (AQ, Sun OpenMQ)
Small vendors: SwiftMQ, SonicMQ, Fiorano, JbossMQ
Certain details will change with the provider used
some will use Properties files and the filesystem
some will use a central database/repository
configuration will change based on those details
some will offer certain features others don't
recoverability, administration, monitoring, ...
choosing the provider can be the hardest part at times
messaging is flexible
messaging is scalable
messaging can operate over many channels
messaging requires more work on the part of the programmer
many different messaging exchange patterns exist
Who is this guy?
Architect, Engineering Manager/Leader, "force multiplier"
Principal -- Neward & Associates
http://www.newardassociates.com
Educative (http://educative.io) Author
Performance Management for Engineering Managers
Author
Professional F# 2.0 (w/Erickson, et al; Wrox, 2010)
Effective Enterprise Java (Addison-Wesley, 2004)
SSCLI Essentials (w/Stutz, et al; OReilly, 2003)
Server-Based Java Programming (Manning, 2000)