@Matt: would you mind to share your code? On Fri, Mar 13, 2009 at 10:27 AM, Gabriel Schenker <[email protected]>wrote:
> 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 > -- -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 -~----------~----~----~----~------~----~------~--~---
