Java distributed applications urgently need "big unified" theory

zhaozj2021-02-08  479

The status quo of Java is indeed confusing (or "freedom", huh, you can. The old saying "It is more than one way to peel the cat", Java once again verified this. For any purpose, you can have N (n usually greater than 3). There are two points in chaos: (1) It is more difficult to form an integral understanding; (2) select a higher cost. J2EE 1.4 put some commonly used characteristics (such as XML analysis, JAX-RPC) in the specification, I hope to help this status.

----------------------

Down on The (Compute) FARM

A Grand Unified Theory of Distributed Applications for Java

Van Simmons

June 19, 2003

Summary

Java IS in Need of a Sort of "Grand Unified Theory" for Distributed Applications. EJB, JINI, JXTA, AND JMS HAVE MORON THAN JUSTHELETER J, THOUGH You Wouldn't Know It from Reading The Specs.

So What Do you mean grand unified theory?

Last week, for the first time since 1998, I made it out to San Francisco for JavaONE. The intervening years have seen the crest of the tech wave that had only been building back in 1997 when I attended my first J1. The changed atmosphere of this edition produced a vague feeling that there was some thread running through the whole thing that I just was not picking out. Then, while listening intently to a conference session concerning a JSR with which I was totally unfamiliar, it dawned on me that my Unfamiliarity with the topic at hand. itself the key factory.

Back in '98, I felt that I understood Java as a technology There was no session that year that I could attend where I did not have at least a passing familiarity with the topic and some exposure to the API involved -. And I didn 't Consider Myself at All Special in That Regard. Javadoc and O'Reilly Books on Java WERE JUST The Stuff You Read in Your Spare Time if You Wee a Geek. But Things Have Changed Since Then.

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. Do not believe me? Try this - in one nice in a JMS topic. I've certainly tried it and the result somehow left me feeling stupid.My thesis for the next few posts to this blog will be that Java is in need of a Grand Unified Theory for distributed applications that would enable me to Write Just Such a List.

Let me assure you that I do not have the elements of the list predetermined and that I'd greatly appreciate feedback from the community on what I'm missing. (I should note that I derived a great deal of guilty satisfaction recently from hearing Some of the people 's.

Sounds pretty vague to me

This Particular Musing is not a hazy abstract for me. It is Directly Related To Problems I Face In A CURRENT Project And That I've Simply Got To Solve In The Coming Months.

I'm building out a compute farm for a coarse-grain, numerically intensive problem that has got to dramatically scale up. (I need at least a 50X increase in throughput over the current multi-threaded app). A distributed technology that allows me to quickly add new hardware at near-linear cost per compute cycle is the only way I see that we can make that happen. So I hope to be mixing blades, 8-way symmetric servers and maybe some desktops into the computational mix, scattering those resources across several different locations and trying to do it all on the cheap.I've already made certain technology choices, so I can at least begin to fill out my decision tree. Configuration, control and logging of the entire beast is going to be vested in objects living in a J2EE container, so that I can take advantage of JMX. Moving the computational tasks around is going to be a Jini / JavaSpaces responsibility. (marrying those two technologies in a reasonable way is the subject of much hacking at pre sent.) JXTA offers some interesting notions that I intend to explore for sharing spaces across sites. And finally, JMS is of interest because there could be real-time data which every computation will need to be aware of. How all of this eventually will Shake out is still onewhat mysterious to me, thing.

Okay, So Its One Interesting Facet of a Tiny Grain of Sand On The Computing Beach

I've read Jim Waldo's posts to this site with interest, because I agree with him that a) this sort of scalable, distributed application is going to a Very Important Trend in computing and b) this will require some form of mobile code. I 've certainly mistaken the problem I happen to be working on for the Gulf Stream of computing currents before, so I could be way off here - but if I am, this is still the most fun I've had writing code in a while. hopefully I can get some more details and thoughts posted in the next week or two. in the meantime, I look forward to hearing the thoughts of others on unifying Java distributed technologies into a broader framework.

Talk back!

Have an Opinion? Readers Have Already Posted 10 Comments About this Weblog Entry. Why not add yours?

RSS feed

IF you'd like to be notified whene Van Simmons Adds A New Entry to His Weblog, Subscribe to His RSS feed.

About the blogger

Most who've heard of Van Simmons before will remember him in his former role as President of VNP Software. Since 1990, Van has usually made a living architecting, designing, writing and generally being frustrated with large systems for Wall Street firms. Originally he hacked his way about these in Objective-C on the old NeXT platform, but starting in 1996, he realized that he was flogging a dead horse and transferred his allegiance to the (then) immature Java platform. These days, Van is an employee of a firm with a lot of numbers to crunch, so he's spending his days trying to figure out how to get an hours worth of computation done in a minute of elapsed time. Venting, musing and guffawing on this topic is what he plans to write about .

转载请注明原文地址:https://www.9cbs.com/read-714.html

New Post(0)