内容


加快 Java 企业应用程序的设计和开发

使用模型驱动工程原则自动设计和实现 EJB 和 JAX-RS 服务

Comments

简介

本文将介绍如何加快 Java 企业应用程序的设计和开发,Java 企业应用程序使用了一些主流技术,比如 Java Persistence API (JPA)、Enterprise Java Beans (EJB) 和 Java API for RESTful Architecture。按照 RESTful 架构的原则,我选择了基于构成业务域的实体建模资源。我们使用 Enterprise Java Beans 作为中间层,以便利用它们提供的事务管理支持。IBM® Rational® Software Architect 提供了一组预定义的模型到代码转换,支持使用主流技术开发 Java 企业应用程序。

从在 JPA 技术环境中表示业务域的 UML 模型开始,这样就可以生成包含 Java Persistence API 实体的 Java 工件。此外,UML 到 EJB 3.0 的转换根据 UML 模型元素生成了 Enterprise Java Beans 和 Java 代码,可以扩展它来捕获 EJB 技术域。可以使用 UML to Java 转换及其名为 UML to JAX-RS 的转换扩展来获取 JAX-RS 代码,以便生成 JAX-RS Web Service 元素的代码。

为实现此目标,我们提供了一个新的模型驱动架构支持增强,如图 1 所示。

图 1. 新的模型到模型和模型到代码转换扩展
RESTful API 模型转换自动生成
RESTful API 模型转换自动生成

要设计 EJB 和 JAX-RS 模型,则需要生成两个新的模型到模型转换。

  • JPA to EJB 3.0 转换
  • EJB 3.0 to JAX-RS 转换

将这些模型到模型转换作为插件来实现,它们会扩展 Rational Software Architect 工具。

当为方法实现调用两个新的转换扩展时,将会实现生成的 JPA 操作。这些转换扩展是:

  • UML to EJB 3.0 转换
  • UML to JAX-RS 转换

模型到模型转换设计和规则定义

在这一节中,将通过使用模型到模型转换来设计 JPA 和 EJB 3.0 模型,这些模型转换是使用 Model Transformation Authoring Framework (MTAF) 构建的。MTAF 是一个用来实现 IBM Rational Software Architect 和 IBM® InfoSphere Data Architect 中的各种转换的工具。MTAF 框架允许定义任意域之间的转换。它还提供了个得到确认的 API,该 API 支持命令式和声明式映射。图 2 显示了用于模型转换的 JPA to EJB 3.0 模型的设计。

图 2. 用于模型转换的 JPA to EJB 3.0 模型的设计
 JPA to EJB 转换的结构图
JPA to EJB 转换的结构图

主要的转换(扩展了 RootTransform 类)被组织为一组 UMLKindTransform 类。在这些特殊的示例中,只有一个 UMLKindTransform 类实例。它包含从 ModelRule 类继承的一组转换规则类。

不过,JPA 和 EJB 3.0 的设计都基于相同的转换特性,如表 1 所示。

表 1. 模型到模型转换的设计特性
方向性无方向性
源 – 目标关系 不同的源模型和目标模型。源模型可以是一个嵌套的包。目标模型不能是一个嵌套的包
渐进性 利用 Fuse Utility Class 来调用比较框架和合并框架。
转换生命周期的管理 通过调用 IrunTransformationListener 接口来控制转换的开始和结束。
映射类型允许显式控制转换规则的执行。映射类型是必不可少的。
规则定义 域:元对象设施 (MOF)
应用条件:在 canAccept() 方法中实现
泛型参数化:使用 generics 作为一个参数
规则调度:规则是按一定的顺序执行的

模型到代码转换的设计

IBM Software Architect 包含一个预定义的 UML to Java 转换,您可以通过使用 Eclipse 扩展机制来扩展它。转换的创作者只能通过扩展转换的一部分(执行一个或多个 UML 模型元素)来做出贡献。UML to EJB 3.0 和 UML to JAX-RS 转换扩展是在该特性的基础上进行开发的。这两个扩展都旨在扩展 UML to Java 转换,该转换将 UML 操作类转换成了方法声明。

工作示例

在本文的整篇文章中,都使用域设计 UML 模型样例(如图 3 所示)作为模型转换的输入。从该模型开始,EJB 3.0 和 JAX-RS 的设计与实现都是自动生成的。

样例 JPA 模型(如图 3 所示)由两个实体组成:UserPages,以及它们之间的组合关系。这个业务领域背后的理念是创建名为 VirtualDiary 的应用程序,允许用户拥有一个由任意数量的页面组成的在线日记。每个页面都有一个标题、内容和创建日期。每个用户都与无限数量的页面有关。用户个人资料包含以下信息。

  • 名字
  • 姓氏
  • 出生日期
  • 用户名
  • 密码

用户名和密码字段非常重要,因为它们允许用户进行登录,对于这个特定的操作,创建了自定义命名查询。

图 3. 样例 JPA 域模型
VirtualDiary 应用程序的 UML 类图
VirtualDiary 应用程序的 UML 类图

先决条件

在继续本文中的后续步骤之前,必须满足一些先决条件和后置条件。这些条件是:

受支持的执行环境

部署 JPA、EJB 和 Web 项目到 IBM® WebSphere® Application Server 或 IBM® WebSphere® Liberty Profile 上。

应用内置和自定义 UML 配置文件

将以下 UML 配置文件应用于 EJB 目标模型。

  • EJB 3.0 转换配置文件: Rational Software Architect 中提供的内置配置文件
  • Java 转换配置文件:Rational Software Architect 中提供的内置配置文件
  • 用于实现 JPA to EJB 转换的 JPA 配置文件:自定义配置文件,在 com.ibm.rational.transform.demo.jpa2ejb 插件中提供
  • 用于实现 JPA to EJB 转换的 EJB 配置文件:自定义配置文件,在 com.ibm.rational.transform.demo.jpa2ejb 插件中提供

将以下 UML 配置文件应用于 JAX-RS 目标模型。

  • REST:Rational Software Architect 中提供的内置配置文件
  • JAX - RS:Rational Software Architect 中提供的内置配置文件
  • 用于实现 EJB to JAX-RS 转换的 CDI 配置文件:自定义配置文件,在以下插件中提供:com.ibm.rational.transform.demo.ejb2jaxrs

已导入的模型库

将 J2EE 助手库(在 com.ibm.rational.transform.demo.jpa2ejbcom.ibm.rational.transform.demo.ejb2jaxrs 插件中提供)导入 EJB 和 JAX-RS 目标模型。将 Java Primitive Types 库(在 rational Software Architect 中提供)导入到 JAX-RS 模型。

设计和实现 EJB 3.0 方法

本文的这一节将向您展示如何生成以域 JPA 模型开始的 EJB 3.0 模型和代码。

JPA to EJB 3.0 模型到模型转换

EJB 通常被用作 JPA 实体的一个 façade,因为它们提供了事务管理功能。JPA 实体的 UML 模型表示了 JPA to EJB 3.0 模型到模型转换的源。转换输出是一个 EJB façade 的 UML 模型。本文中提供了映射规则,并使用 UML 元素的通用名称显示了它们的输出示例。

Package 规则的映射转换

描述

Package 规则将源模型中的每个 UML 包都转换成目标模型中的一个 UML 包。这里使用了包结构,每个生成的包都被附加到一个名为 ejbs 的嵌套包中。

元素

  • JPA 元素
  • 转换输出

图表

图 4. Package 规则的输入 JPA 模型的示例
JPA 包结构
图 5. EJB 模型中已生成的 UML 包
生成的 EJB 包结构

应用条件

该规则接受源包作为一个输入参数。

Entity to Bean 规则的映射转换

描述

JPA 模型中的实体被映射到一个无状态或有状态 bean。如果会话 bean 与接口之间存在一个实现关系,那么 JPA 模型也被映射到一个本地接口和一个远程接口(最多)。您可以选择生成一个单例 bean,但只能与有状态或无状态 bean 类型结合使用。您需要指定 bean 类型和接口作为转换参数。您还可以选择容器或 Bean 事务管理类型。

  • 容器:在您创建会话 bean 时,持久上下文被注入,新的实体管理器被实例化。
  • 有状态:持久性上下文被扩展。每个会话 bean 和接口都实现了一些操作来:
    • 创建实体
    • 更新实体
    • 删除实体
    • 通过 ID 发现实体。如果实体的 ID 值是复合值,那么键的所有字段都被传递给 findById() 操作。
  • 单例会话 bean:单例会话 bean 包含三个公共方法,而不是 CRUD 操作:
    • createCache()
    • deleteCache ()
    • refreshCache()

元素

  • JPA 元素
  • 转换输出

图表

图 6. 带有一个 id 属性的输入 JPA 实体的示例
Entity to Bean 规则中的 JPA 输入类

Bean 和接口类型

  • 本地和远程接口中的无状态会话 bean

转换管理类型

  • 容器
图 7. 使用两个接口作为 Entity to Bean 规则 的输出生成的会话 bean
生成的 EJB 3.0 元素
生成的 EJB 3.0 元素

应用条件

该规则接受 «Entity» 模式的应用程序中的类(作为一个输入参数)。这个类可以从 Java Persistence API Transformation 配置文件中获得。

属性规则的映射转换

描述

您可以根据 Generate Query methods for attributes 的值,选择为每种 bean 类型的每个实体字段生成一个 finder 操作。对于单例 bean,这些方法是私有方法。

元素

  • JPA 元素
  • 转换输出

图表

图 8. 包含一个 id 和非 id 属性的输入 JPA 实体的示例
包含一个非 id 属性的 JPA 实体
图 9. 包含已生成的 findByAttributeName 操作的单例 bean 类
生成的 FindByAttributeName 操作
生成的 FindByAttributeName 操作

应用条件

如果输入参数是 «Entity» 模式中的类,并且属性的一个转换属性 Generate Query 方法被设置为 true,则调用该规则。

Named 查询规则的映射转换

描述

会话 bean 可以为源实体中定义的每个自定义命名查询实现额外的操作。命名查询的参数成为了操作的参数。该查询被解析,以确定参数的类型和数量。新的依赖关系被创建。第一个依赖关系与和 @NamedQuery 模式有关联的源操作有关系;第二个依赖关系与已生成的操作中的源操作有关系。执行这一步是为了检索稍后的开发流程步骤中的查询名称(在调用 UML-to-EJB 转换扩展时)。第二个关系是在实体类和生成的操作中的 EJB 容器来之间产生的。

备注:
此关系被用在 JAX-RS 方法的实现中。

元素

  • JPA 元素
  • 转换输出

图表

图 10. JPA 实例中的命名查询元素的指定
自定义命名查询被用作 Named 查询规则的一个输入
自定义命名查询被用作 Named 查询规则的一个输入

命名查询字符串值:

图 11. 自定义命名查询字符串的指定
命名查询字符串的示例
命名查询字符串的示例
图 12. 从 Named 查询规则生成的 EJB 3.0 操作
生成的操作中的会话 bean
生成的操作中的会话 bean

应用条件

如果以下条件成立,该规则接受 UML 操作作为一个输入参数:

  • 模式 «NamedQuery» 被应用,它包含在 Java Persistence API Transformation 配置文件中。
  • 转换属性 Generate operation for custom named queries 被设置为 true。

表 2 概括了转换属性,包括 custom defined configuration 选项卡中定义的参数。

表 2. JPA to EJB 3.0 模型到模型转换中的转换参数
名称类型
会话 bean 类型 字符串 Stateful, Stateless, Stateful/Singleton, Stateless/Singleton
转换类型 字符串 Container, Bean
接口类型 字符串 Local, Remote, LocalBean
属性的通用查询方法布尔值 True, False
来自自定义 NamedQueries 的通用操作布尔值 True, False
JPA 项目名称(可选) 字符串

在定义了业务模型之后,下一步是为 JPA 实体生成 Java 代码。为此,可以调用预定义的 UML to JPA 转换。为了实现转换来解析所有自定义命名查询,必须在调用 JPA to EJB 3.0 模型到模型转换之前实现这些实体。执行以下步骤来获得 EJB 3.0 模型。

  1. File > New > Transformation Configuration
  2. JPA to EJB model to model transformation 文件夹中选择 JPAtoEJBTransformation
  3. 单击 Next
  4. 选择源模型和目标模型
  5. 单击 Next
  6. extensions 页面显示了可用转换扩展的列表。选中 ID 复选框:com.ibm.rational.transform.demo.jpa2ejb.extension.GUI,如图 13 所示。
  7. 单击 Next
图 13. JPA to EJB 3.0 转换配置文件 中的 Extension 选项卡
JPA to EJB 3.0 转换文件中的 extension
JPA to EJB 3.0 转换文件中的 extension
  1. 图 14 显示了第一组转换属性。
    • 转到 Generate query methods for attributes,将该属性的值设置为 true
    • 转到 Generate operations from custom NamedQueries,将该属性的值设置为 true
    • 输入 JPA project name,其中的 JPA 实体已实现。
  2. 单击 Next
图 14. JPA to EJB 3.0 转换配置文件的 Properties 选项卡
转换属性的示例
转换属性的示例
  1. 选择每个实体的 bean 类型、事务和本地接口,如图 15 所示。
图 15. JPA to EJB 3.0 转换配置文件中包含其他属性的 Custom 选项卡
custom 选项卡中的其他转换属性
custom 选项卡中的其他转换属性
  1. 要开始转换,请单击 Finish
  2. 打开转换配置文件的第一页。
  3. 单击 Run

生成的 EJB 3.0 模型如图 16 所示。

图 16. 作为 JPA to EJB 3.0 模型到模型转换的结果的 EJB 3.0 模型
生成的 EJB 3.0 模型
生成的 EJB 3.0 模型

JPA to EJB 3.0 模型到模型转换的一个限制是继承类的转换。JPA 继承性非常复杂,因为它可以映射到不同的数据库结构(Single Table、Joined 或 Table Per Class)。因为这极为复杂,所以超出了本文的讨论范围。

UML to EJB 模型到代码转换的扩展

EJB façades 需要实现所有 CRUD 方法来访问 JPA 实体。这些方法的实现基于一些编程模式,这些编程模式类似于受 Rational Software Architect 和 IBM Rational Application Developer 支持的 JPA Manager Beans。不过,那些反映了 Stateful and Singleton Beans 的行为的编程模式被添加到 UML to EJB 模型到代码转换扩展。这些模式是通过事务管理类型来区分的。正如 JPA to EJB 3.0 模型到模型转换 部分所提到的那样,您可以在以下这些项中进行选择。

  • 一个容器事务,其中的 EJB 容器设置了事务的边界。
  • 一个 bean 托管事务:EJB façades 被显式标出。

使用 Entity Manager API 来:

  • 创建一个实体
  • 更新一个实体
  • 删除持久性实体实例
  • 通过主键找到一个实体
  • 查询实体

对于容器托管事务,Entity Manager 是通过容器创建的,该容器使用了 persistence.xml 中的信息。Entity Manager 是通过 @PersistenceContext 注释注入 EJB 类的。

对于 bean 托管事务,持久性上下文不被传播到会话 bean,Entity Manager 实例的生命管理周期是通过应用程序进行管理的。在此实例中,应用程序通过使用 javax.Persistence.EntityManagerFactorycreateEntityManager() 方法创建了 Entity Manager 对象。

您需要创建一个新的转换配置选项卡,在 CRUD 方法的实现中生成 EJB 3.0 代码。创建该选项卡。

  1. File > New > Transformation Configuration
  2. 从 Java Transformations 文件夹中选择 UML-to-EJB 3.0
  3. 输入名称并配置文件目标
  4. 单击 Next
  5. 选择生成的 EJB 3.0 模型作为源模型,选择 EJB 或 Web 项目作为目标模型
  6. 单击 Finish 并打开转换配置文件
  7. 在 Extensions 选项卡下,选择与 com.ibm.xtools.transform.uml2.ejb3.java.internal.UML2EJBTransformExtension 有关的 ID 复选框
图 17. UML to EJB 3.0 转换的 Extension 选项卡
extension 选项卡
extension 选项卡
  1. 单击转换配置文件的首页上的 Run 按钮来启动转换。

EJB 3.0 代码是在 EJB 3.0 设计中指定的方法的实现中生成的。

生成 JAX-RS 设计和实现 JAX-RS 方法

这一节将介绍如何使用 EJB 3.0 to JAX-RS 模型到模型转换生成 JAX-RS 设计并实现其方法。这一节的起始模型是上一节中生成的 EJB 3.0 模型。

EJB to JAX-RS 模型到模型转换

EJB façades 可以暴露为 RESTful 资源,以便可供 Web 2.0 应用程序使用。EJB façades 的 UML 模型被转换成 JAX-RS 资源的 UML 模型,该转换是通过应用一个自定义 EJB 3.0 to JAX-RS 模型到模型转换来实现的。映射规则是使用 UML 元素的通用名称来定义的。

Packagerule 的映射转换

描述

如果目标是一个模型,则会在目标模型中创建一个新包。如果目标是一个包,那么目标包必须是根包。源模型的包结构已重新在目标模型中创建,但调用了 ejbs 的源模型中的每个嵌套包都将被转换成调用 jaxrs 的包。

元素

  • JPA 元素
  • 转换输出

图表

图 18. 输入 EJB 3.0 模型元素的包结构
输入 EJB 3.0 模型到包规则
图 19. JAX-RS 模型中生成的包结构
生成的 JAX-RS 模型

应用条件

该规则接受源包作为一个输入参数。

Application 规则的映射转换

描述

该转换创建了一个新的 UML 类。该名称被构造成目标 JAX-RS 模型的名称,并被附加到后缀 Application 中。该类是在 JAX-RS 模型的根包中生成的。在 REST 配置文件中,将模板 Application 应用到于这个已生成的类上。

元素

  • JPA 元素
  • 转换输出

图表

图 20. Application 规则的输入 EJB 3.0 模型元素
Package 规则中的相同输入模型
图 21. 作为 Application 规则的结果的已生成的 Application 类元素
包含生成的 Application 类的 JAX-RS 模型
包含生成的 Application 类的 JAX-RS 模型

应用条件

该队则接受源包作为一个输入参数。

Bean to Resource 规则的映射转换

描述

每个会话 bean(包含 StatelessSingleton 模式的 application 类)都被映射到一个资源。JPA 模型的结构确定了 JAX-RS 模型的结构。因此,保持源 EJB 类及其相关实体之间的依赖关系非常重要。在此上下文中,表示 JPA 实体的 UML 类被划分成两组,根据它们是否是复合聚合(composite aggregation)和另一个实体类的结束部分

  • JPA 实体 "包含" 在其他任何 JPA 实体中 – 相应的 EJB Class 元素被转换成一个 JAX-RS Root Resource。在 Root Resource 和包含 "{name}/{entity name}" 的 Application 类之间,新的依赖关系被创建。«Path» 模式被应用于该依赖关系。相应会话 bean 类型的新属性被添加到资源类(包含 «Inject» 模式的 application 类)。此模式可用于自定义 CDI Profile 中。
  • JPA 实体 "包含" 在另一个 JPA 实体中 – 相应的 EJB Class 元素被转换成一个 JAX-RS Sub-resource。在 Sub-resource 元素及其容器资源之间创建了依赖关系。因为只可以从 Sub-resources 的父资源到达 Sub-resources,所以一个新的 Sub-resource 定位操作被添加到资源容器。根资源和 Sub-resource 之间的依赖关系的 URI 名称是 "/{entity name}/{id attribute}"。相应会话 bean 类型的新属性也被添加。使用 Java Naming and Directory Interface ( JNDI) 定位此 bean。

此规则的另一个重要方面是所生成资源的可视范围。Signleton bean 被映射到 «ApplicationScoped» 模式中的资源,而 Stateless bean 被映射到 «RequestScoped» 模式中的资源。

元素

  • JPA 元素
  • 转换输出

图表

图 22. 从不 “包含” 在其他任何 JPA 实体中的某个实体中生成的输入会话 bean
输入会话 bean 的示例
图 23. 利用 Application 类的依赖关系生成的 Root Resource 类元素
生成的 JAX-RS Resource 元素

应用条件

该规则接受包含 «Stateless» 或 «Singleton» 模式的 application 类的 UML 类 元素。

Operation 规则的映射转换

描述

从一个会话 bean 中的每个操作,在 JAX-RS Resources 中创建一个新操作,使用与原始方法相同的名称和参数。表明了请求方法指示器的模式被应用于每个已生成的方法。表 4 显示了这些模式的应用。

元素

  • JPA 元素
  • 转换输出

图表

图 24. 会话 bean 操作被用作 Operation 规则的一个输入
包含 6 个 UML 操作元素的输入会话 bean
图 25. Resource 类中的已生成的 POST、PUT 和 DELETE 操作以及其路径值中的两个 GET 操作
从 Operation 规则生成的 JAX-RS 元素
从 Operation 规则生成的 JAX-RS 元素

应用条件

该规则接受源元素 UML 操作,包含在以下模式的一个 UML 类中:«Stateless» 或 «Singleton»。此外,该容器必须与一个 JPA 实体存在依赖关系,而该操作必须是公共操作。

表明了请求方法指示器的模式被应用于每个已生成的方法,如表 4 所示。

表 4. 表明 JAX-RS 方法上的 HTTP 方法指示器的模式的应用
操作类型表明方法指示器的模式路径值
创建 «POST»未指定
更新 «PUT»未指定
删除 «DELETE»未指定
通过 id 查找 «GET»" /{id}"
其他探测器 «GET»" /" + 操作名称

转换参数(包括自定义配置选项卡中定义的那些参数)如表 5 所示。

表 5. EJB 3.0 to JAX-RS 模型到模型转换的转换参数
名称类型
使用介质类型来创建、更新和删除方法类型字符串 JSON、XML、JSON (XML)
允许组合使用介质类型和注释,将它们应用于自定义探测器方法的输入参数上字符串 @FormParam/FORM_URLENCODED
/JSON
/XML
/JSON(XML)
@QueryParam/
生成介质类型字符串 JSON、XML、JSON (XML)

已生成的方法可以使用和生成 JSON 或 XML 格式的消息。假设生成的 JAX-RS API 主要用于 WebSphere Application Server 或 WebSphere Liberty Profile。不过,这些环境为 JSON 和 XML 格式的序列化和反序列化提供了支持。

根据以前生成的 EJB 3.0 模式来生成 JAX-RS 设计。

  1. File > New > Transformation Configuration
  2. 选择 EJB-to-JAX-RSTransformation
  3. 指定 nameconfiguration file destination,然后单击 Next
  4. 选择以前生成的 EJB 3.0 模型作为源模型。
  5. 选择目标模型。
  6. 单击 Next
  7. 包含可用转换扩展的页面将会打开。选中包含 ID com.ibm.rational.transform.demo.ejb2jaxrs.extension.GUI 的扩展,如图 26 所示。
  8. 单击 Next
图 26. EJB 3.0 to JAX-RS 转换配置文件的 Extension 选项卡
EJB 3.0 to JAX-RS 转换中的 extensions
EJB 3.0 to JAX-RS 转换中的 extensions
  1. 在 Transformation properties 向导的最后一页上,选择方法类型以及 Consumes(使用)Produces(生成)哪些类型。
  2. 选择将应用于某些方法的参数的注释类型。
  3. 单击 Finish。图 27 显示了最后一页。
图 27. EJB 3.0 to JAX-RS 转换配置文件的参数
EJB 3.0 to JAX-RS 转换的其他属性
EJB 3.0 to JAX-RS 转换的其他属性
  1. 打开转换配置文件的第一页。要调用转换,请单击 Run

图 28 显示了生成的 JAX-RS 模型。

图 28. 作为 EJB 3.0 to JAX-RS 模型到模型转换的结果的 JAX-RS 模型
生成的 JAX-RS 模型
生成的 JAX-RS 模型

UML to JAX-RS 模型到模型转换的扩展

所选中的编程模式将根据资源类型来实现 JAX-RS 方法。JAX-RS 根资源类通过上下文依赖关系注入 (CDI) 获得了对企业 bean 实例的引用。这意味着对根资源中某个企业 bean 的引用已使用 @Inject 注释进行注释。不过,在子资源中,对企业 bean 的引用是通过 JNDI 查找获得的(使用 Java Naming and Directory Interface 语法)。根据 JAX-RS 规范,不能将子资源暴露为一个 CDI bean。在此转换中,java:global JNDI 命名空间被用作为通过 JNDI 查找发现企业一种可移植方式。JNDI 地址是使用以下形式构造的。

java:global[/application name]/module name/enterprise bean name

应用程序名称是可选的,只在应用程序被打包到一个 EAR 中时才需要。您可以指定此名称作为配置选项卡扩展中的转换参数。

如果定义了一个应用程序名称,那么它将包含在查找字符串中。模式名称可以使用以下两种方式之一进行检查:

  • ejb-jar.xml 文件。在 EJB 项目是名称并且会话 bean 被实现的时候使用。
  • web.xml 描述符。如果未指定自定义模式名称,那么该转换将会采用 JNDI 地址字符串中的自定义模块名称。

每个 JAX-RS 操作都会调用相应的 EJB 方法。

执行以下这些步骤来生成 JAX-RS 代码:

  1. File > New > Transformation Configuration
  2. Java Transformations 文件夹中选择 UML to Java
  3. 输入名称和配置文件目标。
  4. 单击 Next
  5. 选择已生成的 EJB 3.0 模型作为源模型,选择 Web 项目作为目标模型。
  6. 单击 Finish
  7. 在 extensions 选项卡上,选择包含 ID com.ibm.xtools.transform.uml2.jaxrscom.ibm.xtools.uml2jaxrsExtension 的那些项的复选框。
图 29. UML to Java 转换的 Extension 选项卡
UML to Java 转换扩展的列表
UML to Java 转换扩展的列表
  1. 单击转换配置文件的主页面上的 Run 来启动转换。

结束语

最初的解决方案(本文中介绍的解决方案)是手动解决方案。因为域 JPA 模型的复杂性的不断增加,手动解决方案所涉及的时间和细节也会显著增加。

建议的解决方案在生成 EJB 和 JAX-RS 模型与代码时是完全自动的。这一过程耗时两个小时,不会涉及最初 JPA 模型的复杂性。

本文中还讨论了绑定的选择。在了解所生成的 JAX-RS API 的可预测性时,它们非常重要,这是开发生产力的另一个重要方面。

按照已建立好的标准和格式,本文中提供的最佳实践和选项应该会导致一个一致的、容易理解的、可预测的 API 设计。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational, Information Management
ArticleID=1005174
ArticleTitle=加快 Java 企业应用程序的设计和开发
publish-date=05052015