public void GetCurrentTenants(GetCurrentTenantsRequest request,
Action<GetCurrentTenantsResponse> callback)
{...}
Then set Async=true for your pages if using WebForms (Monorail can do the
same). That way you are not blocking server threads. Client (browser) can
still be connected for all the time it takes to get response & not use AJAX.
On Sat, Mar 14, 2009 at 4: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
-~----------~----~----~----~------~----~------~--~---
