inline On Fri, Mar 13, 2009 at 9:39 AM, Matt Burton <[email protected]> wrote:
> > 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...) isn't it possible with RSB to define a message handler that does not have to explicitly implement a ConsumerOf<TMessage> for every message it wants to handle but where I can rather handle ALL (or a filtered subset) of the messages? > 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. I don't understand this... If I use the correlation Id of the original message and provide it to the corresponding response message I should receive it back with the response? > 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. > > > > > > > > > -- -Gabriel --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
