I would _strongly_ recommend moving to a polling option instead of locking,
On Sat, Mar 14, 2009 at 6:12 AM, Matt Burton <[email protected]> wrote: > > Gabriel - > > Hopefully Oren was able to give you some further advice on this - I > like his idea of going with REST - that's the direction I'm pushing > for currently, but I'm working with sensitive financial data so it's > not an easy sell from the security perspective - still thinking about > that one. In any event, the only code I have on hand is a really old > spike but it shows the basic principle: > > public class TenantService : ServiceBase, ITenantService, > ConsumerOf<GetCurrentTenantsResponse> > { > private readonly IServiceBus bus; > private GetCurrentTenantsResponse response; > > public TenantService(IServiceBus bus) > { > this.bus = bus; > this.bus.AddInstanceSubscription(this); > } > > public GetCurrentTenantsResponse > GetCurrentTenants(GetCurrentTenantsRequest request) > { > this.bus.Send(request); > > this.WaitForResponse(); > > return this.response; > } > > public void Consume(GetCurrentTenantsResponse message) > { > this.response = message; > > this.NotifyResponseReceived(); > } > } > > You'd just need to add in a message interface that contains a > CorrelationId (so all request and response messages would inherit from > that interface) and then track that in the responses you get. > > HTH, > Matt > > On Fri, Mar 13, 2009 at 3:27 AM, Gabriel Schenker <[email protected]> > wrote: > > @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 -~----------~----~----~----~------~----~------~--~---
