JSF, JPF, Struts, SDO小探

eTony

原文：http://www.javaresearch.org/arti ... 23&thread=21531
一直对这几个概念不是非常清楚，一直对学习JPF心存疑虑。这几天，花了一点时间，大致上看了一下这几个东西的文档，有了一点收获，和大家探讨一下。

Struts：不用多说，大家都非常熟悉了。

Service Data Object(SDO)是JSR235讨论的一种简化数据访问的结构。在Web应用中，可以使数据源对开发人员透明。

J2EE标准的Java Server Faces(JSF)，BEA的JPF，都是基于Struts的，那么有一些什么区别呢？

JSF 更多的是关注于页面的表现，很多结构和Struts非常相似。事实上，JSF的操刀者正是Struts的作者。可以在JSF中非常明显地看到，设计思路是在Struts上的提高和完善。比如，在Struts中，ActionForm事实上就是一个Bean，储存了数据。在JSF中，直接引入了 Managed-Bean的概念，这些储存有数据的Bean可以直接放到页面上，这些Bean由程序员完成，美工只是直接把BEAN拖放到页面上，这样，进一步分割了Model和View，简化了开发过程，更加便于协作开发。

BEA的JPF更多地注重页面和数据的绑定。事实上，绝大多数的动态Web页都涉及到数据的读取和存储，JPF封装了大量的数据绑定功能，也简化了这一类的开发。

从IBM的红皮书上可以看到，现在IBM的所有涉及到JSF的例子，都用了WDO(WebSphere Data Object)。我的理解，这是SDO的一种。事实上，SDO还只
是处于JSR状态下，IBM实现了部分的SDO规范的功能。在IBM的例子中，可以看到，通过JSF和WDO/SDO，页面可以很容易地绑定数据，显示数据。

这一点，和BEA的JPF有异曲同工之妙。巧合的是，JSR235 SDO规范专家组的领头人正是BEA和IBM。

由此，我得出如如下的结论：
1、JPF是基于Struts的，将来会基于JSF
2、JPF和Struts/JSF不是一个层面的东西，JPF是比后两者更高级的框架
3、JPF在某种程度上，是BEA的SDO实现，将来的SDO正是规范中，必将有JPF的影子
4、虽然IBM现在在热推JSF，但是其红皮书中承认，JSF目前还是非常新的技术，并不完善，还有待于得到广泛的支持。Apache正在开发JSF-Struts库，
以便于Struts到JSF的迁移。所以，现在不必急追JSF，有了扎实的Struts知识，迁移到JSF不会太困难
5、学习JPF是安全的，（这和我以前的观点不同，以前对于JPF了解不深刻，向BEA致歉），将来的SDO会有JPF的影子。

BEA致力于简化J2EE应用的开发，致力于可视化开发J2EE应用。JPF屏蔽了后台的实现，看上去更漂亮、更简单了。
但是，另外一个方面，这样一来，对程序员，尤其是新手会带来意想不到的麻烦。
由于JPF屏蔽了后台的实现，程序员实际上是在和BEA提供的API交互，虽然其实质仍然是Struts，仍然是标准的技术，但是程序员看到的和写的却是BEA独有的TAG。
如果，当程序员需要开发Tomcat+Struts上的应用，或者就是WebSphere上的应用的时候，他就会迷惑。因为他需要用到截然不同的API，工作方式完全不同。在WLW中可以DnD拖放，很方便。但是到了JBuilder或者WSAD里，就不是这样了。JDJ上有一个人抱怨Workshop，原文记不得了，大意是“什么都是可视化的，都从前门进出，你都不知道屋子里有什么？”
所以，增加了程序员跨平台变成的成本。如果使用标准的方法，即只使用JSF，那么跨平台就比较容易了，至少遇到的TAG都是一样的，对象方法也都是一样的。但是，这样，就丧失了WLW开发的便利性。

看来，WebLogic上要真正成为一个优秀的程序员，还得有一套JBuilder之类的传统IDE，标准的技术一定要学，然后再学习BEA的技术。就像练剑要先练气的道理一样。

我过去是在WebSphere上做的，IBM的东西的特点就是复杂。其实，是因为讲解得比较深刻。我学EJB的时候，看《EJB 2.0 Development with WSAD》，那本书里面，有一大半是讲解EJB规范、概念、方法，极其枯燥。到了后面一半，才结合 WSAD讲解实际开发。
看的时候，的确累。但是看完后，受益匪浅。后来在JBuilder上做EJB，觉得极其容易，看了一下JBuilder的文档，怎么用那个EJB Designer就行了。花了15分钟的样子。
但是，换一个角度，如果仅仅看了WLW开发EJB的例子，换到JBuilder上，就没那么快了，就被IDE绑死了。
这就是为什么很多新手，老是喜欢讨论JBuider好，还是Eclipse好，或者IDEA好的道理。有经验的程序员是不会问这些问题的，他们要问的是，"xxx功能在那个菜单里"、“xxx源代码在那个目录下”。

所以，WLW的快速开发，适合于有很强J2EE功底的程序员，在项目中需要快速开发的时候；而对于学习者，还是老老实实，从规范开始，从《Mastering EJB》开始，装一个JBuilder或者Eclipse+Lomboz，老老实实从写代码、写配置文件开始。用WLW学习EJB 或者Struts，很容易迷路的。

在JPF刚出现的时候，就得知BEA非正式地提供了可以迁移到Tomcat的工具。凭借BEA的实力，我毫不怀疑，将来的Java Control和JPF等，都可以顺利地移植到Tomcat或者WAS上运行，甚至连运行库都不需要，直接翻译成标准的 Servlet代码。这是完全可行的。

我前面所说的都是从程序员开发的角度谈，不涉及运行时兼容的问题。Beehive把 Workshop Runtime开源了，大家都可以来研究了，非常有利于Workshop的推广。但是，并不是开源的东西一定可以成为标准，承认吗？ Tapestry也很不错，也是开源的，但是偏偏Struts最为市场接受，成为了事实上的标准。

我们是不是不能排除这样一种可能， Beehive开源了，也在一定程度上被广泛接受了，但是就是没有成为标准。成为标准的是JSF+SDO，假设这样。那么，作为程序员，我就有风险了。我花了时间精力，学习了Workshop Framework，也很精通Java Controls了。我毫不怀疑，我写的程序，可以被deploy到任何 J2EE兼容的App Server上去。

另一方面，移植的过程是很复杂的，谁都不能保证移植的程序100%可运行。但是客户的平台是多样化的，出于以后维护的考虑，比如客户是小公司，一直运行Tomcat，他的维护工程师只懂JSP/Servlet/Struts，不懂JPF，那么为了维护，他也希望我用他懂得技术开发。即使我的JPF应用顺利部署到他的Tomcat上，他对今后他将面对的维护也会有畏惧。我总不能强迫他学JPF吧。
而且客户，都有一种惯性。用惯了.NET的，你向他推荐J2EE都很困难；同理，如果向他推荐非常先进的JPF，客户未必接受。

我，作为程序员，有交流的问题。比如说，JSP/Servlet，只要是J2EE程序员，大家都懂。无论在Team内部，还是到dev2dev， developerWorks, TSS上，大家都用同样的语言，JSP/Servlet规范和相关的术语。同样的道理，Struts由于是事实上的标准，也是可以被无障碍交流的，大家都懂ActionForm, ActionServlet。但是，只要Workshop一天没有成为标准，就有可能成为一种外语。我在BBS上跟人讲，NetUI:XXXX，不是人人都懂，我讲JCS,JPF，别人就未必懂。我只能到dev2dev,找你Hilaser请教。

其实，我认为，标准的含义对我而言，就是方便与人交流。UML语言诞生的初衷也是为了交流。虽然，大家都知道，JPF的底层就是 Struts，但是偏偏封装后，名字改了，虽然都是巧克力，但是你说它叫“朱古力”，可我只知道他叫“巧克力”怎么办？那就要求我必须同时懂得 Struts和JPF，自己给自己翻译了。或者用工具，把JPF转换成Struts，然后拿着机器生成的Struts代码和人讨论？

谈到这里，所有问题的根出现了，那就是
   *****************************************************
   * BEA是否有足够的实力，把自己的专有技术推广成标准 ? *
   *****************************************************
是要所有的人都接受，成为标准；而不仅仅是开源。

这里有太多的非技术因素。且不说BEA的股价，庞然大物如IBM或者Oracle的态度。作为客户，他是否愿意押宝在BEA身上，明确BEA的JPF等技术就是将来的J2EE规范呢？恐怕比较难。即使庞大如IBM，客户也不会下这种赌注。客户一般都喜欢用成熟的技术。EJB2.0的规范出现是在哪一年？看看 EJB2.0开始广泛运用又是在哪一年？

这也是，WebLogic这么多年来备受青睐的原因，因为他的技术最标准。所以，我的建议是，在 JPF明确成为事实上的标准前，还是持观望态度比较合适。因为JPF和基于J2EE规范的不同Implementation不同，JPF的API是独特的，事实上一个程序员如果只精通JPF，而不懂Struts和JPF的关系的话，那他就真的被绑在BEA上了。对于Struts、JSP/Servlet 群来说，他是一个外星人。那么用漂亮的Workshop开发JPF的人，又有多少会想到去了解底层的Struts呢？

其实，BEA为什么要重新搞一套特殊的API呢？Struts的不足，可以在保留Struts API的基础上，进行扩展，没有必要全部改头换面。保留Struts API的TAG要省多少事啊，再加上BEA的扩展，不一样可以吗。为什么全部换掉呢？

JPF的技术真的不错，但是，我只了解大致原理，我不去看具体的语法API，我等它成为标准。