Jan Algermissen wrote: > On Friday, March 30, 2007, at 05:33PM, "Gregg Wonderly" <[EMAIL PROTECTED] > <mailto:gergg%40cox.net>> wrote: > >Steve Jones wrote: > >> On 30 Mar 2007 01:46:38 -0700, Jan Algermissen <[EMAIL PROTECTED] > <mailto:algermissen1971%40mac.com> > >> <mailto:algermissen1971%40mac.com>> wrote: > >> > IWO, do you think in terms of 'business interaction' == method > invocation? > >> > >> God no. > > > >So, I'd like to know more about which programming languages don't allow a > >developer to write a single HTTP operation as a method call in the client. > Is > >there a different programming paradigm used by some languges? > > > >If I wanted to order a pizza in Java, I'd create a URL and open the > connection > >and read the results. That's about 4 different method invocations. If I > wanted > >to order a pizza with an RMI call, I'd have the Pizza object at hand, and a > >reference to the Remote object. I'd then just invoke the method to place > the order. > > > >Jan, are you suggesting that somehow those two different mechanisms are not > >capable of the same thing? > > It depends on what one understands by 'capable'. The question of choosing an > architectural style > is not about being able to achive a task (ordering pizza) but about the > expected nature of an environment > (e.g. that components will change frequently or that there is no central > design authority) and how well > a system addresses the problem space.
I think there is a disconnect here. This whole discussion has been around whether the INVOKE operation, used by Java RMI programming model implementations, to turn method calls into remote communications, is RESTful or not. The other decisions regarding the technology preference etc are important, but I'd prefer that we settle the INVOKE issue without going through all these other decisions. > The benefits of REST can only be seen in the context of, for example, change > or decentralization issues and > only in these contexts one can evaluate whether to trade other system > properties in for what REST gives us. Right now, I sense that noone involved in this discussion can pull their thoughts away from the JRMP implementation of the RMI programming model that is present in the JDK today. The Jini Extensible Remote Invocation (JERI) stack removes the dependency on JRMP, and eliminates the requirement for Java, if you create appropriate endpoints and invocation layer factories for another language/platform/network. As I've said before, I've used JERI to turn method calls into MODBUS network operations. > > > >The HTTP pizza order requires a few things be known. > > > >o What's the resource > >o What data is required in what format > > Not sure what you mean by 'known' but in a REST system you'd discover > both at runtime. You'd discover the resource by type (e.g. look to a > PizzaOrderProcessor) > and that will in turn send you a form telling you what Order MIME type to use > (maybe > UBL some day?). In the Jini programming world, service discovery and mobile code solve the above issues about how you "discover the resources by type". You get a reference to a resource that you can interact with, as you would an HTTP accessed resource. I'm still hunting for your line of division here. What are we miscommunicating? Gregg Wonderly
