On Fri, 2006-12-08 at 22:31, Gregg Wonderly wrote: > Andrew S. Townley wrote: > > In any event, > > doing something useful with that message is going to mean writing code > > anway, but it'll be code that's not tied to a particular remote object > > interface, only the messages and the business-level exchange protocol of > > the service. > > Knowledge of a particular remote object interface is exactly equal to the > knowledge of the messages, their structure and the business-level exchange. > This is the standing argument I have with the REST proponents suggesting that > somehow REST has less cohesion or binding of the application to the service. > > I don't see how there is a difference here. Maybe I'm missing something...
I guess to me I see a difference between early and late binding. To be honest, I'm probably more of a Uniform Pipes & Filters (UPF) guy than anything, but when you have a generalized invocation mechanism that allows anyone interested and capable of responding to the message (e.g. NEXTESTEP/MacOS responder chain--an example of the GoF Chain of Responsibility), you aren't directly tied to selecting or interacting with a particular endpoint. To me I see this as one of the main ways towards achieving loose coupling between service requesters and providers. I know you can do this sort of thing with dynamic proxies in Java to some degree, but I haven't looked at them in great detail. I agree with you that it's about messages (i.e. data, not method calls), their structure and the business level exchange protocols, but I'd rather not have to worry much about how to get those messages from point A to point B. I don't know if this helped any, but from the way I view distributed systems, there is a pretty real difference. ast -- Andrew S. Townley <[EMAIL PROTECTED]> http://atownley.org
