JSF, JPF, Struts, SDO小探

Question

一直对这几个概念不是非常清楚，一直对学习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的影子。
欢迎大家讨论。

Answer 1

都劳动高人了，荣幸荣幸。
在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，我等它成为标准。