an oracle article in high level to descibe how to archtichre operator JAVA relevet project

SOA 环境中的配置管理最佳实践

SOA 环境中的配置管理最佳实践

作者:Brian Jimerson

下载
download-icon13-1Oracle SOA Suite
download-icon13-1Oracle WebLogic Server
download-icon13-1Oracle Enterprise Manager

简介

根据定义,配置管理 (CM) 是指通过一致的版本、命名、更改控制和自动化来管理 IT 资源、资产和控制的实践。软件解决方案的 CM 包含许多准则,包括版本控制、自动部署、环境配置和团队开发。这些准则是众所周知的,还有许多实现传统解决方案 CM 的标准工具。

但是,SOA 解决方案实践对 CM 提出了独特的要求。用于支持 SOA 实践的服务版本控制、分布式部署、动态端点解析以及基础架构等都有独特的要求。令人欣慰的是,可以在 SOA 实践中采用许多传统的 CM 工具和技术。

本文将讨论 Oracle SOA Suite 11g 实践中的 CM 最佳实践。将讨论这些实践中用于确保正确管理软件、服务和基础架构配置的工具、技术和过程。

 注意:本文假设读者熟悉传统 Java Platform, Enterprise Edition (Java EE) 的 CM 原则。本文中的许多讨论和示例都基于这些原则。

SOA 构件的构建过程

对任何应用程序而言,一个最基本的需求就是用于将源代码构建为可执行程序包的可重复过程。对于 Java EE 应用程序,这些可分发的单元通常采用以下形式:

  • JAR 文件,用于独立应用程序、Enterprise JavaBean (EJB) 和库
  • WAR 文件,用于 Web 应用程序
  • EAR 文件,用于企业应用程序
  • RAR 文件,用于资源适配器

构建这些构件通常包含相同的基本步骤:

  1. 删除所有旧的构建构件。
  2. 构建所需的所有依赖。
  3. 将源代码编译为类。
  4. 在资源中应用环境特定的设置。
  5. 将资源复制到特定目录中。
  6. 将编译的代码、库和文件按照目标格局组合在一起。
  7. 创建部署存档(JAR、WAR 等)。


由于这些标准步骤,因此有几种用于构建 Java EE 构件的实际工具。Apache Ant 是众所周知的用于配置、构建和部署 Java 项目的工具。它在安装到 *nix 系统之后建模,几乎可针对所有类型的构建需求进行完全配置。它还提供了一个插件系统,以便可通过 Ant 构建完成其他任务,例如,通过 SSH 进行安全复制以及部署到特定应用服务器(如 Oracle WebLogic Server)。

Ant 使用 XML 文件描述构建过程。完成特定任务所需的任务组称为目标。每个目标可以具有 0 个或多个任务,这些任务是构建过程中的可执行步骤。XML 构建文件中的一组目标称为一个项目。清单 1 显示了一个可以编译 Java 应用程序并创建可分发 JAR 文件的简单 Ant 构建文件。

清单 1 — Ant 构建文件示例

<project name="Sample Build" default="dist" basedir=".">
  <description>A sample Ant build file.</description>

  <!-- Clean target deletes old build files -->
  <target name="clean" description="Cleans old build artifacts" >
    <delete dir="build"/>
    <delete dir="dist"/>
  </target>

  <!-- Compile target compiles all Java source code; depends on the clean target -->
  <target name="compile" depends="clean" description="Compiles source code" >
    <javac srcdir="src" destdir="build"/>
  </target>

  <!-- Dist target creates JAR file of compiled code; depends on the compile target, 
  which in turn depends on the clean target -->
  <target name="dist" depends="compile" description="Creates a distributable JAR file" >
    <mkdir dir="dist/lib"/>
    <jar jarfile="dist/lib/SampleProject.jar" basedir="build"/>
  </target>
</project>


多年来,Ant 一直是标准构建工具。构建过程完全可配置,并且通过使用插件可完成几乎所有任务。但是,Ant 无法满足某些标准构建过程需求,例如依赖管理、命名惯例、报告及生成标准构建过程。

Apache Maven 克服了 Ant 的一些缺点,尤其是依赖管理、标准源代码布局和构建过程。Maven 在很大程度上依赖于源代码布局、构建配置和命名的惯例,从而极大地简化构建过程。例如,要实现类似于清单 1 中 Ant 构建的构建,只需执行以下命令:

mvn clean package

只要项目具有标准布局,该命令便会清理和编译 Java 项目,并创建项目的 JAR 存档以便分发。Maven 还通过使用依赖信息库极大简化了项目的依赖管理。在一个被称作项目对象模型 (POM) 文件的 XML 描述文件中描述项目的依赖和版本;Maven 在构建时自动下载和打包这些依赖。使用 Ant 时,需要手动收集和打包项目的依赖。

由于 Maven 比 Ant 有所改进,因此许多组织都使用 Maven 实现其所有构建和部署。但是,不同的项目类型需要 Maven 插件才能正确执行。例如,Java Web 应用程序需要 WAR 插件才能正确构建 WAR 可分发文件。该插件通过标准 Maven 信息库免费提供。

某些种类的项目程序集(如 Oracle SOA Suite 组合应用程序)没有可用的稳定 Maven 插件。Oracle SOA Suite 组合应用程序具有广泛的 Ant 支持,用于构建和部署服务组件架构 (SCA) 存档;实际上,在 Oracle JDeveloper 中部署 SCA 组合时,将利用这些 Ant 脚本执行构建和部署过程。

对于当前使用或希望使用 Maven 构建 Web 应用程序 (WAR)、Java 库 (JAR) 和企业应用程序 (EAR) 等标准应用程序的 SOA 实践,将 SCA 组合整合到其构建基础架构时有两种方法:

  • 将 SCA 组合的 Ant 构建与其他应用程序的 Maven 构建混合使用。如果 SCA 组合独立于其他应用程序构建和部署,并且使用了支持两个平台的构建服务器,则该方法非常有效。
  • 使用 Maven AntRun 插件从 Maven 中调用 SCA Ant 任务。对于希望使用 Maven 实现其所有构建和部署的企业而言,这是一个很好的选择。尽管 Ant SCA 任务仍需通过组合应用程序进行配置,但 Maven 插件负责将构建和部署调用委派给基本 Ant 任务。

注意,Oracle JDeveloper IDE 以开发人员预览版更新的形式为 Maven 项目提供支持。对于当前使用 Maven 并正在考虑转换到 Oracle JDeveloper 以进行标准 Java EE 开发的组织,应该评估 Oracle JDeveloper Maven 更新状态是否足够稳定并足以满足它们的需求。在 SOA 环境中,许多实践都混合使用各种开发工具,如 Eclipse 或 NetBeans(具有对标准 Java EE 应用程序的 Maven 支持)以及 Oracle JDeveloper,它们完全支持组合、BPM 和其他 Oracle SOA Suite 项目的 Ant 构建。

SOA 构件的部署过程

可以使用几种工具将 SOA 构件部署到 Oracle WebLogic Server。其中最重要的工具是 Oracle Enterprise Manager、WebLogic Scripting Tool (WLST)、Apache Ant 以及具有 WebLogic 插件的 Apache Maven。

对于偶尔的手动部署,Oracle Enterprise Manager 是很好的选择。Oracle Enterprise Manager 为部署提供了一个图形界面,并提供了配置部署所需的大多数选项。但是,使用 Oracle Enterprise Manager 进行部署是手动过程,可能会导致部署过程中出现错误。尽管如此,使用 Oracle Enterprise Manager 记录新构件的步骤和配置仍然是一个非常有用的过程。

WLST 提供了一个用于部署 SOA 构件的自动化界面。WLST 是命令行脚本工具,用于管理 WebLogic 服务器,包括部署应用程序。WLST 使用 Jython 语言编写脚本;部署可以保存在 Jython 脚本文件中并在调用时传递给 WLST。Jython 是 Python 通向 Java 的桥梁,并且使用 Python 语言语法;可以在此处找到有关 Python 语法的更多信息。清单 2 显示了一个用于部署 SOA 组合应用程序的 WLST 命令的示例。可以在此处找到有关如何使用 WLST 编译、部署和管理组合应用程序的更多信息。

清单 2 — 使用 WLST 部署组合应用程序

wls:/soa_domain/ServerConfig> sca_deployComposite("http://localhost:7001", 
"/deploy/sca_MyComposite_rev1.0.jar")


对于自动部署 SOA 构件而言,Ant 和 Maven 也是很好的选择。具有 WebLogic 插件的 Maven 可用于部署非 SCA 的 SOA 构件,如独立 Web 服务项目。包含 SCA 自定义任务的 Ant 可用于部署组合应用程序;如前所述,Maven 对组合应用程序的支持是最低的。

使用 Maven 部署 WebLogic 应用程序需要 WebLogic Maven 插件。该插件还需要进行配置;您将在此处找到包含 WebLogic 配置的示例 pom.xml。注意针对开发、测试和生产环境使用不同的配置文件。使用此类配置文件能够针对不同的环境设置不同的配置,然后将配置文件指定为 mvn 命令的一部分。

使用 Ant 部署 SCA 组合应用程序时,需要引用与 Oracle JDeveloper SOA Composite Editor 插件一起打包的 SCA 构建脚本;默认情况下,这些脚本位于 JDeveloper/bin 目录中。需要以下构建脚本:

  • ant-sca-deploy.xml
  • ant-sca-mgmt.xml
  • ant-sca-package.xml
  • ant-sca-test.xml
  • ant-sca-upgrade.xml
  • ant-soa-common.xml
  • ant-soa-util.xml


将这些脚本打包于组合应用程序中之后,可以使用包装脚本编译、打包和部署组合。本文包括该包装脚本的一个示例 [参见 sca-build.xmlsca-build.properties];该示例可以用于自定义 SCA 组合部署。

要使用该脚本,需要更新 sca-build.properties 文件中的属性,将 sca-build.properties 和 sca-build.xml 文件与 Oracle JDeveloper 构建脚本放在同一目录中,并针对环境执行相应的目标(如 dev-deploy)。还需要针对每个环境的组合配置计划,即使组合没有环境特定的配置。

源代码和版本控制

源代码和版本控制处理以下过程:在团队环境中管理源文件以及提供文件的版本和管理。版本控制软件的示例包括 Subversion、CVS、Microsoft Team Foundation Server、Mercurial 等。

传统的源代码控制非常适用于 SOA 实践的源代码控制。SOA 实践具有几个独特的要求,这些要求通常与传统的软件开发中心无关。对本文而言,将使用 Subversion 术语,因为 Oracle JDeveloper 和相关的 Oracle SOA Suite 工具完全支持 Subversion。所有其他主要版本控制系统技术都支持相同的概念,只不过使用的术语不同。

SOA 实践在其版本控制软件中首先要使 SOA 组合应用程序版本与版本控制软件中的修订保持一致。将 SOA 组合应用程序部署到 WebLogic 服务器时,始终对这些应用程序进行版本控制。组合的运行时版本应该能够向后与源代码控制系统中的修订相关联。如果能够将运行时组合的版本与源代码控制系统中的修订关联,则团队可以提供版本的更改文档,重现或回滚到某一版本,并传递特性和版本说明。

SOA 环境的一个类似的不合理要求是版本分散服务的能力。SOA 的一个原则是服务和客户之间的合同;大多数服务在整个生命周期内都不可避免地需要更改其合同,但这样做,它们需要针对现有用户维护先前版本的合同。这样,需要对用户可以绑定到的分散服务进行综合版本控制。

大多数源代码控制系统都使用自己的修订命名系统。Subversion 使用增量式数字系统;每个 Subversion 事务都会在修订号中生成一个增量。在整个部署生命周期内,使源代码控制系统的修订与组合或分散服务的版本保持一致可能很难,并且不总是必需的。通常,服务的生产版本需要向后与源代码控制修订关联,但服务的开发版本可以变化,不需要专门与源代码控制修订保持一致。

为了缩小服务版本和源代码控制系统中的修订之间的差距,可以使用标记或标签。服务的生产版本很有用,它们通常在测试环境中进行功能和回归测试之后才部署;对测试环境进行部署时创建标记是影响相对低的解决方案。标记可以具有任意名称,因此标记命名可以反映一个服务的版本,与源代码控制系统的版本控制系统无关。图 1 描述了为服务版本添加版本控制标记的过程。


jimerson-config-soa-fig01
图 1 — 版本控制标记

自动构建和部署

自动构建和部署 SOA 构件可以显著减少构件部署的工作量、部署错误,并且还可以减少开发人员从 IDE 或命令行部署构件的需要。通常,使用构建服务器自动执行构建和部署。构建服务器能够配置多个项目或多个构建;能够调用诸如 Maven、Ant 或 shell 脚本之类的构建工具;还能够提供诸如故障报告和通知之类的审计特性。

一款极佳的开源构建服务器是由 Oracle 主持的 Hudson。Hudson 在分类上属于持续集成服务器,但可用于大多数类型的自动构建和部署。它可以执行 Maven 目标、Ant 目标、Java 编译器任务、.NET 构建以及 shell 命令。它还可以和大多数版本控制系统协同工作,包括 CVS、Subversion 和 Perforce。Hudson 还支持项目、版本控制标记以及跨多台计算机分布构建。

与 Hudson 具有类似功能的其他构建服务器包括:


SOA 构件的环境配置

SOA 构件与传统应用程序一样,当通过开发、测试和生产实现升级时,需要能够针对不同的环境对自身进行配置。应用程序需要能够更改到外部实体(如数据库、电子邮件服务器和第三方)的连接和登录信息。SOA 构件还需要动态解析服务端点。

根据构建平台的不同,可以使用多种方法针对环境更改配置信息:

  • Maven 筛选器和配置文件:Maven 筛选器能够在构建时将属性文件中的属性与资源合并。通过将每个环境的配置文件与筛选器相组合,可以根据所用的配置文件,针对不同的环境合并不同的筛选器文件。可以在此处找到有关 Maven 筛选器的更多信息。
  • Ant 复制任务:使用复制任务,Ant 构建可以针对不同的环境复制或重命名不同的配置文件。通常,通过在 Ant 目标中设置一个环境属性并将该属性用作复制任务名称解析的一部分,完成上述操作。
  • 环境属性或变量:每个服务器或环境都有自己专用的资源,应用程序可以在运行时找到并加载这些资源。

这些方法非常适用于连接设置、登录信息等内容。但是,SOA 环境中的服务端点解析需求更为复杂。在 SOA 环境中使用服务应采用松耦合形式,而将端点 URI 作为应用程序的一部分提供则违反了这一原则。理想情况下,端点 URI 在运行时动态解析;动态解析端点 URI 可以使服务在无需变更用户的情况下独自改变其位置和合同。

为了实现动态端点解析,通常使用服务注册表。服务注册表可根据键值或注册表项提供服务端点 URI。Oracle Service Registry 是符合 UDDI 版本 2 和版本 3 的服务注册表,并且可以进行结构化以便根据键值和环境属性为客户端提供动态端点解析。

在 Oracle Service Registry 中实现动态端点解析的一种方法是针对不同的环境创建一种分类法。注册表中的每个服务可以具有多个绑定,每个环境一个绑定;每个绑定都有一个分配给它的环境类别。客户端可以在注册表中查询服务,然后查找对应于其环境的绑定。图 2 以图形方式显示了这一过程。

jimerson-config-soa-fig02
图 2 — 通过 Oracle Service Registry 动态解析端点

总结

本文讨论了 SOA 开发实践的多种配置管理技术和最佳实践。SOA 实践具有许多与传统软件开发相同的配置管理需求;但是,SOA 开发的配置管理还具有传统开发实践中所没有的其他独特需求。本文介绍了如何将行业标准配置管理技术应用于 SOA 环境从而确保提供高质量的解决方案。


Brian Jimerson [LinkedIn] 是 Avantia, Inc. 的一名高级技术架构师,Avantia, Inc. 是俄亥俄州克利夫兰市的一家定制解决方案提供商。他专门研究中间件和 Web 基础架构解决方案、企业集成模式与实践以及企业方法。
原文地址:https://www.cnblogs.com/lexus/p/2353426.html