java nosql_使用NoSQL实现实体服务–第4部分：Java EE

java nosql

现在，我已经准备好了一个框架式的合同优先型Web服务，并使用Ektorp和CouchDB创建了一个数据访问层 ，是时候将它们连接到一个可以正常工作的实体服务中了 。 为此，我将使用Java EE和Glassfish 3.1。

值得注意的是，对于他的那种R＆D工作，我完全不需要使用Java EE。 我不需要像Glassfish这样的JEE服务器所提供的安全性或交易功能，我可能可以使用更轻便的东西，例如Tomcat或Jetty。 但是，我喜欢JEE的便利性和功能，许多在像Tomcat这样的标准Java应用程序服务器上开始使用的应用程序最终都会将JEE功能移植到Tomcat中（例如JAX-WS）或迁移到完整的JEE服务器（例如玻璃鱼。

Tomcat的用户经常需要JEE功能-这是在Apache上启动TomEE项目的主要理由。 该项目将JEE Web Profile功能添加到原始的Tomcat堆栈中，因此它可以处理EJB和JAX-WS之类的事情。

将业务逻辑分为Bean。

我的应用程序已经具有2个不同的层。 第一个（从消费者的角度来看）是Web服务层，其任务是提供所有Web服务操作以及其他特定于服务的任务，例如处理定制SOAP标头和消息传递元数据 ，这些问题有助于解决幂等问题。 最后一层是数据库访问层 ，负责与数据库进行通信并处理我的Product实体的持久性和检索。

我现在要添加的第三层也是最后一层是连接前两层的中间层-业务逻辑层。 该层将负责实施产品实体服务的规则和决策，例如确保在执行持久性操作之前，存在，添加或验证任何语义上重要的信息。

这种语义上重要的信息的一个例子是产品的“状态”。 在我的模型中，我允许产品在多个状态之间转换，以维持严格的产品生命周期。 这些阶段如下，并且本质上是线性的（每个状态都跟随最后一个状态）…

• 临时
• 有货
• 可售
• 已停产
• 已删除

在我的业务逻辑层中，我的产品管理器bean确保每个实体的状态对于每个服务操作都有意义。 例如，如果您对Product调用createProduct（）操作，则给定的Product的状态必须为“临时”。 如果没有，我的逻辑将对其进行更改。

这些规则对于每个企业都是唯一的，因此它不是一种适合所有解决方案的规模。 在现实世界中，规则引擎或类似的引擎将是理想的选择，因为它将在定义和管理这些规则时提供更多的灵活性。 但是，对于我的基本R＆D需求，此硬编码解决方案很好，并充分说明了提供业务逻辑层的好处，因为您可以将业务逻辑“关注点”与消息和数据库处理逻辑分开 。

一种数据模型可以全部统治。

所有这些层都有一个共同点，那就是它们管理的数据（aka Entity）对象。 产品实体由XML表示，由XSD描述并由WSDL引用。 这些定义由JAX-WS转换为Java对象，并且这些相同的Java对象在整个代码中本机使用，从而避免了任何数据模型转换 。

这种技术被称为“避免转换”，是这种基于NoSQL的实体服务开发技术的特殊样式的主要优点之一。

避免转换是提高服务可重用性和可组合性的最佳实践– soapatterns.org。

本质上，通过此服务开发，我设法在每个层中使用了这些相同的Java数据对象，但仍保持了真正的合同优先的开发方法。 对于开发人员而言，这确实是个好消息。 我还避免了对数据模型转换层的需求，当消息和数据库之间的数据模型不兼容时（ESB销售人员的坏消息），数据转换层经常变得很必要。

使用NoSQL还使我完全避免了对表和数据关系使用任何SQL DDL，并且不需要任何复杂的对象映射（例如处理传统ORM所需的那些）。 我什至可以随时间推移变形我的数据模型，而不会经常破坏东西（非常适合服务版本控制）。

关于保持JEE简单的注意事项。

为了减少与JEE相关的部署和配置麻烦，我使用了新的部署和打包机制，该机制使您可以在同一应用程序WAR文件中定位EJB和Web应用程序。 这使使用JEE功能变得轻而易举，并大大简化了Maven的构建，因为我仅使用一个项目和零个部署描述符（甚至缺少web.xml！）。

带有EJB 3.1的JEE从未如此简单，因为它现在基于一些非常简单的Java注释的使用。 例如，指定无状态EJB可以是那么简单，因为添加@Stateless注释的一类。 这样做是在告诉应用程序服务器将类部署到池中，以使其具有高可用性，并将对方法的调用包装在事务中。 作为无状态Bean，它将没有会话的概念，并且不会在调用之间保持任何状态（对于无状态服务而言是理想的）。

@Stateless
public class ProductsManager

为了从应用程序的另一部分（例如，从@WebService类）使用此bean，您只需添加正确类类型的引用变量，然后使用@EJB注释对该变量进行注释。 这告诉应用程序服务器在运行时使用一种称为依赖项注入的机制从预填充的Bean池中“注入”正确类型的实例。

@WebService(...)
public class ProductsEntityService implements Products {
  @EJB
  private ProductsManager bean;
  ...

其他有用的JEE功能。

消息驱动的Bean非常适用于实现事件驱动的消息传递 ，其中消息生产者和使用者之间需要持久和异步通信。 但是我可能不会将它们用于特定的R＆D工作，因为我的需求是用例太弱而无法证明工作的合理性（我将向谁通知新产品？）。 此外， @ MessageDriven bean批注使此功能非常易于使用，并且它是基于JMS的完善且高度可靠的功能。

EJB 3.1还允许使用许多新的有用的bean类型。 单例bean是由服务器管理的单例类，并使用@Singleton批注指定（如果您担心像群集单例这样的事情，这很方便）。 @Schedule批注可用于根据日程安排（例如，每个星期五中午）生成常规事件，可以方便地进行报告等。

摘要

因此，我现在拥有一个可以正常工作的n层Web服务，该服务可以使用NoSQL数据库来持久化，管理和检索Product实体。 下次，我将介绍使用这些技术实现更多SOA模式的方法。 订阅我的博客以在发生这种情况时得到通知。

继续第5部分 。

参考： 使用NoSQL实施实体服务–第4部分：我们的JCG合作伙伴 Ben Wilcock的Java EE ，位于SOA，BPM，Agile和Java博客上。

翻译自: https://www.javacodegeeks.com/2012/09/implementing-entity-services-using_389.html

java nosql