Andrew S. Townley wrote:
> With REST, this isn't the case. The server is in control of the
> interaction, not the client. The client is an active participant and
> always has an option of stopping the conversation at any point, but the
> server is responsible for maintaining the application state internally
> (but it may push the storage of that state information out to the client
> and not manage it itself).
This is an interesting thing to contemplate for web based applications. If I
have a web based application that I need to integrate several different
services, then HTML+FORMS may really get in the way because I have to know
enough about what's important in that stream to create a unified page. Thus, I
haven't one anything.
Jini's ServiceUI facilitates services attaching multiple UIs (and not
necessarily GUIs) to the service registation in the lookup service. The role
field in the UIDescriptor Entry object can be used in lookup operations. A
service deployment might therefore put multiple service definitions using a
particular Java interface into the lookup service. Each might have a separate
UIDescriptor that indicates the specific type of UI role that service supports.
So, I might construct a template as
new ServiceTemplate( null, new Class[]{ TheInterface.class },
new RESTHtmlDescriptor() );
or
new ServiceTemplate( null, new Class[]{ TheInterface.class },
new RESTXmlDescriptor() );
to get an appropriate UI element that my application can use based on the type
of UI I need to use.
The service registration in Jini is editable by anyone having permissions to do
so, as granted by the lookup service. So, I can buy a service from you. When
you register your service object, I can programatically modify that
registration
to attach one or more UIDescriptors.
This is an exploitation of mobile code to provide the UI on top of the service
base. A new UIDescriptor might wrap an Object which performs the integration
of
multiple services into the application framework that I need.
By attaching it to the service registration, it will have a similar lifecycle
to
the service object it is registered with. So replication of services will
carry
with them the UI needed by the clients, and if that machine goes down or the
network fails, the service registration will disappear along with the
UIDescriptor to help manage the issue.
Web based services rely on some machine being able to direct the client to an
alternative point of entry. This has to be done by DNS A records typically.
Jini just does this with lookup services, which can run on separate machines
from the services, and in duplicity to manage partial failure quite effectively.
Gregg Wonderly
