配置java ee_Java EE中的配置管理

配置java ee

当我尝试配置管理与云计算有很多相关性时，争论较早。实际上，我大胆地宣称配置管理是任何认真尝试从软件中节省几美元的基石。

那么什么是配置管理及其主要目标？在不使事情变得过于复杂的情况下，我认为接下来的两个目标与事实相差不远。

以可预测的方式建立配置，以确保系统行为正确。
随着时间的变化，保持配置的一致性。

换句话说，能够在整个软件生命周期中以可靠和安全的方式管理行为的变化。

但是什么是配置？它是源代码吗？是否静态加载到当前的类加载器中？可以在运行时更改它吗？它是持久性数据吗？ VCS是否跟踪？实际上，它存储在哪里？群集中的每台计算机都可以访问吗？更改配置后会怎样？我们是否关心更改是否经过验证？用户更改配置是否被授权这样做？更改如何传播到集群成员？是否会通知应用程序有关配置更改？

在此之前，我想回顾一下有关维护的知识。

维护通常消耗大约40％至80％（平均60％）的软件成本。因此，这可能是最重要的生命周期阶段。

关于软件工程的经常被遗忘的基本事实

简而言之（无需争论数字），OAM既困难又成本高昂，显然在动态和弹性的云计算环境中更是如此。从生产率的角度来看，如果我们可以设计软件，从而避免反弹VCS，从部署管道一直到生产一直迭代产品发布，并且仍然能够管理行为更改，那么我们也许应该考虑对吗？显然，这也将使软件更适合于不同的环境，即Java的精神和灵魂。

我要指出的是，我们使用配置来延迟决策，不仅是关于环境及其资源的决策，而且是针对应用程序业务特定决策的决策。企业必须能够快速配置与应用程序服务器资源/基础架构无关的产品/规则。

因此，我认为发布后不得更改的部分（行为完整性）是程序的一部分，而配置是运行时行为不变的，严格由程序策略控制，以便可以保证可预测的系统行为，并根据不同的速率在不同级别上强制实施变革–以有效，非侵入性和可靠的方式（但此为基调）。我想到了开放/封闭原则。

在Java EE的上下文中，此定义仍然不够清楚。 Java EE 6发布了DataSourceDefinition批注，该批注假定配置是代码。组装者/部署者角色赋予了更多的配置灵活性。简而言之，目的是可以在部署之前就可以修改应用程序（特别是其xml描述符），可能会覆盖硬编码值。

这种方法一直使我感到困惑，但是也许这取决于不同的人如何看待哪种类型的数据被认为是配置？但是，我在职业生涯中从来没有听说过，没有听说过或未见过任何实际使用过预期目的的人。这样做可能有充分的理由。

在Maven中，反馈循环的编译和打包实际上是并行的-几乎每个Maven项目都旨在以存档的形式生成工件。描述符由Maven生成或由VCS静态跟踪。无论哪种方式，此过程都会密封应用程序以进行进一步修改，除非解压缩了存档并对其进行了修改。

但是我无法想象这样一种情况：打开JAR文件，修改文本文件，重新打包和重新部署（使用您专有的工具– asadmin，wlst等）是个好主意。为什么？考虑发布新版本的* authentic *存档时会发生什么。汇编程序/部署程序所做的更改将被覆盖或需要重新配置。因此，如果对版本控制的文件进行临时更改，而这些更改从未被VCS跟踪，则可以说不是一个好主意。即使他们这样做了，我们也会失去灵活性。

值得一提的是，许多开放源代码项目都使用数字签名来签署发布，以便安全意识强的用户可以找到压缩包的数字信任路径。如何在不破坏签名的情况下更改此类存档的配置？

考虑对开发的影响，其中每个开发人员可能都有一个单独的数据库表空间来进行集成测试。聪明的开发人员可能会构建一些对配置文件敏感的Maven插件，以在部署描述符中搜索/替换其私有数据。但是，为什么在每次更改配置值（例如在两个JUnit测试之间）时，他都应该为此承担负担并遭受周转打击（我不敢认为这些测试会是什么样子）？仅Xml文件本身无法验证更改，我们需要一个程序来为我们完成更改。等待1-2分钟以便应用程序部署只会发现您的值无效，然后再做一遍，这对开发人员的生产力来说是一场灾难。

如果我们进一步研究如何使用阶段然后切换的方法来为集群系统部署软件，则部署描述符将变得更加成问题，因为将需要两个版本的相同档案。以及为什么生产系统由于静默的价值需要改变而被打扰（升级）并停顿？考虑何时拒绝某个值–您是否将值改回（重新打包应用程序等）并在群集上回滚，更正该值并重试？我不知道……但是现在开始在整个群集中维护SLA可靠性和配置一致性感到不安。

在多租户的情况下，平面名称=值类型的配置也受到限制。层次结构或类似图形的配置规范更适合于对租户进行建模以启用配置组合等。也许是这样的：

import javax.validation.constraints.Max;
import javax.validation.constraints.Min;
import javax.validation.constraints.Pattern;
import javax.validation.constraints.Size;@Configuration
public class MysqlXADataSource {@Property(desc = "User name to use for connection authentication.")@Size(min = 6, max = 255)private String user = ""; // default value - hence optional property@Property(desc = "Password to use for connection authentication.")@Size(min = 6, max = 255)private String password = ""; // default value - hence optional property@Property(desc = "A JDBC URL.")@Pattern(regexp = "([a-zA-Z]{3,})://([\w-]+\.)+[\w-]+(/[\w- ./?%&=]*)?")private URL url; // required property@Property(desc = "Port number where a server is listening for requests.")@Min(0)@Max(65535)private Integer portNumber = 1521; // default value - hence optional property@Resourceprivate List<ConfigurableItem> items; // configuration childs
}@Stateless
public class SessionBean {@Resource(name = "jdbc/mysql-ds")private DataSource ds;
}

这将是应用程序视图，并请注意，不假设在何处以及如何实例化配置，并且我们可以通过使用注释处理器在编译时强制类型安全来快速失败。

这是我的自发反映，也许太过分了。但是我仍然认为，大型和小型应用程序都将从运行时进行配置，不进行软件安装并与配置源（文件，db，ldap，mib等）分离以及如何对其进行管理中受益。

我什至认为Java SE也将从Configuration Management中受益。

有关配置管理，还有很多其他方面需要讨论，例如安全性，管理，通知，架构注册/发现等。但是我将在这里停下来进行评论/反映/意见–部署描述符是管理配置的好方法还是我们需要更复杂的东西吗？

这是与Java EE 7专家组邮件列表上的“ [jsr342-experts] Re：配置”和“ [[jsr342-experts] Re：资源配置””主题相关的帖子。请随时在这里或邮件列表中发表评论。

参考： Deep Hacks博客上的JCG合作伙伴 KristofferSjögren的 Java EE配置管理。

相关文章：