|
|
|
|
Sponsored Link •
|
|
Advertisement
|
These use cases are intended to capture the requirements of the ServiceUI design project in terms of how the resulting APIs and conventions will be used. It is vital that we are considering all use cases when we think about this design, so if you think a use case is missing or misrepresented by the list on this page, please let us know. All comments are welcome and should be e-mailed to serviceui@jini.org.
To participate in, or just keep track of, the development of a recommended
approach to adding UI to a service, including definition of well-known
interfaces and classes, join a mailing list for the ServiceUI project
at jini.org.
| SERVICE PROVIDER |  |
Associates one or more UIs with a service it offers |
A service provider wishes to offer one or more UIs that provide access to its service or services. It may wish to associate multiple UIs with the same service, because that will enable its service to be usable from many different kinds of devices. Scenarios: Service provider wishes to allow third party UIs, or disallow them. Service provider may also want to make it impossible for their UI to be used with third party services.
| THIRD PARTY | |
Associates a UI with a particular existing service |
A third party wishes to offer a UI that provide access to a particular, existing service.
| THIRD PARTY | |
Creates and makes available a UI for a particular kind (or kinds) of service |
A third party wishes to offer one or more UIs that provides access to a particular kind of service. The third party wishes to make it possible for the UI to be used with any service of the appropriate kind (or kinds) that clients may encounter in the future.
| CLIENT | |
Narrows a search for a service of a particular type based on the UIs it offers |
A user wishes to use a service of some type via a device. On its initial query of the lookup service, the client (the device) is only interested in services of the desired type that offer UIs that have a decent chance of working on the device. Thus, it wants to narrow its search for a service based on the type of service and UIs offered by that service. Two scenarios: resource rich client and resource poor client.
| CLIENT | |
Selects a best-fit UI for a particular service |
After a client has selected a particular service as a certain or likely candidate, the client searches for a UI for the chosen service that best matches its capabilities and user preferences. Two scenarios: resource rich client and resource poor client.
| CLIENT | |
Uses a known UI with a discovered service of a particular type |
A user has a long-term relationship with a UI for a particular type of service. Whenever that user encounters and wishes to use a service of the appropriate type, it wishes to attach the known UI with the recently discovered service. Two scenarios: resource rich client and resource poor client.
| SERVICEUI PROJECT | |
Evolves attributes that describe UIs |
The ServiceUI folks wish to evolve the attributes, factories, etc., describing UI objects over time, to accomodate changes in the hardware infrastructure and user interface capabilities, without breaking existing client code that expects the old form of the attributes.
|
Sponsored Links
|