| ProfilMaple's WorldBlogListen |  Extras  Hilfe |
|
28 Juni 文档收尾文档基本准备完毕了，现在处于收尾阶段。
我们将我们得所有文档集合在一起。最后将以pdf得格式交付。
胜利再望。
不管结果如何，一起走过比赛得整个过程，均让我们受益匪浅。
－pipidog－ 21 Juni 提交文档1 项目综述已经完成提交文档 1 项目综述已经完成。
文档2 系统架构设计 正在加紧整理中，前期做的工作还是值得肯定的。预计明天可以完成。
ps:神秘人物的工作相当的重要。
-pipidog1982- 15 Juni 抓紧时间做架构设计...时间紧迫了啊，我们要抓紧时间做架构设计，没什么必要的信息要发布的话，我们就暂停这个贼慢的blog······
~~~~~~~
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~--weijian [ MSN Spaces真慢啊,还在一边拉着Messenger死不放 :( ] 14 Juni 关于业务流程建模的规范化我觉得我们在详细的流程建模（服务建模同样也是）中要严格遵循BPEL的规范，以便进行BPEL的验证和流程的合并，有利于后面的代码生成等。 可参照文章“按需业务流程的生命周期，第 3 部分: 使用 WBI Modeler 进行业务流程建模” 和“第 4 部分: Rational XDE 和 WebSphere Business Integration Modeler 的构件集成”的部分内容。
关于BPEL流程建模的详细资料可参考 IBM redbook：
BPEL4WS Business Processes with WebSphere Business Integration: Understanding, Modeling, Migratinghttp://www.redbooks.ibm.com/redpieces/abstracts/sg246381.html 其中的 Chapter 5. WebSphere Business Integration Modeler: modeling for BPEL4WS 就是具体讲了如何使用WebSphere Business Integration Modeler V5进行流程建模的方面。
－－weijian [ MSN Spaces真慢啊,还在一边拉着Messenger死不放 :( ] 需求完成，建模阶段这些天，我们细化了需求。
开面开始建模阶段。
需求还是整得我们半死，因为没有经验，把握不准。
我们细化了业务流程。
weijian别吼，这家伙，死吼吼的。
整天被论文开题折磨，今天我写好了第二个。真是麻烦。
加油加油
=pipidog= 13 Juni 时间不多了呀～09 Juni 以服务为中心的企业整合
这里仅列出“以服务为中心的企业整合”一文中的要点，主要是整个架构设计时需要参考和考虑的因素，$$$希望后面的设计能够参考虑到下面的提到的大部分的要点€€€ 首先是概念： 以服务为中心的集成"是英文词语"Service-Oriented Integration"的中文翻译，简称 SOI。 它可以定义为：在"以服务为中心的体系架构"（Service-Oriented Architecture，SOA）中，通过服务的交互来集成各企业的 IT 资源，如分布的应用或者数据，帮助企业 IT 部门将已有但老旧而不灵活的系统集成起来，释放其中功能或数据为可重用的服务与业务流程。
完整的SOI 解决方案包括如下要素：
a) 代表应用的功能和数据资源的服务； b) 提供连接服务的基础设施即企业服务总线（Enterprise Service Bus, ESB），连接已有应用的 连接器（Connector）和适配器（Adapter）； c) 元数据及其管理如服务描述和服务注册管理（Service Registry）等； d) 将服务组合成业务流程的引擎如 BPEL4WS 引擎； e) 业务流程管理和业务绩效管理的部分； f) 一个基于标准的编程模型以及支持它的建模、开发和组装、测试、部署和管理的端到端工具环境； 企业集成的架构按本文最后所附的图所示的方式划分为六大类： 业务逻辑服务(Business Logic Service)：包括用于实现业务逻辑的服务，和执行业务逻辑的能力。这其中包括业务应用服务(Business Application Service)、业务伙伴服务(Partner Service)以及应用和信息资产(Application and Information asset)。 控制服务(Control Service)：包括实现人(people),流程(process)和信息(information)集成的服务，以及执行这些集成逻辑的能力。 连接服务(Connectivity Service)：连接服务通过提供企业服务总线提供分布在各种架构元素中服务间的连接性。 业务创新和优化服务(Business Innovation and Optimization Service)：用于监控业务系统运行时服务的业务性能，并通过及时了解到的业务性能和变化，采取措施适应变化的市场。 开发服务(Development Service)：贯彻整个软件开发生命周期的开发平台，从需求分析，到建模、设计、开发、测试，维护全面的工具支持。 IT服务管理(IT Service Management)：支持业务系统运行的各种基础设施管理能力或服务，如安全服务、目录服务、系统管理和资源虚拟化。
l 连接服务 - 企业服务总线 企业服务总线(Enterprise Service Bus)，以下简称ESB, 是过去消息中间件的发展，ESB 采用了"总线"这样一种模式来管理和简化应用之间的集成拓扑结构，以广为接受的开放标准为基础来支持应用之间在消息、事件和服务的级别上动态地互联互通。 ESB 所提供的基于标准的连接服务，将应用中实现的功能或者数据资源转化为服务请求者能以标准的方式来访问的服务,这个转换过程需要相应的适配器或连接器 ESB 采用总线结构模式简化了应用之间的集成拓扑，通过源自实践的模式，提供了基于标准的通用连接服务，使得服务请求者和服务提供者之间可以以松散耦合、动态的方式交互，从而在不同层次上使得SOI 解决方案是一个松散耦合、灵活的架构。
l 业务逻辑服务
1、整合已有应用 - 应用和信息访问服务。已有应用和信息是实现业务逻辑和业务数据的重要资产，如本大赛中的CRM和ERP系统。通过集成已有的应用和信息将可以在已有企业系统上实现更多增值服务。以服务为中心的企业集成通过应用和信息访问服务(Application and Information Access Service)来实现对已有应用和信息集成，它通过各种适配器技术将已有系统中的业务逻辑和业务数据包装成企业服务总线支持的协议和数据格式。通过企业服务总线，这些被包装起来的业务逻辑和数据就可以方便的参与上层的业务流程，从而已有应用系统的能力可以得以继续发挥。这里的已有应用包括遗留应用、预包装的应用和各种企业数据存储。在参考架构中，主要有两类访问服务：1)可接入服务(On-Ramp Service): 通过各种消息通信模式(单向、请求/应答和轮询)将业务逻辑和业务数据包装成企业服务总线可以访问的功能。 2)事件发现服务(Event Detect Service) : 提供事件通知服务将已有应用和数据中的变化通过事件框架发布到企业服务总线上。 2、整合新开发的应用 - 业务应用服务。和已有应用和数据类似，新开发的应用也作为重要的业务逻辑成为企业集成的目标。以服务为中心的企业集成通过业务应用服务(Business Application Service)实现新应用集成。在本题中我们可以想象许多合理的新业务应用服务添加到我们整合的系统中。 在参考架构中，有三类业务应用服务： 组件服务(Component Service)：为可重用的组件提供应用的运行时容器管理服务，如对象持久化、组件安全管理和事务管理等。 核心服务(Core Service)：提供运行时的服务，包括内存管理、对象实例化和对象池、性能管理和负载均衡、可用性管理等。 接口服务(Interface Service)：提供和其他企业系统集成的接口，如其他企业应用，数据库、消息系统和管理框架。 3、整合客户和业务伙伴（B2C/B2B）－伙伴服务。以服务为中心的企业集成通过伙伴服务提供与企业外部的B2B的集成能力。因为业务伙伴系统的异构性，伙伴服务需要支持多种传输协议和数据格式。在参考架构中，提供如下服务： 社区服务(Community Service): 用于管理和企业贸易的业务伙伴，支持以交易中心(Trade Hub)为主的集中式管理和以伙伴为中心的自我管理。 文档服务(Document Service)：用于支持和业务伙伴交换的文档格式，以及交互的流程和状态管理，支持主流的RosettaNet、EDI和AS1/AS2等。 协议服务(Protocol Service)：为文档的交互提供传输层的支持，包括认证和路由等。 l 控制服务 1、数据整合－信息服务。企业数据的分布性和异构性是应用系统方便访问企业数据和在企业数据之上提供增值服务的主要障碍。数据集成和聚合技术在这种背景下诞生，用于提供对分布式数据和异构数据的透明访问。以服务为中心的企业集成通过信息服务提供集成数据的能力，目前主要包括如下集中信息服务： 联邦服务(Federation Service): 联邦服务提供将各种类型的数据聚合的能力，它既支持关系型数据，也支持象XML数据、文本数据和内容数据等非关系型数据。同时，所有的数据仍然在自己本身的方 式管理。 复制服务(Replication Service)：复制服务提供远程数据的本地访问能力，它通过自动的实时复制和数据转换，在本地维护一个数据源的副本。本地数据和数据源在技术实现上可以是独立的。 转换服务(Transformation Service)：转换服务用于数据源格式到目标格式的转换，可以是批量的，或者是基于记录的。 搜索服务(Search Service)：提供对企业数据的查询和检索服务，既支持数据库等结构化数据，也支持象PDF等非结构化数据。 2、流程整合- 流程服务。企业部门内部的IT系统通过将业务活动自动化来提高业务活动的效率。但是这些部门的业务活动并不是独立的，而是和其他部门的活动彼此关联的。勿容置疑，将彼此关联的业务活动组成自动化流程可以进一步提高业务活动的效率。以服务为中心的企业集成通过流程服务来完成业务流程集成。在业务流程集成中，粒度的业务逻辑被组合成业务流程。流程服务提供自动执行这些业务流程的能力。 在参考架构中，流程服务包括如下内容： 编排服务(Choreography Service): 编排服务通过预定义的流程逻辑控制流程中业务活动的执行，并帮助业务流程从错误中恢复。 事务服务(Transaction Service)：事务服务用于保证流程执行中的事务特性(ACID)。对于短流程，通常采用传统的两阶段提交技术，对于长流程，一般采用补偿的方法。 人工服务(Staff Service)：人工服务用于将人工的活动集成到流程中，一方面它通过关联的交互服务使得人工可以参与到流程执行中，另一方面它需要管理由于人工参与带来的管理任务如：任务分派，授权和监管等。 3、用户访问整合 - 交互服务。用户访问集成是实现这一目标的重要一环，它负责将信息系统中的信息传递给客户，不管它在那里，它以什么样的设备接入。 以服务为中心的企业集成通过交互服务来实现用户访问集成。参考架构中的交互服务包括如下类型： 交付服务(Delivery Service): 交付服务提供运行时的交互框架，它通过各种技术支持同样的交互逻辑可以在多种方式(图形界面、语音和普及计算消息)和设备(桌面、PDA、无线终端等)上运行，比如通过页面聚合和标签翻译使得同一个Portlet可以在桌面浏览器和PDA浏览器上展现。 体验服务(Experience Service): 通过用户为中心的服务增强用户体验, 其中的技术包括：个性化、协作、单点登录等。 资源服务(Resource Service): 提供运行时交互组件的管理，如安全配置、界面皮肤等。 l 管理支持 为业务流程和服务提供安全、高效和健康的运行环境也是以服务为中心的企业集成重要的部分，它由IT服务管理来完成。IT服务管理包括如下两部分： 安全和目录服务(Security and Directory Service)：企业范围的用户、认证和授权管理，如单点登录(SSO)；系统管理和虚拟化服务(System Management and Virtualization Service)：用于管理服务器，存储、网络和其他IT资源。
最后，要注意：服务建模（Service Modeling）是 SOI 活动中至关重要的活动。它包括如何找到和确定服务，如何处理服务的粒度，如何通过服务体现和实现业务目标，如何详细说明服务，如何确定服务与已有系统的关系等。
再强调一下：$$$希望后面的设计能够参考虑到下面的提到的大部分的要点€€€，并参照一下“以服务为中心的企业整合－案例分析” -weijian [ MSN Spaces真慢啊,还在一边拉着Messenger死不放 :( ] 08 Juni 关于业务流程建模在使用 WBI Modeler 进行业务流程建模过程如下:
首先,根据业务需求分析出业务过程中的大的活动,接着是确定细节处的数据元素,并且为其建模， 比如到来的订单，生产数据和验证数据。注意这些数据项可以被输入或者输出到活动、存储库、流
程或者服务。
关于服务的建模:服务作为外部实体,在被建模的流程的外面，可以在组织的流程里面使用。
在流程建模中要注意以下几个流程元素: 控制流,子流程,策略和度量;因此我们在流程建模中要注
意以下方面做好:1)标识和列出任务 2)任务排序 3)任务之间控制流的创建 4)流程里面数据的引入
(包括输入数据和输出数据) 5)流程模型内部服务的集成
关于流程建模中的任务:在流程建模中，任务是最低级的活动。一项任务不能再进一步分解。每项 任务说明包含输入、输出和完成该任务所需的资源。
另外还要根据需要创建循环、添加决策点和存储库(存储库这个概念同编程语言中变量类似,每个存 储库有一个名称和一个相关的业务条目类型。两种类型的存储库是局部的和全局的。局部存储库为
一个流程所有，并且仅能被该流程中的元素使用。这些数据元素直道流程结束时都是可用的。全局
存储库是在项目的级别上创建的，对于多个流程都是可以访问的。)
最后，还要将服务和子流程集成到流程模型：服务以及子流程元素通过与其他元素连接被添加到流 程中。注意服务是可重用的元素；作为最佳实践，关于被建模的现有服务的任何知道的信息都应该
被添加到服务描述字段中。该信息可能包含服务描述、绑定选择、发现机制和部署选项。这些描述
指导开发人员去创建所需的发现、绑定、部署和集成代码。
另外，最后流程建模结束后我们还可以使用 BPEL 模式来 BPEL流程模型的验证。 建模的一些细节问题还请大家参照文章：按需业务流程的生命周期，第 3 部分: 使用 WBI Modeler 进行业务流程建模
－－
-weijian [ MSN Spaces真慢啊,还在一边拉着Messenger死不放 :( ] 07 Juni 业务流程复合模式业务流程复合模式
这种模式允许人工初始化业务流程，它集成了不同的应用程序和服务器，并且能够与人进行交互完成他的请求。同时，也可以监控业务和流程的整个过程。 业务流程复合模式包括：
业务流程复合模式可选择地包括：
详见：按需业务流程的生命周期，第 2 部分: 电子商务模式指南
-weijian [ MSN Spaces真慢啊,还在一边拉着Messenger死不放 :( ] 01 Juni 需求分析阶段的建模关于建模和架构～～～ 祝各位儿童节快乐！ ～～～
服务建模和架构要注意的问题:
1. SOA 三个重要的元素： 服务， 流，和实现服务的 组件。同样需要可以明确定位鉴别、制定和实现服务所需的技术和过程，它们的流程和组合，以及实现和确保所需服务质量的企业级组件。
2. 需要进行范例的替换，以便更好的区分 SOA 的两个关键角色之间的截然不同的需求：服务提供者和服务消费者。 3. 假设为一个企业或者业务线构建的应用程序，现在必须被提升到一个供应链中使用，并且公开给合作伙伴，这些合作伙伴可能组合、联合和封装应用程序到一个新的应用程序中。 4. SOA的三个主要参与者之间定义了交互模型：服务提供者，公布服务描述并且实现服务，服务消费者; 定义 SOA 的架构样式描述了一系列模式和指导方针来创建 松耦合，依赖业务的服务，由于描述、实现和绑定之间关系的分离，为新业务迹象和机会提供了空前的灵活性。 SOA 是企业级的 IT 架构，用来按需连接资源。在 SOA 中，资源对于价值网、企业、业务线内的参与者时可用的（典型的是在一个企业内或多个企业之间跨越多个应用程序）。它由一系列依赖业务的 IT 服务组成，这些服务共同满足了组织的业务流程和目标。你可以将这些服务设计成合成的应用程序并且通过标准协议来调用它们 5. 基于服务的建模是基于服务的分析和设计（SOAD）过程，来建模、分析、设计和生产依赖业务分析、过程和目标的 SOA。
6. SOA 的一个架构模板:
服务和组建之间的关系是，企业级的组件（大粒度的企业或者业务线组件）实现该服务并且负责提供它们的功能和维持它们的服务质量。通过组合这些公开的服务到合成的应用程序，就可以支持业务过程流。综合的架构通过使用 Enterprise Service Bus（ESB）支持这些服务、组件和流程的路由、中介和转化。 SOA 架构文档设计的模板：
7. 基于服务的建模和架构过程包含三个主要的步骤：服务，组件和流程（典型地，服务的编排）的鉴别，指定和实现。
这个过程由域分解、现有资产分析和目标服务建模的自顶向下、自底向上、中间向外技术的联合组成。在 自顶向下视图中，业务用例的蓝图提供了业务服务的规范。这个自顶向下的过程作为 域分解来被引用，域分解由业务领域到它的功能区域和子系统的分解组成，包含它的流程或过程分解成过程、自过程和高级别业务用例。很多情况下，这些用例是公开在企业边缘的业务服务，或者在贯穿业务线企业边界内所用的非常好的候选。 在过程的 从下到上的部分或者 现有系统分析中，现有的系统被分析和选择作为可行的候选，来为支持业务过程的底层服务功能性实现提供低消耗的解决方案。在这个过程中，分析和利用了来自遗留和打包应用程序的 API、事务和模块。在有些情况下，为了支持服务的功能重新模块化现有的资产需要遗留系统的组件化。 中间向外视图由目标服务建模组成，来验证和发现自顶向下或自底向上的服务鉴别手段中没有捕捉到的其他服务。它将服务连结到目标和子目标、关键性能指示和尺度。 这个活动在服务被指定时开始。将服务分级为服务层次是非常重要的，反映了服务的复合或者不规则的本性：服务可以也应该由良好粒度的组建和服务组成，分级帮助决定合成和分层，以及基于层次的相互依赖服务的协同构建。同样，它帮助减轻服务增值综合症，这种症状中，越来越多的小粒度的服务被定义、设计和部署，却缺乏控制，导致了主要的性能、可伸缩性和管理问题。更加重要的是，服务增值未能提供服务，这些服务对业务是非常有用的。 这个活动获取上面域分解过程中发现的子系统，并且指定子系统之间的相互依赖和流程。它同样将域分解过程中鉴别的用例作为子系统接口上公开的服务。子系统的分析包含创建对象模型来表现内部工作方式，以及所包含的公开服务并且实现它们的子系统设计。这时，“子系统”的设计结构将实现为大粒度组件实现构造，在下面的活动中实现服务。 在下面的主要活动中，实现服务的组件的细节将指定：
消息和时间指定以及管理定义出现在这一步骤中。 服务分配包括分派服务到目前鉴别的子系统。这些子系统具有实现了他们所公布的功能的企业组件。你经常会简单化假定，子系统同企业组件有一对一的联系。 结构化组件在你使用模式来构造 企业组件时会通过以下几点的联合的形式出现：
服务分配同样由服务的指派和在 SOA 层中实现他们的组件组成。组件和服务向 SOA 层中的分配是一个关键的任务，需要关键架构决策的文件和决议，这些决策不仅仅同应用程序架构有关系，也同在运行时设计和用来支持 SOA 实现的技术操作架构有关的。
这个步骤指出实现给定服务的软件必须被选择或者自定义构建。其他可用的选项包括使用 Web 服务来集成、转化、订阅和外购不同功能。在这个步骤中，你决定哪个遗留系统模块用来实现给定的服务，以及哪个服务将从基础来构建。服务的其他实现决策不同于业务功能包括：服务的安全、管理和监视。 事实上，项目趋向于利用任意数量的相应的努力来满足关闭的机会窗口。因此，我推荐并行的管理三个流。 自顶向下的域分解（过程建模和分解，基于变更的分析，方针和业务规则分析，领域特定行为建模（使用语法和图表））是同供组件化（模块化）和服务公开候选的现有遗留资产的分析并行控制。为了获得项目背后的业务意图和使服务同业务意图密切合作，目标服务建模可以来控制。 -weijian [ MSN Spaces真慢啊,还在一边拉着Messenger死不放 :( ]
-weijian [ MSN Spaces真慢啊,还在一边拉着Messenger死不放 :( ] |
|
|
