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:

1. Maintain and further develop the Jini specifications
2. To provide an example implementation of these specifications (currently known as the JSTK)
3. 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:

1. 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)
2. 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:

1. Service registration and discovery
2. Security – authentication, authorization, confidentiality and integrity
Transactions
3. Leasing
4. Events
5. Configuration
6. Availability
7. 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. Resources

• The current River project page from the Apache incubator

Message was edited by: joeo@enigmastation.com

Congratulations on what has been a very long road, to Dan and all those involved. This move to Apache makes it much easier for us to consider adding JINI-based features to our Coherence software. Now if I could just find some good JINI programmers .. ;-) Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid

Congratulations on what has been a very long road, to Dan and all those involved.
This move to Apache makes it much easier for us to consider adding JINI-based features to our Coherence software. Now if I could just find some good JINI programmers .. ;-)

I know at least two of 'em...

Congratulations on what has been a very long road, to Dan and all those involved.

This move to Apache makes it much easier for us to consider adding JINI-based features to our Coherence software. Now if I could just find some good JINI programmers .. ;-)

Peace,

Cameron Purdy
Tangosol Coherence: The Java Data Grid

I'd be willing to learn/take what I know further. ;)

Congratulations on what has been a very long road, to Dan and all those involved.

This move to Apache makes it much easier for us to consider adding JINI-based features to our Coherence software. Now if I could just find some good JINI programmers .. ;-)

Peace,

Cameron Purdy
Tangosol Coherence: The Java Data Grid

Thanks Cameron. Re: Jini programmers, well I'm not really up to scratch but I know a few who are ;)

This move to Apache makes it much easier for us to consider adding JINI-based features to our Coherence software. Now if I could just find some good JINI programmers .. ;-)

Peace,

Cameron Purdy

Boy, how many years is it I've been telling you about Jini and JavaSpaces Cameron? At last, you've seen the light? :-) -John-

Boy, how many years is it I've been telling you about Jini and JavaSpaces Cameron? At last, you've seen the light?

Sometime (in private, since I'd like to maintain our lead on the market), I'll explain my thoughts on the subject. In the meantime, you'll just have to ask yourself what I'd take from JINI to add into the world's fastest, most scalable and highest throughput clustering solution (Tangosol's TCMP implementation) and the most popular Java/.NET data grid and distributed caching solution (Coherence) :-). Suffice to say, Sun's change in license has made it simpler, and we've progressed to the point where this makes sense. Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid

Boy, how many years is it I've been telling you about Jini and JavaSpaces Cameron? At last, you've seen the light?

Sometime (in private, since I'd like to maintain our lead on the market), I'll explain my thoughts on the subject. In the meantime, you'll just have to ask yourself what I'd take from JINI to add into the world's fastest, most scalable and highest throughput clustering solution (Tangosol's TCMP implementation) and the most popular Java/.NET data grid and distributed caching solution (Coherence) :-). Suffice to say, Sun's change in license has made it simpler, and we've progressed to the point where this makes sense. Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid

does that mean I no longer need to walk into dunkin donut to get fresh coffee and donuts? it will be mobile service oriented coherence for mobile dunkin donuts :) please excuse the silly joke peter

In the meantime, you'll just have to ask yourself what I'd take from JINI to add into the world's fastest, most scalable and highest throughput clustering solution (Tangosol's TCMP implementation) and the most popular Java/.NET data grid and distributed caching solution (Coherence) :-)

If I remember John's late-night ramblings and your napkinware correctly it might possibly have something to do with mobile code that is located close to the data it is using, and possibly also combined with the point that it is reasonably easy to hot-update the code in a Jini-network. But this is pure speculation, of course. I really have no clue. Looking forward to be amazed or something.

If I remember John's late-night ramblings and your napkinware correctly it might possibly have something to do with mobile code that is located close to the data it is using, and possibly also combined with the point that it is reasonably easy to hot-update the code in a Jini-network.

But this is pure speculation, of course. I really have no clue. Looking forward to be amazed or something.

It sounds like you have got more than a clue :) but hot-update the code part still sounds speculative to me as I haven't seen an example of fully hot-updated code in Jini and will be happy to hear if someone did it or tells how it can be done. (reregistration of a updated service proxy is not counted as fully hot-updated code, neither updated [new version of] javaspace entry class)

If I remember John's late-night ramblings and your napkinware correctly it might possibly have something to do with mobile code that is located close to the data it is using, and possibly also combined with the point that it is reasonably easy to hot-update the code in a Jini-network.

But this is pure speculation, of course. I really have no clue. Looking forward to be amazed or something.

It sounds like you have got more than a clue :) but hot-update the code part still sounds speculative to me as I haven't seen an example of fully hot-updated code in Jini and will be happy to hear if someone did it or tells how it can be done. (reregistration of a updated service proxy is not counted as fully hot-updated code, neither updated [new version of] javaspace entry class)

Think you need to define what you consider hot-updated code first...... And just because you haven't seen it or heard of it doesn't make it speculative or non-existent.

And just because you haven't seen it or heard of it doesn't make it speculative or non-existent.

Oooh we are playing logic game here haa. I didn't claim it doesn't exist, I am not prejudice at all. I will be happy to learn how it can be done as I said before.

Think you need to define what you consider hot-updated code first.....

Ok, this is a fair statement. Java enables moving code around. Jini uses this to distribute proxies, remote listeners and callbacks among JVMs. What happens if I update the proxy or callback class and serve them via a web(class/jar file) server? I would expect new version of these classes to be automagicly downloaded, hot-updated at the JVMs holding instances of previous version. I can imagine there are many issues from notifying the class updates to classloading to using new class instances. here is another scenario that explains what I mean by hot-updated code: let say a JavaSpace (or alike service) implementation allows you to run 'agent' code on the space data. So you lookup for that service, get the proxy, send your agent code over to the space. Space then downloads the agent classes and constructs the agent instance[s]. while my agent code is running on the space, how can I get my updated agent code replace the old version running on the space? Jini is about orchestration of services running on different JVMs. Updates of moving codes on a such distributed environment still looks problematic to me. I hope my concerns are clear enough...

And just because you haven't seen it or heard of it doesn't make it speculative or non-existent.

Oooh we are playing logic game here haa. I didn't claim it doesn't exist, I am not prejudice at all. I will be happy to learn how it can be done as I said before.

Well I left that one quite open didn't I? ;) I'm not playing a logic game, just making sure that readers don't imply the wrong thing from your statements.

Think you need to define what you consider hot-updated code first.....

Ok, this is a fair statement. Java enables moving code around. Jini uses this to distribute proxies, remote listeners and callbacks among JVMs. What happens if I update the proxy or callback class and serve them via a web(class/jar file) server? I would expect new version of these classes to be automagicly downloaded, hot-updated at the JVMs holding instances of previous version. I can imagine there are many issues from notifying the class updates to classloading to using new class instances.

here is another scenario that explains what I mean by hot-updated code: let say a JavaSpace (or alike service) implementation allows you to run 'agent' code on the space data. So you lookup for that service, get the proxy, send your agent code over to the space. Space then downloads the agent classes and constructs the agent instance[s]. while my agent code is running on the space, how can I get my updated agent code replace the old version running on the space?

Jini is about orchestration of services running on different JVMs. Updates of moving codes on a such distributed environment still looks problematic to me.

I hope my concerns are clear enough...

Hmmm from where I stand that's really two different scenarios. The first implies the handling of updates caused by updating a back-end service such that the client isn't really aware of what's going on and has no control over the process. The second seems subtly different because the thing that pushed the code into the space could be the same thing that wishes to update that code. That seems like a much simpler case to me than the above. All of that said, I still don't think you have a full definition of hot-update because whilst you've given examples you haven't I believe fully stated your requirements in terms of what is and is not allowed to be done at the client. In the end, hot-update as a whole is in my belief nothing more than a process that an admin triggers to achieve a "non-stop" update in a system. There are lots of ways to do this technically all of which put constraints of some kind on the code in the system. And history suggests that making the demands of hot-update explicit in the lifecycle of user-code works a lot better because it removes the risk of dark corners and subtle unexpected interactions. Further, the way in which hot-update works across a truly distributed system versus a single JVM is different by virtue of fundamental limitations introduced by each environment. Finally, given this is such a challenge (and has such value) is it really in my interest to tell you how to do it on a public forum? ;)

Java enables moving code around. Jini uses this to distribute proxies, remote listeners and callbacks among JVMs.

Correct. Sun built the mobile code support into RMI (which caused a cascading series of less-than-elegant changes in core Java components). So Java SE has supported mobile code (obviously with caveats) since JDK 1.1. For more details, see: sun.rmi.server.MarshalInputStream sun.rmi.server.MarshalOutputStream java.rmi.server.RMIClassLoader You will be intrigued. :-)

What happens if I update the proxy or callback class and serve them via a web(class/jar file) server? I would expect new version of these classes to be automagicly downloaded, hot-updated at the JVMs holding instances of previous version.

In general, this is conceptually how most Java EE servers work. The obvious approach is to instantiate a new ClassLoader each time a change occurs, since changes tend to be incompatible. In Java EE, the "change" event is usually at a deployment unit level (e.g. an .EAR file changed), although I've seen it implemented down to the class and resource level.

here is another scenario that explains what I mean by hot-updated code: let say a JavaSpace (or alike service) implementation allows you to run 'agent' code on the space data. So you lookup for that service, get the proxy, send your agent code over to the space. Space then downloads the agent classes and constructs the agent instance[s]. while my agent code is running on the space, how can I get my updated agent code replace the old version running on the space?

Exactly. It's not a problem that is confined to Jini or Java EE. It's a general problem that needs to be solved across the board. In development, it's important for the ability to quickly prototype, change and tweak things. It's also extremely important in a production environment, e.g. for the types of continuously available applications that our customers deploy. I've been impressed with the work that OSGi has done in this area as well. If Java EE servers had been built on / with OSGi .. well, our world would be a much different place. I think that Rod and the other architects at i21 have picked up on this already in Spring, and BEA is (very quietly so far) blazing some very interesting trails in this area as well. Paremus got me looking in this direction probably a year and a half ago now. Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid

In general, this is conceptually how most Java EE servers work. The obvious approach is to instantiate a new ClassLoader each time a change occurs, since changes tend to be incompatible. In Java EE, the "change" event is usually at a deployment unit level (e.g. an .EAR file changed), although I've seen it implemented down to the class and resource level.

It's not a problem that is confined to Jini or Java EE. It's a general problem that needs to be solved across the board. In development, it's important for the ability to quickly prototype, change and tweak things. It's also extremely important in a production environment, e.g. for the types of continuously available applications that our customers deploy.

Agreed. When we got a new build to deploy at work, for instance, we got the luxury of restarting our a few J2EE servers. all done. But with Jini, we are dreaming of a 'Jini Network' with massive deployments of individual services. It doesn't have to be in a local network. Image Jini services deployed all around world available to you. ...and code is still moving... It would be very nice if the mobile code in Jini network can get hot-updated very easily [again, maybe it can, I just don't know].
Yes it is not a problem in Jini or J2EE. It is just that when you distribute, things get complicated. When you distribute and mobilize, it even gets scary.

When we got a new build to deploy at work, for instance, we got the luxury of restarting our a few J2EE servers. all done.

Why do you restart the servers? I realize that may sometimes be an easy way "to be safe", but most servers do hot deploy.

Yes it is not a problem in Jini or J2EE. It is just that when you distribute, things get complicated. When you distribute and mobilize, it even gets scary.

Absolutely. I think that challenge explains a lot of the demand that we see in the market. Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid

When we got a new build to deploy at work, for instance, we got the luxury of restarting our a few J2EE servers. all done.

Why do you restart the servers? I realize that may sometimes be an easy way "to be safe", but most servers do hot deploy.

Yes it is not a problem in Jini or J2EE. It is just that when you distribute, things get complicated. When you distribute and mobilize, it even gets scary.

Absolutely. I think that challenge explains a lot of the demand that we see in the market. Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid

I think many people still don't trust hot deploy :) Hot deploy has improved a lot over the last 4 years, but it didn't always work reliably for all situations. I can think of several servlet containers that had problems with repeated hot deploys causing stability issues. I'm just guessing, so i could be totally wrong. peter

Now if I could just find some good JINI programmers ..

OT, but I am just curious: do you recruit for talent or for skill? Can corporate America afford to recruit for talent anymore - and fill in the gap with necessary training?

Now if I could just find some good JINI programmers ..

OT, but I am just curious: do you recruit for talent or for skill? Can corporate America afford to recruit for talent anymore - and fill in the gap with necessary training?

Have they been doing it? I have seen little of it in recent years. Sure, you can find examples, but on the whole the industry wants preexisting skills and certifications and wants to pay little for it.

Now if I could just find some good JINI programmers ..

OT, but I am just curious: do you recruit for talent or for skill? Can corporate America afford to recruit for talent anymore - and fill in the gap with necessary training?

Personally, when I am interviewing and recruiting, I look at attitude and talent. Attitude is extremely important, because a good attitude helps to build a great place to work, and it's nice to know that you can count on all those around you in both the good times and the bad. Specific skills are relatively unimportant to me if the attitude and the talent (e.g. good communication abilities, apparent brightness, true understanding of the concepts behind great software, etc.) are there. As far as acquiring skills, there are very few software jobs in which someone determined to learn new things will fail to do so. In an environment like ours, it is close to the extreme, in which almost every project is a big learning experience. The other problem in looking for people to fill specialized roles is that there will likely be no one available that has the skills necessary. None (not even one!) of our engineers had experience in the specialized areas in which we work. Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid

Congrajulations to Dan and his team. Thanks for bringing JINI in to limelight. Hope this increases JINI jobs in the market so that some us can still continue doing interesting stuff. :-)

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.

+1. I don't know why JINI hasn't grabbed traction, but I hope this rejuvenates interest a bit. P.S. Dan, Since you have been a player in the JINI arena on the Blitz Javaspaces side, how do you feel about this move? Should this be taken as a positive or just another Apache "put out to pasture" project?

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.

+1.

I don't know why JINI hasn't grabbed traction, but I hope this rejuvenates interest a bit.

P.S.

Dan,

Since you have been a player in the JINI arena on the Blitz Javaspaces side, how do you feel about this move? Should this be taken as a positive or just another Apache "put out to pasture" project?

Thank you for the affirmation! A minor point but I've been involved in a lot more than just Blitz. I've worked on many a Jini deployment, fixed bugs in some of the JSTK services, done a lot of Jini evangelism etc. I was also one of the original advocates for dumping the SCSL and moving to an opensource license. I'm very positive about the move - a chance to expand resources, a chance to redefine things, maybe re-package things and move away from the (confusion of the?) JSTK and a chance to change direction or focus into new areas. There are risks, people have to learn a new way of working and I think they have some hard lessons to learn because they've actually not been doing the work of shipping a product unlike the Sun team or, maybe me with Blitz. But that comes with the territory and we have enough experience around to make it work. Is it out to pasture? No I don't think so but even if that happens I have a (serious) contingency in place to deal with that cos I can see at least one substantial niche to go after!

Dan and the rest of the Jini community, congratulation! I'd like to quote from Geva Perry blog: Jini - Killer Apps aren't developed; they emerge :

"..While a technology may have been around for a while, massive acceptance only occurs when there is significant environmental change that suddenly makes those technologies relevant.. Once this change happens, and if the technology is positioned to seize the opportunity, everything else will fall into place: products rapidly improve, they become cheaper, and with multiple applications -- including killer applications." Source: Richard Gabriel's presentation Models of Software Acceptance: <a href"http://www.dreamsongs.com/Files/AcceptanceModels.pdf">How Winners Win (PDF)

That's defiantly seem to be the case with Jini. The fact that most business critical applications runs on our Jini/JavaSpaces based product is the best proof for that. The resent testimonial from Virgin Mobile is yet another important evidence. Those looking for implementing a true SOA application using the Jini technology should look into the Rio project which provides POJO based abstraction to Jini Services and define a light weight SLA driven container model an essential piece to any serious Jini related development. Dan, keep on the good work - without your dedication non of this would have happen. BTW can we start and commit contribution to the River project? Nati Shalom GigaSpaces Write Once Scale Anywhere http://www.gigaspacesblog.com/

BTW can we start and commit contribution to the River project?

Depends what you mean by commit. Getting to be a committer is about meritocracy etc - you have to be invited based on past efforts and the like. Typically you get to be committer status by offering stuff up for contribution that people like and approve of and the committers choose to "merge". Over time, if you do this often enough, you'll likely be invited to be a committer. I can't see how GigaSpaces itself could be a committer but I can see how individuals within GigaSpaces could be......

why sun put its failing(or deprecated and stopping) specs in apache ? it did it with JDO and no further dev done on it and now it puts JINI as if apache is the grave of such specs, i think apache foundation should n't accept such behavior

why sun put its failing(or deprecated and stopping) specs in apache ? it did it with JDO and no further dev done on it and now it puts JINI as if apache is the grave of such specs, i think apache foundation should n't accept such behavior

Joe, see previous threads on Jini and Apache.

did it with JDO and no further dev done on it

Whilst I agree with the sentiments, please go across to Apache JDO and have a look at what will be JDO 2.1 ... doesnt seem like "no further dev" to me

why sun put its failing(or deprecated and stopping) specs in apache ? it did it with JDO and no further dev done on it and now it puts JINI as if apache is the grave of such specs, i think apache foundation should n't accept such behavior

I'd say that was verging on trolling but..... Jini isn't dead - that's why it moved to Apache. Sun can't provide enough manpower to deal with all the demands and they don't feel able to co-ordinate the whole community anymore. It's just getting too big! If Jini were dead, there'd be no need to move it to Apache because the license was already Apache V2 anyways. Thus Sun could've cut it loose and left the community to it. You should also be careful about your judgements in respect of Apache. One of the longest debates we had was over proving that we weren't using them as a dumping ground at their request! Fact is for the first time since I started playing around with all this stuff, I've got more Jini work than I can get done, I'm pushing stuff onto others and it's been like that for more than twelve months. And I suspect if you take a look around the blogosphere and elsewhere you'll see more noise than before and you might want to note what Cameron is saying elsewhere!

Fact is for the first time since I started playing around with all this stuff, I've got more Jini work than I can get done, I'm pushing stuff onto others and it's been like that for more than twelve months. And I suspect if you take a look around the blogosphere and elsewhere you'll see more noise than before and you might want to note what Cameron is saying elsewhere!

That is great news. It seems people are finally seeing and believing that a UI + database is not the only way to build "applications". While I am not currently in the financial/insurance/... industry I think there is usage for Jini/JavaSpaces/Coherence. But it is still a hard sell and I have to "prototype" it first.