`
`66
`
`KEY CONCEPTS
`
`as printers, diSplays, or disks; software such as applications or utilities; informa—
`tion such as databases and files; and users of the system.
`Services in a Jini system communicate with each other by using a service pro-
`tocol, which is 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 define critical service interactions.
`
`AR.2.I.2 Lookup Service
`
`Services are found and resolved by a lockup service. The lockup 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 lockup service may include other lockup services; this provides
`hierarchical lockup. 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 Lookup service and other forms of lockup service. Of course, ref-
`erences to a Jini Lookup service may be placed in these other naming and direc—
`tory services, providing a means for clients of those services to gain access to a
`Jini system.
`A service is added to a lockup service by a pair of protocols called discovery
`and join~—first the service locates an appropriate lockup service (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 (RM). The infrastructure to support communication between
`services is not itself a service that is discovered and used but is, rather, a part of
`the Jini technology infrastructure. RMI provides mechanisms to find, activate, and
`garbage collect object groups.
`Fundamentally, RMI is a Java programming language-enabled extension to
`traditional remote procedure call mechanisms. RM] allows not only data to be
`passed from object to object around the network but full objects, including code.
`Much of the 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 JLWARCHH'ECTURE SPECIFICATION
`
`AR.2-1-4 Security
`
`67
`
`EO
`E".H
`(D
`f‘.H
`
`S"1ED
`
`E
`
`The design of the security model for Jini technology is built on the twin notions of
`a principal and an access control list. Jini services are accessed on behalf of some
`entityjthe principalm— which generally traces back to a particular user of 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 of the services in the Jini system environment is lease based. A
`lease is a grant of guaranteed access over a time period. Each lease 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 network fails, or the lease is not permitted to be renewed—then both the
`user and the provider of the resource may conclude that 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 wrapped in 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—is left up
`to the service using these 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 programs to be
`written with a variety of reliability and scalability guarantees.
`
`
`
`
`81
`
`81
`
`
`
`w?—
`
`____:
`
`68
`
`AR.2.2 Component Overview
`
`COMPONENT OVERVIEW
`
`The components of the Jini system can be segmented into three categories: infra-
`structure, programming model, and services. The infrastructure 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 of reliable services, including those that are part of the
`infrastructure and those that 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 systems that have some of the functionality of the Jini system with vari-
`ants on the categories or without all three of them. But a Jini system gains its full
`power because 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 power of a Jini system will be available
`only to new services that 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 components in the
`familiar Java application environment are shown in Figure AR.2. 1:
`
`
`Infrastructure
`I Programming Model
`1—Services
`Java APIS
`JNDI
`
`Base
`Java
`
`RMI
`Java Security
`
`JavaBeans
`.
`.
`.
`
`Enterprise Beans
`JTS
`I
`
`
` Java VM
`
`
`Java
`+
`Jini
`
`Discoverylloin
`Distributed Security
`Lookup
`
`Leasing
`Transactions
`Events
`
`Printing
`Transaction Manager
`JavaSpaces Service
`
`_—I
`
`
`FIGURE AR.2.'t: Jini Architecture Segmentation
`
`
`
`
`82
`
`82
`
`
`
`E?
`fig.
`Pa.-
`.732H
`t
`
`('D
`
`C"
`
`
`
`THE JIM ARCHITECTURE SPECIFICAnorv
`
`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 extends the Java plat—
`form’s security model to the world of distributed systems.
`0 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 of the federation.
`o 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
`proxies to the service that placed the code into the lookup service.
`
`The discovery and join protocols define the way a service of any kind
`becomes part of a Jini system; RMI defines the base language within which the
`Jini services communicate; the distributed security model and its implementation
`define how entities are identified and how they get the rights to perform actions on
`their own behalf and on the behalf of others; and the lookup service reflects the
`current members of the federation and acts as the central marketplace for offering
`and finding services by members of the federation.
`
`AR.2.2.2 Programming Model
`
`The infrastructure both enables the programming model and makes use of it.
`Entries in the lookup service are leased, allowing the lookup service to reflect
`accurately the set of currently available services. When services join or leave a
`lookup service, events are signaled, and objects that have registered interest in
`such events get notifications when new services become available or old services
`cease to be active. The programming model rests on the ability to move code,
`which is supported by the base infrastructure.
`Both the infrastructure and the services that use that infrastructure are compu-
`tational entities that exist in the physical environment of the Jini system. However,
`services also constitute a set of interfaces which define communication protocols
`that can be used by the services and the infrastructure to communicate between
`themselves.
`These interfaces, taken together, make up the distributed extension of the stan-
`dard Java programming language model that constitutes the Jini programming
`
`83
`
`83
`
`
`
`
`
`a?
`
`70
`
`COMPONENI OVERVIEW
`
`model. Among the interfaces that make up the Jini programming model are the
`following:
`
`9 The leasing interface, which defines a way of allocating and freeing
`resources using a renewable, duration-based model
`
`0 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
`
`c 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
`
`The lease 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 lavaBeans components and the Java application environment to the distributed
`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” whether it has
`completed its portion of the task and is ready to commit any changes it made. In
`the second step, a coordinator issues a “commit" request to each object.
`The Jini Transaction protocol differs from most transaction interfaces in that it
`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 implementor of 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 J ini programming model are used by the infra—
`structure components where appropriate and by the initial 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 new A RCHITECTURE spectrumrioiv
`
`71
`
`service. one example of a Jini service, utilizes leasing and events, and also sup
`ports the Jini Transaction protocol. The transaction manager can be used to coor~
`climate the voting phase of a transaction for those objects that support transaction
`protocol.
`.
`‘
`‘
`.
`_
`'
`‘
`.
`The implementation of a service is not required to use the .l 1m programming
`model, but such services need to use that model for their interaction with the lini
`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 model to the services and the infrastructure
`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 each other, simplifies the
`overall system and unifies it in a way that makes it easier to understand.
`
`AR.2.2.3 Services
`
`The Jini technology infrastructure and programming model are 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 made up of other objects. A service has an 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:
`
`o A printing service, which can print from Java applications and legacy appli-
`cations
`
`6 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
`
`o A transaction manager, which enables groups of objects to participate in the
`Jini Transaction protocol defined by the programming model
`
`
`amnairqeuv
`
`(HV)
`
`
`
`
`
`85
`
`85
`
`
`
`PI1
`('3
`=1"
`3'(D
`nF.
`s-i
`
`m
`
`'3
`E.
`
`
`
`
`
`THE JINIARCHITECTURE SPECIFICATION
`
`71
`
`service, one example of a Jini service, utilizes leasing and events, and also sup-
`ports the Jini Transaction protocol. The transaction manager can be used to coorr
`dinate the voting phase of a 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 need to use that model for their 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 lockup ser—
`vice will be leased and will need to be periodically renewed.
`The binding of the programming model to the services and the infraSLructurc
`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 each other. simplifies the
`overall system and unifies it in a way that makes it easier to understand.
`
`AR.2.2.3 Services
`
`The Jini technology infrastructure and programming model are 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 programmatic ally as objects written in the Java programming
`language, perhaps made up of other objects. A service has an 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:
`
`0 A printing service, which can print from Java applications and legacy appli—
`cations
`
`c A J avaSpaces service, which can be used for simple communication and for
`storage of related groups of objects written in the Java programming lan-
`guage
`
`c A transaction manager, which enables groups of objects to participate in the
`Jini Transaction protocol defined by the programming model
`
`
`
`86
`
`86
`
`
`
`
`
`F'.
`
`72
`
`SERVICEARCHITECTURE
`
`Tl
`
`AR.2.3 Service Architecture
`
`Services form the interactive basis for a J ini system, both at the programming and
`user interface levels. The details of the service architecture are best understood
`once the Jini Discovery and Jini Lookup protocols 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
`lockup. A pair of these protocols—~discovery and join—occur when a device is
`plugged in. Discovery occurs when a service is looking for a lookup service with
`which to register. Join occurs when a service has located a lookup service and
`wishes to join it. Lookup occurs when a client or user needs to locate and invoke a
`service described by its interface type (written in the Java programming language)
`and possibly other attributes. Figure AR.2.2 outlines the discovery process.
`
`A serwce prowder seeks ‘
`a Iookup serwce
`
`Lookup
`Service
`
`
`
`FIGURE AR.2.2: Discovery
`
`Jini Discovery/'Join is the process of adding a service to a Jini system. A ser-
`vice provider is 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 lockup services to identify themselves (discovery, see Fig-
`ure A1122). 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 other descriptive attributes.
`
`
`
`87
`
`87
`
`
`
`a‘1CD
`
`LP:1
`"I—I-
`{up
`I'D
`OH
`
`D5
`
`5
`
`
`
`THE JEN! ARCHH’ECT'URE SPECIFICATION
`
`A service provider registers a
`service object (proxy) and its
`service attributes with
`
`l—“'
`-
`
`
`
`Loom)
`Service
`
`the lookup service
`
`‘
`
`Client
`
`‘
`
`
`Service
`Provider
`
`l
`
`FIGURE AR.2.3: Join
`
`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 shown in the following diagram (Figure AR.2.4).
`
`A client requests a service by
`Java language type and,
`perhaps, other service attributes.
`A copy of the service object is
`moved to the client and used by
`
`
`
`Service
`Provider
`
`the client to talk to the service
`
`
`Client
`
`'
`
`
`
`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 languageialong with descriptive attributes that
`
`
`
`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).
`
`The client interacts directly with
`the service provider via the
`
`service object (proxy)
`
`
`
`.
`
`Service
`
`i
`
`
`
` L Service Object I
`
`
`
`Service
`Provider
`
`_
`|
`
`FIGURE AR.2.5: Client Uses Service
`
`The service object‘s methods may implement a private protocol between itself
`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 of the service gives the service provider great
`freedom in the communication patterns between the service and its clients. This
`code movement also 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 object is
`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 came originally 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
`
`prograrrnning 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 way ensures that the program looking for the service will know how to
`
`
`
`89
`
`89
`
`
`
`
`
`THE JrNr ARCtm across SPECIFICA rtorv
`
`use that service, because that use is defined by the set of methods that are defined
`by the type.
`Programmatic interfaces may be implemented either as RMI references to the
`remote object that implements the service, as a local computation that provides all
`of the service locally, or as some combination. Such combinations, called smart
`proxies, implement some of the functions of a service locally and the remainder
`through remote calls to a centralized implementation of the service.
`A user interface can also be stored in the [ookup service as an attribute of a
`registered service. A user interface stored in the lockup service by a J ini service is
`an implementation that allows the service to be directly manipulated by a user of
`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 and let
`the human user interact directly with a service.
`In situations in which no lockup service can be found, a client could use a
`technique called peer lockup instead. In such situations, the client can send out the
`same identification packet that 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 and drop or refuse the rest.
`
`AR.2.3.2 Service Implementation
`
`Object-s 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 each other, typically by running them in a different virtual machine or
`address space.
`A service may be implemented directly 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
`appear to be objects written in the Java programming language, and, only as far as
`correct functioning is concerned, one kind of implementation could be replaced
`
`a-I-:
`
`As
`it:
`Es_.
`t:
`
`HFD
`
`
`
`
`90
`
`
`
`90
`
`
`
`
`
`
`
`76
`
`SERVICE ARCHITECTURE
`
`by another kind of implementation without change or knowledge by the client.
`(Note that security pennissions must be properly granted.)
`
`
`
`91
`
`91
`
`
`
`
`
`THE JINI ARCHITECTURE SPECIFICATION
`
`
`
`AR.3 An Example
`
`THIS example shows how a 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 powered up once it
`has been connected to a Jini system grouping needs to discover the appropriate
`lockup service and register with it. This is the discovery and join phase.
`
`AR.3.1.1 Discovering the Lockup Service
`
`The basic operations of discovering the lockup service are implemented by a J ini
`software class. An instance of this class acts as a mediator between devices and
`
`services on one hand and the lockup 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 lockup services to identify them-
`selves. The instance listens for replies and, if there are any, passes to the printer an
`array of objects that are proxies for the discovered lockup services.
`
`AR.3.1.2 Joining the Lookup Service
`
`To register itself with the lockup service, the printer needs first 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 needed is an array
`of LookupEntr‘y instances 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 paper sizes, and printing resolution.
`
`
`
`
`92
`
`
`
`>i.
`I2-!
`(D
`OF!-
`
`O3_
`
`E('D
`
`L ‘
`
`H
`
`92
`
`
`
`
`
`78
`
`PRINTING
`
`The printer then calls the register method of the lookup service object that it
`received during the discovery phase, passing it the printer service object and the
`array of attributes. The printing service is new 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 name for the service, information about its 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 when the printer is out of paper.
`One way the system administrator could do this would be to use a special util-
`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
`
`When the printer registers with the Jini Lookup service it receives a lease. Period—
`ically, the printer will need to renew this lease with the lockup service. If the
`printer fails to renew the lease, then when the lease expires, the iookup service
`will remove the entry for it, and the printer service will no longer be available.
`
`AR.3.2 Printing
`
`Some services provide a user interface for interaction with them; others rely on an
`application to mediate such interaction. This example assumes that 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 needs to do after it is connected to the net—
`work is locate a Jini printing service. Once a printing service has been located and
`selected, the camera can invoke methods to print the image.
`
`AR.3.2.1 Locate the Lookup Service
`
`Before the camera can use a Jini service, it must first locate the Jini Lookup ser-
`vice, just as the print service needed to do to register itself. The camera registers
`
`THE JIM
`
`itself Vi
`
`notify
`
`AR.3.2
`
`Findin
`and iii
`
`requin
`which
`
`right I
`type 3
`attribu
`that st
`are lei
`of all
`the ca
`lution-
`result
`A
`
`prime
`longe:
`
`AR.3
`
`Befor
`be do
`this u
`
`may :
`the Ct
`
`
`
`93
`
`93
`
`
`
`
`
`
`
`THE JEN} ARCHITECTURE SPECIFICATION
`
`itself with a local instance of the Iini software class LookupDi scove ry, which will
`notify the camera of all discovered lookup services.
`
`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, which is the first filter on possible services, and a set of attributes
`which is used to reduce the number of matching services 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, and its fields specify values to be matched. For each attribute, fields
`that should be matched, such as color printing, 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 match it. If there are several matching services,
`the camera may further filter them—in this case perhaps to ensure high print reso~
`lution—and present the user with the list of possible printers for choice. The final
`result is a single service object for the printing service.
`At this 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 image is 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 camera calls the print method of the service object, passing
`it the image as an argument. The service object performs any necessary prepro-
`cessing and sends the image to the printer service to be printed.
`
`94
`
`79
`
`_.-._r .
`.
`.
`
`p-:n
`:1"~-H-
`re
`(1H-
`1:.,
`
`m
`
`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
`needs to register itself with the printer service using the service object. The cam-
`era might also wish to register to be notified if the printer encounters any errors.
`
`AR.3.2.6 Receiving Notification
`
`When the printer has finished printing the image or encounters an error, it signals
`an event to the camera. When the camera receives the event, it may notify the user
`that the image has been printed or that an error has occurred.
`
`
`
`95
`
`95
`
`
`
`THEJINIARCHITECTURE SPECIFICATION
`
`81
`
`
`
`ARA For More Information
`
`THIS document does not provide a full specification of Jini technology. Each of
`[he Jini technology components is specified in a companion document. In particu-
`lar, the reader is directed to the following documents:
`
`9 The Java Remote Method Invocation Specification
`
`0 The Java Object Serialization Specification
`
`9 The Jini Discovery and Join Specification
`o The Jini Device Architecture Specification
`
`O The Jini Distributed Events Specification
`
`0 The Jini Distributed Leasing Specification
`
`0 The Jini Looknp Service Specification
`
`0 The Jini Looiaip Attrihnte Schema Specification
`
`0 The Jini Entry Specification
`
`0 The Jini Transaction Specification
`
`
`
`(EV)9.1moanqotv
`
`
`
`!
`I!
`
`
`
`96
`
`96
`
`
`
`
`
`THE JINI DISCOVERY AND .lOlN SPECIFICATION defines how a service should
`behave when it first starts up to find the local lockup services with which
`it Slit? uld register, and how lookups should advertise their
`availability. The discovery protocol lets a service find
`A "discoverable " lockup services. A service may also be
`configured to register with specific lockup services or to
`register only with particular lookup services. Most
`services will use discove ry, since most will want to be
`available to local clients. Clients will use discovery to find
`local services, but use explicit denotation to contact spec‘ific
`