Jini uses a service view of applications, in contrast to the simple object-oriented view of an application. Of course, a Jini "application" is made up of objects, but these will be distributed out into individual services, which will communicate via their proxy objects. The Jini specification claims that in many monolithic applications, there are one or more services waiting to be released, and making them into services increases their possible uses.
To see this, let's look at a smart file viewer. This application will be given a file name, and the structure of the name will determine what type of file it is (.rtf is Rich Text Format file, .gif is a Graphics Interchange Format file, etc.). Using this classification, the application will then call up an appropriate viewer for a given type of file, such as an image viewer or document viewer. A UML class diagram for this application might look like Figure 1-12. Figure Overview of Jini.12, “Figure 1-12. A UML diagram for a smart file viewer application”
If we take a service-oriented view of the smart file viewer, then we can see a number of possible services in this application. Classifying a file into types is one possible service (which will be used heavily in the sequel, because it is simple). A file classification service can be used in many different situations, in addition to determining the file type for viewing contents of files. Each of the different viewer classes is another possible candidate for a service: an image display service, a text display service and so on. This is not to say that every class should become a service; that would be overkill. What makes these qualify as services is that they
Have a simple interface
Are useful in more than one situation
Can be replaced or varied
They are reusable, and this is makes them good candidates for services. They do not require high-bandwidth communication and are not completely trivial.
If the application is reorganized as a collection of services, it might look like Figure 1-13. Figure Overview of Jini.13, “Figure 1-13. An application as a collection of services”
Each service may be running on a different machine on the network (or on the same machine; it doesn't matter). Each service exports a proxy to whatever service locators are running. The SmartViewer application finds and downloads whatever services it needs, as it needs them.