Messaging: Flexible, Powerful, and Extensible model.
Ted Neward.
NET377.
These session notes serve primarily to share the content of the session and as a reference for me. They may also provide some value to those interested in the session topics. Some of the information found in these notes may be inaccurate due to my typing errors or a lack of understanding of the subject matter. DevTeach policy is that session material is available online to registered attendees only, so I cannot respond to any requests for session PPTs or source.
Applications need to talk to one another.
Communications Issues:
- flaky network connectivity
- huge burst loads (slashdot effect)
- scale out "today Duluth, tomorrow, the world!"
- priority to certain clients
- require transactional semantics when communicating with multiple recipients.
- what if we evolve.
RPC exposes behavior.
RPC == request message + response message. Allows for different exchange patterns: request-response, fire and forget, solicit-notify, request-async response.
Messaging exposes data.
- instead of creating contrcts based on interfaces (RPC)
- create contracts based on message types (Messaging)
- seductively similar to RPC (now working with messages instead of objects)
What is Messaging
Message = headers (routing info) + payload
Destination = named message repository
Runtime = variety of delivery semantics
- reliable, transacted, prioritized, deadline-based, publish-and-subscribe, etc.
- provides one or more channels to deliver messages
Messaging System Examples
File transfer, shared database, msmq, soap, http, email, etc.
Use messaging for flexibility
- application now has many more data flow options
- permits more granular processing logic, series of processing steps not known at design-time, content-based router [EAI]. Book recommendation - Enterprise Integration Patterns
Complications of message-based system
- communication is with queues, not objects. Two queues, one for request, one for respone
- no sense of conversational state. Sequence not guaranteed, synchronous communication requires additional work.
- no sense of "object identity." Messages come to queues, not objects, disruption of the usual "client-server" approach, more like "producer-consumer" or even "peer-to-peer"
For request/response communication, stick with RPC!
MSMQ 3.0.
- System.Messaging namespace.
Use using (MessageQueue myQ =...)
Formatter = new XmlMessageFormatter(new Type{} {typof(string) });
Asynchronous message retrieval.
- q.BeginReceive();
Messaging example: ordering on Amazon with maxed credit card. "Thank you for your order." An email was sent to customer when the cc validation took place....LATER.
Summary - Definition of Messaging remains vague, other than using existing technologies with a non request-response approach. Very abstract type of session, not a how-to approach to messaging, which is okay. Because the definition of messaging remains vague to me (or I'm too dense to get it) 9 out of 10. Ted Neward is a very smart guy, maybe the smartest guy at this conference. A natural presenter.