EJB 完全引错了路——论企业应用的核心问题

to:jini

大厂商和大厂商也许是不一样的。先了解一下BEA的SOA去...

面对一个事实会有不同的认识.在BEA发展的道路上的分歧就是一个例子.
其实在我看来BEA在逐渐的淡化EJB容器提供商这个形象,也在逐渐减少在EJB上的投资.他们的下一个目标在于门户和EAI.这一点和IBM的情况基本类似,也就是他们通过几年的销售发现还是直接面对终端客户比较好.而SOA则是一个既面对终端又面对软件开发者的概念,也就是说IBM和BEA都希望通过使用这样的一个技术来整合自己的技术,从而可以使其产品的销售能够做到持久而更加封闭(和他们声称的相反,使用SOA会让你的所有工作更加依赖于一个SOA的Architecture,更加服务于一个Architecture,更加加强一个Architecture).实际这就等于用Architecture在客户的应用方面定下一个技术围墙,并且贴上非我族类请勿接近的标语.实际上任何一种Architecture都有这个问题.
而Webservice得普及带来的SOA其实非常可能破坏这种很有生机的技术----我觉得IBM和BEA共同炒作的SOA是在向MS现在准备进军他们的市场作出的竞争性措施,很有可能会随着使用SOA从而把现在统一的一个有w3c维护的标准,变成有一个由事实的商业标准转化的标准.这样的标准实际上根本就没有遵守的必要,或者说你在这样的标准说投资越多,最后你死得就越惨.典型的例子大家可以看看MS是怎么来玩OLE这个玩具的.而java社区和ms社区的差别会造成如果java社区的什么人也如同ms那样搞一次标准游戏,死得就不是简单的几个工具提供商会死去,而是一群软件开发公司和客户的应用共同的完蛋.而这样的前兆已经在IBM和BEA在同SUN争夺java控制权的时候发生了.
返回来说EJB的标准.大家都在说EJB是一个标准,应该尽量的遵守这个标准.可是我怎么觉得EJB仅仅只是IBM的标准,BEA的标准,SUN的标准,JBOSS的标准呢?你说你遵守了EJB的标准,但是怎么体现呢?有什么好处呢?是真的一次编译到处运行吗?或者退而求其次是一次编写到处运行?或者再退做到一个编写到处都可被调用吗?现在的情况就好像当场的unix大战,标准很好,但是遵守标准的人最后都死去了.
标准这个东西也要看,不是是一个标准你就要去遵守,如果一个标准明显带有快速前进并且是高度依赖于个别厂商的标准,干脆就别去遵守.这个时候你遵守标准带来的风险要比你不遵守标准带来的风险大的多.

这里讲的“标准”大概是“普及、被广泛使用”的意思，我猜EJB的发明者一定是希望EJB能像VB一样成为“标准”，而看看目前的状况，好像其目的也基本上达到了，至少项目经理们和客户都已经认同了这个“标准”。Java这东西就是需要时间去琢磨、去领悟，再也不像VB/PB时代写程序就像吃快餐一样快捷、方便、简单，可惜我们现在才醒悟过来，已经太晚了，现在想不EJB都难了！

dear robbin

我不認為你了解 SOA.
作了這種批評真的令我驚訝你堅守的客觀立場

http://www.middlewareresearch.com/soa-blueprints/industry.jsp

或許你研究之後
我們再來討論 SOA 對於 enterprise 有沒有任何意義
到底是不是被鼓吹起來的技術泡沫

to jini：
这个关于SOA的问题，就跟你前面对EJB的态度一样。EJB有没有价值？web service有没有价值？它们有，我们大家都知道。问题是，EJB是不是像很多广告吹嘘的那样可以一统天下？SOA是不是像这些文章吹嘘的那么革命性？很可疑，实际上照我的理解答案就是否定的。别忘了我们这里不是要向不懂技术的CEO们宣传，我们自己都是IT的专家，web service有什么价值我们都清楚，要是SOA不能让我们看到更多的价值，那我们就得说它是个hype。对于那些没用过web service的开发者，SOA确实很有价值；但对于我们这些用web service做过一大堆项目的人，SOA就只能当热闹看看了。

目前 SOA Spec 只有 0.5 版
BEA 也不過推出 BETA 的實作
你就已經看到他的未來
真是厲害
我真的是很佩服你們

我没看到它的未来，我只看现在。今天它提供不了任何超越我现有web service架构的东西，我就说它是个hype；明天它提供了好东西，那它明天不再是hype，但它今天仍然是。难道你看待一个技术不是这样的吗？

你不用佩服我们，我们只有一条：实事求是。

嗯

請問 "SOA 提供不了任何超越我现有web service架构的东西"

這句話會不會是因為你對 SOA 的了解不夠深入 ??
還是 你現有 web service 架構的東西 已經包含了各式各樣的考量 超越了 SOA  ??
我不是你 我不知道 我也不想詆損你
我只是覺得要批評一個技術 要徹底了解該技術
你實事求是 讓我覺得更是敬佩

我不懂SOA，但看这样下去不免又要争吵起来，现在gigix提出的观点如下：
现有的SOA提供不了任何超越我现有web service架构的东西，我就说它是个hype。

jini若要反驳，请举出实例，如果gigix现有web service架构的东西不包含你所举出的实例，便算你有道理，上一个回帖没有意义。

[quote="Better, Faster, Lighter Java By Justin Gehtland, Bruce A. Tate
"]It never ceases to amaze me how often the simplest answer turns out to be the best one. If you're like the average J2EE developer, you probably think you could use a little dose of simplicity about now. Java complexity is growing far beyond our capability to comprehend. XML is becoming much more sophisticated, and being pressed into service where simple parsed text would easily suffice. The EJB architecture is everywhere, whether it's warranted or not. Web services have grown from a simple idea and three major APIs to a mass of complex, overdone standards. I fear that they may also be forced into the mainstream. I call this tendency "the bloat."

Further, so many of us are trained to look for solutions that match our predetermined complicated notions that we don't recognize simple solutions unless they hit us in the face. As we stare down into the creek at the simple database problem, it becomes a blob of EJB. The interfaces become web services. This transformation happens to different developers at different times, but most enterprise developers eventually succumb. The solutions you see match the techniques you've learned, even if they're inappropriate; you've been trained to look beyond the simple solutions that are staring you in the face.

Java is in a dangerous place right now, because the real drivers, big vendors like Sun, BEA, Oracle, and IBM, are all motivated to build layer upon layer of sophisticated abstractions, to keep raising the bar and stay one step ahead of the competition. It's not enough to sell a plain servlet container anymore. Tomcat is already filling that niche. Many fear that JBoss will fill a similar role as a J2EE application server killer. So, the big boys innovate and build more complex, feature-rich servers. That's good梚f the servers also deliver value that we, the customers, can leverage.

More and more, though, customers can't keep up. The new stuff is too hard. It forces us to know too much. A typical J2EE developer has to understand relational databases, the Java programming languages, EJB abstractions, JNDI for services, JTA for transactions, JCA and data sources for connection management, XML for data representation, Struts for abstracting user interface MVC designs, and so on. Then, she's got to learn a whole set of design patterns to work around holes in the J2EE specification. To make things worse, she needs to keep an eye on the future and at least keep tabs on emerging technologies like Java Server Faces and web services that could explode at any moment.

To top it off, it appears that we are approaching an event horizon of sorts, where programmers are going to spend more time writing code to support their chosen frameworks than to solve their actual problems. It's just like with the cement mixers in Mexico: is it worth it to save yourself from spending time writing database transactions if you have to spend 50% of your time writing code supporting CMP?

Development processes as we know them are also growing out of control. No human with a traditional application budget can concentrate on delivering beautiful object interaction diagrams, class diagrams, and sophisticated use cases and still have enough time to create working code. We spend as much or more time on a project on artifacts that will never affect the program's performance, reliability, or stability. As requirements inevitably change due to increasing competitive pressures, these artifacts must also change, and we find that rather than aiding us, these artifacts turn into a ball, tied to a rope, with the other end forming an ever-tightening noose around our necks. There's a better way.

A few independent developers are trying to rethink enterprise development, and building tools that are more appropriate for the job. Gavin King, creator of Hibernate, is building a persistence framework that does its job with a minimal API and gets out of the way. Rod Johnson, creator of Spring, is building a container that's not invasive or heavy or complicated. They are not attempting to build on the increasingly precarious J2EE stack. They're digging through the muck to find a more solid foundation. In short, I'm not trying to start a revolution. It's already started.
和ozzzzzz的观点一致，论述的很精彩。最近比较忙，没时间译了，抱歉。