Java分布式应用迫切需要“大统一”理论

原创 2003年06月24日 09:04:00
Java的现状的确是混乱(或者叫“自由”,呵呵)得可以。老话说“给猫剥皮不止一种办法”,Java再次验证了这一点。为了任何一个目的,你都可以有n(n通常大于3)种办法。混乱的代价有两点:(1)更难形成整体性的理解;(2)选择成本更高。J2EE 1.4把一些常用的特性(例如XML解析、JAX-RPC)都放到了specification里,希望对此现状有所帮助吧。
 
——————————————————————
 
Down on the (Compute) Farm
A Grand Unified Theory of Distributed Applications for Java
by 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 more in common than just the letter 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 wasn't 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 was itself the key factor.

Back in '98, I felt that I understood Java as a technology. There was no session that year that I could attend where I didn't 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 were 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. 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.

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 don't 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 who wrote the APIs mentioned above say that they really weren't able to make such a list either ).

Sounds pretty vague to me

This particular musing is not a hazy abstraction 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 present.) 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 somewhat mysterious to me, though.

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 whenever Van Simmons adds a new entry to his weblog, subscribe to his RSS feed.

About the Blogger

CSDN_Dev_Image_2003-6-24844201.jpg 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.

This weblog entry is Copyright © 2003 Van Simmons. All rights reserved.

hadoop学习笔记之二:分布式系统中的CAP理论

from:http://divinedm.iteye.com/blog/2252845 首先,CAP理论描述的对象是一个分布式系统,其中  C:从客户端来的读请求访问任何一个分布式系统节点,一...
  • basycia
  • basycia
  • 2016年11月02日 18:04
  • 600

分布式系统的思考及CAP理论

在讨论常见架构前,先简单了解一下CAP理论: CAP是Consistency、Availablity和Partition-tolerance的缩写。分别是指: 1.一致性(Consistency)...
  • lavorange
  • lavorange
  • 2016年09月09日 20:36
  • 2591

分布式CAP理论的理解.

分布式系统:部署在不同的节点,通过网络通信实现协同工作。 CAP理解: C:Consistency, all nodes see the same data at the same time;强一...
  • jasonsungblog
  • jasonsungblog
  • 2015年10月10日 07:28
  • 789

分布式理论基础

一、什么是分布式? 分布式就是计算机之间的分工与合作 例如:对应现实世界中,针对某项任务,我分给一个人干还是一群人干产生的效果也是不同的,一群人干肯定要比一个人干要快的; 和计算机一样,在计算机内部首...
  • Afa_zhang
  • Afa_zhang
  • 2017年06月13日 20:44
  • 145

java中的分布式应用(一)之分布式介绍

分布式概念 要理解分布式系统,主要需要明白一下2个方面: 1.分布式系统一定是由多个节点组成的系统。 其中,节点指的是计算机服务器,而且这些节点一般不是孤立的,而是互通的。 2.这些连通的节点上部署了...
  • zzjstudent
  • zzjstudent
  • 2016年08月23日 11:02
  • 24400

我的读书笔记--关于java分布式应用

最近因为有Java分布式应用的需求,因此,我搞到了林昊的《分布式Java应用基础与实践》(以下简称F)这本书。我决定花2个月时间,把这本书仔细研读一下,好好学习,多多实践。另外,我会把自己的读书心得、...
  • lxlhu
  • lxlhu
  • 2015年03月24日 20:16
  • 752

JAVA分布式事务原理及应用(转)

JAVA分布式事务原理及应用(转) 引言   JTA(Java Transaction API)允许应用程序执行分布式事务处理--在两个或多个网络计算机资源上访问并且更新数据。JDBC驱动...
  • wangxin1982314
  • wangxin1982314
  • 2016年03月01日 15:23
  • 3738

分布式系统之----CAP理论

分布式的优点是大大的,最明显的就是可以同时处理很多事情,可以同时响应很多请求。 分布式的缺点也是大大的。 机器之间需要花费不少时间精力来沟通,这就是分布式的缺点。 沟通到机器认识在一...
  • dotedy
  • dotedy
  • 2016年01月13日 20:15
  • 466

分布式下必须要知道的CAP理论

CAP理论 CAP(Consistency一致性、Availability可用性、Partition-tolerance分区可容忍性)理论普遍被当作是大数据技术的理论基础 分布式领域CAP理论...
  • king866
  • king866
  • 2017年02月19日 16:26
  • 816

科普一下,什么是分布式架构设计中的CAP原理?

大家在看书或者参加会议的时候,对于数据架构设计的时候,一定经常听到CAP原理,比如根据CAP原理,对于分布式设计系统,只能做到数据的最终一致性而不是实时事务的一致性;那么,这些行家或者架构师常挂在嘴边...
  • chancein007
  • chancein007
  • 2016年12月18日 23:03
  • 2299
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Java分布式应用迫切需要“大统一”理论
举报原因:
原因补充:

(最多只允许输入30个字)