Websphere Community Edition 部署架构简介

摘要 : 本文介绍了 WAS CE 服务器部署模块的结构, 并以部署一个 WAR 为例, 在部署过程中解析执行的过程.

 

1.       部署概念简介

 

    实际的 JEE 开发中, 用户最终打包后的应用程序可能是多种多样的, 复杂的可以是一个 EAR 包, 里面包含了 WAR 模块, RAR 模块, EJB 模块等. 也可能只是一个 WAR 包, 但是里面可能包含一些 Web Service 的应用或者对其他 EJB Bean 的引用. 那么在部署时, WAS CE 服务器能够解析和处理的这些各式各样的应用, 完全得益于其灵活的部署插件架构.

 

2.       WAS CE 部署架构简介

 

a)        WAS CE 中部署组件的结构图

 

 

b)        Deploye GBean

 

    WAS CE 中, 无论是在命令行还是在控制台部署, 最终都是 Deployer 这个类执行部署工作. 可以说, 它是所有应用部署的入口, 第三方应用同样可以通过在内核中获取该对象的应用来向 WAS CE 服务器中部署用户程序

 

c)        ServiceConfigBuilder/EARConfigBuilder

 

    这两个类都实现了 ConfigBuilder 接口, 该接口中有三个关键方法

 

1. Object getDeploymentPlan ( File planFile, JarFile module, ModuleIDBuilder idBuilder ) throws DeploymentException;

       Deployer GBean 通过调用该 Builder 的 getDeploymentPlan 方法来判断当前的 ConfigBuilder 能否对用户程序进行解析

 

2. Artifact getConfigurationID ( Object plan, JarFile module, ModuleIDBuilder idBuilder ) throws IOException, DeploymentException;

       该方法会为当前部署的应用生成一个唯一标识, 在 WAS CE 服务器中, 所有的应用都有一个 Artifact 唯一标识

 

3. DeploymentContext buildConfiguration ( boolean inPlaceDeployment, Artifact configId, Object plan, JarFile module, Collection configurationStores, ArtifactResolver artifactResolver, ConfigurationStore targetConfigurationStore ) throws IOException, DeploymentException;

       Deployer GBean 通过调用 buildConfiguration 方法, 完成对部署应用的解析, 在返回的 DeploymentContext 中, 包含了该部署应用的所有解析后的信息, 比如对受管理类的注释的解析, 对一些资源引用的解析等

 

    WAS CE 应用服务器提供了如图所示的两个 ConfigBuilder 的实现, ServiceConfigBuilder 是对 WAS CE 提供的包含 geronimo-service.xml 的模块部署的支持. 而 EARConfigBuilder 则提供所有符合 JEE 标准的应用程序的部署的支持.

 

d)        EJB Builder/Connector Builder/WAR Builder/Client App Builder

 

    在 JEE 标准中, 一共定义了五种标准应用程序包, 分别是 EAR (企业应用程序包), RAR (资源适配器包), WAR (网络应用程序包), CAR (客户端应用程序包), JAR (在 JEE 中, EJB 一般会打包成 JAR 的方式). 其中 EAR 可以包含一个或者多个其他应用程序包, 所以 EAR 包的解析由上述的 EARConfigBuilder 完成, 其他四种类型的包分别由对应的 Builder 完成, 这里的四个 Builder 都实现了 ModuleBuilder 接口.

 

e)         Web Service Builder/Service Builder/Naming Builder/Cluster Builder

 

    以 WAR 包为例, 用户可以 POJO 的方式实现一些 WebService 的应用, 那对于用户来说, 可能只需要在某个 POJO 类上加上 WebSerivce 的注释, 而服务器则需要对类路径中的类进行扫描, 如果发现了某个类上有 WebService    的注释, 则需要对其进行处理, 比如为其生成 WSDL 文件, 创建 Web 访问点等工作.

 

f)         Module Builder Extension (JPA Builder/JSF Builder)

 

    其实 Module Builder Extension 和上述的各种 Builder 概念是相似的, 由于在实际的应用中, 用户在开发时, 可能会用到这样那样的技术, 比如使用 JSF 来实现表现层的展示, 那么如果部署程序检测到 JSF 的配置, 它需要将 JSF 的实现添加到应用程序的类载入器中, 在 WAS CE 中使用的开源的 MyFaces 作为 JSF 的实现, 同样, JEE 标准中说明了对于 JSF 的 Managed Bean 的注入的支持, 部署程序也需要对这些 Bean 的资源注入的注释等进行处理

 

3.       部署一个 WAR 的时序图

 

 

4.       总结

 

    WAS CE 的应用部署架构相当清晰和灵活 , 用户甚至 可以添加自己的 ConfigBuilder 和 ModuleBuilder, 来实现在部署过程中的一些自定义的处理 , 比如可以实现对应用程序中的 JSP 页面进行预编译等 .

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/91446/viewspace-604235/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/91446/viewspace-604235/