About discussing this on skype --> I send you an email off-line. On Fri, Mar 13, 2009 at 11:50 AM, Ayende Rahien <[email protected]> wrote:
> It might be best for us to chat on this on Skype.I am heading to the > airport now, and likely to be dead to the world until Sunday, can we > schedule something ? > > On Fri, Mar 13, 2009 at 2:31 PM, Gabriel Schenker <[email protected]>wrote: > >> the type of response that SL code expects has not yet been nailed down >> since we are in an experimental phase. We are open for any elegant >> solution... >> And yes, I think REST is possible with SL. Have to double check it >> >> >> On Fri, Mar 13, 2009 at 9:54 AM, Ayende Rahien <[email protected]> wrote: >> >>> 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. >>>> > > >>>> > >>>> >>>> >>>> >>> >>> >>> >> >> >> -- >> -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 -~----------~----~----~----~------~----~------~--~---
