您是否因为需要花时间部署多个服务而感到倦怠了呢?是不是每次进行更改后都必须重新启动服务器?Apache Axis2 可以帮您摆脱这些烦恼。Axis2 是干净的可扩展开源 Web 服务平台,正逐渐受到广泛的接受。Axis2 集中了 Apache SOAP 家族的大量优势,而且进行了一些重大改进。
引言
Apache Axis2(主要的开源 Web 服务平台之一)提供了一系列新功能,最为可贵的是,其中的很多功能都对向开发人员提供更为用户友好的方法起到了促进作用。在之前的 Axis 版本中,并不十分重视用户友好性。例如,在 Axis1 中,用户必须手动调用管理客户机并更新服务器类路径,然后重新启动服务器以应用更改。这个有点麻烦的部署模型对新手肯定是一道障碍。因此,Axis2 经过了精心的设计,能够克服此缺点,并提供更为灵活、可方便进行配置的部署模型。
Axis2 部署新功能
Axis2 部署模型将一系列新功能引入了 Apache Web 服务堆栈中(其中一些功能对于 Web 服务范式并非新事物)。以下列出了最为重要的主要更改和新功能:
类似于 Java™ 2 Platform Enterprise Edition (J2EE) 的部署机制(基于存档)
热部署和热更新
存储库(可以在其中放置服务和模块)
处理程序(模块)部署的更改
新部署描述符
多个部署选项
在下面的内容中,我们将逐个对每个方面进行详细讨论。
类似于 J2EE 的部署机制
在任何 J2EE 应用服务器中,都可以将应用程序作为自包含包部署,可以将所有的资源、配置文件和二进制文件打包为一个文件并进行部署。这显然非常实用,而也正是因为如此,Axis2 也引入了相同的机制来更方便地部署服务(和模块)。
考虑这样的情况,假如您有一个存在多个第三方依赖关系和一组属性文件的服务,同时假定没有类似于 J2EE 的部署机制。必须手动将所有这些依赖 JAR 文件和属性文件放入类路径中。如果有一个或两个服务器,这项工作的量将翻倍!在存在数百副本的集群环境中,将依赖 JAR 文件和其他资源添加到类路径中的做法并不实际。有了类似于 J2EE 的部署机制后,就没有这些问题了,只需要将服务放入副本中,而不需要进行任何其他工作了。
Axis2 自包含包(或存档文件)的内部结构如图 1 中所示。两种 Axis2 服务(存档和模块存档)非常相似。二者之间的细微差别包括:
对于 Axis 服务,描述符文件是 services.xml;而对于 Axis 模块,描述符文件是 module.xml。
Axis2 服务的文件扩展名是 .aar(服务的文件名将为 foo.aar),模块的文件扩展名为 .mar(模块的文件名将为 foo.mar)。
热部署和热更新
对于企业级应用程序,可用性是一个大问题。即使短时间的停机都可能带来很大损失,因此重新启动服务器并不是一个较好的做法。需要在不用关闭系统的情况下对其进行更新。而这就是热部署和热更新的用武之地。热部署和热更新是 Apache Web 服务堆栈(如 Axis 和 Axis2)中的新功能。这两个新功能如下所述:
热部署是指在系统启动并运行的情况下部署新服务的能力。例如,假定您有两个服务——service1 和 service2——已启动并运行,现在要在不用关闭系统的情况下部署名为 service3 的新服务。部署 service3 就是一个热部署场景。作为系统管理员,如果不喜欢服务的热部署,则可以通过更改名为 axis2.xml 的 Axis2 全局配置文件,将全局配置参数更改为以下所示,从而关闭此功能:false。
热更新是指在不关闭系统的情况下更改现有 Web 服务的能力。这是一个重要的特性,是测试环境中需要的一个功能。不过,在实时系统中使用热更新并不明智,因为这可能导致系统进入未知状态。此外,还可能会丢失该服务的现有服务数据。为了防止出现这种情况,Axis2 缺省将热更新参数设置为 FALSE。如果希望使用此功能,请按照以下所示更改配置参数,从而启用此功能:true。
存储库
Axis2 存储库实际上就是文件系统中具有特定结构的目录。它可以位于本地,也可以位于远程计算机上。之所以引入存储库概念,目的是为了方便地支持基于存档的热部署功能。
存储库目录包含两个主要子目录,分别名为 services 和 modules。还可能有一个可选的子目录,名为 lib。如果希望部署服务,需要将服务存档文件放入 services 目录中。类似地,如果希望部署模块,请将模块存档文件放入 modules 目录。对于 lib 目录,要将其作为放置对服务和模块公用的第三方库的位置。图 2 显示了存储库的图形表示形式。
图 2. Axis2 存储库
注意:如果 modules 目录中的部分或全部模块希望共享某些资源,可以将这些资源添加到 modules 目录中的 lib 目录内。类似地,如果 services 目录中的全部或部分服务希望共享公共资源,恰当的位置是在 services 目录内的 lib 目录。
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
相关推荐
-
SAP收购CallidusCloud 与Salesforce竞争
一直被称为后台办公巨头的SAP现在似乎也想在前台办公大展拳脚。 最新的迹象是SAP收购CallidusClou […]
-
请问CloudStack和Hadoop有什么区别,都是apache的产品有什么不一样吗
-
如何选择Web服务器:Nginx对阵Apache
Nginx人气的迅猛提升与Apache在Web服务器市场份额领域的稳步下降不禁引发诸多猜测,很多从业者认为这种趋势将使新部署流程中的方案选择变得更为清晰。
-
API设计如龙生九子 各不相同
IT咨询管理公司CA Technologies对API产业做了个问卷调查,问卷内容涉及API设计风格以及管理部署的新动向。调查结果表明,JSON与XML可谓两分天下。