[
https://issues.apache.org/activemq/browse/AMQNET-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=60017#action_60017
]
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: https://issues.apache.org/activemq/browse/AMQNET-201
> 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.
