领域模型设计详细举例.docx

领域模型设计详细举例.docx

《领域模型设计详细举例.docx》由会员分享，可在线阅读，更多相关《领域模型设计详细举例.docx（12页珍藏版）》请在冰豆网上搜索。

领域模型设计详细举例

领域模型设计详细举例

1系统框架

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

每一层都有一组明确的功能，而且都利用定义明确的接口与其他层交互。

分离组件使应用有了更好的可维护性和可扩展性。

下一节将详细介绍图1中所示的解决方案架构中的每一层。

2层次介绍

2.1表示层

2.1.1简单领域模型

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

消息通知机制：

用简单的观察者模式来描述。

2.1.2复杂领域模型

表示层用Portlet来描述。

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

表示层中所有组件起的都是系统接口的作用。

这些接口使用户得以向系统发出请求。

它综合使用HTML（特别是表格）、图形内容和JavaScript。

表示层以适于用户阅读的方式整合第三方EIS和服务。

灵活的导航系统方便使用内容管理功能。

可定制的外观和感受可以为不同的用户群体提供不同的信息。

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

−配送中心（DC）门户

−供应商门户

−零售店门户

针对这三个门户，提供了很多现成的portlet有些只是简单的显示portlet，而有些则提供复杂的用户交互功能。

开发具有复杂用户交互功能的portlet时使用Java页面流。

Java页面流将导航功能从显示中分离出来，执行数据验证和错误处理，并访问由业务流程层、服务层或者集成层提供的服务。

图3所示为Java页面流出现在WebLogicWorkshop中的一个实例。

表示层充分利用了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相关的业务流程，负责处理那些到达消息总线的消息。

解决方案预封装了如下流程：

本层中的业务流程是消息总线上事件的使用者。

一个或多个流程可处理同一个事件。

业务流程层的核心是BEAWebLogicIntegration，它提供了在其上创建、执行、管理和监视业务流程的关键基础架构。

WebLogicIntegration还包括通信和数据转换功能。

其他系统因此可以被纳入到业务流程之中。

BEAWebLogicIntegration业务流程是制作业务级服务的一种理想方式。

这些服务可由任意多个功能级或者数据级服务组成，并且是符合SOA架构的。

利用WebLogicWorkshop

开发环境，WebLogicIntegration业务流程可自动地展现为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）以复杂的方式从集成层获取数据。

服务层是执行业务逻辑和进行数据处理的地方。

它还提供了用于支持企业应用的重要基础

架构。

服务层最常见的组件是EnterpriseJavaBeans（EJB）和面向Web服务接口的定制控

件。

控件是较新的Java结构，使用它开发者不必了解复杂的J2EE就可以构建业务逻辑。

由开发人员构建业务逻辑，由BEAWebLogicWorkshop框架创建适当的J2EE结构（如，

无状态会话bean、有状态会话bean、实体bean、消息驱动bean等），从而提供所希望得到的操作。

BEAWebLogicWorkshop框架还为控件生成Web服务。

这为应用生成可重复使用的服务提供了一种便捷方法，进一步促进了SOA的推广。

各种表示设备、业务流程或其他应用也可以使用这些服务。

服务层存放在BEAWebLogicServer上。

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

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

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）PortalSPI（内容管理系统）

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

e）JMS实现异步方式

3．完成数据集成服务。

（是SOA中又一个重要的服务提供领域）。

集成层提供访问RFID应用以外其他企业信息系统（EIS）的功能。

这一层隐藏了从架构中级

别较高的层次访问外部系统的复杂性。

对RFID来说，外部系统包括但不局限于以下系统：

−Velosel公司的产品信息管理系统（PIM）

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

−Connecterra公司的ECP-IS

−各种数据库管理系统

访问这些外来系统的机制可以多种多样。

对数据库的访问通过JDBC来实现。

访问目录服务（如LDAP）可以通过标准的LDAP应用编程接口实现。

访问内容管理系统可以通过WebLogicPortal内容管理服务提供商接口（SPI）。

访问PIM、ONS和EPC-IS可以通过Web服务接口实现。

访问其他系统的方法有许多，如JCA适配器、数据引擎（SAP和Siebel）、Web服务等。

假如Web服务是标准的而且是免费的，那它将是最有前途的一种集成方法。

然而，因为它是一种相对比较新的技术，只有某些最新版本的EIS产品才有此项功能。

最简单的配置方法是利用适配器。

它们使利用源数据浏览和进行XML转换变得非常轻松，但是这项功能需要付费。

JavaMessagingService（JMS）提供了一种以异步方式与外部系统集成的方法。

JMS使系统能够对后端系统进行异步呼叫；反过来，后端系统也可以在RFID解决方案中发起异步处理。

例如，处理传入阅读器事件就是由RFID解决方案异步完成的。

当解决方案必须包含数据聚集部分时，这一层应当有BEALiquidDataforWebLogic。

LiquidData能够访问多个数据源并且将数据整合到一个聚合视图中，从而提供了一个实

时显示多数据源数据的统一视图。

数据集成是SOA中又一个可提供服务的领域。

用于管理数据的控件可以被展现为提供数据访问功能的服务。

为企业提供业务功能和流程的其他服务可充分利用这些服务。

2.5开发

2.6简单领域模型

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

2．一些特定的运用

a）算法密集型

b）数据库密集型

c）海量数据型

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

2.6.1复杂领域模型

1．半平台式的开发

a）业务梳理

b）流程设计

c）考虑部署、实施。

RFID解决方案的开发层由BEAWebLogicWorkshop提供。

该层涵盖了表示层、业务流程层、服务层和集成层，因为WebLogicWorkshop为这四个层次提供的是统一的开发环

境。

下图是WebLogicWorkshop的屏幕快照：

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

相关的解决方案。

由于具备自动生成Web服务的能力，WebLogicWorkshop提供理想的面向服务的应用开

发（SODA）环境。

简单地提供WSDL文件的位置就可以创建Web服务控件来使用Web服务。

点击鼠标就可以将WebLogic控件和业务流程展现为Web服务。

这种易用性节约了构建SOA应用过程中的大量时间。

2.7管理

管理层控制初始配置和管理功能，并为RFID解决方案提供运行和维护服务。

WebLogicIntegration控制台用于配置业务服务和监视可配置的流程级SLA。

JCA适配器和事件通道也通过基于Web应用的控制台进行管理和监视。

WebLogic管理控制台用于实际上处于服务器级的低级管理任务。

这些任务包括管理到数据库和其他数据源的连接，以及管理对服务器端其他资源（如EJB、JMS、群集、线程管理等等）的连接。

WebLogic管理控制台还用于配置安全接口，以便在必要时与活动目录系统（ActiveDirectorysystem）配合使用。

门户管理工具是一种Web应用，完成门户特有的管理任务，如修改用户档案、设置门户特有的安全性以及控制对管理工具自身的使用等。

只有利用门户技术的解决方案才需要门户管理工具。

日志也在这一层进行配置，以确定系统输出的消息的本质和类型。

日志级别也可配置，以

帮助完成调试或满足更严格的安全性要求等任务。

域配置是整个WebLogic平台配置的一个扁平化版本。

该组件掌管系统级配置，如端口数、网络地址等。

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

RFID配置是该解决方案特有的针对解决方案的配置。

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

2.8安全性

对于向客户和业务部门提供新的广泛的服务的信息技术（IT）组织而言，部署、管理和维护安全性是一个巨大的挑战。

为了提供一个面向内外用户的全球性网络，IT组织必须解决保证系统及其数据的保密性、完整性和可用性的一系列重要问题。

安全性问题涉及到系统的每一个组件，从网络本身到各台客户机。

确保整个基础价构的安全性是一项复杂工作，既需要保持高度的警惕，也需要建立完善的、沟通良好的安全策略和程序。

RFID解决方案架构提供应用级的安全性，属于网络和操作系统等较低层次的安全性。

该

架构包括基于SSL的Web访问，以确保用户信息不被XX者截获或阅读。

该架构还包含基于公司LDAP目录中用户信息的用户登入/登出功能以及当用户不活动的时间达到所配置的时间长短（如，20分钟）时的自动登出功能。

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

一样。

3组件视图

前面介绍了RFID架构。

RFID解决方案还有一种视图就是功能的组件视图，它反映了公

司希望在一个典型的RFID解决方案中所看到的功能。

图4RFID功能的组件视图上图表明了在IT环境中新的RFID系统与已有系统的关系。

RFID系统与许多已有系统相连，这些已有系统可能包括第三方EIS、Web服务和Oracle数据库。

RFID系统提供了不同类型的集成方式，以使与第三方EIS以及与其他系统集成时具有最大的灵活性。

与解决方案进行交互的方式主要有二种。

一种是通过集成来自阅读器和EDI的数据。

WebLogicRFIDEdition通过JMS将消息传递给事件模型。

然后，事件模型创建一个相应的包含有所接收事件的RFID消息，并将消息置于RFID消息总线上。

供应商也可以利用EDI或者FTP接口将发货通知单（ASN）以及其他类型的信息传输给系统进行处理。

另一种方式是通过交互模型所提供的人机接口。

交互模型由预先封装的和/或定制的portlet构成。

这些portlets也构造RFID消息，并将这些消息放置在消息总线上。

在适当的地方，交互模型还可以直接利用服务层。

RFID消息总线将接收到的消息传送给一个或多个感兴趣的客户。

接收者的确定是通过配

置层动态决定的。

消息本身是用XML写成。

消息总线同步呼叫每一个感兴趣的客户（在业务流程层），并且为每一个分享消息的感兴趣的收听者构造一个响应。

通常只有一个收听者对一种事件类型感兴趣，但是事件收听者模型具有极大的灵活性。

业务流程层由一组采用同样接口的业务流程构成。

每个流程都以RFID请求消息作为输

入，通过客户请求/响应接口返回RFID响应。

业务流程本身决定了异步的程度，因为在完成所有业务逻辑之前就可以将响应返回给呼叫者。

业务流程层不能直接与内外服务进行交互。

与这些系统的交互通过服务层进行。

服务层由

一组标准接口组成，这些接口可由一个或多个提供商实施。

可以利用控件直接访问服务

层，或者利用Web服务接口间接访问服务层。

这种架构在部署上具有灵活性，而且解决了可伸缩性的问题。

EIS特有的业务功能划归实施层。

在这里使用特有的接口与第三方以及标准的集成策略相

连直接访问内外服务（包括EIS）。

实施层也可以作为RFID消息总线的一个客户。

解决方案中预打包的与外部系统的连通性包括：

ConnecterraEdgeServer和EPC-IS所支持的BEA’sWebLogicRFIDEdition、Velosel提供的ProductInformationManagement、对VeriSign的ObjectNamingService（ONS）的访问，以及对仓库管理系统（WMS）和货场管理系统（YMS）的访问。

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

安全层也不是标准技术，由WebLogicPlatform的安全模型提供支持。

跨所有层的快速开发功能由BEA’sWebLogicWorkshop开发环境提供。

3.1RFID部署实例

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

下图是RFID解决方案的一个实际部署实例：

图5RFID实际部署实例

上述实例是一个典型的零售环境。

边缘服务器部署在需要阅读器和需要跟踪产品移动的位

置。

这些位置包括各个商店和物流中心。

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

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

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

3.2总结