曲靖做网站建设的公司,免费咨询服务,seo怎样才能优化网站,wordpress acf主题选项文章目录 1. 价值驱动的体系结构——连接产品策略与体系结构1.1 价值模型1#xff09;概述2#xff09;价值驱动因素3#xff09;传统方法识别价值模型的缺陷#xff08;了解即可#xff09; 1.2 体系结构策略#xff08;挑战#xff09;1#xff09; 优先级的确定2概述2价值驱动因素3传统方法识别价值模型的缺陷了解即可 1.2 体系结构策略挑战1 优先级的确定2确定处理最高优先级挑战的方法 1.3 价值模型和体系结构策略的联系 2 Web服务在HL7上的应用——Web服务基础实现框架2.1 HL7模型2.1.1 参考信息模型2.2.1 消息结构2.1.3 交互2.1.4 应用程序角色2.1.5 Storyboard 2.2 体系结构2.2.1 HL7应用2.2.2 发送者和接收者2.2.3 商业逻辑的任务2.2.4 Web服务适配器1发送端2接收端 2.3 开发HL7 Web服务适配器2.3.1 消息和数据类型的设计2.3.2 适配器模式的选择2.3.3 HL7Web服务契约开发2.3.4 产生Web服务 Stub和代理的实现2.3.5 开发适配器业务逻辑 2.4 案例研究 3. 以服务为中心的企业整合3.1 案例背景3.2 业务环境分析3.3 服务建模3.4 IT环境分析3.5 高层架构设计1信息服务2企业服务总线中的事件服务3程服务4企业服务总线中的传输服务 3.6 结论 1. 价值驱动的体系结构——连接产品策略与体系结构
1.1 价值模型
1概述
价值模型的作用 有助于了解和传达关于价值来源的重要信息 解决的问题如 价值如何流动期望值和外部因素中存在的相似性和区别系统要实现这些价值有哪些子集 优点 使用顺序推理和分类逻辑易于教授和讲解结果易于验证
2价值驱动因素
价值期望值 概念表示对某一特定功能的需求 包括内容(功能)、满意度(质量)、不同级别质量的实用性 如汽车驾驶员对刹车的快慢、安全性的价值期望值 反作用力 概念通常期望值越高难度越大 变革催化剂 概念环境中导致价值期望值发生变化的事件或导致不同结果的限制因素 反作用力和变革催化剂称为限制因素 3传统方法识别价值模型的缺陷了解即可
对参与者的行为模型关注较多对目标关注较少。将参与者固定化分成几种角色忽略限制因素之间的差别结果简单 要求得到满足/未满足用例成功完成/未成功完成
1.2 体系结构策略挑战
体系结构策略要点 能够被所有利益相关者所理解在系统的整个生存期内保持相对稳定 体系结构具有挑战性的原因 各种限制因素使得实现各个期望值变得困难 识别体系结构挑战的评估 哪些限制因素影响一个或多个期望值这些影响对满足期望值是积极的还是消极的其影响程度如何高中低三个等级 限制因素对期望值的影响不能跨背景考虑确定体系结构挑战的步骤 确定优先级确定处理最高优先级挑战的方法
1 优先级的确定
制定系统体系结构的切入点 识别合适的价值背景并对其优先化在每一背景中定义效用曲线优先化期望值识别和分析每一背景中的反作用力和变革催化剂检测“限制因素使满足期望值变难”的领域 优先化体系结构的权衡点 重要性 受挑战影响的期望值的优先级有多高这些期望值的特定的背景相对优先级如何 程度 限制因素对期望值产生了多大影响 后果 有多少方案可供选择这些方案的难度或有效性如何 隔离 最现实的方案的隔离情况
2确定处理最高优先级挑战的方法 在以下领域分析“应对最高优先级挑战的方法”的指导原则 组织 如何系统性地组织子系统和组件?它们的组成和职责是什么?系统如何部署在网络上?都有哪些类型的用户和外部系统?它们位于何处?是如何连接的? 操作 组件如何交互?在哪些情况下通信是同步的?在哪些情况下是异步的?组件的各种操作是如何协调的?何时可以配置组件或在其上运行诊断?如何检测、诊断和纠正错误条件? 可变性 系统的哪些重要功能可以随部署环境的变化而变化?对于每一功能哪些方案得到支持?何时可以做出选择(例如编译、链接、安装、启动或在运行时)?各个分歧点之间有什么相关性? 演变 为了支持变更同时保持其稳定性系统是如何设计的?哪些特定类型的重大变革已在预料之中应对这些变更有哪些可取的方法? 1.3 价值模型和体系结构策略的联系
软件和系统的存在是为了提供价值体系结构提供了价值的模型的折中方案 价值是一个标量它融合了对边际效用理解和诸多不同目标之间的相对重要性。目标折中是一个极其重要的问题。 价值模型包含了软件体系结构的主要驱动因素 价值存在于多个层面其中某些层面包含了目标系统并将其作为一个价值提供者。用于这些领域的价值模型包含了软件体系结构的主要驱动因素。 价值模型的变化是系统演化的一个重要依据 该层次结构中高于上述层面的价值模型可以导致其下层价值模型发生变化。这是制定系统演化原则的一个重要依据。 不同价值背景其体系结构挑战优先级不同 对于满足不同价值背景需要系统的开发赞助商有着不同的优先级。 体系结构挑战是不同价值背景的期望值引起的 体系结构挑战是由环境因素自某一背景中对期望的影响引起的 体系结构方法通过首先克服“最高优先级体系结构挑战”来实现价值的最大化体系结构策略是通过总结共同规则、政策和组织原则、操作、变化和演变从最高优先级体系结构方法综合得出的。该点似乎与价值模型无关对于每一个价值群价值模型都是同类的。暴露于不同环境条件的价值背景具有不同的期望值。该点似乎与体系结构无关
2 Web服务在HL7上的应用——Web服务基础实现框架
HL7的概念 Health Level 7是一个国际标准组织专注于医疗领域的信息交换标准 HL73.0版本扩展到了各种卫生保健行业如制药业、医疗设备及成像设备。 将HL7软件应用在 Web Services 上 设计一个正确的体系结构提供一个可执行且满足 Web Services 的环境 HL7
2.1 HL7模型
领域卫生保健领域概念 为协同工作而创建的基层结构它使用参考信息模型 (RIM)来获得具体领域的信息模型并将这些信息模型精炼到HL7 说明书中结合具体的消息类型自动产生XML表单定义 (XSD)
2.1.1 参考信息模型
概念 是一个静态的卫生保健信息模型它代覆盖了HL7 涉及领域的各个方面。 HL73.0版本标准开发过程定义了一些规则这些规则用于从参考信息模型中获取一些具体领域信息模型从而在 HL7 规格说明书中使这些模型更精确最后产生 XML表单定义 (XSD) 与一个具体的消息类型联合起来。 2.2.1 消息结构
wrappers 指HL7 消息的封装被用来支持消息的传输
2.1.3 交互
时间触发消息转移 此处教材原文吧啦吧啦说了一堆口水话没有说出任何和其他类型软件的区别。 2.1.4 应用程序角色
HL7 里的每一个应用属于一个具体的应用程序角色体现了应用程序的职责。 上边是截取的教材原文说了好像没说 2.1.5 Storyboard
概念 由一段简短的描述所构成这段描述记叙了它自身的目的以及与应用程序角色间相互作用的方式和层级通过交互作用图表在应用层面上展示出来 交互作用的图表指明了 相应交互作用的职责(即应用程序角色)交换信息的类型期望的信息交换的顺序
2.2 体系结构
2.2.1 HL7应用
定义基于HL7概念模型我们可以更精确地定义HL7应用作用旨在支持应用程序角色软件组件的设计与实现
2.2.2 发送者和接收者
概述 由各应用程序角色担任利用Web服务通信基础设施作为底层支撑确保信息在不同角色间的顺畅传递和处理 内部的两组核心功能 商业逻辑Web服务适配器
2.2.3 商业逻辑的任务
发送端 负责创建HL7消息的XML描述 包括消息体、Transmission Wrapper、Control Wrapper 将这一消息传递给Web服务适配器适配器负责将消息传送至接收端 接收端 接收Web服务适配器传来的 HL7 消息验证HL7消息是否满足商业规则和约束核实发送应用端是否需要确认信息若需要则发送确认消息
2.2.4 Web服务适配器
功能处理消息的分发和确认信息主要内容如下
1发送端
读取接收到的HL7消息的Transmission Wrapper 以确定消息如何到达Web服务基础设施进而配置SOAP以适应传输需求 基于 HL7消息类型、应用配置、规则来准备一个 SOAP 消息把SOAP消息传递到Web服务代理通过网络进行传输准备接收并存储来自接收端相应确认消息
2接收端
从Web服务器接收SOAP 消息验证接收到的 SOAP 消息满足应用配置和一些约束条件(如安全性)在内存中保存这些消息有选择性地从 SOAP消息里打开 HL7 XML消息并核对是否与期望值相符验证是否需要返回确认信息传递HL7消息给接收应用端
2.3 开发HL7 Web服务适配器 其开发步骤如下 2.3.1 消息和数据类型的设计
必须的设计 可交换的消息已用的数据类型XSD表单里它们的说明书
2.3.2 适配器模式的选择
由第一步中的消息类型来制定
2.3.3 HL7Web服务契约开发
WSDL Web Services Description Language一种标准化的可用计算机处理的语言 Web服务契约 使用WSDL来开发
2.3.4 产生Web服务 Stub和代理的实现 Stub充当远程服务的一个本地代理允许客户端应用程序以本地调用的方式访问远程服务 2.3.5 开发适配器业务逻辑
WSDL 契约都详细说明了一个 Web服务的名字和端口端口的作用 Web服务器通过这些端口和客户端通信端口指定了 网络中服务生效的位置端口上的操作通信的协议 端口类型代表了暴露在Web 服务上的各种接口操作 是接口的方法定义了客户端请求服务端的输入信息服务器用于应答客户的输出信息 消息的格式也是基于WSDL契约中所定义的类型的格式 (XML表单)。
2.4 案例研究
两个相互交互的系统 医疗信息系统 (Hospital Information System,HIS)实验室信息系统 (Laboratory Information System,LIS) 两个服务的信息如下 HIS是由两个 Sub-systems组成排序、报告LIS是由Web服务和业务逻辑组成的 Web 服务从 HIS排序系统接收命令业务逻辑将确认信息返回到HIS排序或报告系统 消息的交互与前文所述一致两个服务各自有一个客户端 上图流程说明 当用户接口从HIS 客户机那里收到信号时 HIS 业务逻辑就会产生一个序号标识符同时通过创建一个 XML文件以及在HL7负载里加入一个序号 I D来构造POLB_IN2120 信息。业务逻辑发送一个 POLB_IN2120 信 息 (Send Order) 给适配器通过它的代理服务(POLB_AR002942 服务代理)来调用 LIS服务。在 Laboratory端 POLB_AR002942 Service Stub 接收到SOAP信息同时使它对于LIS Web服务适配器是可用的。LIS适配器从 SOAP信息里得到HL7信 息 (Order), 同时依据 HL7信息类型表单来验证从 SOAP 那得到的被封装的HL7 负载。LIS 适配器从 SOAP信息里得到 HL7信 息 (Order), 同时依据HL7信息类型表单来验证 从 SOAP 那得到的被封装的 HL7 负载。如果需要它会准备确认序列这个确认序列是通过构造一个XML 文件同时在文件里附上一个预先定义的应答确认来实现的。当一个新的信息到达时 LIS业务逻辑重新从顺序队列里得到 HL7信息并且将信息发送给 LIS客户端。 3. 以服务为中心的企业整合
以一个经过简化的实际案例为例介绍了以服务为中心的企业集成的基本步骤从业务分析到服务建模到架构设计到系统开发的整个生命周期。以服务为中心的企业集成涉及的主要技术被穿插在各个步骤中进行了详细的讲解。
3.1 案例背景
某航空公司的信息系统已有好几十年的历史。该航空公司的主要业务系统构建于20世纪七八十年代以IBM的主机系统为主包括运行于TPF上的订票系统和运行在IMS上的航班调度系统等。在这些核心系统周围也不乏基于UNIX 的非核心作业系统和基于.Net 的简单应用。这些形形色色的应用有的用汇编或COBOL编写运行于主机和 IMS之上有的以PRO*C编写运行在 UNIX 和 Oracle上。这些应用虽然以基于主机终端的界面但是基于Web和 GUI 的应用也为数众多。 近年来该公司在企业集成方面也是煞费苦心——已经在几个主要的核心系统之间构建了用于信息集成的信息 Hub(Information Hub), 其他应用间也有不少点到点的集成。尽管这些企业集成技术在一定程度上增进了系统间的信息共享但是面对如此异构的系统技术人员依然觉得企业集成困难重重。 (1)因为大部分核心应用构建在主机之上所以Information Hub是基于主机技术开发很难被开放系统使用。 (2)Information Hub对 Event 支持不强被集成的系统间的事件以点到点流转为主被集成系统间耦合性强。 (3)牵扯到多个系统间的业务协作以硬编码为主将业务活动自动化的成本高周期长被开发的业务活动模块重用性差。 为了解决这些企业集成中的问题该公司决定以Ramp Control 系统为例探索一条以服务为中心的企业集成道路。本文将以Ramp Control系统中的Ramp Coordination流程为例说明如何用以服务为中心的企业集成技术一步步解决该公司 IT技术人员面临的企业集成问题。
3.2 业务环境分析
在航空业中 Ramp Coordination是指飞机从降落到起飞过程中所需要进行的各种业务活动的协调过程。通常每个航班都有一个人负责 Ramp Coordination, 这人通常称为RampCoordinator。 由Ramp Coordinator协调的业务活动有检查机位环境是否安全以及卸货、装货和补充燃料是否方便和安全等。 实际上 Ramp Coordination的流程因航班类型的不同机型的不同有很大差异。图12-14所示的流程主要针对降落后不久就起飞的航班这种类型的航班称为short turn around航班。除了short turn around航班外还有其他两种类型的航班。 Arrival Only航班指降落后需要隔夜才起飞的Departure Only航班是指每天一早第一班飞机。这些航班的Ramp Coordination的流程和Short Tum Around类型的流程大部分的业务活动是相似的。这三种类型的航班根据长途/短途国内/国外 等因素还可以进一步细分。每种细分的航班类型的Ramp Coordination的流程都是略有不同。 很明显如此多的流程之间共享着一个业务活动的集合如此多种类型的流程都是这些业务活动的不同组装方式。以服务为中心的企业集成中流程服务就是通过将这些流程间共享的业务活动抽象为可重用的服务并通过流程服务提供的流程编排的能力将它们组成各种大同小异的流程类型来降低流程集成成本加快流程集成开发效率的。以服务为中心的企业集成通过服务建模过程发现这些可重用的服务并通过流程模型将这些服务组装在一起。
3.3 服务建模
IBM推荐使用组件业务建模 (Component Business Model) 和面向服务的建模和架构(Service-Oriented Model and Architecture) 两种方法建立业务的组件模型、服务模型和流程模型。 服务模型是服务建模的主要结果。 Ramp Coordination相关的服务模型和Ramp Coordination流程相关的有两个业务组件①Ramp Control 负责Ramp Control相关各种业务活动的组件 ②Flight Management负责航班相关信息的管理包括航班日程乘客信息等 这两个业务组件分别输出如下服务。 (1)Retrieve Flight BO: 由Flight Management输出主要用于提取和航班相关的数据信息。 (2)Ramp Coordination: 由Ramp Control输出主要用于Ramp Coordination流程的编排。 (3)Check Spot: 由Ramp Control输出用于检测机位安全信息。 (4)Check Unloading: 由Ramp Control输出用于检查卸货状况。 (5)Check Loading: 由Ramp Control输出用于检查装货状况。 (6)Check Push Back: 由Ramp Control输出用于检查关门动作。 在服务建模确定系统相关的服务输出后还需要确定服务在当前环境下的实现方式。在我们的案例中 Retrieve Flight BO被实现为信息服务 Ramp Coordination被实现为流程服务通过 BPEL4WS方式实现。其他4个服务都是 Staff Service。 需要注意的是因为环境的不同和随着系统的演化我们可能会改变服务的实现方式如 Check Push Back现在通过 Staff Service即人工服务实现。将来随着自动化程度的增强 Check Push Back完全可能通过自动化的系统实现。到那时只需重新实现这个服务而无需改变整个流程。这是服务的可替换性的一个典型实例。
3.4 IT环境分析
在构建Ramp Control 系统之前该航空公司已经有大量的信息系统。作为架构设计的重要步骤对现有IT环境调研描绘了和Ramp Control相关的 IT系统的状况包括周围应用和应用提供的接口这些应用和 Ramp Control 交互的类型和数据格式。简化的IT环境视图描绘了Ramp Coordination 流程和周围系统交互状况。目前 Ramp Coordination流程需要4种类型的外围应用交互。 (1)从乘务人员管理系统提取航班乘务员的信息。 (2)从订票系统中提取乘客信息。 (3)从机务人员管理系统中提取机务人员信息。 (4)接收来自航班调度系统的航班到达事件。 通过将主机应用中的信息集中为粗粒度的业务对象并通过信息服务输出为该公司的核心系统提供了更加通用的连接能力同时为IT 系统的平滑演进提供了必要的条件。
3.5 高层架构设计
据需求和设计阶段的业务模型和现有IT环境调研结果再结合传统的IT应用开发方法Ramp Coordination系统的高层架构被设计了出来如图12-15所示。 本案例中的主要架构元素以及它们之间的工作关系如下。
1信息服务
Federation Service是 Ramp Coordination 流程中需要从已有系统中提取4类信息在Service 建模阶段这4类信息被聚合为Flight BO(Business Object)。 如上文所述Retrieve Flight BO服务用于从已有系统中提取Flight BO。 它实际上是一个Federation Service,将来自乘务人员管理系统、机务人员管理系统和订票系统中的信息聚合在一起。从这三个已有系统来的 Crew Info、Cockpit Info和 Passage Info 是在已有系统中已经存在的业务逻辑或业务数据它们属于可接入服务 (on-ramp Service), 接入的协议分别为 JDBC、IMS J2C Connector和socket。 乘务人员管理系统基于Oracle数据库 Crew Info可以直接通过 JDBC获得。机务人员管理系统基于 S/390上的 IMS,IBM 已经提供了 IMS的J2C Connector, 所以Cockpit Info可以通过J2C connector获得。订票系统构建在IBM TPF 之上由于实时性的要求 socket 是比较好的接入方法。Retrieve Flight BO 被实现为一个EJB, 外部访问通过RMI/IIOP绑定访问这个服务。在Retrieve Flight BO 内部Flight BO以 SDO来表示。
2企业服务总线中的事件服务
Event Service是在检查机务环境安全 (Check Spot) 前Ramp Coordiator 需要被通知航班已经到达。这个业务事件由航班调度系统激发 Flight Arrival是典型事件发现服务 (Event Detect Service), 它通过M Q将事件传递给 Message Broker, 通过JMS的Pub/Sub, 这个事件被分发给Check Spot。 这里的Event Service是本例中 ESB的重要组成部分。通过 ESB上的通用事件服务现有Information Hub的缺陷得到了克服。应用程序间的事件集成不再需要点到点的方式而是通过 ESB 的事件服务完成订阅发布应用程序间的耦合性得到了极大的缓解。
3程服务
Process Service是Ramp Coordination被实现为一个Process Service, 它被WBI SF的BPEL4WS容器执行 BPEL4WS 容器提供Choreograph Service、Transaction Service和Staff Service支持。 Ramp Coordination通过RMI/IIOP协议调用在BPEL4WS容器中 WSIF被用于通过各种协议调用服务它成为ESB 中Transport Service 的一部分。 Ramp Coordination中的人工动作被实现为Staff Service 而集成到流程中。这里 Staff Service通过Portlet 实现运行在Websphere Portal Server上。Portal Service 实现部分 Delivery Service支持PDA设备 RampCoordinator通过PDA设备访问系统。
4企业服务总线中的传输服务
RCMS是即将新建系统用于提供包括 RampCoordination在内的Ramp Control的功能。 RCMS通过由 WSIF 实现的 Transport Service 以SOAP/HTTP 调用 Ramp Coordination服务。
3.6 结论
通过一个简单的案例讲解了以服务为中心的企业集成的主要步骤和涉及的技术。这些集成的技术无论是方法学、体系结构还是编程模型都在不断地发展中。随着这些技术的不断完善以服务为中心的企业集成方案的实施将更加简单高效。
