On Tue, 2006-12-12 at 14:08, Gregg Wonderly wrote:
> 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.
Interesting...
I agree HTML+Forms isn't the right answer for that kind of problem. See
my earlier mails from today on the potential use of XForms submission
entity descriptions to allow you to more easily process it through some
other machine.
Of course, depending on how you slice your system, there's nothing
stopping you as a service provider or consumer from creating a Web-based
facade that does something similar to your UIDescriptor to provide a
more domain-specific integration point, but I don't think you'd do that
except in very specific situations.
Like I said, Jini is on my list of things to read about, but,
unfortunately, it's a long list. :)
ast
--
Andrew S. Townley <[EMAIL PROTECTED]>
http://atownley.org
