If you can use .NET 3.5 SP1, then you have the ability to use POCO
objects with the DataContractSerializer in WCF, so stand up a WCF
service that looks like
[ServiceContract]
interface IMessageEndpoint:
[OperationContract]
object Handle(object message)
Then in your implementation of the service you'd do bus.Send(message)
in each operation and then the implementation class itself would be a
consumer of all the response messages supported
(ConsumerOf<ListCustomersResponse> which corresponds to the
ListCustomersRequest message, etc...) Up to now it's pretty clean, but
when you start talking about request-response scenarios it gets messy.
We used a ManualResetEvent (just like in the Starbucks example) and
wait until that's been set by the Consume method for the reply message
and then return that. Obviously you'll need to specify a timeout
that's reasonable for the operation (100 ms, 5 seconds, etc...)
There's a major gotcha here - when you do bus.Reply in RSB it does not
use the correlation ID of the message that was originally sent, so
it's up to you to maintain and check for a correlation ID in your
Consume method implementation. In a high load scenario who knows whose
reply message you're actually getting - sure it was sent back to the
same box that originated the request, but it could be anybody's. In
the case where you got a message you don't want you do a
bus.HandleCurrentMessageLater() to put it back at the end of the
queue.
I'm sure there's a more elegant way, but that's what we were starting
to use until we discovered the correlation ID issue.
On Fri, Mar 13, 2009 at 12:58 AM, Gabriel Schenker <[email protected]> wrote:
>
> We are implementing a distributed app with a Silverlight 2.0 client.
> The Web server forwards the calls from the client to an application
> server which sits behind a firewall.
>
> Question:
> --------------
> what would be the easiest/most elegant solution to bridge the WCF
> calls from the Silverlight client into RSB.
>
> Sketch of the envisioned solution:
> ------------------------------------------------
> My wish it is to have one single WCF service with a single method
> accepting "generic" messages (possibly serialized with the
> XmlMessageSerializer of RSB) and replying with a "generic" message
> response (also serialized with the XmlMessageSerializer). That would
> make the configuration of WCF very easy/slim...
>
> As soon as the message arrives at the WCF service I want to feed it
> into the bus. On the application server I then have the appropriate
> message handlers that consume the messages and reply with a message
> response.
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Rhino Tools Dev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/rhino-tools-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
