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. 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
