dev2dev 首页 > 资源中心 > 技术文章
使用 WebLogic Workshop 构建过程驱动的应用程序
使用 WebLogic Workshop 构建过程驱动的应用程序
许多应用程序具有共同的特点：包括一系列的步骤或者“状态”。步骤之间的过渡由用户交互和与其他系统之间的交互控制。这类应用程序的例子包括：
订单入口：用户从产品目录创建一个在线订单。用户向库存管理提交订单以预留货物，并得到最终的报价。然后，用户作出最后的决定是购买还是放弃。系统在这个决定的基础上继续进行，执行订单取消、延迟交货等等的操作。
用户注册：新用户 —— 如一个新员工，必须进行注册以便在各种IT系统上创建一个帐号和个人信息。应用程序将提示用户已经在员工数据库中保存了信息，例如，专职员工必须签约雇佣合同，以得到保险金、股票购买计划等。但是一个临时工就不需要这些了。从用户发来的数据根据参数将提交到不同的后台系统。最后，各种后台系统中注册过程将汇报到需要输入更多信息的用户手中。
这里只是举了一些例子。很容易想象很多用例具有相同的基本特点。这篇文章将着眼于在 WebLogic Workshop中如何使用 Java 过程定义建立这样应用程序。
应用程序范例：订单入口
我们来详细查看一个应用程序范例。图 1 描述了一个订单入口向导的页面流。页面流基本上是一个 Struts 控制器和相关的 JSP 文件的图形化表示。以更简单的形式定义和阐明了
Web 应用程序如何从一个页面到另一个页面流动。我们探讨一下订单入口页面流：
- 用户从开始动作开始，然后迅速跳转到 Greeting 页面。从这里，用户将通过 getProduct 动作，进入到 orderProduct 页面。
- 用户从在线订单中选择产品，完成后开始 checkout 动作。
- 在检查过程中，应用程序将联系库存管理系统为这个订单预留货物，并联系客户数据库和产品数据库获取关于客户和产品的信息，以便计算出小计和合计数目。
- 为了达到最大的可伸缩性和健壮性，所有操作异步进行。其间，浏览器询问Web 应用程序直到应用程序从后台系统得到通知。这将在 pollCheckoutResponse
操作中和 waitForCheckout 页面进行。
- 当后台系统准备完毕，用户就能够回顾显示的最后订单。这将在showCheckedOutOrder 页面中执行。这时，用户可能要花点时间来考虑是否要下订单购买。在此期间，系统预留订单中请求的货物，因而当订单结束时即可立即提交给用户。
- 当用户最终决定了，仍有一些事情可能发生：
a. 用户决定取消订单 – CancelOrder 动作。这种情况下，系统必须在库存系统中取消货物预留，并发送用户返回到开始。
b. 订单超时是因为用户做决定花的时间太长，应用程序不能无限期的预留货物。货物将由库存系统取消预留，并且如果用户随后可通过 PlaceOrder 操作继续订单操作。这个操作侦测超时，并将用户发送到timedOut页面。
c. 在预期的时间内，用户通过 placeOrder操作继续处理订单。
- 如果用户决定在预期的时间内继续处理订单，应用程序将在 placeOrder 操作中提交订单到各个后台系统中执行。如前面提到的，这些将以同步方式执行。因而，当订单正在处理，浏览器显示在等待页面
– waitForOrderPlaced 将使用 pollOrderPlaced 操作询问 Web 应用程序。
- 当后台系统已经完成订单处理，他们将对Web 应用程序做出响应，响应将在orderPlaced页面上显示给用户。
图1 ：订单入口应用程序页面流
实现中的挑战是什么？
现在，我们已经从前到后查看过这个应用程序的流程。但是很清楚，在实现前面所描述的清晰的或模糊的逻辑过程中，还存在许多挑战性的问题。
首先，我们并没有真正说明如何访问后台系统。第二，我们执行了很多异步操作，而大家知道在J2EE中比较难以实现的异步操作。第三，我们也需要在某种程度上管理状态。我们考虑一下这些问题，并如何着手解决掉这些问题。
访问系统资源
构建过企业应用程序的人知道，连接到现有系统并交换数据是非常复杂的事情。大量的技术都应用到这个方面，如 JDBC、JCA、Web 服务、JMS和更专有的
API 函数。
构建这个应用程序的程序员需要某些处理更加普通化和更加简单化。他不应该参与到如何连接底层系统的实际细节问题。毕竟，这是一种管道，应该有基础架构来处理。
当使用BEA WebLogic Workshop构建应用程序时，使用 Java Control 提供底层资源的普通且简单的抽取方式。当然，有些人仍然需要写一个
Java 控件来访问每个后台系统，但是最常用的控件已经内置于 Workshop中，所以不必太苛求。例如：可以使用内置控件访问 EJB 、JDBC数据资源、Web服务和JMS文件。
不管是有人构建新的控件或是控件已经存在，控件使 应用程序员 访问系统资源变得非常轻松。控件的使用，让系统级工程师到应用级工程师定义一个可复用的、可交付的组件变得非常轻松自如。
异步操作
订单入口向导必须以异步方式访问后台系统，以获得最大的健壮性和可伸缩性。当许多系统连接在一起时，如果操作总是以异步方式完成，会导致不可预料的等待时间甚至是死锁。通过使用异步调用，底层系统的操作能够独立执行与用户和应用程序中运行的其他代码的交互。
常常遇到的问题是实现异步操作很困难。 J2EE中不能直接使用线程，所以不能简单得创建新线程（这个非常有意义）。 J2EE中实现异步操作的正确方法是使用JMS和消息驱动的控件（
MDB ）。然而，这种方法并不简单，包括设置 JMS 服务器和 JMS目标。在客户端必须实例化环境和工厂对象，通常还需要知道如何使用 JMS API 函数。在接收端，需要完成整个独立的MDB以接收消息并完成操作。这样做不但有难度，而且还会将你的代码增加到不同的新组件中，使得代码阅读和维护变得很困难。仅仅因为它们是异步调用，而使得你的业务逻辑的某些部分属于完全不同的组件，这样做看起来不太正确，难道不是么？
当然 ，也可以使用一些技巧来解决这些问题。但是，这只是附加的工作，因为您光为了完成基本的异步调用已经花费了大量的工作。
幸运的是，当使用Java控件和WebLogic Workshop时，事情不会这么艰难了。Java控件上的操作很容易被标记为异步的。它也将按照前面期望的和描述的那样正确执行。底层
Workshop 运行时框架提供了必要的MDB和JMS管道。这里不必了解JMS和MDB。
过程和状态管理
订单入口向导就是我们所谓的过程驱动应用程序，因为应用程序由遵循某一过程的一组步骤构成。过程阶段之间的转换，是由用户决定和系统信息基础决定来控制的。例如，是否有超时发生，库存中是否有足够的货物等。
当构建这样一个应用程序时，会有很多问题需要解决。应用程序必须一直知道当前处于哪种状态下，这些状态可能会对其他系统非常重要，而不仅仅是对用户。这种情况下，产生的影响比对用户的影响还多得多：如果丢失了状态，货物不能正确得返回到库存，会导致库存管理系统和物理库存之间有偏差。
这种状态是业务关键信息，所以这种状态必须按照需求保存足够长的时间，而且这种状态必须以交互的方式来访问以避免混乱。这根本不同于 HTTP 会话中保存的典型用户会话状态，具有相似的缺乏“安全”的存放位置。当用户会话状态丢失时，将影响用户体验，而不是系统状态。
除了状态管理还有大量的其他问题需要处理，例如异常处理、分组以及如何控制哪个操作能在哪种状态下执行等等。
使用WebLogic就不需要手工书写所有的代码。当需要构建过程时，可以使用WebLogic Workshop的Java Process Definition。过程定义已经包括了所有这些，并且许多能力已经内置到框架中，因此注意力可以集中在设计过程，然后让框架来完成剩余的工作。
监控
因为已经定义一个过程来驱动应用程序，您需要能够自动得将应用程序监控的更好。WebLogic可以监控所有在给定时间运行的过程实例，并且还可以查看已经完成过程的历史数据。可以监测到的内容有：
- 过程实例的完成时间。
- 过程实例一个阶段完成时间。
- 正处于等待状态的过程实例在哪里。
- 过程实例是否超出了服务协议内容。
- 发送到过程实例的数据。
- 过程实例包括的数据。
这只是管理控制台提供的监控能力的一部分。
不同的XML和Java Data Model协同工作
前面我们讨论过连接到不同后台系统时的问题。不幸的是，通过调用操作和接收响应，不足以能够与这些系统对话。当使用一些后台系统的API函数时，您不得不处理它们使用了哪种数据模型。当给系统发送数据时，必须以系统定义的某种格式进行保存。通常要么有一个
Java 类的图表作为数据容器，要么使用XML schema定义成XML格式。
问题是，在您自己的应用程序中，不可能总是使用相同的 Java 类或 XML 对象集合，并且需要对话的其他后台系统也很有可能没有使用相同的数据类型。每次接收从用户发来的数据，不得不将数据发送到某个后台系统，必须提取图表中的所有元素，并将其组装成特殊系统能够识别的数据对象。每次都执行相同的操作：接收到一个系统发来的数据，将其发送到另一个系统或者返回给用户。不得不将其发送到其他的系统并反馈给用户。这里有些手工操作，而且当数据格式发生变化时重复使用和维护将变得非常困难。
现在有许多技术使得这项工作变得很简单，他们是：
- XML Beans
- Xquery
- Visual Data Transformation Designer
XML Beans是BEA在Apache许可证下已经在开放源代码社区发布的框架结构。Apache许可证允许使用XML 文档作为Java对象，很轻松的将XML解析成Java图表，并且同样轻松的从Java对象集合生成
XML。
然而可以在完全脱离WebLogic的环境下使用XML Beans ，它被内置在WebLogic和WebLogic Workshop中，所以可以很轻松的从XML
shcema文件创建出XML Beans。这使得XML文档流到Java对象的数据转换变得极其容易。
一旦数据被表示为一个XML bean，可以使用XQuery表达式访问数据图表的单个元素。对于提取单个数据项或从复杂的重复数据集合中提取数据，这个表达式的功能非常强大。XQuery是一个由许多软件库和供应商支持的标准，所以可以在不同环境中重用XQuery表达式来表示相同的数据提取。
最终和最强大的工具是数据转换控件和可视化设计工具，可以在直观的可视化方式下设计数据转换。这个工具可以完全利用XML Beans和Xquery，展示源对象和目标对象的可视化图形，可在两张图上的元素之间画上连接线。因为构建的转换实际上是一个控件，所以可以在任何执行相同转换的地方重用它。因此只需要在一个地方维护转换，就可以在整个应用中使用了。
讨论
我们已经探讨了过程驱动应用程序的实现过程中遇到的问题特点。关键点在于，这是一种非常普通的应用程序，许多时间都浪费在重复实现相同的框架、模式和服务上，而这些框架、模式和服务对于过程驱动应用程序来讲是非常常见的。介绍
Java 过程定义概念将会使您将精力集中于编写过程，让基础架构处理其余事务。
Java 过程定义现在已经在Java Community Process 下标准化了。JSR 207 “Process Defination for
Java”（或缩写为 PD4J）是一个获得IBM 和其他公司（这些公司编写如何用经过注释的Java源码定义过程的程序）广泛支持的标准。获得广泛认可的是，企业基础架构必须直接支持构建和运行过程。这是如何构建未来IT系统的一部分内容。这是一个从固定的、严格的应用程序到构成企业信息网络的‘灵活易变’服务和数据的转变。
| 作者简介 |
Jesper Joergensen |
Jesper Joergensen 在Java企业软件工程和营销方面拥有7年多的经验。Jesper于两年前加入BEA，担任产品推广专员，主要负责面向服务架构与WebLogic Platform。在加入BEA之前，Jesper是Caput的CTO，该公司是欧洲最早研发出WebLogic之上的ISV产品的公司之一。在Caput的5年中，他负责技术和产品，并帮助该公司从一个当地的小公司发展为基于WebLogic应用服务器平台协作解决方案的J2EE组件的全欧供应商。这些工作使他获得了在WebLogic上构建J2EE应用程序的直接经验。 |
作者其它文章
|
