The announcement of the Apache River project
in the Apache Incubator is the culmination of the process of transforming Sun's Jini project into a completely opensource effort. There are also discussions around migrating the Service UI
project and the test kit to River as well.
The purpose of the Apache River project will be to:
- Maintain and further develop the Jini specifications
- To provide an example implementation of these specifications (currently known as the JSTK)
- Develop tools, infrastructure, documentation and other materials
Note that it is not currently the intention of the Apache River project to provide a reference implementation. Instead, it's expected that third parties will provide value-added re-implementations of key components guided by the Jini specifications. Thus where the specs are unclear, the specs will be revised accordingly.
Although the source code for the Jini project was already available under the Apache License V2, the surrounding community (including Sun) decided that a move to Apache would provide several advantages:
- More development resource – additional testers, developers, documenters to work with Sun's developers (most of whom are on the initial committers list for the project)
- More open development process providing greater opportunity for collaboration, access to a bug database and a public code repository
But perhaps the biggest advantage of the transition is an opportunity to re-position Jini which, due to Sun's marketing strategy has been viewed as a niche technology for embedded devices.
Jini is an architecture for the construction of network systems built out of discrete, dynamic assemblies of software services. Core concepts of the architecture include:
- Service registration and discovery
- Security – authentication, authorization, confidentiality and integrityTransactions
- Legacy integration/service bridging
If these concepts sound familiar, that's because you'll find them all lying around in SOA. Much of the JBI specification focuses around the implementation and provision of each of those features.
Here are some of the key characteristics of services in any Jini system:
- At compile time, services have to know what other services they need to function but don't need access to (via classpath etc) the stubs or proxies (i.e. the implementation of) of the services they are dependent upon.
- At runtime, services can find the other services they need (without need for static naming strategies) at which point they receive the proxy or stub required to communicate use the chosen service.
- Services find each other in a manner which means there's no risk of the usual dependency loops where service "Y" needs service "X" before it will start and vice versa.
- Services can be deployed in completely non-stop fashion - no restart of containers, web servers, etc.
- Security for authentication, authorization, integrity and confidentiality can be configured on a service by service basis at deployment or runtime.
All of these sound useful but Jini goes some way beyond satisfying these basic SOA requirements:
- Services could be running anywhere, servers, desktops, laptops, phones etc.
- A piece of hardware that uses Jini doesn't need to embed the entire Jini stack, support multicast etc.
- Services don't have to be Pure Java.
- Each service is free to define and use whatever communication protocol is appropriate for it's intended function.
One cannot mention Jini without talking about JavaSpaces. Many people see JavaSpaces as being of equal significance to Jini itself but that isn't really the case. A JavaSpace as expressed in the Jini specifications is simply a service (one of many) that combines elements of the Jini and tuplespace programming models. In some systems, such a service is useful and in others it isn't (for example Orbitz use the Jini programming model, infrastructure and the lookup service but not the JavaSpace service). Perhaps because many of the other services such as the transaction manager are considered "mundane," JavaSpaces attract more attention.
With current trends driving a move away from static, monolithic and disconnected systems to dynamic assemblies of modular inter-communicating, evolvable services, Sun may just have given away the crown jewels to Apache.
Message was edited by: firstname.lastname@example.org