gae代码_GAE中的Java EE

gae代码

云计算是一个快速增长的领域，正在为未来的IT基础架构定义路线图。 如果您想生活在不断发展的边缘，则不应该只是从旁观望，而应该尝试一下！ 另一方面，企业Java已经存在了很长一段时间，目前已经处于第六步。 随着时间的流逝，各个专家组不断完善规范，修正了先前版本的错误，尽管存在复杂性，但简化了用法，当然还增加了有趣的新技术。

公司以及开发人员本身已经投入了大量资源，工作和知识来掌握他们的Java企业技术，而云计算主要是由于其逻辑限制，其工作方式与我们在重量级Java中所使用的完全不同。企业世界。 潜在的问题很明显–为了迁移到云端，我们真的必须忘记并丢弃过去几年Java企业编程中学到的很多知识吗？

Google必须根据自己的需要开发云基础架构，并且处于向公众提供云服务的理想位置，因此它是最早提供免费PaaS服务的公司之一。 该服务名为GoogleAppEngine （GAE），并且在最初的产品中服务于Python应用程序。 由于这项初始服务取得了可喜的成功，并且Java作为一种开放源代码的企业就绪语言而广受欢迎，因此他们将GAE服务也扩展为可以托管Java应用程序。

使用Java，通常的做法是将良好且成功的自定义框架或项目转换为规范。 最后两个Java EE规范是其JPA，JSF，EJB3以及最新的CDI和BeanValidation的很好示例。 同时，提到的前三个进行了升级，这恰好证实了它们的广泛采用和良好的用户反馈。 CDI是一种新的企业规范，它基于流行的自定义应用程序框架（例如JBoss Seam，Google Guice和Spring框架）中的最佳品种。 它允许简单的类型安全的配置，这对于大型项目而言非常有用，并且可以与当今功能强大的IDE工具完美地结合使用。

由于Google绝对了解最佳做法，因此他们会尽量支持现有标准。 但是由于云处理有其特定的限制，所以并非所有的事情都那么简单。 这就是本文的重点。 如何保持标准技术的存在，同时仍然遵守云的限制。 我们将更详细地研究如何引入CDI，以及如何将其与JPA，JSF和BeanValidation透明有效地集成，同时还将替换缺少的EJB3功能。 我们还将介绍所有主要的GAE限制以及如何在Java企业环境中正确解决这些限制。

由于当今的解决方案需要经过全面测试，因此还将介绍一种新的测试方法。 这项新的测试允许透明的环境切换，使测试真正适用于Java。 运行一次，到处测试。 这也适用于“我们的” GAE环境。

CDI简介

我们不会过多地介绍什么是CDI及其工作原理。 这是另一篇文章的主题。 在这一篇中，我们将展示如何在GAE中最好地使用它。

GAE的一个主要限制（如果实际上不是“那个”）是30秒的请求/响应时间限制。 这意味着，如果应用程序在不到30秒内没有响应，则GAE本身将终止该线程并引发适当的异常。 另一方面，如果一段时间未使用该应用程序，则GAE只会关闭所有应用程序实例，这意味着下一个请求将承受启动新实例的开销。 最近，此功能有了一些改变，增加了“ Always On”功能，但不幸的是它并非免费提供。

为了使CDI能够正常工作，CDI运行时需要在初始化时检查所有可能的bean，从而花费大量时间确定和验证应用程序的bean配置。 考虑到在第一个请求上，您可能不仅会处理请求，还会引导整个应用程序，因此必须努力地尝试尽可能延迟地初始化Bean，这意味着将初始化处理时间减至最少。 要考虑的另一件事是过滤掉所有在应用程序中实际上不用作Bean的类。 在Joss的CDI和RI实施Weld中，我们有几种不同的方法来限制潜在bean类的列表。 一种方法是在beans.xml中定义一个过滤元素，另一种方法是提供具有列出的bean类名的确切bean-classes.txt文件。

与每个框架一样，CDI需要在您的应用程序中有一个切入点。 在Web应用程序中，引导自定义框架的最简单方法通常是通过Servlet侦听器。 CDI或专用于Weld也不例外。 但是，但重要的是，这只是一个初始引导程序，它仅设置了CDI BeanManager和应用程序的Bean。 由于我们在Web应用程序中，因此我们的逻辑可能通过servlet和过滤器进行访问。 要将CDI与这些组件一起实际使用，必须引入其他集成机制。

对于“标准” Web容器，例如Tomcat和Jetty，Weld已经提供了完整的现成的CDI集成。 但是，由于GAE并不是纯粹的Jetty，而是没有所有功能的基于Jetty的派生工具-主要是出于安全原因，我们需要找到与CDI集成的另一种方式。

这并不像乍看起来那样困难。 所有的CDI实现都为自定义扩展留出了一定的空间，这些扩展可以轻松地用于获取应用程序的BeanManager实例。 这确实使您的应用程序在不同的CDI实现之间有点不可移植，但是如果您确实需要它，可以轻松地对其进行抽象。 在Weld的情况下，我们使用BeanManager在引导时也作为servlet上下文属性添加的事实。 这样，我们可以轻松地创建初始Servlet的CDI感知委托。 这种工作方式是非CDI感知的servlet接收请求，然后将其委托给CDI感知的类似于servlet的委托。 好的，现在我们可以启动并运行我们的超级惰性CDI bean，以准备满足某些请求。 让我们看一下这些bean如何真正做一些严肃的事情，例如与您的数据库进行交互。 继续参加JPA！

JPA用法

尽管GAE拥有自己的低级持久性API（一个简单的类型化DataStore），但JavaEE开发人员更习惯于JPA API，因此GAE也提供了这种功能。 但不足为奇的是，有很多合理的限制必须要意识到。

实际数据库不是众所周知的关系数据库，而是高度可伸缩的非关系BigTable。 虽然我们通常只有一个关系数据库实例，但GAE实际上有一个未知数量的BigTable实例（或节点），从用户的角度来看，它在写入数据时会随机选择。 为了进行此类ACID写入，任何“相关”数据都必须位于同一节点上，这意味着需要精心设计JPA关系。 已经存在现有的OSS框架，可以最大程度地帮助您解决此关系问题。 在我们的案例中，我们在标准化JPA的基础上开发了自己的简单解决方案，该解决方案在代理实体的帮助下隐藏了变通方法的实现细节。 实际上，每个使用的实体实例都是一个代理实例，该代理实例拦截对潜在关系的调用并将其转换为适当的查找。

众所周知，JPA的一部分也是其二级缓存，在我们的案例中，它非常方便。 无需进行昂贵的查询查找，我们可以轻松地缓存许多以前查找的数据，尤其是考虑到缓存在GAE中“便宜”。 借助此功能，以一种非常懒惰的方式实现初始JPA EntityManagerFactory初始化也很有意义。 如果可以使用以前缓存的数据来处理查找，则不必实际实例化EntityManagerFactory。

JSF，BeanValidation和缓存

为了使用JSF2，必须正确设置初始上下文参数，不幸的是，甚至要使用一些技巧。 这些参数需要禁用任何多线程JSF行为，而我们使用的这种破解方法使我们过去无法使用类。 不允许使用InitialContext。 要注意的另一件事是，GAE的类路径中已经带有EL 1.0（统一表达式语言库），由于使用了一些奇怪的规则而不是应用程序附带的EL库，因此使用了它-这意味着我们被EL 1.0功能所困扰，需要一些解决方法来调用参数化的bean方法。

实际的实现用法取决于我们要从BeanValidation中获得多少验证功能。 在我们的案例中，事实证明，我们实际上只需要一个简单的bean属性验证，这使我们自己实现并使用几个BeanValidation SPI变得更加容易和轻巧。 由于所有实际用法都隐藏在适当的BeanValidation API后面，因此，如果需要，可以用更复杂的实现替换它。

正如我们已经提到的，在GAE中进行缓存是“便宜的”，而您有很多。 这应该鼓励您尝试并缓存尽可能多的内容。 当然，您应该高度注意缓存逐出策略，以及如何在所有层上正确应用它，以免遗留任何陈旧的数据。 要记住的另一件事是，随着应用程序版本的更新，缓存数据的结构可以更改，从而破坏了序列化协定。 同样，GAE UI管理界面允许管理员更改数据。 因此，应该通过应用程序的管理界面公开“清除所有缓存”操作。

测试中

GAE的另一个优点是，即使在本地环境中，它也易于使用。 设置对应用程序的测试应该不太困难。 与我们使用的其他技术一样，我们的测试框架也应该能够支持运行时环境更改。 在JBoss，我们开发了两个真正的最新测试框架来帮助您轻松实现这一目标-Arquillian和ShrinkWrap 。 ShrinkWrap项目抽象了实际的部署位，而Arquillian抽象了实际的运行时容器（又称环境）。 为了在GAE中测试您的应用程序，我们只需要编写一个能够在嵌入式模式下运行GAE的适当的Arquillian容器实现即可。 这样，测试代码与环境无关，其中实际环境由测试类路径上的实际单个Arquillian容器实现确定。

结论

我们可以看到为GAE开发应用程序并不意味着我们需要放弃先前学习的JavaEE技术。 但是，在使用这些技术时，我们确实需要更加谨慎，根据现有和潜在的GAE限制评估每个用例。 我们还可以看到使用标准化API和良好框架隐藏环境依赖性的好处。

在JBoss Weld项目中，我们鼓励用户提供任何关于现有GAE体验的反馈，同时考虑到所有建议，错误修复，补丁或批评，同时使CDI成为与GAE一起使用的愉快平台。

Ales Justin将发表他的“ Google App Engine上的JavaEE：CDI进行救援！” 通过在JAXconf上的会议获得更多有关在GAE限制性沙箱中使用Java EE规范的信息，同时仍然受益于它提供的可伸缩环境并保持对其他Java EE容器的可移植性。 JAXconf将从6月20日- 23 ^日 ，2011年，在加利福尼亚州圣何塞市 运行 。 有关会议的更多信息，请访问JAXconf网站 。

翻译自: https://jaxenter.com/java-ee-inside-gae-103153.html

gae代码