折腾了一把JAX-WS, SOA & Java EE 5（part 3 of 3）

６，ClassLoader 与打包部署 .ear
了解一下服务器的ClassLoader的结构及工作步骤有助于正确打包和部署。一般来说，不同组件的ClassLoader
一般也不尽相同。ClassLoader的树状结构的最顶端是jvm的ClassLoaders。如Boostrap class loader,
extention class loader, system class loader等等，用来装载 jre/lib/rt.jar,jre/lib/ext/*.jar
及$CLASSPATH上的资源。接下来是服务器的ClassLoader，用来装在服务器的资源，如lib等。接下来是应用的
ClassLoader（application class loader），每个应用的ClassLoader各不相同。这个应用ClassLoader直
接负责装载我们的应用的代码及其它资源。Application Class Loader 一般又分为ejb class loader和war 
class loader。后者在最低下。

据说这些class loader在装载资源时，总是试图向其上一级的class loader请求，看看是否已经装载过了。如
没有装载过，该class loader才会自己去搜寻装载。

这就意味着一个基本的打包原则：war中的资源对ejb来说是不可见的；而ejb中的资源对war中的客户是可见的。
因此当打包成ear时，通用的资源应放置在根路径下，如我们由Schema产生的类型及共用的utility classes等，
应打包成common.jar，放置在.ear的根目录下。这样，这些资源对整个应用来说就是可见的。与其平行放置的其
他组件是：META-INF，ejb.jar，webapp.war，client.jar。他们各自的目录结构不再?嗦。

由于annotation的使用，各种descriptor的配置就不是必需的（可能META-INF/application.xml除外）。

这里有张图，有助于理清这些descriptors'角色与位置：
http://docs.sun.com/app/docs/doc/819-3660/6n5s7klp9?a=view#beacw

如part 2中所提，对web service来说，POJO通过annotation的方式搞成Web Service，该POJO应打包在.war中；
无状态EJB通过annotation的方式搞成Web Service，该ejb应打包在ejb-jar中。

７，客户程序的选项及系统集成
简单提一句话，如果我们的业务逻辑采用Schema定义，然后通过jaxb绑定来产生必要的源代码，并由此来实现业务
要求的话，整个系统的分层就更细了。而供客户程序的选择余地会更大：客户可通过ejb,web service, jms等方式
来与该系统互动，应该是不错的SOA结构了。而web service, jms则提供了较好的系统集成途径。

毛病就是一旦Schema需要改动，jaxb绑定要重新来过。倒是可以通过ant等实现自动化。

另一个问题是这种机构的项目，对开发团队的要求是较高的。


８，两本Java EE 5 书籍读后感
(a) Enterprise JavaBeans 3.0 (5th Edition) 
针对Jboss，有较详细深入的介绍。

(b) Java EE 5 Development using GlassFish Application Server 
针对GlassFish，简明扼要，入门介绍。

不足之处，敬请指教。