新的Java EE 7规范负责人Linda DeMichiel（右图）在主题演讲中详细介绍了通用方法。 Java EE 7的主要重点是将Java应用程序引入云中。 通过从J2EE到Java EE的步骤，通用服务方法已集成到平台中。 意思是，开发人员能够使用服务并以声明方式使用服务。 从Java EE 7开始，平台本身应成为一种服务。 在含义上提供了使用Java EE应用程序服务器启用PaaS（平台即服务）的足够方法。 基本上是为了使EE的客户和用户能够利用整个范围的云（公共，私有和混合）。 这应该通过添加新的平台角色，元数据和API来实现，这些角色支持所需的需求，如多租户，弹性和可伸缩性。 除了新的“块上孩子”，成熟的规范还需要大量更新以支持这些要求。
查看9个“进行中的”规范中已经存在的要点问题，应该使我们更加了解如何实现“云目标”。
JPA 2.1（ JSR 338 ）
包含新功能的第一个规范是JPA 2.1。 可以使用以下简短列表来描述新功能：
–多租户（表区分符）
–存储过程 –自定义类型和转换方法 –示例查询 –动态PU定义 –模式生成（附加映射元数据以提供更好的标准化）
JMS 2.0（ JSR 343 ）
一般而言，这可以认为是最成熟的规范。 自上次维护版本（2002年4月）以来，还有9年的时间。
–适度的范围
–易于发展 –可插拔JMS提供程序 –支持“云”的扩展
EJB 3.2（ JSR 345 ）
Enterprise JavaBeans 3.2的目标是巩固这些进步，并继续简化EJB架构，并为进一步实现云计算的Java EE平台范围的目标提供支持。 EJB 3.2的范围旨在相对地集中于这些目标。
–增量因式分解（拦截器）
–进一步使用注释来简化EJB编程模型 –建议的可选：BMP / CMP –建议的可选：使用RPC的Web服务调用
CDI 1.1（ JSR 346 ）
自从CDI 1.0规范的最终版本发布以来，社区已经发现了许多问题，并且对该规范进行了更新可以解决这些问题。 此处提供了建议的更新列表，但是EG将考虑随着JSR进行而提出的其他问题。
–嵌入式模式
–生命周期事件 –声明式包扫描 –拦截器和装饰器的全球订购 –注入静态变量
Servlet 3.1（ JSR 340 ）
在开发Servlet规范3.1时，EG将考虑平台的任何要求，以优化Web应用程序的平台即服务（PasS）模型。 除此之外，还应解决以下领域。
–云支持
– NIO.2异步I / O –利用Java EE并发 –安全改进 – Web套接字支持 –易于发展
JSF 2.2（ JSR 344 ）
新的JSF JSR将是一项重要的功能更新，它将基于以前的JavaServer Faces版本的改进。
–易于发展
– HTML 5支持（表格，标题，元数据） –新组件 – Portlet集成
JAX-RS 2.0（ JSR 339 ）
JAX-RS解决了大多数要求的社区功能。 仅举几例：
–客户端API
–超媒体 –用于验证的主要API将是Bean验证API –易于发展
表达式语言3.0（ JSR 341 ）
自JSP 2.0以来，表达式语言（EL）已成为JSP规范的一部分。 在Java EE 7中，它将成为一个单独的JSR。
–独立的JSR
–易于在外部容器中使用 –基于标准的集合选择 –新运营商 –用于表达评估的CDI事件
Bean验证1.1（ JSR 349 ）
作为1.0版，Bean验证在明智的方面保持了优势。 社区已经表达了对其他功能的兴趣，这些功能可以增强规范第一版中所做的工作。 –与其他JSR（JAXRS，JAXB，JPA，CDI，EJB，JSF）集成 –方法级验证 –约束构成
云？ 那是雨吗？
通过查看这些提案，很明显其中一些提案具有启用云的空间。 有些根本不在乎。 到目前为止，搜索云内容很少成功。 让我们看一下伞JSR 342 。 官方页面是公开的，可以在http://java.net/projects/javaee-spec/上找到。 非常有趣的是Java EE 7平台和PaaS模型支持文档 （PDF），该文档描述了Java EE 7中PaaS支持的总体体系结构。通过评论，专家组在很大程度上达成了一致。 它总结了所需的角色（PaaS产品供应商，PaaS提供者，PaaS客户经理，PaaS客户，应用程序提交者，应用程序管理员，最终用户），并给出了两个示例场景，它们在PaaS环境中发挥作用。 进一步，您会发现一些定义和术语：
PaaS应用程序：
“包含领域特定代码的离散软件工件，
可以由PaaS客户上载到PaaS环境并部署在其中。
该工件可能会消耗PaaS资源，并分布在多个JVM中 根据QoS设置和/或SLA的实例。 根据其使用条款， 随后，可以通过以下方式将PaaS应用程序部署到PaaS环境中： 可能还有其他任何PaaS客户。”
承租人：
“由于在此处描述的模型中，PaaS客户对应于
隔离域，我们将使用术语“租户”来避免与
在业务环境中“客户”一词的其他用法。”
应用程序开发人员：
“我们将使用“应用程序开发人员”一词来表示
应用程序开发人员的常识。 用传统的Java EE术语， 此角色在应用程序组件提供程序和应用程序之间分配 汇编器。”
此外，您还可以找到有关“保护”投资的强制性声明：
Java EE 7的目标是增加对PaaS模型以及
SaaS模型的有限形式，同时尽可能保留
建立了Java EE编程模型，并进行了大量投资 由客户，供应商和系统集成商集成到Java EE生态系统中。（来源： Java EE 7平台和对PaaS模型的支持 ）
您很快就会看到Jerome Dochez的qcon London幻灯片 ，您会发现，与专家组在公开文档中讨论的内容相比，还有很多事情要处理：
–更好的云打包（模块化应用程序）
–版本控制
–部署模型 – SLA监控 –帐单
而且我敢肯定，您可以提出更多建议。 由甲骨文Openword的Adam Leftik和John Clingan提出的GlassFish / Java EE战略和路线图 （PDF）通过查看以下内容对未来进行了更详细的描述：
–动态服务供应
– Iaas管理
–使用自动缩放的弹性 –监控 –虚拟机管理程序抽象
到目前为止，这似乎是在云中使用Java EE的最完整，最具体的方法。 看到GlassFish团队使用最新的GF 4.0发行候选者进行演示时，您可以想象到工作完成了多少。 （即使我认为仍有大量工作要做：）
没有雨，但是会阴天
目前正在发生许多变化。 在成熟的规范中，随着方向的改变，这是预期的。 通过相信新的Oracle云产品和GlassFish团队正在进行的前沿工作，我相信可以实现宏伟的目标，因为我们有足够的商业价值。 我担心的是，单一规范可能会拒绝包含“需要的”云内容，以支持错误修复或社区要求。 这是伞式规范首次朝着完全不同于包含子项的方向发展。 另一方面，正如我们从过去所知，雨伞本身是一个可比较的小规格，它在非常一般的细节水平上进行规定。 一般而言，这可以为供应商带来机会。 在此让我补充一点：我坚信，Java EE 7自古以来对规范领导者将是最大的挑战。 通常，遵循整个“云”主题而不分散或优先考虑单个包含的规范将是一项非常政治的工作。 即使Linda DeMichiel是Java EE的资深人士，我也相信很多工作正在这里等待。
2013年夏季与2012年第三季度最终发布–错失良机
我在时间表上遇到的真正大问题是，我们没有机会获得用于应用程序打包的真正模块化方法。 无论是针对云的打包（以及相关的东西，如版本控制，SLA等）设计什么，都将无法利用Java SE 8随附的新项目Jingsaw功能。我个人认为，这是对Java的主要要求云的Java EE PaaS基础架构。 如果新的云元数据将建立在Java EE 6打包规范的基础上，那么就错过了采用最新，最好的Java模块化的机会。 我非常好奇地看到，EG将如何解决此问题，而无需再次使用Java EE 8进行所有工作。
参考：来自JCG合作伙伴 Markus Eisele的 Java EE过去，现在和Cloud 7 ，在“使用Java进行企业软件开发”博客中 。
翻译自: https://www.javacodegeeks.com/2011/10/java-ee-past-present-cloud-7.html
扫一扫
698
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
