On Friday, March 30, 2007, at 05:33PM, "Gregg Wonderly" <[EMAIL PROTECTED]>
wrote:
>Steve Jones wrote:
>> On 30 Mar 2007 01:46:38 -0700, Jan Algermissen <[EMAIL PROTECTED]
>> <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.
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.
>
>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?).
Jan
>
>The RMI pizza order, if it used Jini with just RMI from an existing client,
>would require:
>
>o What restaurants understand the version of the Order interface that my
> client knows about.
>
>That is, the two questions needing to be answered for HTTP, are implicitly one
>question in Jini because I will do the lookup by interface, so I get the
>resource as a result of that, and because of the method signatures involved,
>I've stated the type of data that I know how to send.
>
>If on the other hand, I used something like my Jini desktop client that is
>ServiceUI aware, I'd lookup the service using attributes instead such as.
>
>new Entry[] {
> new FoodService( FoodType.PIZZA ), // Looking for pizza services
> new UIDescriptor( // Want ones that provide a UI
> MainUI.ROLE, // Want the main ui, not admin
> JComponentFactory.TOOLKIT, // Swing compatible
> null, // no specific attributes
> null // no specific factory
> )
>}
>
>Now, I get a GUI that just lets me select some stuff and submit my order. I
>have no earthly idea, nor do I need to know, how the order is actually
>submitted. Through Jini security, I will have specified some authentication
>constraints to control how I tell them about who I am (during service access),
>and I'll have configure policy to control how their softare interacts on my
>machine with the available resources.
>
>In this case, the uniformity of the client/server interaction is not a
>protocol,
> it is a set of capabilities that is negociated as part of the service
>discovery, and thus we have some control, if needed, of how those negociations
>proceed, and when we find something, we know we can use it.
>
>Gregg Wonderly
>
>
>
>Yahoo! Groups Links
>
>
>
>
>
