Jini Network Technology

Over the last quarter century, network technology has evolved rapidly and in some unexpected ways. Client/server and multi-tier models operating within a single business enterprise have given way to an Internet/Web environment where services are provided by nodes scattered over a far-flung network.

Today, the next generation of network interaction is emerging that will place unprecedented demands upon existing network technologies and architectures. For example, participants in one network will need to directly access and use the services provided by participants in another network. It is in this network environment - one of mind-numbing complexity driven by geometric increases in scale, rate of change, and multiplicity of participant interactions - that the simplicity of the Jini architecture clearly wins.

By using objects that move around the network, the Jini architecture makes each service, as well as the entire network of services, adaptable to changes in the network. The Jini architecture specifies a way for clients and services to find each other on the network and to work together to get a task accomplished. Service providers supply clients with portable Java technology-based objects that give the client access to the service. This network interaction can use any type of networking technology such as RMI, CORBA, or SOAP, because the client only sees the Java technology-based object provided by the service and,subsequently, all network communication is confined to that Java object and the service from whence it came.

When a service joins a network of Jini technology-enabled services and/or devices, it advertises itself by publishing a Java technology-based object that implements the service API. This object's implementation can work in any way the service chooses. The client finds services by looking for an object that supports the API. When it gets the service's published object, it will download any code it needs in order to talk to the service, thereby learning how to talk to the particular service implementation via the API. The programmer who implements the service chooses how to translate an API request into bits on the wire using RMI, CORBA, XML, or a private protocol.

When the Internet was developing, there were two essential activities: defining and perfecting the underlying protocols and infrastructure, and creating applications and services on top of that infrastructure. Internet infrastructure includes TCP/IP, HTTP, SMTP, and FTP--protocols and their implementations. On top of these were built email composers and readers, file fetching programs, Web browsers, and the Web itself. No single company or organization did all the work, and none could, if the venture was to be successful, because underlying it all is a standard protocol, and a protocol can be successful only if it is widely adopted. For Jini network technology to succeed, the underlying protocols and infrastructure must become pervasive, and to accomplish this requires a strong community of participants and partners.

The Sun Community Source License (SCSL) is a mechanism to build such a community around Jini technology. The SCSL opens the source code for the Jini technology infrastructure to the community of Jini technology licensees, who are free to use it, modify it, improve it, and repair it by following an open process that insures both fairness and stable evolution of the technology. Community members may add to this common body of source code while still maintaining, if they wish, proprietary implementations, though interfaces must be published so other community members can build their own implementations.

For more information on licensing, please go to wwws.sun.com/jini/licensing.

For more information on the Community, please go to wwws.sun.com/jini/community.