Discussions

General J2EE: Synchronous messaging

  1. Synchronous messaging (5 messages)

    Why would someone do that while other alternatives for request/response exists? Yeah..yeah,I can understand incompatibilities between systems and all other things around them. I mean, with protocols like webservices, http available in market why would i do such thing? Being asynchronous was the major advantage(well not exactly but still MQ is majorly used for asynchronous integration to fullfilment systems) for Messaging queues and not what kind of system on the other hand is consuming message(this may very well go hand in hand but definitely has lots of variables around it). well help me I am having hard time digesting the whole synchronous messaging stuff.

    Threaded Messages (5)

  2. Synchronous messaging[ Go to top ]

    I have never fully understood the needs of messaging. Could someone shine some light on why messaging is needed why not use web services or http.
  3. Synchronous messaging[ Go to top ]

    Messaging infrastructure is most useful for the relay of asynchronous messages in high-throughput and/or latency-sensitive environments. Securities Trading systems are a great example, where messages arrive from customers or exchanges and need to be pipelined very quickly (and asynchronously) through a series of systems that transform, validate, enrich, route, persist, and perform other business functions.

    Middleware provides a network-wide bus to which any number of applications may attach themselves in a loosely-coupled manner and subscribe to messages by topic and according to various message delivery contracts (i.e. guaranteed, "reliable", etc). In complex systems, this frees your application code from having to deal with a fair amount of transport-related logic--reconnection and retransmission due to various failure scenarios is handled for you.

    Now, if you tried to build such a system with just request/response IPC capabilities, you'd run into bottlenecks very quickly since each message you send requires that you wait for both a network round-trip to another process and the time it takes that remote process to digest the message. Why not parallelize these to increase the throughput? Because in many use-cases large quantities of messages must be processed in serial order (say, from a single customer) and because the additional network overhead for even a single message may not be acceptable.

    So why synchronous messaging? Because it's fairly easy for middleware providers to build on top of their asynchronous capabilities, and if you are already using their interfaces, why add more? A trading application may have to absolutely guarantee that a compliance system has processed a certain message, but then can do a fire-and-forget for the next stage of trade processing (say, to deliver an order to an exchange).

    At Gemstone we provide a very interesting alternative approach. Since we have done so much work on the transport and communications infrastructure needed to keep our distributed cache instances in sync across various and diverse network and system topologies, we support the full range of message delivery options and semantics as simple tuning options on how cache changes are propagated and how cache listeners (your own API callbacks) are invoked in response to cache modifications. The includes synchronous invocation, asynchronous invocation, transactional, as well as fire-and-forget with store-and-forward queues. To this we have added the concept of Roles and Policies that allow you to configure behavior in response to various failure scenarios. Through configuration, you could (for example) say that if your Compliance cluster is unavailable, processing must immediately stop, but if your Post-Trade Settlement Processing system goes down, it's ok to store-and-forward all trade updates for later processing.

    This effectively ties together high-performance in-memory distributed caching persistence strategies with ultra low-latency message distribution in a way never before productized.

    Anyway, I hope this helps people to understand some of the rationale behind "middleware" type message delivery technologies.

    Cheers,

    Gideon
    GemFire-The Enterprise Data Fabric
    http://www.gemfire.com
  4. Synchronous messaging[ Go to top ]

    ****************
    So why synchronous messaging? Because it's fairly easy for middleware providers to build on top of their asynchronous capabilities, and if you are already using their interfaces, why add more?
    ****************
    Well, Most of the time when people decide to use queue based messaging, MDB is the first choice to listen to the message. anyways let me give you an example, user makes a request from UI for some data which is provided by third party. what if MQ or the system on other side goes down while user is waiting and request times out. what would happen when server comes back up? Yeah I know I can specify when a message should go in dead letter queue. But lets just say MQ went down and not system other side, MQ came back up reads the message and delivers to system on other side response comes back. And I throw away the response as there is no request waiting on it anymore. now why would I go through such hassle when no one is waiting on the response anymore.
  5. Re: Synchronous messaging[ Go to top ]

    But lets just say MQ went down and not system other side, MQ came back up reads the message and delivers to system on other side response comes back. And I throw away the response as there is no request waiting on it anymore. now why would I go through such hassle when no one is waiting on the response anymore.
    Then you use a NON_PERSISTENT delivery mode with a time-to-live based on how long you expect to wait before telling the client that the request timed out. Don't worry that some remaining "one in a million" times the request will actually go through to the back end system without the response being able to go back to the user; that one in a million is completely unavoidable, because a client connection cannot be guaranteed. Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  6. Re: Synchronous messaging[ Go to top ]

    I'd like to throw my 0.02 Turkish Lira... - and since I'm from GigaSpaces you can guess that I'm going to offer an alternative: JavaSpaces. NOTE: Before I talk about JavaSpaces, note that the full GigaSpaces product also offers a full JMS implementation - so if needed you can use that as well. JavaSpaces is a powerful distributed shared memory bus that can be (and is) used for high-performance dynamic messaging. And because it is fully distributed, messages, queues, channels, etc. can be automatically relocated to available healthy resources. JavaSpaces has built-in notification (check out: this example) - that can help avoid "dead letter" situations by having notifications invoked if a client is no longer subscribed to the message - eliminating the need for unnecessary work-arounds. In addition - JavaSpaces offers content-based routing out-of-the-box, allowing message routing to be determined "just-in-time" by the message contents - as opposed to pre-determined destinations. There's a LOT more that Space-based messaging can do for your application (we do support MDB's for the JMS alternative as well) - I would like to suggest that you download our product here and try it out - there are very detailed messaging examples you can use in your own application. Finally - we have integrated with MULE (open-source ESB) to offer ESB on Space-based messaging. All of the above should help you make an informed decision about alternatives for messaging architectures without sacrificing flexibility - or using artifical solutions workarounds. Gad Barnea GigaSpaces, Inc.