Java 和 J2EE 的企业应用：崎岖的蜜月之路（转）

Java 和 J2EE 的企业应用：崎岖的蜜月之路

如果你最近随手拿起一本 Java 的书（包括我自己写的书，罪过！罪过！），你几乎会被「企业应用（enterprise application）」或「Java 2 Enterprise Edition（J2EE）」等名词所淹没。似乎大家开口闭口都是 J2EE 以及企业应用的革命。许多人认为企业应用（通常是分布式架构）就是该用 J2EE 平台才能因应。
Lutris Technologies 是 Lutris Enhydra（一套开放原始码的 Java 应用服务器）的赞助者。我身为 Lutris Technologies 的员工，我深知这个问题。至少我们曾经听到有人问起「何时 Enhydra 会支持 J2EE？」或是「下一版的 Enhydra 会兼容于 J2EE 吗？」糟糕的是，人们似乎认为他们的应用一定需要 J2EE，他们认为企业应用和 J2EE 的联姻既完美且持久。让我当第一只乌鸦告诉你：其实蜜月之路遍布荆棘石块。

真正的需求与假性的需求
或许今日在建立企业应用所面临的最大问题在于「想要」和「需要」之间界线的模糊。常常，人们对于他们的应用系统过于狂热，我戏称他们为「buzzmania」。「buzzmania」指的是天性倾向于疯狂地买、疯狂地拿、疯狂地用的人，只因为产品上有着越来越多的「buzzword（行话）」。这也是 J2EE 所遭遇到的大麻烦。J2EE 产品描述和规格书读起来就像一堆超强技术的无敌组合，无怪乎在产品发表会上经理们个个听得热血澎湃。
但是，实际上，只有少数的公司和少数的业界需要用到全部的技术。我预估有 50% 到 70% 的公司只是白花钱购买 J2EE 的产品，其实他们的系统只要透过简单的 servlet 和 JDBC 来设计就绰绰有余了。将系统逻辑放在 servlet 内，再透过 JDBC 来存取数据库，这样对大多数的应用（包括电子商务）而言就已经够了。再加上使用 JSP 或是其它 presentation 的技术（比方说 Enhydra XMLC），整个系统就已经够稳固了。
但是，这样的做法到底有没有吸引力？如果你真的提供只使用 servlet 的阳春解决方案，而非豪华的 EJB+XML 方案，Sprint、Cisco、和 eBay 这些大户又会做如是想？他们的意见可能不多。如果你的计划能准时又符合预算，这些大户又会做如是想？他们可能当场乐翻天。你想想，只需要雇用 servlet 和 JDBC 程序员，而不用辛苦地找寻 EJB、XML、JMS 等技术的专家，省了时间，也省了预算。
那么，为什么这种方式不能近悦远来？因为许多公司不知道他们真正的需求是什么。对于每周营收不到百万美金的中小型的企业来说，EJB server 高昂的售价可真是要了他们的命。EJB server 提供了交易和安全管理，让高流量、高营收的网站可以省却不少麻烦，但是中小企业根本不需要 EJB server 的这些功能。
事实上，在小型网站使用这些 EJB 的服务非但无意义，甚至对效能有害。比方说，JMS 保证讯息的正确传递，但是大多数的程序员根本就不了解 JMS 所使用的「出版，订阅」和「点对点」服务到底是什么，更不可能知道应该什么时候使用他们。至于 XML，虽然使用者已经很多，但是 XML 是一种又大又慢的格式，不太适合用在许多地方。虽然 XML 可以提供资料的意义以便进行不同程序之间资料的交换，许多公司正使用 XML 当作沟通的工具，比方说：让 servlet 和 EJB container 在同一台计算机上沟通，这如果改用 Java 简单的 serialization 机制其实效能会大幅增加。
我再说一次，当开发企业应用时，一定要弄清楚业务和技术的「需要」而非「想要」。如果系统真的需要透过 HTTP 进行跨平台的沟通、需要讯息保证送达、需要支持许多笔交易（金融方面）、需要在五十个不同的服务器上执行，你们就需要使用 J2EE 的解决方案。但是，我也当了好几年 enterprise Java 的顾问，我碰过真正需要这样做的例子还不多。
我常常看到许多对技术一知半解的行销人员，在会议室对着没有需求的经理和程序员侃侃而谈那些技术，然后经理就真的买了在演示文稿中，他印象最深刻的那个高科技缩写字的产品。我们就来看看，什么是「想要」？什么又是「需要」？对于多数的人来说，J2EE 其实是想要而非需要。

一次购足，有必要吗？
一旦你浏览过这些夸大的广告词和高科技缩写字之后，你得到的印象是：J2EE 提供了一次购足的好处。换句话说，J2EE 的解决方案，可以完整地提供你在企业应用所需要的一切。许多人声称采用 J2EE 的原因是在为未来做打算。但是我们都知道结果不见得如此。
J2EE 还正朝着第一个统一的企业应用开发平台和 API 迈进，还没到达终点。让 J2EE 脱离 Sun 的活动正在进行，这说明了此点。请到 java.sun.com 看看，你会发现有一堆 XML 相关的规格和 API 正在开发，这全都是要用在企业应用上的。
这些发展无一是属于目前的 J2EE，这些技术或许会包含进下一版的 J2EE 中也不一定。由这点来看，J2EE 距离完备尚有一段日子。
除了和 XML 的鸿沟之外，J2EE 还有一些明显的漏洞，J2EE 中没有时间的观念，你可能觉得这又不重要，但其实不然。想象两台服务器和使用者互动 100,000 股的线上股票交易，如果此二服务器的时差是 30 秒，百万美金可能就飞了。如果服务器是三十台而非两台，有百万用户，你能想象这会是多大的混乱吗？
分布式系统的时间服务兹事体大。因为缺少计时功能，完整的工作排程也不能进行，所以在 J2EE 中付之阙如。J2EE 整体都还是架构在「要求与响应」的事件模式，某些骇客甚至可能以 JMS 入侵服务器。
管理也是 J2EE 的一大难题。虽然 JMX（Java Management Extensions）是一个管理的 API，但目前并非 J2EE 的一部份。你可以叫你的老板买一套所费不眦的 J2EE 解决方案，然后在他需要管理功能时，嗫嗫嚅嚅地告诉他这需要再买另一套也是很贵的产品，等着被老板修理。为何 JMX 的进展步履蹒跚，JMX 的出现甚至早于 J2EE 呢！使用一个不成熟的平台，搭配一个更不成熟的管理 API，你真得要这么做？你可得想清楚。
你可以看出 J2EE 平台确实还有一些缝隙待填补。软件使用授权、组件版本、安全性、系统日志、metadata... 这只是主要尚未解决的问题其中几个。不要误以为目前版本的 J2EE 是一个天衣无缝的完美解决方案。

本文的寓意是 ...
到底本文要表达的是什么？难道本文想告诉你的是 J2EE 根本是浪费时间的玩意儿？不！我绝对没有这样的意思。事实上，我们公司的 Application Server 产品也快支持 J2EE 了，我只是认为 Application Server 厂商不该拿这些夸大不实的信息来作为行销主轴。虽然许多人都知道采用 J2EE 是很重大的决定，但还是有许多人宣称 J2EE 是完美的解决之道，是万灵丹。如果真是这样，根本就没有必要开发 Enhydra XMLC、Apache Cocoon、SOAP、以及其它非 J2EE 技术。
你应该用 J2EE 吗？有可能，也有可能不。再说一次，你必须先考虑你的业务需求。如果你只有 1000 个顾客，你只是提供 100 网页给他们，那么使用 J2EE 只是浪费时间和资源，去买本 O'Reilly 的 Java Servlet Programming（Jason Hunter 所着），省下使用 J2EE 所要伤的脑筋吧！如果你经营的是世界最大的银行，情况可就完全不同了，你最好准备使用 EJB 和 XML，来接受迎面而来的大量业务，但虽然此时 J2EE 有必要，执行起来倒也不见得完全都如你所预期。不要以为照着 Sun 的「宠物店」范例来如法泡制就能完万事顺利，毕竟一两个范例无法教会你 J2EE 的一切。

所以，睁大眼睛，认清事实：

「企业应用」不等于「J2EE」，而且「J2EE 」不等于「一劳永逸」
上面这段逆耳的忠言，或许可以让你省下大笔花在软件购买和建置的浪费。水可载舟，亦可覆舟，你得认清你的需求再决定使用哪些技术。虽然 J2EE 和企业运算可以成功，但要称他们是佳偶天成之前，还是有一些问题需要先解决。

本文作者：Brett McLaughlin（着有 O'Reilly 出版的 Java and XML）
本文译者：蔡学镛

很久以前读过这篇文章，今天重读，又有了一些新的理解。Brett McLaughlin 先生和我们设计这个中间件的想法是非常接近的。
我们已经听到过太多的 Marketing Hype，然而 J2EE、WebService 所许诺的美好世界始终没有出现。今天让我们正本清源地坐在这里好好想一想，企业采用 IT 技术到底想要得到什么？
WebService 这些东西真的就是软件企业所需要的核心技术吗？如果你没有一点透过现象看本质的能力，那么总有一天会被 M$、IBM 这些 Software Giant 玩死的。

适可而止是好的设计人员的素质，也是非常难达到的一个境界。所以 Martin Fowler 大师专门写了一篇文章“设计已死”来讨论很多设计过程中的策略取舍以及如何通过一系列的技巧（单元测试、持续集成、重构）来避免过度设计。
http://www.agilechina.org/MartinFowler/isdesigndead.htm
另外 Martin Fowler 大师的另外两篇文章“持续集成”和“新方法学”也可以在敏捷中国的网站上找到。
http://www.agilechina.org