activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Gellings (JIRA)" <>
Subject [jira] Commented: (AMQNET-201) WCF binding to support request reply message exchange
Date Thu, 10 Jun 2010 14:38:52 GMT


Mark Gellings commented on AMQNET-201:

That is because MSMQ is naturally one way, and that's because the way I understand it you
use MSMQ, ActiveMQ, etc to apply load leveling functionality.  Meaning, you off load the processing
because it is generally too long for a client to wait for a response and you can load balance
the processing as well as level it out as a response is not real time.

Maybe I don't understand the customer driven motivation you mention.  Why would they want
to switch from request/reply done through WCF to use ActiveMQ?  Why not just continue using
the request/reply through WCF and increase the timeout values?  If you are concerned about
reliability of message transfer then you can enable reliability through the SOAP 1.2 endpoints.
 If you are concerned with ability to load level messaging, then why would you want to do
request/reply with ActiveMQ over of point-to-point (one-way) or pub/sub?

Yes ActiveMQ implements request/reply, but with .NET we have WCF to do it whereas not sure
if other languages have such a technology.

> WCF binding to support request reply message exchange
> -----------------------------------------------------
>                 Key: AMQNET-201
>                 URL:
>             Project: ActiveMQ .Net
>          Issue Type: Improvement
>          Components: NMS
>    Affects Versions: 1.1.0
>            Reporter: Mark Pollack
>            Assignee: Jim Gomes
>            Priority: Minor
> I remember a while back there was some discussion on a JIRA issue where there was an
explicit decision not to implement the request reply message exchange pattern in the WCF binding.
 I think this is not the correct decision.  Request/Reply is a natural interaction for messaging
systems, though clearly not the default.  Implementation options are to use a temporary queue
as the return destination or to setup a standard queue but create a message listener with
a selector.   Just for reference the TIBCO WCF binding supports request reply message exchange.
 A customer driven motivation behind this is that usually everyone creates request/reply endpoints
over http transport in WCF. When they want to switch transports to messaging they discover
(in MSMQ case) that they can't and would have to redesign their entire web services design
to accomodate using JMS transport.  This is simply not needed.  Please reconsider and let's
discuss more.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message