领域模型设计详细举例

领域模型设计详细举例

目 录

1

2 系统框架 . ......................................................................................................................................... 3 层次介绍 . ......................................................................................................................................... 3

2.1 表示层 ..................................................................................................................................... 3

简单领域模型 ................................................................................................................. 3

2.1.2 复杂领域模型 ................................................................................................................. 4

2.2 业务流程层 ............................................................................................................................. 5

2.2.1 简单领域模型 ................................................................................................................. 5

2.2.2 复杂领域模型 ................................................................................................................. 5

2.3 服务层 ..................................................................................................................................... 6

2.3.1 简单领域模型 ................................................................................................................. 6

2.3.2 复杂领域模型 ................................................................................................................. 6

2.4 集成层 ..................................................................................................................................... 7

2.5 开发 ......................................................................................................................................... 8

2.6 管理 ......................................................................................................................................... 9

2.7 安全性 ................................................................................................................................... 10

3 组件视图 . ....................................................................................................................................... 10

3.1 RFID 部署实例 . .................................................................................................................... 12 2.1.1

1 系统框架

例如，RFID 框架架构以BEA WebLogic Platform 为基础，满足RFID 支柱技术的一系列核心要求，同时具有适应不断变化的业务需要的技术灵活性。

每一层都有一组明确的功能，而且都利用定义明确的接口与其他层交互。分离组件使应用有了更好的可维护性和可扩展性。下一节将详细介绍图 1 中所示的解决方案架构中的每一层。

2 层次介绍

2.1 表示层

2.1.1 简单领域模型

表示层是直接的表示层，直接用一些页面，客户端界面来描述。

消息通知机制：用简单的观察者模式来描述。

2.1.2 复杂领域模型

表示层用Portlet 来描述。

消息通知机制用发布-订阅模式来描述。

表示层中所有组件起的都是系统接口的作用。这些接口使用户得以向系统发出请求。它综合使用 HTML (特别是表格) 、图形内容和 JavaScript 。

表示层以适于用户阅读的方式整合第三方EIS 和服务。灵活的导航系统方便使用内容管理功能。可定制的外观和感受可以为不同的用户群体提供不同的信息。

表示层提供了下列三个门户

− 配送中心 (DC)门户

− 供应商门户

− 零售店门户

针对这三个门户，提供了很多现成的 portlet 有些只是简单的显示 portlet ，而有些则提供复杂的用户交互功能。开发具有复杂用户交互功能的 portlet 时使用 Java 页面流。

Java 页面流将导航功能从显示中分离出来，执行数据验证和错误处理，并访问由业务流程层、服务层或者集成层提供的服务。图 3 所示为 Java 页面流出现在 WebLogic Workshop中的一个实例。

表示层充分利用了 WebLogic 平台提供的至关重要的基础架构服务。这些服务包括用于容 错（在 HTTP 会话中）、负载均衡、配置、登录和错误处理中的用户会话数据副本。 表示层隐藏了集成和处理的复杂性。与业务流程、服务和集成层的通信通过定义明确的接 口实现。因此，多个门户应用可以重复使用同一组业务服务。例如，用于提供客户服务门 户的许多服务都可以用于提供客户自助服务门户。

2.2 业务流程层

2.2.1 简单领域模型

1． 通常没有单独的业务流程层。与服务层合并在一起。

2． 流程在运用程序中固化，辅助以对象的手段

a) 面向对象多态

b) Xml / Ini / txt /配置文件

c) 代码级Ioc 注入接口，增强灵活性。

3． 有两种常用的模式：

a) 对上、下调用接口实现组件式的编程。

b) 扩充配置文件，变为围绕脚本语言式的软件结构。

4． 通常是同步的流程。

2.2.2 复杂领域模型

1． 单独的业务流程层，一般需要工作流引擎；在很多特定的运用中，甚至是用户操作驱

动的流程。

2． 固化基础流程和行业通用的流程（很难与业务无关）。

3． 通过事件驱动，例如RFID 的数据事件。

a) 广泛使用发布-订阅模式。

b) 广泛使用消息队列等技术。

c) 业务流程是消息总线上事件的使用者。

4． 可以创建、执行、管理和监视业务流程（通常是通过流程编辑器设计工作流引擎）

5． 通常需要考虑设计出符合 SOA 架构的业务级服务。这些服务可由任意多个功能级或

者数据级服务组成。

6． 通常要考虑异步流程。

业务流程层囊括了应用对工作流的所有需要。它提供了使业务流程自动化和减少或消除为 完成业务流程所需要的人工干预的能力。业务流程层协调服务、数据源以及人之间的交互，从而实现业务流程自动化。

连接 RFID 解决方案最重要的一个接口就是通过业务流程层实现的。因为，RFID 解决方案主要是解决集成问题，事件模型和 RFID 消息总线是该架构的两个关键组件，是作为接入系统的主要接口。

事件模型监听与渠道相关的外部源（如，EDI 和 FTP ）事件以及包含阅读器数据的 JMS 事

件。RFID 消息总线负责将放置在总线上的消息传送给一个或多个感兴趣的接收者。 这一层的构成中还包含一组与 RFID 相关的业务流程，负责处理那些到达消息总线的消息。解决方案预封装了如下流程：

本层中的业务流程是消息总线上事件的使用者。一个或多个流程可处理同一个事件。业务流程层的核心是 BEA WebLogic Integration，它提供了在其上创建、执行、管理和监视业务流程的关键基础架构。WebLogic Integration 还包括通信和数据转换功能。其他系统因此可以被纳入到业务流程之中。

BEA WebLogic Integration 业务流程是制作业务级服务的一种理想方式。这些服务可由任意多个功能级或者数据级服务组成，并且是符合 SOA 架构的。利用 WebLogic Workshop 开发环境，WebLogic Integration 业务流程可自动地展现为 Web 服务，无需增加任何代码。 业务流程层通过意义明确的接口与服务层和集成层进行通信。

2.3 服务层

2.3.1 简单领域模型

1． 服务层直接管理整个系统的流程，组织整个系统的业务逻辑。

a) 通常不是用框架或使用轻量级框架。

b) 对外暴露接口。

2． 进行数据处理，对下直接调用Dao 和BO/DO，

a) 以直接的接口调用的方式从数据库中取数据。

3． 对上被UI 或其他系统调用。

2.3.2 复杂领域模型

1． 执行业务逻辑。

2． 进行数据处理。

3． 支持企业应用的重要基础架构

a) 通常需要使用框架，甚至重量级框架。

b) 为外暴露Web 服务，成为可供重用的服务。

c) 提供必要的基础架构服务，如容错数据副本、负载均衡、安全、线程管理、配置、

登录、错误处理、事务管理、系统监视、环境管理等。

d) 以复杂的方式从集成层获取数据。

服务层是执行业务逻辑和进行数据处理的地方。它还提供了用于支持企业应用的重要基础 架构。服务层最常见的组件是 Enterprise Java Beans (EJB)和面向 Web 服务接口的定制控 件。控件是较新的 Java 结构，使用它开发者不必了解复杂的 J2EE 就可以构建业务逻辑。 由开发人员构建业务逻辑，由 BEA WebLogic Workshop 框架创建适当的 J2EE 结构（如， 无状态会话 bean 、有状态会话 bean 、实体 bean 、消息驱动 bean 等），从而提供所希望得到的操作。

BEA WebLogic Workshop 框架还为控件生成 Web 服务。这为应用生成可重复使用的服务提供了一种便捷方法，进一步促进了 SOA 的推广。各种表示设备、业务流程或其他应用也可以使用这些服务。

服务层存放在 BEA WebLogic Server 上。BEA WebLogic Server 提供必要的基础架构服务，如容错数据副本、负载均衡、安全、线程管理、配置、登录、错误处理、事务管理、系统监视、环境管理等。

服务层依赖集成层从不同的外部源获得所需要的数据、存储数据和向/从其他相关系统发送/接收信息。

2.4 集成层

2.4.1 简单领域模型

仅为Dao 层，访问数据库。加上各种数据访问框架（JDO 、iBatis 、Hibernate 、Ossage 等）。

2.4.2 复杂领域模型

1． 访问的模块：

a) 外部系统（PIM 、ONE 、ECP-IS ）。

b) 访问各种数据库管理系统。

2． 访问机制：

a) JDBC （数据库）

b) LDAP-API （LDAP ）

c) Portal SPI (内容管理系统)

d) JCA 适配器、数据引擎（SAP 和 Siebel ）、Web 服务

e) JMS 实现异步方式

3． 完成数据集成服务。（是SOA 中又一个重要的服务提供领域）。

集成层提供访问 RFID 应用以外其他企业信息系统(EIS)的功能。这一层隐藏了从架构中级 别较高的层次访问外部系统的复杂性。对 RFID 来说，外部系统包括但不局限于以下系统： − Velosel 公司的产品信息管理系统（PIM ）

− VeriSign 公司的对象名称服务系统（ONS ）

− Connecterra 公司的 ECP-IS

− 各种数据库管理系统

访问这些外来系统的机制可以多种多样。对数据库的访问通过JDBC 来实现。访问目录服务（如 LDAP ）可以通过标准的 LDAP 应用编程接口实现。访问内容管理系统可以通过 WebLogic Portal 内容管理服务提供商接口 (SPI)。访问 PIM 、ONS 和 EPC-IS 可以通过 Web 服务接口实现。

访问其他系统的方法有许多，如 JCA 适配器、数据引擎（SAP 和 Siebel ）、Web 服务等。 假如 Web 服务是标准的而且是免费的，那它将是最有前途的一种集成方法。然而，因为它是一种相对比较新的技术，只有某些最新版本的 EIS 产品才有此项功能。最简单的配置方法是利用适配器。它们使利用源数据浏览和进行 XML 转换变得非常轻松，但是这项功能需要付费。

Java Messaging Service (JMS) 提供了一种以异步方式与外部系统集成的方法。JMS 使系统能够对后端系统进行异步呼叫；反过来，后端系统也可以在 RFID 解决方案中发起异步处理。例如，处理传入阅读器事件就是由 RFID 解决方案异步完成的。

当解决方案必须包含数据聚集部分时，这一层应当有 BEA Liquid Data for WebLogic。Liquid Data 能够访问多个数据源并且将数据整合到一个聚合视图中，从而提供了一个实 时显示多数据源数据的统一视图。

数据集成是 SOA 中又一个可提供服务的领域。用于管理数据的控件可以被展现为提供数据访问功能的服务。为企业提供业务功能和流程的其他服务可充分利用这些服务。

2.5 开发

2.6 简单领域模型

1． 面向对象方式，基于类、接口、配置文件；组件式。

2． 一些特定的运用

a) 算法密集型

b) 数据库密集型

c) 海量数据型

d) C / 汇编等实现的控制系统等

2.6.1 复杂领域模型

1． 半平台式的开发

a) 业务梳理

b) 流程设计

c) 考虑部署、实施。

RFID 解决方案的开发层由 BEA WebLogic Workshop 提供。该层涵盖了表示层、业务流程层、服务层和集成层，因为 WebLogic Workshop 为这四个层次提供的是统一的开发环 境。下图是 WebLogic Workshop 的屏幕快照：

即取即用，RFID 解决方案提供了许多预打包的流程和 portlet ，以帮助启动建设与 RFID 相关的解决方案。

由于具备自动生成 Web 服务的能力，WebLogic Workshop 提供理想的面向服务的应用开 发（SODA ）环境。简单地提供 WSDL 文件的位置就可以创建 Web 服务控件来使用 Web 服务。点击鼠标就可以将 WebLogic 控件和业务流程展现为 Web 服务。这种易用性节约了构建 SOA 应用过程中的大量时间。

2.7 管理

管理层控制初始配置和管理功能，并为 RFID 解决方案提供运行和维护服务。WebLogic Integration 控制台用于配置业务服务和监视可配置的流程级 SLA 。JCA 适配器和事件通道也通过基于Web 应用的控制台进行管理和监视。 WebLogic 管理控制台用于实际上处于服务器级的低级管理任务。这些任务包括管理到数据库和其他数据源的连接，以及管理对服务器端其他资源（如 EJB 、JMS 、群集、线程管理等等）的连接。WebLogic 管理控制台还用于配置安全接口，以便在必要时与活动目录系统（Active Directory system）配合使用。 门户管理工具是一种 Web 应用，完成门户特有的管理任务，如修改用户档案、设置门户特有的安全性以及控制对管理工具自身的使用等。只有利用门户技术的解决方案才需要门户管理工具。

日志也在这一层进行配置，以确定系统输出的消息的本质和类型。日志级别也可配置，以 帮助完成调试或满足更严格的安全性要求等任务。

域配置是整个 WebLogic 平台配置的一个扁平化版本。该组件掌管系统级配置，如端口数、

网络地址等。在一个可运行的系统中，使用管理控制台对域配置进行更新。

RFID 配置是该解决方案特有的针对解决方案的配置。该组件配置的内容包括 RFID 服务、适配器、控件和用户接口，它被用于将架构各层联系起来形成一个整体。

2.8 安全性

对于向客户和业务部门提供新的广泛的服务的信息技术（IT ）组织而言，部署、管理和维护安全性是一个巨大的挑战。为了提供一个面向内外用户的全球性网络，IT 组织必须解决保证系统及其数据的保密性、完整性和可用性的一系列重要问题。安全性问题涉及到系统的每一个组件，从网络本身到各台客户机。确保整个基础价构的安全性是一项复杂工作，既需要保持高度的警惕，也需要建立完善的、沟通良好的安全策略和程序。

RFID 解决方案架构提供应用级的安全性，属于网络和操作系统等较低层次的安全性。该 架构包括基于 SSL 的 Web 访问，以确保用户信息不被未经授权者截获或阅读。该架构还包含基于公司 LDAP 目录中用户信息的用户登入/登出功能以及当用户不活动的时间达到所配置的时间长短（如，20 分钟）时的自动登出功能。

集成层本身的安全性是依靠操作系统级的安全功能来保证的，就像知道允许其他外部访问 一样。

3 组件视图

前面介绍了 RFID 架构。RFID 解决方案还有一种视图就是功能的组件视图，它反映了公 司希望在一个典型的 RFID 解决方案中所看到的功能。

10 10

图4 RFID功能的组件视图 上图表明了在 IT 环境中新的 RFID 系统与已有系统的关系。RFID 系统与许多已有系统相连，这些已有系统可能包括第三方 EIS 、Web 服务和Oracle 数据库。 RFID 系统提供了不同类型的集成方式，以使与第三方EIS 以及与其他系统集成时具有最大的灵活性。 与解决方案进行交互的方式主要有二种。一种是通过集成来自阅读器和 EDI 的数据。WebLogic RFID Edition 通过 JMS 将消息传递给事件模型。然后，事件模型创建一个相应的包含有所接收事件的 RFID 消息，并将消息置于 RFID 消息总线上。供应商也可以利用EDI 或者 FTP 接口将发货通知单（ASN ）以及其他类型的信息传输给系统进行处理。

另一种方式是通过交互模型所提供的人机接口。交互模型由预先封装的和/或定制的portlet 构成。这些 portlets 也构造 RFID 消息，并将这些消息放置在消息总线上。在适当的地方，交互模型还可以直接利用服务层。

RFID 消息总线将接收到的消息传送给一个或多个感兴趣的客户。接收者的确定是通过配 置层动态决定的。消息本身是用 XML 写成。消息总线同步呼叫每一个感兴趣的客户（在

11

11

业务流程层），并且为每一个分享消息的感兴趣的收听者构造一个响应。通常只有一个收听者对一种事件类型感兴趣，但是事件收听者模型具有极大的灵活性。

业务流程层由一组采用同样接口的业务流程构成。每个流程都以 RFID 请求消息作为输 入，通过客户请求/响应接口返回 RFID 响应。业务流程本身决定了异步的程度，因为在完成所有业务逻辑之前就可以将响应返回给呼叫者。

业务流程层不能直接与内外服务进行交互。与这些系统的交互通过服务层进行。服务层由 一组标准接口组成 ，这些接口可由一个或多个提供商实施。可以利用控件直接访问服务 层，或者利用 Web 服务接口间接访问服务层。这种架构在部署上具有灵活性，而且解决了可伸缩性的问题。

EIS 特有的业务功能划归实施层。在这里使用特有的接口与第三方以及标准的集成策略相 连直接访问内外服务（包括 EIS ）。实施层也可以作为 RFID 消息总线的一个客户。 解决方案中预打包的与外部系统的连通性包括：Connecterra Edge Server 和 EPC-IS 所支持的 BEA’s WebLogic RFID Edition 、 Velosel 提供的 Product Information Management 、对 VeriSign 的 Object Naming Service (ONS)的访问，以及对仓库管理系统（WMS ）和货场管理系统（YMS ）的访问。

配置和管理层不是基于标准的 JMX 技术，在适当的地方用于将配置和元信息传输给需要的架构组件。

安全层也不是标准技术，由 WebLogic Platform 的安全模型提供支持。 跨所有层的快速开发功能由 BEA’s WebLogic Workshop 开发环境提供。

3.1 RFID 部署实例

RFID 解决方案可部署到多种硬件和操作系统上（如，Linux 、Windows 、Unix ），也可以部署到单机配置一个或多个 CPU 的一台或多台物理机上。下图是 RFID 解决方案的一个实际部署实例：

12 12

图 5 RFID 实际部署实例

上述实例是一个典型的零售环境。边缘服务器部署在需要阅读器和需要跟踪产品移动的位 置。这些位置包括各个商店和物流中心。

边缘服务器通过包括 HTTP/SOAP 在内的标准技术将 RFID 标记移动事件传递给数据中心。

数据中心建有解决方案栈，在有一个或多个数据中心的情况下，还共享数据。

集成和业务流程实施在安全可靠的数据中心环境中完成。

3.2 总结

13

13