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.l.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 lookup services; 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 Loolrup service and other fonns 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 means for 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 lookup 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 (RMI). 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. R.MI 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. RMI 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
`
`

`
`1
`
`JINIARCHITECTURE SPECIFICATION
`
`I" AR.2.1.4 Security
`
`I The design of the security model for Jini technology is built on the twin notions of
`___aprincipal and an access control list. Jini services are accessed on behalf of some
`entity-the prlncipal— 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.
`
`_
`
`IfHV’[Ia.ll1'1.‘)J.|ll['._‘J.l
`
`_ 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.
`
`I
`
`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 transactionmis left 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 programs to be
`written with a variety of reliability and scalability guarantees.
`
`81
`
`

`
`COMPONENT OVERVIEW
`
`AR.2.2 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 infrastructur , 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
`
`Programming Model
`
`Java VM
`
`RMI
`Java Security
`
`Java APIs
`
`JavaBeans
`.
`.
`.
`
`INDI
`
`Enterprise Beans
`ITS
`I
`
`Discoveryfloin
`
`Leasing
`
`Printing
`
`Distributed Security
`
`Transactions
`
`Loolcup
`
`Events
`
`Transaction Manager
`
`Iavaspaces Service
`
`FIGURE AR.2.1: Jini Architecture Segmentation
`
`82
`
`

`
`'
`
`‘HIE JHW ARCHITECTURE SPECIFICATION
`
`AR.2.2.1 Infrastructure
`
`file Jini technology infrastructure defines the minimal Jini technology core. The
`infrastructure includes the following:
`
`'
`
`I
`
`o A distributed security system, integrated into RMI, that extends the Java plat-
`forrn’s security model to the world of distributed systems.
`-
`4 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 lockup service, which serves as a repository of services. Entries in the
`lockup 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
`Jim 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.
`
`_.
`.
`
`__
`.
`
`l
`
`ased, allowing
`services join or leave a
`accurately the set of currently available services.
`lockup 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 Jim 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 Jim programming
`
`.;
`
`83
`
`

`
`COMPONENT O VERVTEW
`
`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
`
`0 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 JavaBeans 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 “connnit" 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 Jim‘ 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 Jim programming model are used by the infra-
`structure components where appropriate and by the initial Iini services. For exam-
`ple, the loolcup service makes use of the leasing and event interfaces. Leasing
`ensures that services registeredcontinue to be available, and events help adminis-
`trators discover problems and devices that need configuration. The Javaspaces
`
`84
`
`

`
`a;1iuoaii1{o.r\,r
`
`IN1ARCHJ"TEC1"URE SPECIFICATION
`
`-cc, one example of a Jini service, utilizes leasing and events, and also sup-
`the Jini Transaction protocol. The transaction manager can be used to coor-
`ate the voting phase of a transaction for those objects that support transaction
`"($0.001-
`The implementation of a service is not required to use the Jini programming
`-mode], but such services need to use that model for their interaction with the Jini
`7'!-fl'gh[]0]0g_y infrastructure. For example, every service interacts with the Jini
`’L0o]g,1p service by using the programming model; and whether a service offers
`ources on a leased basis or not, the service’s registration with the lockup ser-
`'¢g_ will be leased and will need to be periodically renewed.
`The binding of the programming model to the services and the infrastructure
`is-.wfiat makes such a federation a Jini system not just a collection of services and
`protocols. The combination of infrastructure, service, and programming model,
`__I__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.
`
`A_R.2.2.3 Services
`
`The Jim’ 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:
`
`6 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
`
`0 A transaction manager, which enables groups of objects to participate in the
`Jini Transaction protocol defined by the programming model
`
`85
`
`

`
`IHV}o.I1uaa1rt[.1.rV
`
`1rHE JINI ARCHITECTURE SPECIFICATION
`
`581-Vice, one example of a Jini service, utilizes leasing and events, and also sup-
`I.
`'.' ports the Jini Transaction protocol. The transaction manager can be used to coor«
`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 lini 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
`'L0o1;up 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
`I overall system and unifies it in a way that makes it easier to understand.
`
`H '
`
`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 prograrnmatically 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
`i that can be used to access the service. A single service may be implemented by
`using other services.
`Example Jini services include the following:
`
`9 A printing service, which can print from Java applications and legacy appli-
`cations
`
`0 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
`
`0 A transaction manager, which enables groups "of objects to participate in the
`Jim Transaction protocol defined by the prograrnrning model
`
`86
`
`

`
`SERVICE ARCHITECTURE
`
`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
`once the Jim Discovery and Jim 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 protoco1s—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. Loolcup 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 service provider seeks
`a Iookup service
`
`Lookup
`Service
`
`Service Object
`
`Service Attributes
`
`FIGURE AR.2.2: Discovery
`
`Jini Discoverylloin 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 AR.2.2). Then, a service object for the service is loaded into the loolcup 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
`
`

`
`my JIM ARCHITECIURE SPECIFICATION
`
`A service provider registers a
`service object (proxy) and its
`service attributes with
`
`the lookup service
`
`3611506 Objfict
`
`Service Attributes
`
`S.erv1'ee I
`Provider
`
`Service Object
`
`IHV)a.u11Je1i1[.
`
`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 he 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
`the client to talk to the service
`
`.
`_
`SBWICC Object
`
`Sewlce Ambutes
`
`Client
`
`Service Object
`
`FIGURE AR.2.4: Lookup
`
`A client locates an appropriate service by its type—that is, by its interface
`written in tlie Java programming 1anguage——a1ong with descriptive attributes that
`
`88
`
`

`
`SERVICE ARCHITECTURE
`
`are used in a user interface for the loolcup 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 Object
`
`Service Attributes
`
`Service Object
`
`House 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 diflerent 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
`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 way ensures that the program looking for the service will know how to
`
`89
`
`

`
`THE JINIARCHITECTURE SPECIFIC.-lTION
`
`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 lookup service as an attribute of a
`registered service. A user interface stored in the lookup service by a Jini 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 lookup 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
`
`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 each other, typically by nmning 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
`
`90
`
`

`
`by another kind of implementation without change or knowledge by the client.
`(Note that security permissions must be properly granted.)
`
`SERVICE ARCHITECTURE
`
`
`
`',,&._.,,5.....,,_.,...,.,l,.,..'..,,,,m,-.m..,mw.»..\.~.u.»...-a.»w_m»
`
`
`
`
`
`_
`
`91
`
`

`
`
`
`I:)1J3.1111notrt[;).I
`
`THE JINI ARCHITECTURE SPECIFICATION
`
`:“AR.3 An Example
`
`THIS example shows how a Jini printing service might be used by a digital carn-
`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
`
`I 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 Lookup Service
`
`"The basic operations of discovering the lookup service are irnplernented by a 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 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 lookup services.
`
`. AR.3.1.2 Joining the Looknp Service
`
`To register itself with the lookup 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 LookupEntry 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
`
`

`
`
`
`
`
`)__q,._,,,,,.,_,,_,,,;.,._,,_,..s‘.,.-.
`
`PRINIYNG
`
`The printer then calls the regi ster 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.l.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.=t Staying Alive
`
`When the printer registers with the Jim’ Lookup service it receives a tease. 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 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 exampleassumes 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
`
`93
`
`

`
`lHV’F orIl1.131ll]3.l\.-’
`
`mg JINI ARCHITECTURE SPECIFICATION
`
`‘itself with a local instance of the Jim software class LookupD1' scove ry, which will
`"='n01jfy the camera of all discovered lockup services.
`
`_. 53.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-
`- 1ution—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 ccnfi gu re 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-
`ceasing and sends the image to the printer service to be printed.
`
`94
`
`

`
`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
`
`

`
`0.1t1'1.1'.11!tp.I.\..-'
`
`I THE JHVI ARCHITECTURE SPECIFICATION
`
`S
`
`t\R.4 For More Information
`
`Tms document does not provide a full specification of Jini technology. Each of
`the Jim’ technology components is specified in a companion document. In particu-
`lax, the reader is directed to the following documents:
`
`_
`
`0 The Java Rennote Method Invocation Specification
`
`4» The Java Object Serialization Specification
`
`o The Jini Discovery and Join Specification
`
`6 The Jini Device Architecture Specification
`
`4» The Jim’ Distributed Events Specification
`
`0 The Jini Distributed Leasing Specification
`
`0 The Jini Lookttp Service Specification
`
`4» The Jini Lootaip Attribute Schema Specification
`
`The Jini Entry Specification
`
`The Jini Transaction Specification
`
`0 6
`
`96
`
`

`
`fl
`
`THE JIM DISCOVERYAND JoIII SPECIFICATION defines how a service should
`behave when it first starts up to find the local lockup services with which
`it should register; and how lookaps should advertise their
`availability. The discovery protocol lets a service find
`"discoverable ” lockup services. A service may also be
`configured to register with specific lockup services or to
`register only with particular lockup services. Most
`services will use discovery, since most will want to 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.
`
`U
`
`This discovery protocol is designedfor discovery on IP
`networks. IP networks are widespread and so was thefirst
`discovery protocol designed. Other networks will require
`dfierent discovery protocols that will be designedfor their
`distinct characteristics.
`
`97
`
`

`
`uio1'].-‘C.1-.1.m3si(}
`
`The Jini Discovery and Join
`Specification
`
`DJ.1 Introduction
`
`ENTITIES that wish to start participating in a distributed Jini system, known as a
`_djinn, must first obtain referenc