Yep - that's where we are at now, like I said this was an early spike. We're now using the typical Amazon "we got your request and we're working on it" for commands sent into the system, and then a thin WCF web service layer for doing reads/queries that just read straight from the data store with authorization (interceptor/behavior) to make sure the user can read that data. Here there are polling operations exposed that can be used by the client for things like AJAX spinner scenarios.
I'd like to move the query part to REST, but the downside is the data is of a sensitive nature, so we'd have to use HTTPS or use HTTP and encrypt the document on the server and decrypt on the client in JavaScript (suggested by Udi in a comment on one of his blog posts...don't know how I feel about that though...) so we're effectively bypassing the potential benefits of REST. HTTPS internet traffic won't be cached (some proxies can, I know, but not all will) and browsers will most likely not cache it locally, and the client decrypt in JavaScript doesn't sound like the ideal solution either... Oh, and as for caching on the server, we are doing this for smaller datasets, but when you're talking about the "give me page N of 100 pages of data" scenario caching everything and using pub-sub to maintain the cache starts to break down. So our current take is to have a set of query capabilities that's hitting either denormalized, preprepared data (maintained via pub-sub) or finely tuned access paths to the normalized data. Not perfect, but works for now... On Fri, Mar 13, 2009 at 6:13 PM, Ayende Rahien <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
