--- In [email protected], Gregg Wonderly <[EMAIL PROTECTED]> wrote: > > Steve Jones wrote: > > It depends if the service is viewed as the technical service, in which > > case the UI isn't part of it. Or a business service which is > > providing capabilities to an end user, in which case the UI is part of > > it. Effectively the execution context changes between the two > > scenarios with a UI being one of the few ways for a person to interact > > with a computer. > > One of the things that I think is important is to make sure and use GUI > (graphical user interface) when you mean something that a human sees to interact > with a service. The use of the term UI (user interface), for me, implies all > classes of interfaces that any "client/user" of a service might use to interact > with the service.
Would it not be a simpler and less ambiguous convention to confine the term User to human users? In this case a UI would be what interacts with a person and a Client Interface, or CI, could what interacts with a client. Using GUI to denote what interacts with a human by definition rules out using non-graphical interfaces with humans... Gervas > > In Jini, the ServiceUI mechanism, abstracts the access to the service as a > factory which consumes the service definition, and provides one or more ways to > get the appropriate UI for use at the "client". In the current implementation, > it is focused on the GUI mechanisms, defining such classes as JFrameFactory, > JDialogFactory, JComponentFactory, ComponentFactory, FrameFactory and > DialogFactory. The "factory" object is a separately marshalled object graph, > stored with the service registration, and includes a "role" designation that > qualifies the "use" of the factory. Also present is the "toolkit" which > together with role, allow a service deployment to have a wide range of attached > user interfaces for different uses. > > The classic "administration" and "main" UI roles are already defined, and > toolkit designations such as "javax.swing" and "java.awt" provide the needed > control, allowing a client to find something that they can use. > > The generality of the UIDescriptor classes fields, toolkit, role and the > attributes list, allows for services to "search" for things that they now how to > use. This also completely separates the services core interface from the > external user interface. The fact that Java mobile code is used when > marshalling the factory object, means that a client, can find the appropriate > interface, download and instantiate it, without having to be concerned about > what other role or toolkits are supported, and having codespace taken up by > unneeded functionality. > > Gregg Wonderly >
