The Artima Developer Community
Sponsored Link

Separating UI and Functionality
The Flexible Way to Architect a Jini Service
by Bill Venners
October 1999

<<  Page 5 of 5

Advertisement

Conclusion

As a general rule, service providers should not mix UI code with service object code. For example, a Jini service object should not extend a class from a user interface library, such as java.awt.Panel or javax.swing.JPanel. Nor should it contain dependencies on any kind of UI library. Jini services, therefore, should not be designed in the way that desktop applications have often been defined, with UI code intermingled with functionality. The Jini service object should encapsulate the functionality of the service, the whole functionality of the service, and nothing but the functionality of the service. Prior-knowledge Jini clients can just use the service object directly. Human users can access the service via a "user adapter" object, and non-Jini clients can access the service via a "protocol adapter" object.

To find out just how service providers and third parties should attach UIs to Jini services, and how clients can search for a best-fit UI, see the ServiceUI Project pages.

Note: This article did not appear in the Jiniology column at JavaWorld.

<<  Page 5 of 5




Google
  Web Artima.com   
Copyright © 1996-2017 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us