I am not sure if SL has this, but I think it would be easier to have REST interface which accepts RSB XmlSerialized messages and directly post them to the bus.Matt's suggestion is also good.
The question is what is the backend doing, and what types of response does the SL code expects? On Fri, Mar 13, 2009 at 1:39 PM, 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...) 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 -~----------~----~----~----~------~----~------~--~---
