J2EE首先是一种构架。它包罗了Java的多种先进的技术,最合适使用MVC的方法来构建系统,其表现层使用JSP,控制层可以使用Servlet或Session Bean,用于实现业务逻辑,Entity Bean则对业务实体进行抽象。此外它还使用JAAS实现安全机制,JNDI用于查询资源,JDBC和JTA访问数据库和管理事务;JMS实现企业的消息处理;JavaMail实现与企业外界的联系,不一而足。
要正确理解并设计J2EE的应用,应该树立以下的观念:
1.Professinal,每个参与者都应该是专业的专家。大的概念是容器提供商提供专业的容器及服务,部件提供商提供专业稳定的部件及服务,应用系统提供商对于单个的系统应提供专业的应用系统。从小的方面来说:JSP页面设计师是专业的,Servlet开发工程师是专业的,EJB开发工程师也是专业的,部署人员也是专业的。设计人员也是专业的。这是由于一个人的精力是有限的,一个项目是由团体人员通力合作的结晶,每个人应该对自己负责的部分非常专业,也可以这样说,J2EE并不太认同每个人都是通才、全才的想法,而是认为每个人应该是老老实实的软件蓝领,但在自己的领域中是出色的专业蓝领。
2.Configration,有人认为在项目中使用J2EE有n多的风险,说什么配置起来很复杂,很花费时间。其实,这种说法本身就是没有理解J2EE的一个重要的特性,即配置性。J2EE的配置主要由XML文件来完成,有ejb-jar,weblogic-ejb-jar,rdbms等等配置,正是由于这此配置,EJB的重用才成为可能性。而这些配置其实也有很多的工具可以用于辅助工作的。
3.任务简单化,真正在项目中运用过J2EE的人会发现,写EJB是容易的,而布署EJB应用也是容易的,写Servlet/JSP也不难。当然系统的设计是难一些的。这也正切合将大问题进行细分,符合分而治之的道理。
4.重用性。部件的重用一直是软件界的难题。J2EE的EJB如果设计得好,在以后的项目、应用系统中是可以重用的,这也包含供他人/自己重用,以及重用他人的商业化构件。
5.通力合作,沟通最难。在一个系统的实施过程中,什么问题最难,不是纯技术上的难,假以时日,当你的技术水平上升到一定程度时,您会发现,日新月异的技术专有名词不过是一些类似的、或似曾相识的名词的转换或迁移。我的一位同事很久以前就曾扬言,只有想不到的,而没有他做不出来的。我在一定程度上赞同他的话,如果不考虑时间限制,人力财力,诚然。什么问题难以解决?沟通问题是也。沟通包含客户-需求人员-分析人员-设计人员-编程人员-布署人员-计算机之间的迭代沟通。J2EE并不能解决这个问题,但是它要求参与的人员是Professional的,相互之间的沟通是有界限的,也就是设计中常说的接口界面。这在一定的程度上可以避免相互之间的紧耦合。
我知道本文可能会令一些软件精英耻之以鼻,不过我还是认为真正沉下心来作专业软件蓝领的人太少,如能多些这样的人,中国软件赶印超日的可能性才会来到。