We don't, right now. We're still exploring that area, finding out where the bottlenecks are when reading data. I'm really delving into what-if scenarios here - the REST issues I described were just me thinking out loud - by the book REST, where you have public data that can be read by anybody (weather data, etc...) has inherent benefits as you are taking advantage of the internet itself - proxies cache, browsers cache, etc... with the appropriate expiry on your resources you can really exploit this to great effect. For our domain, I don't think it will work. We can certainly offer a REST interface over our services as an alternate API, but it's going to have to be HTTPS and fully secured, and only cached on the server side where appropriate.
On Sat, Mar 14, 2009 at 9:14 AM, Ayende Rahien <[email protected]> wrote: > why do you need caching for sensitive info? > > On Sat, Mar 14, 2009 at 6:12 PM, Matt Burton <[email protected]> wrote: >> >> Yeah - security by obscurity didn't fly too well with the security guys :) >> >> On Sat, Mar 14, 2009 at 9:07 AM, Ayende Rahien <[email protected]> wrote: >> > use a guid as the rest key, you can be assured that it will not be >> > guessable. >> > however, at the point, you have to worry about traffic sniffing, etc >> > in general, you don't want caching of sensitive info >> > >> > On Sat, Mar 14, 2009 at 6:00 PM, Matt Burton <[email protected]> >> > wrote: >> >> >> >> 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 -~----------~----~----~----~------~----~------~--~---
