Van Simmons thinks that we need a unified theory for our Java distributed applications. EJB, Jini, JXTA, and JMS have more in common than just the letter J, though you wouldn't know it from reading the specs.

Back in 1998 he understood Java as a technology. Now, with so many JSR's, how we can relate all of the technology?

"There are now so many pieces of the Java specification that it is entirely possible to work heavily with one API and still be completely incapable of explaining how to relate that API to another one which has some overlapping features. Don't believe me? Try this - in one nice, neat list describe the decision tree you'd use to determine whether to house an object in a distributed application in a) an EJB container, b) a JXTA peer group, c) a Jini service or d) broadcast it in a JMS topic. I've certainly tried it and the result somehow left me feeling stupid."

Van isn't simply thinking outloud about abstract ideas. He is actually trying to work out these questions as he builds a high throughput compute farm. How can he choose which technologies he should use?

Read: A Grand Unified Theory of Distributed Applications for Java

When I was first introduced to EJB in a class almost 3 years ago now, I was thinking a lot of the same thoughts that are brought up in this article. ie I had read and used JINI a little and a lot of terms, thoughts etc were the same. I thought then as I do now the alphabet soup needs to be tamed a little to make it easier for newer people to get into java. JXTA, Jini, and J2EE have a lot of crossover in how they work, and before I am flamed they also have a lot that is specific to the problem domain that each attacks. Couldn't they all somehow come together to create 'Super Servers', 'Super Clusters' or 'Super failover clusters'.

J2EE is trying to solve well-know, well-described specific problems. Things are mostly static and require more admistrative work; thing about number of xml files you have to go over and server names you staticly bound. Jini on the other hand, is trying to solve network(distributed) programing problems over all by providing more dynamic, proactive behaviours. It doesn't solve any specific application-level problem though, which makes people a little uncomfortable with Jini. you hear people asking how Jini handles persistance, refering to the J2EE's Entity beans. there is no Entity bean kind of specification in Jini, and I don't thing there should be. More important than that, there is no container concept in Jini, things are distributed freely as 'services'. Jini brings true 'service oriented' programing model. nodes in a Jini network would be called 'service', whereas nodes in a JXTA network would be called 'peer' and nodes in a J2EE network would be called 'j2ee server'.

they are not truely competing technologies rather complementary technologies. if you are writing a J2EE server, you can use Jini's dynamic, self healing features. if a Jini service needs to persist data in a way that entity beans does, then the Jini service can make use of a J2EE server to do that. if you are writing JMS implementation, you might want to leverage Jini JavaSpaces technology. JNDI might internally be interfacing with Jini Lookup Service to gain some dynamic behaviour.

since Jini and J2EE has different transaction service model, it is hard to achieve true clustering among them. you might achieve load-balance and fail-over if you make some assumptions and exceptions but when it comes to replication things are more complex. in J2EE, you know what to replicate; such as statefull session beans, http session... whereas since there is no specification on custom service level specification, something like statefull/stateless jini service, you don't know what to replicate. each service has to take care of its own replication.

I think some J2EE vendors will expose a way to deploy Jini services in them. this is not much useful rather meaningless if you ask me unless J2EE server's core has strong ties to Jini. More natural cooperation of these two technologies would be that J2EE server is built on top of Jini technology and Jini services are either deployed into the J2EE servers or running remotely and making use of J2EE server for the things that J2EE is good for.

even though marriage of Jini and J2EE is possible and might be good for some cases I still think that having Jini based infrastucture would be the best. keep J2EE as J2EE and Jini as Jini. don't try to see they are brother and sister or life-time friends.

I cannot relate JXTA to J2EE much. maybe someone else will.

-talip
check out JPower @ jpower.org
a free Jini JavaSpaces implementation

I cannot relate JXTA to J2EE much. maybe someone else will.

Of all the frameworks mentioned, only JXTA and Jini have built in heart beat. Only EJB and JXTA have both synchronous RPC and asynchronous messaging. And only JXTA can tunnel bidirectionally through a client's firewall over port 80. So for wide area networking, JXTA's the best transport. The others should be services layered above JXTA.

Brian: And only JXTA can tunnel bidirectionally through a client's firewall over port 80. So for wide area networking, JXTA's the best transport.

WANs are not about being able to go through port 80. Applications working well on a WAN need to be designed for high-latency and relatively low bandwidth. Rarely do WAN applications have a requirement to hide their communication in a text-based web surfing protocol.

OTOH When you are working with "public Internet peer-to-peer", then the port 80 issue arises. Sun's JXTA was its answer to "how do I build Napster in Java?" (Peer-to-peer public network distributed applications.)

So, building J2EE on top of JXTA might be "cool", but I'm not sure if it's the right sub-strate. (I do have lots of opinions on clustering, though, so take my opinion with a grain of salt.)

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Easily share live data across a cluster!

My experiences have exactly matched yours based on your description, Cameron. The "Tunnel anywhere over the Inernet" paradigm seems cool until you actually use it. Then you discover the joy of lost packets and atrocious performance, not to mention what firewalls do to your tunnelling data.

It seems like a great idea, at least, until you're the one to debug a production app that uses it :-)

     -Mike

The "Tunnel anywhere over the Inernet" paradigm seems cool until you actually use it. Then you discover the joy of lost packets and atrocious performance, not to mention what firewalls do to your tunnelling data.

So you've tried JXTA over the Web and it sucked? Or are you *assuming* that the failure of other Web programming paradigms also applies to JXTA?

\Miller\
So you've tried JXTA over the Web and it sucked? Or are you *assuming* that the failure of other Web programming paradigms also applies to JXTA?
\Miller\

I think you misconstrued my (badly worded) argument. JXTA has its place for certain applications, but in particular people seem to want to apply it to a wider domain that it's really suitable for. In particular, a number of developers and architects I've talked to seem to assume that tunneling technology is "free" in terms of performance, capability, error recovery, etc - and its not. For some apps, such as one or two I've seen described here, JXTA looks really nice, but you do _not_ want to just JXTA-enable anything, and many people are _not_ going to be very happy with the constraints tunneling puts on them.

     -Mike

WANs are not about being able to go through port 80.

That may be so within your corporate upper crust, where system administrators have the talent and chain-of-command to poke the necessary holes in their firewalls. But this isn't the case generally in userland. Our collaborative web application unites far flung high school teachers, and initial proof-of-concept testing revealed that only HTTP over port 80 gives ubiquitous reach. JXTA's the only bidirectional port 80 solution mentioned in this thread, and this does matter on the Web. Peer-to-peer amorphous topology increasingly matters, and J2EE missed this.

When you are working with "public Internet peer-to-peer", then the port 80 issue arises. Sun's JXTA was its answer to "how do I build Napster in Java?"

Again, that's too dismissive. JXTA isn't merely about tunneled ad-hoc federation. Even client/server benefits from JXTA's ability to asynchronously push the server's callbacks through the client's firewall without polluting the business interface with polling methods and and poll result structures. And the enterprise motivation for CRUDlets is directly suited to JXTA.

Cameron: When you are working with "public Internet peer-to-peer", then the port 80 issue arises. Sun's JXTA was its answer to "how do I build Napster in Java?"

Brian: Again, that's too dismissive. JXTA isn't merely about tunneled ad-hoc federation. Even client/server benefits from JXTA's ability to asynchronously push the server's callbacks through the client's firewall without polluting the business interface with polling methods and and poll result structures. And the enterprise motivation for CRUDlets is directly suited to JXTA.

Far from being dismissive ... it was quite a compliment. I've been corresponding with Calvin Cheng at Sun regarding our potential use of JXTA. You could say that I have a lot of interest in this area.

However, a "collaborative web application" is not the same as a WAN, any more than accessing a web server on the public Internet is a WAN. I don't want to continue arguing about terms though when the subject at hand is more important. ;-)

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Easily share live data across a cluster!

<!--So, building J2EE on top of JXTA might be "cool", but I'm not sure if it's the right sub-strate.-->

I never understand this argument. IMHO P2P is a good buzz to share data, but building RPC style service oriented framework like J2EE/CORBA on top of it is not gonna fly. Lot of non-determinism when it comes to WAN. Who will garbage collect your client side refrences?How you going to maintain state?

What I'd like to see in the java plaform is an extension model
à la Eclipse.

Think:

1) When you write a java application you must write down a method

public static void main (String [] args);

this means that the java executable implicitly defines an extension point (I'm using the eclipse jergon) that you implement by writing down an extension, that is,
the main method.

2) When you write a servlet you must implement the Servlet interface and must provide a descriptor for your component. This means that the web container implicitly defines an extension point that you implement by writing an extension, that is the servlet and the descriptor.

3) When you write down an 1.5 resource adapter, you can define some deployment properties of a message driven bean, and its interface: you are yourserlf defining an extension point which will be implemented by the message driven bean developer, and also implementing an extension point defined by the server.

It would be nice if the eclipse extensibility model would be brought to the
java platform, which needs it. Consider how many apis there are in the j2ee platform, and the fact that a comprehesive integration mechanism lacks.

(Should the model define, besides the usual extension point - extension vertical mechanism, an horizontal orthogal mechanism, aop?)

Before the J2EE goes the CORBA way with too many players and too many specifications the J2EE community should put all its technology in a proper perspective. Too much of innovation may be an overkill.

The thing with all this is that each domain problem is unique, and although J2EE or JINI or even JXTA can provide a solution to most distributed apps (either as stand-alone API's or in combination), there are many situations we all come across where a "standard" solution just does not fit. Hence, for example, the variety of persistence architectures. Saying that too much innovation is a problem is a little naive, I think the difficulty lies more in determining which solution or decision tree to stick with, and making that commitment. My recommendation (as Rod affirms in hiw Wrox book) is to shy away from un-tested tools that have not been fully specced or use them based on the promise of future deliverables. But again, this determination is somewhat subjective.

But I do agree there is a sore need for a grand theory joining the dots and pointing to solutions to a type of problem domain. Does this sound like a book to you?

I feel the solution is not a technological matter, but a new paradigm is needed.
We can think as POJO that can be "aspectized" to grant the feature needed ( Ejb, Jini, Jxta, ... ).

Aspect Oriented Programming can be a good solution. A good example is the JBoss 4.0 AOP framework.

I'm not really a fan of dotNet but this is a good idea that Microsoft did catch on too. You can "aspectize" a method to be accessible via RPC with SOAP by simply adding a [Web Service] tag before the function declaration. The compiler and the container take care of the rest. Of course, in the java world we wouldn't want to tie it to one container or one compiler, so there would need to be standards. I'm not really happy with the XDoclet code generation method or syntax. Even though I think it uglifies the language (and screws up symbols), I like Microsoft's syntax. It's about time to leave behind the legacy of the BCPL preprocessor and make code a bit more readable and concise. Python rubbed me the wrong way for the longest time because of its sxntax, but I find I'm liking it more, the more I use it; only wishing that they weren't so creative with builtin methods, just for the sake of being different.

My idea is that today a software developer has to satisfy mainly the Functional Requirment.
Non functional requirements are an adaption and a developer must write software with the simplest technology.
A process of adaptation to a technology during compile time or better during runtime is a must be accomplished.
Of course after adaption, a process of intercepting call with a new technology must be provided using an Aspect Oriented Technology.
In my company, we are specifying a new methodology called ACUBE that focuses on adapting POJO classes to the chosen technology letting the developer to know only java or only C#.

The current supported adapted techonologies are JINI, CORBA and EJB.

Picking an API then writing the app to it is backwards. Write the app so it works, then put it on top of whatever API(s) you need. In many/most cases, the application itself shouldn't care whether it's using EJB or Hibernate or a giant flat file for persistence, nor should it care about whether the front end is built with JSP, servlets, Swing, etc.

By using a methodology like SAND you can build your app and then deploy it onto whatever technology platform you want using powerful code generators (think XDoclet on steroids). SAND is designed from the ground up for developing high-peformance distributed applications, so it takes care of the messy stuff like persistence/logging/configuration/deployment/caching/serialization/etc letting you concentrate on *what* your app does, not *how* it does it. I've used similar (but less advanced) architectures in developing several trading systems, and they save a LOT of development time.

There's an open source implementation called sandboss on SourceForge under active development.

As with most things, there's more than one way to get where you're going. So far SAND has been the easiest for what I need.

We've been developing this way for years, although less from a 'lookup an instance' perspective than from 'connect to a service' perspective. The CocoBase 3.x product wrappered RMI, Corba and Proprietary APIs to provide a unified persistence API that could use any of those services as the transport layer. We were preaching this methodology when vendors were still arguing that all objects in the enterprise should be IDL and distributed instances... Our current Distributed Transparent Persistence implementation uses EJB Session Bean (RMI/IIOP) technology or Local persistence. This means that the API for programming a local persistence manager, or one residing on a remote system using EJB technology behave identically!

The problem with making business objects aware of the persistence layer is that this inherently reduces both their portability and reusability. If you have a good generalized persistence manager, the actual physical transport layer, or even persistence mechanism should be irrelevant. This was 'sort-of' the point of some of the standards efforts around persistence, but they all missed the boat on the specifics. What's wrong with EJB and JDO is that in both cases 'special' object types are required. Not only is this COMPLETELY unnecessary, but it interferes with the dream of a generalized layer that works with all APIs.

What you're describing isn't just a 'dream', it's a reality with CocoBase. We could just as easily implement a JINI or a JMS service to supply the same persistence implementation, and all an object must be is serializable... And I'm glad you like this theory, because as far as I know I was the first architect to articulate and implement it :) I'm really glad to see that the market and customers are really reaching a point to understand and ask for the more subtle aspects of our products and APIs - it's rewarding to see! For the longest time most engineers just glazed over when we talked about a unified persistence mechanism (our website used even read that as our tag line).

If you want to see what we've done with EJB technology, have a look at our Distributed Transparent Persistence implementation for CocoBase. There's a free 30 day evaluation and PDF documentation for use with JBoss.

Have fun and happy programming :)

Just my $.02
Ward Mullins
CTO
THOUGHT Inc.
http://www.thoughtinc.com

As evolution of software engineering continues, it seems natural that we converge towards more abstract, high level mechanisms to develop systems.

Java has advanced a long way from assembly. J2ee is yet another evolutionary step which attempts to provide a higher level framwework, in which to build distributed systems ( more specifically client-server web-based).

What I find interesting is that generic distributed system architecture approaches have been attempted for years, long before java and j2ee - and it remains untackled. J2ee is a culmination of punctuated evolution to satisfy the needs of the
webserver model.

Jxta, Jini seem more appropriate for generic distributed systems.

I think that mobile agent systems are theoretically, the most appropriate architecture for the "system = network" vision.
Such an architecture is yet to be realised in a global sense.

going back to the mentioned approaches, what I like about Jxta
(im no expert, so I stand to be corrected) -
but it is platform/language independant which is definitely a plus.
my impressoin of Jini is that its over complex and has security issues
which have yet to be sorted out.

So in conclusion:
- j2ee is just a specialised architecture for client-server model
- there seems to be no generic, widely accepted model for distrubuted systems
- Jxta I would guess is the mentioned technology with most "potential"
- I would guess an agent approach could provide the most powerful, flexible,
generic glue to fit all distributed systems and specialised architectures together

> webserver model.
>
> Jxta, Jini seem more appropriate for generic distributed systems.

I would agree, J2EE is an endpoint, it is not really a truly distributed model, distributed models really are service oriented architectures. In most cases J2EE is still Hub and Spoke architecture, everything connects into the appserver and the appserver controls everything (transactions, security propagation, etc, etc)

> I think that mobile agent systems are theoretically, the most appropriate architecture for the "system = network" vision.
> Such an architecture is yet to be realised in a global sense.

On a practical level, agent systems can be written and deployed using the Javaspace model , where Entries not only have data, but implement the agent interface as well.

> going back to the mentioned approaches, what I like about Jxta
> (im no expert, so I stand to be corrected) -
> but it is platform/language independant which is definitely a plus.
> my impressoin of Jini is that its over complex and has security issues
> which have yet to be sorted out.

Jini is complex to you, J2EE is overly complex to me - (deployment descriptors, build a war,rar,jar,ear(?!?!?!?)) (however with the right tools, complexities like I've mentioned above do reduce). I've been using Jini for nearly three years, most of our integration infrastructure is built with it. It all comes down to the old adage - one man's meat is another man's poison.

BTW, Security issues - if you mean no security, I would take a look at Jini2.0 (on full release) this has more security options than you can shake a stick at. Including message integrity, transport security, encryption, message digests of downloaded code, as well as JAAS).However, it is even more complex than before, so get lots of coffee, be prepared to ask questions on the mailing lists, and take your time.

To the poster saying that you can only go through a firewall using JXTA, not necessarily, Jini 2.0 now comes with customisable exporters including HTTPEndpoints i.e. Port 80

Jini 2.0 adds all the stuff that RMI needed and far much more reducing the need for rmic at all, and dynamic configuration, which has been lacking in previous releases.

> So in conclusion:
> - j2ee is just a specialised architecture for client-server model

agreed - however _vendor_ extensions expand the architecture for a price, however you are still based on a static pre-known location model- no matter how many routers/clusters you put in, the client still needs to know your published address.

> - there seems to be no generic, widely accepted model for distrubuted systems

I would add that there shouldn't be, indeed cannot be.

> - Jxta I would guess is the mentioned technology with most "potential"
As a transport (although I'm not that close to JXTA, but pairing JXTA with Jini has been on my todo list for a while now)

> - I would guess an agent approach could provide the most powerful, flexible,
> generic glue to fit all distributed systems and specialised architectures together

The difficulty is the control and monitoring of an agent architecture, IMHO JMS should be replaced by agents, because at a primitive level, agents can represent messages but can also be so much more.

So we have a heavy calculation problem that requires 50 times more calculation power.
If every step in the solution depends on the result of the previous step then you really don't gain anything by having a distributed system.What you need to do is to get another algorithm that will produce similar results (or good enough results) with less processing power. Also processing power may be achieved by reusing the memory (variables) so the garbage collector will run less often or by having a machine 50 times faster.
If the problem can be distributed across 50 machines then let keep in mind that calculations depend just on the JVM + memory + processor etc... you are using and don't depend so much on the technology you are using to solve the distribution problem. The technology you are using to solve the distribution problem has a word to say in moving the data between processes. But if the data to be exchanged between processes is small, then I think that you don't gain anything by using one technology or another. If you have large amounts of data to be moved between processes then writing the data to a file and then FTP'ing the file may be the best solution. So again you don't have much to worry about which technology to use.
However, in using a technology or another there are some things you should consider :
- availability of developers with skills in that technology
- availability of tools and of documentation
- availability of support
- maintainability
and many other considerations
On the other hand I agree that I feel flooded with new technologies from SUN and I think that would be better if I can know quickly which one is intended for enterprise developers for example. A short description of every technology including intended usage may help. Case studies regarding the usage of the technology in the enterprise applications may help too.
So far, today the Grand Unified Theory of Distributed Applications for me is J2EE (EJB Container) and so far I haven't found problems that can not be solved with it.
I know something about Jini and I think that it has a lot of possibilities. If what I've read from the previous posts is true, it looks like JINI and JXTA are intended more to the companies that develop infrastructure software (like EJB containers). Am I wrong?

Adrian,

Very few calculations are linear (directly dependent). Using distributed processing, e.g. a grid of many systems, or a mega-cluster, you can not only process faster, but more cost-effectively. For example, we see companies replacing very large SMP Unix servers with racks of blades or 1U servers, and turning "overnight" calculations into almost real time calculations, and at the same time saving money on the system (large Unix systems can easily cost over US$5MM). At the same time, since the processing takes a much shorter period of time, more users can actually use the system, and more complex models can be simulated.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Easily share live data across a cluster!

Cameron,

What I was trying to say is that if 50 machines is the way to go , on every machine (out of 50) the calculation power will depend on JVM + memory + processors # + processor frequency etc... and the fact that you use J2EE or Jini or JXTA to solve the distribution problem should not have a big impact in decreasing the time of your calculation(some impact may have the threading model used by the 3 technologies). Because I feel that today J2EE is the most mature technology I said that this may be the way to go for most of us (application developers) to solve the distribution problem. However, since I feel that the author of the article has expertise in J2EE and JINI and JXTA, he can do a small proof of concept by using the 3 technologies and then he can see if there are any differences between them regarding calculation power. Maybe he can let us know his results.
I agree with you that very few calculations are directly dependent on the previous steps.