soa销售点样例.pdfVIP

示例：SOA 模型示例 • 问题描述 • 项目范围和目标 • 服务标识 • 服务设计 • 服务实现 问题描述 在此示例中，我们来看看一个选择将其销售点（PoS）终端的应用程序所使用的特定功能作为服 务重新实施的零售商所面临的问题。现在，贸易应用程序是作为单个应用程序开发的，该应用程 序有非常紧密耦合的组件，但有些组件驻留在商店内服务器（ISS）上，有些请求甚至被 ISS 转 发到位于企业中心的服务器。问题是，由于组件的紧密耦合以及在组件的开发和不同组件之间的 连接中使用了专有协议和技术，所以一般的商店基础结构和特定的贸易应用程序很难维护。 在以前的商店系统中，PoS 终端使用专有和低容量的机器，对于商店内和商店外的带宽有限制， 现在这些限制大多已不存在了。 知道了这一点，以及现有的在企业后端系统中向面向服务的体 系结构的转变，我们已决定 ISS 提供的一些功能和中央服务器应作为服务对贸易应用程序显 现。 项目范围和目标 最初要考虑选择的功能都有一个共同的模式：它们当前要求贸易应用程序中的逻辑在多个数据存 储器中查询信息。这样，提出的服务不仅提供了一个公共的接口，还使贸易应用程序与数据位置 的明确了解脱离，且不必处理多个协议。 • 客户查找；这是一个在终端执行的两步流程，对于已从商店中购买商品或在商店获得对 商品的服务的客户，在商店里有一个本地数据库。如果在存储数据库中找不到客户（对 数据库和执行的 SQL 查询进行直接连接），则贸易应用程序将使用消息队列方法通过 ISS 上的查询服务器查询中央客户数据库。新服务将位于 ISS 上，并作为与贸易应用 程序通信的单个点，应用程序将与 ISS 通信，ISS 将反过来查询本地数据库，然后将 请求转发给中央服务器上的另一个服务（实施相同的服务规范），中央服务器将查询其 本地数据库。 • 服务调度；在此情况下，客户希望对他们购买的商品调度服务，当前，贸易应用程序必 须查询客户数据库（请参阅上文）和中央保证数据库，看该商品是否受保证，并用客户 规划引入商品的日期／时间更新服务调度。看起来有更好的方法解决这个问题，新的调 度服务将如下运行。给定商品的序列号就能查询保证数据库；此数据库已经包含客户标 识，因此可同时抽取客户数据。如果客户只有商品的类型标识，则我们必须照以前那样 为客户和商品进行查询。所有这些都将由服务完成，除去贸易应用程序的逻辑。 • 库存检查；在此情况下存在类似的问题，服务首先查询本地实时数据库的库存，如果找 不到商品，则它将查询包含较少产品信息但包含所有存储库存（除了前一天晚上批量更 新，所以不受保证的那些库存）的企业数据库。新的 ISS 服务将聚集以上的查询，但 还将为中央服务器提供实时更新，以将库存更改事件传递到中心，并使得对其他商店的 查询更准确。这意味着中心的库存服务能接收这些库存更改事件，而本地服务则不能。 这些服务将通过 RMI 从贸易应用程序访问 ISS 服务，并使用 SOAP over JMS 从 ISS 到集 中服务。 服务标识 以下内容概述了体系结构团队所执行的步骤，该团队包括拥有 IT 组织的零售商成员和作为开发 面向服务解决方案的专家引入的外部顾问。请注意以下步骤并不表示推荐使用的 RUP 活动， 只是列出了实际项目的活动。 重要的是，注意此项目将改进当前现有功能的技术实施，所以没有花太多的时间在业务建模或分 析上，因为我们可以复用为原始贸易应用程序创建的模型。当前的模型集（在下图的左边）遵循 以下所示的结构，其中显示了 RUP 用例模型、贸易应用程序公共组件的分析模型、详细的设 计模型和一组用于 Java 开发团队的实施模型。 服务模型被作为分析模型的改进引入（在上图的右边）到一组具有其自己的实施模型的服务中。 现在可修改贸易应用程序设计以显示这些公共服务的用法，另外还显示了贸易应用程序和服务 Java 模型之间的关系。 服务模型创建 如下图所示，存储支持服务模型是根据软件服务的 UML 概要文件和模板模型（包含在 Rational Software Architect 中）创建的。如以上所示，该模型被标识为分析模型的改进。正如您所见， 在显示模板推荐的视图之间依赖关系的概述图中体现了该