Dan Creswell, in "JINI vs SOAP," addresses the perception of competition between JINI and SOAP, and says that JINI and SOAP address different things: "One is a piece of plumbing the other is a set of blueprints."

To be specific, SOAP is the "piece of plumbing" and JINI is the "set of blueprints."

His review of what JINI is:

Okay, so let's review:

• JINI is a design approach/philosophy.
• It's based on the concept of services defined as a Java interface with no restriction on function or granularity. The interface might be styled on RPC or it might be styled as a piece of business logic or it might look like a message queue or anything in between.
• Beyond the interface will be a proxy likely written in Java.
• Nothing beyond the proxy need be Java.
• JINI is protocol agnostic - you can use SOAP, RMI, JERI, sockets, JMS or whatever.

In summary, JINI provides you with just enough definition and specification to give you sufficient mechanisms to build a bunch of distributed services. What those services can do, how they are implemented and so on is not defined and the starter kit is nothing more than one example of implementation it is not the only way of doing things and it's not a reference implementation - just ask SUN if you don't believe me.

Is peer-to-peer networking an underused tool in service-oriented programming?

Is peer-to-peer networking an underused tool in service-oriented programming?

Yes, I believe it is. I think the key is to avoid using it to try and solve every problem.

Peer-to-peer works best in combination with other things (something I think can be said of all technologies - use the right tool for the right job, not all jobs).

The following is a presentation from the recent Jini Community Meeting which provides a good discussion of the relative strengths of JINI, JERI and JXTA and then suggests a way to combine them into a superior solution.

http://www.jini.org/nonav/meetings/ninth/JXTA/JXTA.html

or

http://www.jini.org/nonav/meetings/ninth/JXTA/JXTA.pdf

Anyone who uses JINI with SOAP as the underlying protocol is a damn fool.

Thinking of the flexibillity of JINI, isn't possible to use just JINI to fill the "gaps" that would have been filled by JXTA? I mean if transport would be HTTP over JERI, the JINI goes beyond the restrictions of a LAN/WAN because firewalls won't be a problem right? After all services talk with each other. The only thing that remains is the mith of centralized(JINI)/decentralized(JXTA) models.

Thinking of the flexibillity of JINI, isn't possible to use just JINI to fill the "gaps" that would have been filled by JXTA? I mean if transport would be HTTP over JERI, the JINI goes beyond the restrictions of a LAN/WAN because firewalls won't be a problem right? After all services talk with each other. The only thing that remains is the mith of centralized(JINI)/decentralized(JXTA) models.

Yes, it is possible to just fill in the "gaps" with JINI by using such things as jeri tunnelled over http. However, JXTA has some built-in primitives which make this "gap-filling" easier in some cases.

I've built several clustered JINI services using JXTA for example which was cleaner and took less time than writing lots of invocation calls or working with multicast to get the same results.

Essentially, it comes down to personal taste as you need to choose the tools you're comfortable with and you feel give you the best balance across the breadth of the problem you're trying to solve.

As to centralized/decentralized - JINI does peer-to-peer services whilst JXTA has a peer-to-peer based transport. You can certainly build peer-to-peer communications in JINI and peer-to-peer services in JXTA. I think generally, people make judgements based on what's in the package by default rather than thinking about what might be built atop the package. Thus people see blatant peer to peer in JXTA and blatant services in JINI but they don't see the other possibilities.

Okay, so let's review:

• JINI is a design approach/philosophy.
• It's based on the concept of services defined as a Java interface with no restriction on function or granularity. The interface might be styled on RPC or it might be styled as a piece of business logic or it might look like a message queue or anything in between.
• Beyond the interface will be a proxy likely written in Java.
• Nothing beyond the proxy need be Java.
• JINI is protocol agnostic - you can use SOAP, RMI, JERI, sockets, JMS or whatever.

JINI definitely doesn't compete with SOAP:

- JINI is used by a handful of companies, SOAP by tens of thousands of companies. As a result, SOAP benefits from the "network effect", making it the standard for communication (even if it isn't pretty).

- There are hundreds of different SOAP kits for Java that allow you to build a Java interface and have SOAP behind it. While JINI could theoretically be yet-another-kit-for-putting-a-Java-interface-on-SOAP, I've yet to see it done once.

JINI is still a solution looking for a problem.

Peace,

Cameron Purdy
Tangosol Coherence: The Java Data Grid

Not true - and if you take a little time to look in the Jini Community,you'll see a lot of varied uses in different kinds of solutions.

I do keep in close touch with a number of people in the JINI community, which is where I get most of my strong opinions from. ;-)

If this argument goes the same way as all the previous ones that I've had with the other two JINI supporters, I'm going to predict that you're about to show me how JINI can be used to build a work distributor ..

.. check out this white paper which describes*one* solution area (compute grid) with a number of examples ..

Hey, what do you know? A work distributor example! Unfortunately, the "decomposing the problem into massively computationally-expensive pieces that coincidentally have little or no state requirements and no cross-dependencies" part is left to the reader.

Sorry for my cynicism, but I have found JINI to be as unwieldy as a glacier, and Sun to be in about that much hurry to address the issues with it.

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Coherent Caching

I guess this means you couldn't take the time to actually look into the links I provided.

Not true - and if you take a little time to look in the Jini Community,you'll see a lot of varied uses in different kinds of solutions.

I do keep in close touch with a number of people in the JINI community, which is where I get most of my strong opinions from. ;-)If this argument goes the same way as all the previous ones that I've had with the other two JINI supporters, I'm going to predict that you're about to show me how JINI can be used to build a work distributor ..

.. check out this white paper which describes*one* solution area (compute grid) with a number of examples ..

Hey, what do you know? A work distributor example! Unfortunately, the "decomposing the problem into massively computationally-expensive pieces that coincidentally have little or no state requirements and no cross-dependencies" part is left to the reader.Sorry for my cynicism, but I have found JINI to be as unwieldy as a glacier, and Sun to be in about that much hurry to address the issues with it.Peace,Cameron PurdyTangosol Coherence: Clustered Coherent Caching

I guess this means you couldn't take the time to actually look into the links I provided.

I did take the time to go through, in detail, the links that you posted. In cummulative, I have spent (wasted?) hundreds and hundreds of hours on JINI.

Trust me, the reason that people don't use JINI isn't because they haven't taken the time to look at it. More often, the reason that they don't use it is precisely because they did take the time to look at it.

The sooner that the JINI group stops blaming the world for the lack of JINI adoption, the sooner they can get down to the real business of asking themselves what is wrong with JINI.

Until then, I suggest you just play it safe and assume that anyone who doesn't love JINI is just too lazy to follow the links that you post, or too stupid to appreciate the incredible intelligence behind it. You are par for the course so far.

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java

Although I would love to get into it with you... I'm going to take the high road and not get dragged into your mud pit. The sentiments you tried to attribute to me in your response are ridiculous.

Let me be clear -- I am not trying to convince you or anyone else to use or appreciate Jini technology... I was simply providing information for those who might be interested (and might be confused by the FUD you're spreading). Since you've already drawn your own conclusions, that's fine... "Peace" and move on.

-Jim

I guess this means you couldn't take the time to actually look into the links I provided.

I did take the time to go through, in detail, the links that you posted. In cummulative, I have spent (wasted?) hundreds and hundreds of hours on JINI.Trust me, the reason that people don't use JINI isn't because they haven't taken the time to look at it. More often, the reason that they don't use it is precisely because they did take the time to look at it.The sooner that the JINI group stops blaming the world for the lack of JINI adoption, the sooner they can get down to the real business of asking themselves what is wrong with JINI.Until then, I suggest you just play it safe and assume that anyone who doesn't love JINI is just too lazy to follow the links that you post, or too stupid to appreciate the incredible intelligence behind it. You are par for the course so far.Peace,Cameron PurdyTangosol Coherence: Clustered Shared Memory for Java

Although I would love to get into it with you... I'm going to take the high road and not get dragged into your mud pit.

I was only responding to your comment ("I guess this means you couldn't take the time to actually look into the links I provided.") If your comment was not meant to be snide and curt, as I interpreted it to be, then the error is mine.

I have honestly put a lot of time (my own scarce time) into trying to learn JINI, because I thought that the various JINI services and APIs would be a great fit with what we do. I was frustrated at every turn with the JINI design, and I even took the time to try explain my frustrations to vaious individuals working at Sun on JINI. (You call it "FUD", which I find humorous. Does the "F" stand for "frustrated"?) So while I do honestly think that JINI has serious problems, I also made an honest effort to help highlight and correct those problems.

If you're located in the Burlington office, or if you find yourself on this [east] coast, you're always welcome here, and I would be glad to sit down and discuss this further with you. I'd like nothing better than finding some way that we could incorporate support for JINI services into our own software. You should ask yourself why no one at Sun has tried to help us do that, considering how successful our clustering software is in the market (the biggest Sun app server clusters run on our software, for example).

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java

So while I do honestly think that JINI has serious problems, I also made an honest effort to help highlight and correct those problems.If you're located in the Burlington office, or if you find yourself on this [east] coast, you're always welcome here, and I would be glad to sit down and discuss this further with you. I'd like nothing better than finding some way that we could incorporate support for JINI services into our own software.

Cameron,

Would you be willing to share those serious problems you see with Jini here or at the jini-users mailing list (the latter would be the place where most of the people that can influence the technology hang out). I did a quick search in the mailinglists to see whether you made those problems public already, but I failed to find any.

I think we should be able to provide you a save passage over there in the Jini community ;-)

Mark Brouwer