Bill de hOra wrote:
>
>
> Gregg Wonderly wrote:
>
> > 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
> > )
> > }
>
> from pizza import pizza
> from pizza import BASE
> from units import INCHES
> class CustomerPizza(pizza):
> def __init__(toppings=[], base=BASE.THINCRUST,
> diameter=INCHES.TWELVE), :
> self.toppings =toppings
> self.base = base
> self.diameter=diameter
>
> how do I integrate with your foodservice? Actually, never mind. We can
> find a better question - why do Dominos let me pay for a pizza via HTTP
> but not via RMI?
I'm using RMI here as a programming model namesake, not as any particular
implementation indicator. This is what I feel is not being realized in these
arguments. RMI is NOT Java SE and the JRMP or IIOP transports any longer.
With
the release of Jini 2.0, RMI is now only a programming model, and it has
pluggable details so that the invocation layer (wrapping of Java objects for
transport) and the endpoint (how do you reach the remote end) are abstracted
out.
So, I can implement the Dominos server as a Jini service and you can talk to it
with HTTP, and never know that it's a Java application, let alone that it has a
Jini service registration available for those who don't need web services just
to order a pizza.
My question is still why is the RMI (programming model) INVOKE operation not a
restful operation?
Gregg Wonderly
