`
`66
`
`KEY CONCEPTS
`
`as printers, displays, or disks; software such as applicationsor utilities; informa-
`tion such as databasesandfiles; and users of the system.
`Services in a Jini system communicate with each other by using a service pro-
`tocol, whichis a set of interfaces written in the Java programming language. The
`set of such protocols is open ended. The base Jini system defines a small number
`of such protocols that definecritical service interactions.
`
`AR.2.1.2. Lookup Service
`
`Services are found and resolved by a lookup service. The lookup service is the
`central bootstrapping mechanism for the system and provides the major point of
`contact between the system and users of the system. In precise terms, a lookup
`service maps interfaces indicating the functionality provided by a service to sets
`of objects that implement the service. In addition, descriptive entries associated
`with a service allow more fine-grained selection of services based on properties
`understandable to people.
`Objects in a lookup service may include other lookupservices; this provides
`hierarchical lookup. Further, a lookup service may contain objects that encapsu-
`late other naming or directory services, providing a way for bridges to be built
`between a Jini Lookupservice and other forms of lookup service. Of course, ref-
`erences to a Jini Lookup service may be placed in these other naming and direc-
`tory services, providing a meansfor clients of those services to gain access to a
`Jini system.
`A service is added to a lookup service by a pair of protocols called discovery
`and join—first the service locates an appropriate lookupservice (by using the dis-
`covery protocol), and then it joins it (by using the join protocol).
`
`AR.2.1.3 Java Remote Method Invocation (RMI)
`
`Communication between services can be accomplished using Java Remote
`Method Invocation (RMI). The infrastructure to support communication between
`services is not itself a service that is discovered and used butis, rather, a part of
`the Jini technology infrastructure. RMI provides mechanismsto find, activate, and
`garbage collect object groups.
`Fundamentally, RMI is a Java programming language-enabled extension to
`traditional remote procedure call mechanisms. RMI allows not only data to be
`passed from object to object around the network but full objects, including code.
`Muchofthe simplicity of the Jini system is enabled by this ability to move code
`around the network in a form that is encapsulated as an object.
`
`
`
`80
`
`80
`
`

`

`
`
`THE JINI ARCHITECTURE SPECIFICATION
`
`AR.2.1.4 Security
`
`67
`
`oer)
`=a=
`La]
`Oa
`
`=len@
`
`ke
`
`The design of the security model for Jini technologyis built on the twin notions of
`a principal and an access control list. Jini services are accessed on behalf of some
`entity—the principal— which generally traces back to a particular userof the sys-
`tem. Services themselves may request access to other services based on the iden-
`tity of the object that implements the service. Whether access to a service is
`allowed depends on the contents of an access control list that is associated with
`the object.
`
`AR.2.1.5 Leasing
`
`Access to many ofthe services in the Jini system environmentis lease based. A
`lease is a grant of guaranteed access over a time period. Eachlease is negotiated
`between the user of the service and the provider of the service as part of the ser-
`vice protocol: A service is requested for some period; access is granted for some
`period, presumably taking the request period into account. If a lease is not
`renewed before it is freed—either because the resource is no longer needed, the
`client or networkfails, or the lease is not permitted to be renewed—then both the
`user and the provider of the resource may concludethat the resource can be freed.
`Leases are either exclusive or non-exclusive. Exclusive leases ensure that no
`one else may take a lease on the resource during the period of the lease; non-
`exclusive leases allow multiple users to share a resource.
`
`AR.2.1.6 Transactions
`
`A series of operations, either within a single service or spanning multiple services,
`can be wrappedin a transaction. The Jini Transaction interfaces supply a service
`protocol needed to coordinate a two-phase commit. How transactions are imple-
`mented—and indeed, the very semantics of the notion of a transaction—isleft up
`to the service using those interfaces.
`
`AR.2.1.7 Events
`
`The Jini architecture supports distributed events. An object may allow other
`objects to register interest in events in the object and receive a notification of the
`occurrence of such an event. This enables distributed event-based programsto be
`written with a variety of reliability and scalability guarantees.
`
`
`
`
`81
`
`81
`
`

`

`68
`
`4
`
`COMPONENTOVERVIEW
`
`AR.2.2 Component Overview
`The components of the Jini system can be segmentedinto three categories: infra-
`structure, programming model, and services. Theinfrastructure is the set of com-
`ponents that enables building a federated Jini system, while the services are the
`entities within the federation. The programming model is a set of interfaces that
`enables the construction ofreliable services, including those that are part of the
`infrastructure and thosethat join into the federation.
`These three categories, though distinct and separable, are entangled to such an
`extent that the distinction between them can seem blurred. Moreover,it is possible
`to build systemsthat have someof the functionality of the Jini system with vari-
`ants on the categories or withoutall three of them, But a Jini system gainsits full
`powerbecause it is a system built with the particular infrastructure and program-
`ming models described, based on the notion of a service. Decoupling the seg-
`ments within the architecture allows legacy code to be changed minimally to take
`part in a Jini system. Nevertheless, the full powerof a Jini system will be available
`only to new servicesthat are constructed using the integrated model.
`A Jini system can be seen as a network extension of the infrastructure, pro-
`gramming model, and services that made Java technology successful in the single-
`machine case. These categories along with the corresponding componentsin the
`familiar Java application environmentare shown in Figure AR.2.1:
`
` | Services
`| Programming Model
`Infrastructure
`Java APIs
`Java VM
`RMI
`JavaBeans
`Java Security
`
`JNDI
`Enterprise Beans
`JTS
`
`Base
`Java
`
`
`
`
`
`Java
`+
`Jini
`
`Discovery/Join
`Distributed Security
`Lookup
`
`Leasing
`Transactions
`Events
`
`Printing
`Transaction Manager
`JavaSpaces Service
`
`—t
`
`
`FIGURE AR.2.1: Jini Architecture Segmentation
`
`
`
`
`82
`
`82
`
`

`

`ag
`mec
`n-
`[|
`Lar}
`
`fa)
`
`ao
`
`
`
`THE JINI ARCHITECTURE SPECIFICATION
`
`AR.2.2.1 Infrastructure
`
`The Jini technology infrastructure defines the minimal Jini technology core. The
`infrastructure includes the following:
`
`¢ A distributed security system, integrated into RMI,that extendsthe Java plat-
`form’s security model to the world of distributed systems,
`+ The discovery andjoin protocols, service protocols that allow services (both
`hardware and software) to discover, become part of, and advertise supplied
`services to the other members ofthe federation,
`¢ The lookup service, which serves as a repository of services. Entries in the
`lookup service are objects written in the Java programming language; these
`objects can be downloaded as part of a lookup operation and act as local
`proxiesto the service that placed the code into the lookupservice.
`The discovery and join protocols define the way a service of any kind
`becomespart of a Jini system; RMI defines the base language within which the
`Jini services communicate; the distributed security model and its implementation
`define howentities are identified and how they getthe rights to perform actions on
`their own behalf and on the behalf of others; and the lookupservicereflects the
`current members ofthe federation andacts as the central marketplace for offering
`and finding services by membersofthe federati on.
`
`AR.2.2.2 Programming Model
`
`The infrastructure both enables the programming model and makes use ofit.
`Entries in the lookup service are leased, allowing the lookup service to reflect
`accurately the set of currently available services, Whenservices join or leave a
`lookup service, events are signaled, and objects that have registered interest in
`such events get notifications when new services becomeavailable or old services
`cease to be active. The programming model rests on the ability to move code,
`whichis supported by the base infrastructure,
`Both the infrastructure andthe services that use that infrastructure are compu-
`tational entities that exist in the physical environmentofthe Jini system. However,
`services also constitute a set of interfaces which define communication protocols
`that can be used bythe services and the infrastructure to communicate between
`themselves.
`These interfaces, taken together, make upthe distributed extension of the stan-
`dard Java programming language model that constitutes the Jini programming
`
`83
`
`83
`
`

`

`
`
`a
`
`70
`
`COMPONENT OVERVIEW
`
`model. Among the interfaces that make up the Jini programming model are the
`following:
`
`The leasing interface, which defines a way of allocating and freeing
`resources using a renewable, duration-based model
`@ The event and notification interfaces, which are an extension of the event
`model used by JavaBeans components to the distributed environment,
`enable event-based communication between Jini services
`
`@ The transaction interfaces, which enable entities to cooperate in such a way
`that either all of the changes made to the group occur atomically or none of
`them occur
`
`Thelease interface extends the Java programming language model by adding
`time to the notion of holding a reference to a resource, enabling references to be
`reclaimed safely in the face of network failures.
`The event and notification interfaces extend the standard event models used
`by JavaBeans components and the Java application environmentto thedistributed
`case, enabling events to be handled by third-party objects while making various
`delivery and timeliness guarantees. The model also recognizes that the delivery of
`a distributed notification may be delayed.
`The transaction interfaces introduce a lightweight, object-oriented protocol
`enabling Jini applications to coordinate state changes. The transaction protocol
`provides two steps to coordinate the actions of a group of distributed objects. The
`first step is called the voting phase, in which each object “votes” whetherit has
`completed its portion of the task and is ready to commit any changes it made. In
`the secondstep, a coordinator issues a “commit” request to each object.
`TheJini Transaction protocol differs from mosttransaction interfaces in thatit
`does not assume that the transactions occur in a transaction processing system.
`Such systems define mechanisms and programming requirements that guarantee
`the correct implementation of a particular transaction semantics. The Jini Transac-
`tion protocol takes a more traditional object-oriented view, leaving the correct
`implementation of the desired transaction semantics up to the implementorof the
`particular objects that are involved in the transaction. The goal of the transaction
`protocol is to define the interactions that such objects must have to coordinate
`such groups of operations.
`The interfaces that define the Jini programming modelare used bythe infra-
`structure components where appropriate and bytheinitial Jini services. For exam-
`ple, the lookup service makes use of the leasing and event interfaces. Leasing
`ensures that services registered continue to be available, and events help adminis-
`trators discover problems and devices that need configuration. The JavaSpaces
`
`
`
`84
`
`84
`
`

`

`
`
`THE JINI ARCHITECTURESPECIFICATION
`
`71
`
`service, one example ofa Jini service, utilizes leasing and events, and also sup-
`ports the Jini Transaction protocol. The transaction managercan be used to coor-
`dinate the voting phase of a transaction for those objects that support transaction
`protocol.
`; a
`7
`.
`The implementation of a service is not required to use the Jini programming
`model, but such services need to use that modelfor their interaction with the Jini
`technology infrastructure. For example, every service interacts with the Jini
`Lookup service by using the programming model; and whethera service offers
`resources on a leased basis or not, the service’s registration with the lookup ser-
`yice will be leased and will need to be periodically renewed.
`The binding of the programming modelto the services and the infrastructure
`is what makes such a federation a Jini system notjusta collection of services and
`protocols. The combination of infrastructure, service, and programming model,
`all designed to work together and constructed by using eachother, simplifies the
`overall system and unifies it in a way that makesit easier to understand.
`
`AR.2.2.3 Services
`
`The Jini technology infrastructure and programming modelare built to enable ser-
`vices to be offered and found in the network federation. These services make use
`of the infrastructure to make calls to each other, to discover each other, and to
`announcetheir presence to other services and users.
`Services appear programmatically as objects written in the Java programming
`language, perhaps made up ofother objects. A service has an interfacethat defines
`the operations that can be requested of that service. Someofthese interfaces are
`intended to be used by programs, while others are intended to be run by the
`receiver so that the service can interact with a user. The type ofthe service deter-
`mines the interfaces that make upthatservice and also define the set of methods
`that can be used to access the service. A single service may be implemented by
`using other services.
`Example Jini services include the following:
`
`¢ A printing service, which can print from Java applications and legacy appli-
`cations
`
`@ A JavaSpaces service, which can be used for simple communication and for
`storage of related groups of objects written in the Java programming lan-
`guage
`A transaction manager, which enables groups ofobjects to participate in the
`Jini Transaction protocol defined by the programming model
`
`erA)ERTRESLRRATZ
`
`
`
`
`
`85
`
`85
`
`

`

`y
`
`
`
`THE JINIARCHITECTURE SPECIFICATION
`
`71
`
`service, one example ofa Jini service, utilizes leasing and events, and also sup-
`ports the Jini Transaction protocol. The transaction manager can be used to coor-
`dinate the voting phase ofa transaction for those objects that support transaction
`protocol.
`The implementation of a service is not required to use the Jini programming
`model, but such services needto use that model fortheir interaction with the Jini
`technology infrastructure. For example, every service interacts with the Jini
`Lookup service by using the programming model; and whether a service offers
`resources on a leased basis or not, the service’s registration with the lookup ser-
`vice will be leased and will need to be periodically renewed.
`The binding of the programming modelto the services and the infrasiructure
`is what makes such a federation a Jini system not just a collection of services and
`protocols. The combination of infrastructure, service, and programming model,
`all designed to work together and constructed by using eachother, simplifies the
`overall system andunifies it in a way that makesit easier to understand.
`
`AR.2.2.3 Services
`
`TheJini technology infrastructure and programming modelare built to enable ser-
`vices to be offered and found in the network federation. These services make use
`of the infrastructure to make calls to each other, to discover each other, and to
`announce their presence to other services and users.
`Services appear programmatically as objects written in the Java programming
`language, perhaps madeupofother objects. A service hasan interface that defines
`the operations that can be requested of that service. Some of these interfaces are
`intended to be used by programs, while others are intended to be run by the
`receiver so that the service can interact with a user. The type of the service deter-
`mines the interfaces that make up that service and also define the set of methods
`that can be used to access the service. A single service may be implemented by
`using other services.
`Example Jini services include the following:
`
`¢ A printing service, which can print from Java applications and legacy appli-
`cations
`
`¢ A JavaSpaces service, which can be used for simple communication and for
`storage of related groups of objects written in the Java programming lan-
`guage
`
`¢ A transaction manager, which enables groups ofobjects to participate in the
`Jini Transaction protocoldefined by the programming model
`
`
`
`
`
`86
`
`oO
`
`>is
`fe
`
`e2
`giz
`==|
`
`==
`=i
`
`86
`
`

`

`
`
`_
`
`72
`
`SERVICE ARCHITECTURE
`
`Tl
`
`AR.2.3 Service Architecture
`
`Services form the interactive basis for a Jini system, both at the programming and
`user interface levels. The details of the service architecture are best understood
`oncethe Jini Discovery and Jini Lookupprotocols are presented.
`
`AR.2.3.1 Discovery and Lookup Protocols
`
`The heart of the Jini system is a trio of protocols called discovery, join, and
`lookup. A pair of these protocols—discovery and join—occur when a device is
`plugged in. Discovery occurs whena service is looking for a lookup service with
`which to register. Join occurs when a service has located a lookup service and
`wishesto join it. Lookup occurs whena client or user needs to locate and invoke a
`service describedbyits interface type (written in the Java programming language)
`and possibly other attributes. Figure AR.2.2 outlines the discovery process.
`
`A service provider seeks
`a lookup service |
`
`
`
`Lookup
`Service
`
`[
`|
`
`.
`Client
`
`|
`
`
`[ Service
`|
`Provider
`
`:
`
`|
`|
`
` |
`
`FIGURE AR.2.2: Discovery
`
`Jini Discovery/Join is the process of adding a service to a Jini system. A ser-
`vice provideris the originator of the service—a device or software, for example.
`First, the service provider locates a lookup service by multicasting a request on the
`local network for any lookup services to identify themselves (discovery, see Fig-
`ure AR.2.2). Then, a service object for the service is loaded into the lookup ser-
`vice (join, see Figure AR.2.3), This service object contains the Java programming
`language interface for the service, including the methods that users and applica-
`tions will invoke to execute the service along with any otherdescriptive attributes.
`
`
`
`87
`
`87
`
`

`

`
`
`THE JINI ARCHITECTURE SPECIFICATION
`
`
`
`A service provider registers a [7
`service object (proxy) andits
`|
`service attributes with
`
`Service
`
`the lookup service
`
`|
`
`|
`
`Client
`
`Service
`Provider
`
`|
`
`te
`
`FIGURE AR.2.3: Join
`
`otato
`
`
`ae=
`ie
`-_-
`
`O=—
`
`oOat
`
`Services must be able to find a lookup service; however, a service may dele-
`gate the task of finding a lookup service to a third party. The service is now ready
`to be looked up and used, as shownin the following diagram (Figure AR.2.4).
`
`7
`
`A client requests a service by
`Java language type and,
`perhaps,other service attributes.
`A copyof the service object is
`moved to the client and used by
`the client to talk to the service
`
`|
`Lookup
`Service
`
`
`
`
`Client
`
`Service
`Provider
`
`
`Service Object
`| |
`FIGURE AR.2.4: Lookup
`
`
`
`A client locates an appropriate service by its type—that is, by its interface
`written in the Java programming language—along with descriptive attributes that
`
`j
`
`if
`
`|
`
`
`
`88
`
`88
`
`

`

`74
`
`SERVICE ARCHITECTURE
`
`are used in a user interface for the lookup service. The service object is loaded
`into the client.
`The final stage is to invoke the service, as shown in the following diagram
`(Figure AR.2.5).
`
`Theclient interacts directly with
`the service provider viathe
`service object (proxy)
`
`|
`
`Lookup
`Service
`
`|
`|
`
`|
`|
`
`Service
`Provider
`
`FIGURE AR.2.5: Client Uses Service
`
`Theservice object’s methods may implement a private protocol betweenitself
`and the original service provider. Different implementations of the same service
`interface can use completely different interaction protocols.
`The ability to move objects and code from the service provider to the lookup
`service and from there to the client ofthe service gives the service provider great
`freedom in the communication patterns between the service andits clients. This
`code movementalso ensures that the service object held by the client and the ser-
`vice for which it is a proxy are always synchronized because the service objectis
`supplied by the service itself. The client knows only that it is dealing with an
`implementation of an interface written in the Java programming language, so the
`code that implements the interface can do whatever is needed to provide the ser-
`vice. Because this code cameoriginally from the service itself, the code can take
`advantage of implementation details of the service that are known only to the
`code.
`The client interacts with a service via a set of interfaces written in the Java
`programming language. These interfaces define the set of methods that can be
`used to interact with the service. Programmatic interfaces are identified by the
`type system of the Java programming language, and services can be found in a
`lookup service by asking for those that support a particular interface. Finding a
`service this wayensures that the program lookingfor the service will know how to
`
`
`
`89
`
`89
`
`

`

`
`
`THE JIN] ARCHITECTURE SPECIFICATION
`
`use that service, becausethat use is defined by the set of methodsthat are defined
`by the type.
`Programmatic interfaces may be implemented either as RMIreferencesto the
`remote object that implementsthe service, as a local computation that providesall
`of the service locally, or as some combination. Such combinations, called smart
`proxies, implement someof the functions of a service locally and the remainder
`through remote calls to a centralized implementation ofthe service.
`A user interface can also be stored in the lookup service as an attribute of a
`registered service. A user interface stored in the lookupservice by a Jini service is
`an implementation that allows the service to be directly manipulated by a userof
`the system.
`In effect, a user interface for a service is a specialized form of the service
`interface that enables a program, such as a browser, to step out of the way andlet
`the humanuserinteractdirectly with a service.
`In situations in which no lookup service can be found, a client could use a
`technique called peer lookup instead. In such situations,the client can send outthe
`sameidentification packetthat is used by a lookup service to request service pro-
`viders to register. Service providers will then attempt to register with the client as
`though it were a lookup service. The client can select the services it needs from
`the registration requests it receives in response anddroporrefusetherest.
`
`AR.2.3.2 Service Implementation
`
`Objects that implement a service may be designed to run in a single address space
`with other, helper, objects especially when there are certain location or security-
`based requirements. Such objects make up an object group. An object group is
`guaranteed to always reside in a single address space or virtual machine when
`those objects are running. Objects that are not in the same object group are iso-
`lated from eachother, typically by running them in a different virtual machineor
`address space.
`A service may be implementeddirectly or indirectly by specialized hardware.
`Such devices can be contacted by the code associated with the interface for the
`service.
`From the service client’s point of view, there is no distinction between ser-
`vices that are implemented by objects on a different machine, services that are
`downloaded into the local address space, and services that are implemented in
`hardware. All of these services will appear to be available on the network, will
`appearto be objects written in the Java programming language,and, only as far as
`correct functioning is concerned, one kind of implementation could be replaced
`
`Ra=
`Ao
`aH
`kodG
`=|
`
`=La}
`
`
`
`
`90
`
`90
`
`

`

`
`
`
`76
`
`SERVICE ARCHITECTURE
`
`by another kind of implementation without change or knowledge by theclient.
`(Note that security permissions must be properly granted.)
`
`
`
`91
`
`91
`
`

`

`=oO
`
`ai
`a —
`
`Vd=
`rtala
`e](aa
`
`]=|o
`
`
`
`THE JIN] ARCHITECTURESPECIFICATION
`
`
`
`AR.3 An Example
`
`Ts example showshowa Jini printing service might be used by a digital cam-
`era to print a high-resolution color image. It will start with the printer joining an
`existing Jini system, continue with its being configured, and end with printing the
`image.
`
`AR.3.1 Registering the Printer Service
`
`A printer that is either freshly connected to a Jini system or is poweredup onceit
`has been connected to a Jini system grouping needs to discover the appropriate
`lookupservice and register with it. This is the discovery andjoin phase.
`
`AR.3.1.1 Discovering the Lookup Service
`
`The basic operations of discovering the lookup service are implemented bya Jini
`software class. An instance of this class acts as a mediator between devices and
`services on one hand and the lookup service on the other. In this example the
`printer first registers itself with a local instance of this class. This instance then
`multicasts a request on the local network for any lookup services to identify them-
`selves. The instancelistens for replies and, if there are any, passes to the printer an
`array of objects that are proxies for the discovered lookupservices.
`
`AR.3.1.2 Joining the Lookup Service
`
`To register itself with the lookup service, the printer needsfirst to create a service
`object of the correct type for printing services. This object provides the methods
`that users and applications will invoke to print documents. Also neededis an array
`of LookupEntryinstances to specify the attributes that describe the printer, such
`as that it can print in color or black and white, what document formats it can print,
`possible papersizes, and printing resolution.
`
`
`
`92
`
`92
`
`

`

`
`
`78
`
`PRINTING
`
`Theprinter then calls the register method ofthe lookup service objectthatit
`received during the discovery phase, passing it the printer service object and the
`array of attributes. The printing service is now registered with the lookup service.
`
`AR.3.1.3 Optional Configuration
`
`At this point the printing service can be used, but the local system administrator
`might want to add additional information about the printer in the form of addi-
`tional attributes, such as a local nameforthe service, information aboutits physi-
`cal location, and a list of who may access the service. The system administrator
`might also want to register with the device to receive notifications for any errors
`that arise, such as whenthe printer is out of paper.
`One way the system administrator could do this would beto use a specialutil-
`ity program to pass this additional information to the service. In fact this program
`might have received notification from the lookup service that a new service was
`being added and then alerted the system administrator.
`
`AR.3.1.4 Staying Alive
`
`Whenthe printer registers with the Jini Lookup service it receives a lease. Period-
`ically, the printer will need to renew this lease with the lookup service. If the
`printer fails to renew the lease, then when the lease expires, the lookup service
`will removethe entry for it, and the printer service will no longer be available.
`
`AR.3.2 Printing
`
`Someservices provide a user interface for interaction with them; others rely on an
`application to mediate such interaction. This example assumesthat a person has a
`digital camera that has taken a picture they want to print on a high-resolution
`printer. The first thing that the camera needsto do after it is connectedto the net-
`workis locate a Jini printing service. Once a printing service has been located and
`selected, the camera can invoke methodsto print the image.
`
`AR.3.2.1 Locate the Lookup Service
`
`Before the camera can use a Jini service, it mustfirst locate the Jini Lookupser-
`vice, just as the print service neededto do to register itself. The camera registers
`
`THE JINI
`
`itself
`notify
`
`AR.3.;
`
`Findin
`and fil
`require
`which
`right t
`type ¢
`attribu
`that st
`are let
`ofall
`the ca
`Jution
`result
`A
`printe
`longe:
`
`AR.3
`
`Befor
`be do
`this n
`
`may |
`the cc
`
`AR.
`
`To pr
`it the
`
`cessi
`
`
`
`93
`
`93
`
`

`

`
`
`
`
`fo
`
`>=fe
`7—eLona
`Oa
`==
`
`io
`
`—he
`nailer
`
`THE JINI ARCHITECTURE SPECIFICATION
`
`79
`
`itself with a local instance of the Jini software class LookupDiscovery, which will
`notify the cameraofall discovered lookupservices.
`
`AR.3.2.2 Search for Printing Services
`
`Finding an appropriate service requires passing a template that is used to match
`and filter the set of existing services. The template specifies both the type of the
`required service, whichisthefirst filter on possible services, anda set ofattributes
`whichis used to reduce the numberof matchingservices if there are several of the
`right type. In this example, the camera supplies a template specifying the printer
`type and an array of attribute objects. The type of each object specifies the
`attribute type, andits fields specify values to be matched. Foreachattribute,fields
`that should be matched,such ascolorprinting,are filled in; ones that don’t matter
`are left null. The Jini Lookup service is passed this template and returns an array
`of all of the printing services that matchit. If there are several matching services,
`the camera may further filter them—in this case perhaps to ensure high print reso-
`jution—andpresentthe user with the list of possible printers for choice. The final
`result is a single service object for the printing service.
`Atthis point the printing service has been selected, and the camera and the
`printer service communicate directly with each other; the lookup service is no
`longer involved.
`
`AR.3.2.3 Configuring the Printer
`
`Before printing the image, the user might wish to configure the printer. This might
`be done directly by the camera invoking the service object’s configure method;
`this method may display a dialog box on the camera’s display with which the user
`may specify printer settings. When the imageis printed, the service object sends
`the configuration information to the printer service.
`
`AR.3.2.4 Requesting That the Image Be Printed
`
`To print the image, the cameracalls the print methodof the service object, passing
`it the image as an argument. The service object performs any necessary prepro-
`cessing and sendsthe imageto the printer service to be printed.
`
`94
`
`94
`
`

`

`
`
`80
`
`PRINTING
`
`AR.3.2.5 Registering for Notification
`
`If the user wishes to be notified when the image has been printed, the camera
`needsto register itself with the printer service using the service object. The cam-
`era might also wishtoregister to be notified if the printer encountersany errors.
`
`AR.3.2.6 Receiving Notification
`
`Whentheprinter has finished printing the image or encountersan error, it signals
`an event to the camera. When the camerareceives the event, it may notify the user
`that the image has been printed or that an error has occurred.
`
`
`
`95
`
`95
`
`

`

`
`
`Ae)ERRESTLASAvl
`
`
`
`THEJINIARCHITECTURE SPECIFICATION
`
`81
`
`
`
`AR.4 For More Information
`
`Tus documentdoes not provide a full specification of Jini technology. Each of
`the Jini technology componentsis specified in a companion document. In particu-
`lar, the readeris directed to the following documents:
`
`@ The Java Remote Method Invocation Specification
`@ The Java Object Serialization Specification
`@ The Jini Discovery and Join Specification
`@ The Jini Device Architecture Specification
`
`@ The Jini Distributed Events Specification
`@ The Jini Distributed Leasing Specification
`
`@ The Jini Lookup Service Specification
`@ The Jini Lookup Attribute Schema Specification
`@ The Jini Entry Specification
`@ The Jini Transaction Specification
`
`
`
`96
`
`96
`
`

`

`
`
`THE JIN! DISCOVERY AND JOIN SPECIFICATION defines how a service should
`behave whenit first starts up to find the local lookup services with which
`it should register, and how lookups should advertise their
`availability. The discovery protocollets a service find
`aN “discoverable” lookup services. A service may also be
`configured to register with specific lookup services or to
`register only with particular lookup services. Most
`services will use discovery, since most will wantto be
`available to local clients. Clients will use discovery to find
`local services, but use explicit denotation to contact specific
`lookups that are useful even if they are far away.
`
`I N I This discoveryprotocolis designedfordiscovery on IP
`
`Sed
`
`networks. IP networks are widespread and so wasthefirst
`discovery protocol designed. Other networkswill require
`different discovery protocols that will