随笔 - 181, 文章 - 2, 评论 - 85, 引用 - 0
数据加载中……

留言接受贴!有什么想说的都在这个帖子上回复吧!

Welcome

posted @ 2006-04-21 20:31 wsdfsdf 阅读(246) | 评论 (3)编辑 收藏

大赛推荐文章之二-----下一代模型驱动开发

本文跟踪了IBM Rational 自动化建模工具的发展历程,描述了IBM Rational Software Architect的高级能力,并且帮助读者决定他们是否可以从过渡到这个工具而获利。另外,文章中也讨论了在 IBM基于 Eclipse的软件开发平台(Software Development Platform)中使用集成工具的优势。

在2004年10月, IBM 发布了 IBM® Software Development Platform, 包括新一代的建模和模型驱动开发 (MDD) 工具。IBM Rational® Software Architect是该次发布的设计和构建的中心,是一个为了建立构架良好的应用和服务,与 Unified Modeling Language (UML)一起支持MDD的广泛的、集成的设计和开发产品。

Rational Software Architect 支持使用现代软件工业技术的应用和Web 开发(静态的和动态的),包括:

  • Java 2, Enterprise Edition™ (J2EE) 和 Web services 技术
  • 对象管理组织 (OMG)的模型驱动体系架构 (MDA) 和面向服务的体系架构 (SOA)
  • JavaServer™ Faces (JSF)支持快速应用开发的能力
  • 支持基于资产开发的可重用资产规范 (RAS)

Rational Software Architect包括IBM Rational Application Developer for WebSphere Software (IBM WebSphere® Studio Application Developer产品的最新版本) 的所有能力,并且将他们增加到MDD技术中。结果:打包在单个产品中的一个集成的设计和开发解决方案。

本文的目的是从发展演化的角度来讨论Rational Software Architect,这是一个支持显著区别于那些由先前MDD产品支持的工作流和使用情景的下一代MDD产品。请注意这并不是Rational Software Architect的使用指南;IBM Rational计划不久将出版一部指南。

IBM Rational 建模工具的演化

为了理解Rational Software Architect 建模产品演化的规模,让我们简单回顾IBM Rational产品在这个方面的历史。

Rational Rose

IBM Rational Rose® 软件已经并且继续成为一个市场主导的可视化建模工具。它是一个独立的工具,在应用程序接口(API)层与市场主导的IDE结合,来支持各种编程语言和其它实现技术。然而,尽管Rational Rose已取得一定的成功,也推进了UML建模实践,但是仍然只有一小部分开发人员按照规定使用建模,Rational也已经尝试培训更多的人员。但是大多开发人员不想放弃他们的IDE而去使用额外的工具;他们想将可视化建模集成在IDE里面。

Rational XDE

为了满足这个需要,在2002年,IBM Rational推出了Rational XDE?软件,为当时出现的编程技术(Java 和 Microsoft .NET)提供了一个扩展的开发环境。我们把Rational XDE看成Rational Rose的下一代;严格地说,它并不是新版本的Rose(因而名字发生了变化),而且也未必取代Rose,因为我们有目的地限制Rational XDE只支持一定的IDE和实现技术。

通过将Rational XDE构造成流行IDE的插件,我们鼓励大量开发人员采用建模和模型驱动开发。Rational XDE通过支持功能强大的引擎,允许基于模式的开发,也推进了MDD的发展;另外,也使得软件设计层复用达到一个新的高度。之后加入了具体的定制化的能力,为IBM Rational对 MDA提供了早期的支持((请参见下面的"对于模型驱动的体系结构的支持")。

2003年10月,合并到IBM之后,我们将Rational Rose 和 Rational XDE产品线加固到一个家族 -- IBM Rational Rose XDE Developer -- 这样,无论用户倾向于使用独立的建模工具还是一个直接集成在他们IDE的工具,他们都可以购买工具包,并根据自己的需要进行安装。

与Eclipse前所未有的结合的机会

即使在IBM并购Rational软件之前,这两个组织也是合作伙伴,致力于开发新的、更强大的方法来将MDD的能力集成进Eclipse框架和基于Eclipse的IDE 。这项工作早期的成果是在2003年添加到WebSphere Studio Application Developer中的轻量级作用的代码可视化和可视化编辑特性,这些特性是开发Java实施层模型的非常有效的方法。

该技术现在是IBM开发MDD工具的基础。不再是简单地与Eclipse集成,我们正在Eclipse之上构建新的MDD能力。这为Java 和 C/C++开发提供了前所未有的支持,也为集成其它生命周期工具提供了全新的能力。我们在2004年10月发布了新的工具,基于Eclipse的IBM Software Development Platform的远景逐渐变成现实。我们现在提供了软件开发的完整的集成平台,充分满足开发团队中每个角色的需要。软件开发可以真正成为一个核心业务流程,为我们的客户提供竞争的优势,新的收益和市场机会。

使用Eclipse我们现在能够为建模产品实现更深入和广泛的集成。我们能够影响基于角色的用户接口和工具扩展性;能够更好地将建模与生命周期的其它方面集成,比如需求管理。Rational Software Architect将先前定义的建模、开发和代码分析的实践转换成集成的、统一的设计和开发经验。在一个开放,而不是专有的环境中工作,所有的用户都可以更容易地根据需要定制他们的产品。







Rational Software Architect:集成的设计和开发

我们这个新的、基于Eclipse的Rational Software Architect是一个完整的设计和开发工具解决方案。如同我们前面所提及,它包括Rational Application Developer for WebSphere Software (WebSphere Studio Application Developer的新版本) 的所有能力,拥有代码可视化和可视化编辑特性;它是客户开始使用MDD的一个很好的入口。另外,它还包括Rational Web Developer for WebSphere Software (以前的 WebSphere Studio Site Developer) 全部的、更新的能力。

Rational Software Architec在Rational Application Developer的特性上构建,增加了对MDD的全力支持,包括UML 2建模、代码生成、模式、模型转换,以及实现 MDA开发风格的新途径。它并不是一个全新的产品,是特别为想要应用MDD的客户而设计的,展示了自然的演化和在IBM Rational工具中已拥有的能力。它特别为试图广泛应用MDD的用户而打包。

结构检查和控制

我们已经从客户处了解到,无论你将应用系统设计和构建得多么好,也总会在实现阶段经历代码层的演化,出现未检查的现象,最终导致架构性能的降低,严重影响软件的质量。

针对这个现象,软件架构师在实现之前检查已有的代码,以评估其真实的体系结构和质量。做这项工作的过程中,他们往往发现各种各样的问题:从设计到代码的不正确映射;代码级的改变引起设计和架构的依赖;编码标准、规则和样式方面不规范等。最终,应用系统的架构是由部署的代码来呈现的,所以软件架构师必须分析代码,以估计它的可维护性,并且在规则的辅助下,掌握架构的演化。

为了给这样的分析提供更自动的支持,Rational Software Architect引入了"Java 应用结构的检查和控制"特性。它支持基于模板的规则,并且使用高级别的软件可视化技术,允许用户看到J2EE 和 J2SE实现的架构。用户可以更容易地发现架构的不足之处,或者"反模式",比如循环依赖、集线器之类的一些已逐渐加入到应用程序源代码中的问题。

通过代码可视化和开发人员级别的测试,进行自动结构的检查和控制之后,软件架构师能够显著地提高他们所设计和部署的应用系统的质量。我们在Rational Software Architect中引入的先进特性将开始改变架构师和开发人员考虑开发过程的方法。

运行时支持和语言支持

客户已经告诉我们,在应用的运行时支持环境中设计和开发工具所扮演的重要角色。Rational Software Architect在WebSphere应用服务器上为Java应用提供了极大的运行时支持;它也允许由开放工业标准支持的Java虚拟机和数据相互操作性的多平台执行支持。此外,因为Rational Software Architect 包括支持BEA WebLogic Server的Rational Application Developer,所以,使用Rational Software Architect部署的应用也是隐式的多平台。Eclipse C/C++ Development Tool (CDT)作为IBM Rational Software Architect的一部分而打包在内,同时也扩展了对C和C++开发的支持。基于Eclipse的解决方案允许我们在Rational Software Architect中复用一些特性,来支持上述语言和JAVA中的MDD。

培养现代建模生态系统

我们最近了所发布了一系列Rational Software Architect,为不需要代码生成或者可视化的用户着重建模和设计这两方面。Rational Software Modeler支持UML 2的所有建模特性,并且通过Eclipse Modeling Framework (EMF)提供高级扩展的特性。Eclipse框架的开放性和健壮的扩展性使Rational Software Modeler适合支持曾为Rational Rose的成功作出一些贡献的、支持与生态系统类似的客户和第三方扩展的建模"生态系统"。

Rational Software Architect 和 Rational Software Modeler只是IBM Software Development Platform之后阐明策略的两个实例:帮助业务自动化并集成软件开发。我们希望各角色的实践者都能够拥有他们所创建和获得的单一的用户体验,通用的定义和资产的管理。团队的每个人都能够简单地选择与他们角色和责任相匹配的产品。IBM Software Development Platform是关于团队和组织生产率的。

对模型驱动架构的支持

MDD为使用模型开发软件展示了许多风格,其中,模型驱动体系架构(MDA)是由对象管理组织 (OMG).1创建的。MDA基于一些OMG标准之上,包括Unified Modeling Language (UML 2),以及涌现出来的关于如何最好地将建模应用到软件开发过程的哲理。MDA在抽象层定义了模型,然后定义映射和管理模型与各种实现技术之间关系的转换。以下是一些有用的MDA建模层的定义:

  • 计算无关模型 (Computation-Independent Model , CIM) - 不考虑结构或者处理的情况下,处理系统环境和需求。
  • 平台无关模型 (Platform-Independent Model , PIM) - 不考虑与特定平台相关的细节,处理系统的操作。
  • 平台相关模型 (Platform-Specific Model, PSM) - 将PIM和与特定平台相关的细节结合起来。
  • 平台模型 (Platform Model, PM) - 对于使用 PIM 定义组成特定平台的技术概念、元素和服务。
  • 转化模型(Transformation Model, TM)- 定义并指定从特定PIM转换到PSM所需的转换。

尽管MDA并不是一个标准,它明确提倡使用一些已有的OMG标准。MDA指定了:

  • Meta-Object Facility (MOF)用于定义元模型。
  • UML 2用于指定应用开发模型和转化。
  • MOF Query / View / Transform (QVT)用于指定转化(一旦它被规范化)。

一些客户称他们已经在应用MDA很长时间,并且IBM Rational员工与他们中的许多一起工作 - 以及OMG - 将MDA演化成当前状态。Rational Software Architect支持MDA的理论,也支持MDA建立的基本标准。

但是,我们不能将Rational Software Architect归为一个MDA工具,因为在某种程度上,MDA并不是一个标准,而且仍有一些争论。更重要的是,Rational Software Architect实际上支持一系列以代码为中心的、基于向导的设计和开发范例。换而言之,它支持MDA及其它的开发风格。







Rational Software Architect是否适合于你?

Rational Software Architect是IBM用于建模和模型驱动开发的最完整、最健壮的解决方案。但是它是否适合你?以下选择将帮助你回答这个问题。

你是否从事软件架构的工作?

我们近期发布的产品区分软件架构师与软件开发人员,以及软件架构师与数据架构师这几个角色。例如,这个更大的粒度反映在高度面向角色的IBM Software Development Platform的所有工具中。构建进我们产品名称中的角色定义和区别可以帮助用户基于他们的活动和责任,决定哪些工具最好地适合于不同的员工。但是,角色名字在企业、组织甚至项目线中变化,所以你应该把我们新产品的名称当作决定什么工具对开发团队的哪些人员最有用的起点。

软件架构师是开发团队中负责作出主要技术决定的人员。有时,是由一个人来负责,而这个人常常是项目的开发的领导人;有时,几个人,可能有一个来充当主要架构师,共同来承担这个角色;还有的时候,团队的所有开发人员在架构能力的同一时间操作-一个增长的趋势。经常地,较之他们的工作职位,架构师的概念往往与开发者关联更多些。

软件架构师的职责包括识别并记录应用架构的方面,包括需求、设计、实现和部署。这些方面需要不同的,但相关的应用视图。当然,在开始的架构设计和实际构建架构(真正在代码中运行的架构)之间也有区别。我们认为软件架构师需要一个帮助他们定义所需架构的工具,允许他们发现应用系统的真实架构,并且帮助他们协调两种视图。

Rational Software Architect能够完成这些所有的工作。它包括开发和查看实现中的帮助,以及维护和控制实现来保持架构集成。

如同我们上面所提到的,做架构工作的人员往往并不是架构师。可以从使用Rational Software Architect过程中获益的团队人员有:

  • 需要开发代码的软件架构师。
  • 需要理解并参与代码和模型工作的开发人员。
  • 想要充分应用MDD能力的人员
  • 那些负责检查和确认已有的架构或者想要看到架构演化的实施过程的人员
  • 想在Eclipse 之上应用MDD的C++开发人员。

请记着,Rational Software Architect包括Rational Application Developer的全部能力,一个完全的IDE。客户得到打包进一个产品的完整的设计和构建解决方案。针对那些要求UML 2建模能力而不需开发架构的用户,我们提供了Rational Software Modeler。

你是否使用IBM Rational的其它建模产品?

如果你已在使用IBM Rational软件,建议你有必要时,考虑移植到Rational Software Architect 或者 Rational Software Modeler。这些新产品的优点包括:

  • Eclipse 集成
  • 通过EMF的高级建模和工具扩展性。
  • 更容易使用。
  • UML 2, 最新的建模技术。
  • Rational Software Architect中的新的结构检查和控制特性。
  • Eclipse之上,使用C++的MDD。
  • 建立复杂转化的能力。
  • 以静态次序图表方法可视化代码的能力。
  • 代码检查的能力。
  • 在Rational Software Architect中使用Java IDE和MDD工具。

如果你的团队当前在使用Rational Rose 或者 Rational XDE,那么对你而言,移植到Rational Application Developer也是有道理的。WebSphere Studio Application Developer的代码可视化和可视化编辑特性已升级到UML 2并且在Rational Application Developer中继续存在。尽管它不支持通用建模或者完全的MDD,却支持UML入门级的使用。如果你正使用Rational Rose 或者 Rational XDE,主要为了从代码中截取图形文档,那么这个级别的UML支持就有可能满足了你的需要。

对于Java和Web开发,我们鼓励用户从当前建模工具过渡到Rational Software Architect。除了移植到基于Eclipse的工具的技术优势,IBM还提供了一系列移植和升级的途径。请参照http://www-306.ibm.com/software/awdtools/architect/swarchitect/support/index.html 以了解最新升级的支持信息。

posted @ 2006-04-21 19:46 wsdfsdf 阅读(275) | 评论 (0)编辑 收藏

大赛推荐文章之一-----以服务为中心的企业整合

引言

本文讨论企业整合(集成)的新发展:以服务为中心的集成(Service-Oriented Integration,简称 SOI)。 您将了解到什么是 SOI,推动 SOI 发展的因素以及SOI 带来的价值。作者讨论了 SOI 解决方案所涉及的要素,和这些要素相关的技术、标准以及IBM的产品支持,最后作为总结将它们包括在 IBM 的集成参考架构中,指出如何实现各种集成需求。本文还讨论了在企业集成实践中需要重点注意的事情,如战略规划和IT管理。本文的姊妹篇"以服务为中心的企业整合-案例分析",用一个实际案例来说明基于 IBM 产品的实际 SOI 应用,帮助读者感性地理解 SOI。







1. 企业集成的新方向: SOI

什么是"以服务为中心的集成"?

"以服务为中心的集成"是英文词语"Service-Oriented Integration"的中文翻译,简称 SOI。 它可以定义为:在"以服务为中心的体系架构"(Service-Oriented Architecture,SOA)中,通过服务的交互来集成各企业的 IT 资源,如分布的应用或者数据,帮助企业 IT 部门将已有但老旧而不灵活的系统集成起来,释放其中功能或数据为可重用的服务与业务流程。

为什么需要"以服务为中心的集成"?

企业集成的推动因素。推动"企业应用集成"(Enterprise Application Integration, EAI )的因素,来自商务和技术两个方面。从商务的角度,今天企业要在全球化的经济环境中求生存和发展,就必须努力适应越来越强的竞争和越来越快的变化,这意味着一个企业的业务模型要变得灵活以快速应变,也就是随需应变。在一个企业的业务模型变得灵活的转型过程中,需要将业务流程不断地自动化,然后跨部门横向集成它们,并且管理和优化它们,这意味着支撑这些流程的技术基础,即 IT 应用和数据资源等,需要在企业范围内集成。所以,业务灵活应变的能力是 SOI 的驱动因素之一。

在技术方面,IT 部门面临着业务部门越来越高的期望值,就是用更少的钱做更多的事情,但要做得更快、更好,这迫使 IT 部门考虑如何最大程度地重用已有应用的功能和数据资源,来支持新应用的开发。但这种重用面临着如何将高度异构、分布的各个应用集成起来的难题,SOI是目前最有效的解决之道。在 SOI 中,首先各个应用的功能被封装为基于标准来描述和供访问的服务;其次,借助于 SOI 的通用连接能力,这些来自不同应用的服务,不需要关心对方的位置和实现技术,以松散耦合的方式相互交互来完成集成,所以只要服务的接口描述不变,服务的使用者和提供者双方可以自由发生变化而互不影响;最后,通过服务组合,服务可以按不同的方式来组合成为不同的业务流程。当某个业务流程发生变化的时候,大多数时候,我们调整组装服务的方式来满足这种变化。总之,这种通过重用粗粒度服务而不是在底层编程来开发新应用以满足业务新需求的方法,使得 IT 组织能够以更少的投入、更快的速度、更好的质量来开发应用。综上所述,可以灵活应变的重用方式,是 SOI 的另一个驱动因素。

集成解决方案的发展沿革。集成企业应用的方法各种各样,初级一点的借助于简单的机制如应用编程接口,管道、共享目录和文件,或者某些传输协议如 FTP 来交换数据和互操作;高级一点的则使用各种消息中间件来提供消息的传输、转换、合并、路由和分发、事件的发布和订阅等;分布式计算技术,如 CORBA,COM 等,也有较广的使用。

在初期实践中,应用之间的连接拓扑大多数情况下是点对点的,硬编码的,所使用的协议是非标准的,功能的提供者和使用者之间是紧耦合的,功能的粒度通常较细,数据的表示也不统一。随着集成复杂度的增长,和实践经验的总结,开始出现一些从好的实践中总结出来的集成模式,如消息中枢(Message Backbone)、信息总线、应用集成中心(Application Integration Hub),这些模式从不同的角度以不同的方式来管理集成的复杂性,但都或多或少地尝试提供一个集成基础设施来简化应用之间日趋复杂的连接拓扑,提供异构数据和功能访问方式之间的转换,甚至提供一致的数据和功能表示与访问方式。通过元数据和应用相关的领域知识,这些集成基础实施提供了很多中介和转换的机制与模式来实现高级的功能,如路由、动态选择等能力。

随着互联网络技术的发展、普及和应用,相关技术和标准,如 XML 和 Web Service,被广为接受,这给应用集成带来了新的发展。企业应用架构的风格开始朝着以服务为中心的方向发展,而企业应用集成也转向以服务为中心的集成,服务的描述和访问基于开放一致的标准(如 WSDL),连接应用的基础设施继承了过去发展的成果,并通过支持开放标准,来提供通用的连接服务,包括基本的服务如消息传输、转换,事件的发布和订阅,服务的中介(选择、路由),和高级的服务如安全、事务、服务质量,以及可管理性,来使得服务在一个标准、开放、可靠、安全、可管理、满足服务质量要求的环境下,以松散耦合的方式相互交户,根据需求动态地进行企业应用集成,达成非常高程度的灵活应变能力和重用能力。SOI 是对现有集成技术与实践的总结和标准化。

SOI 的好处。SOI 继承和发展了传统的 EAI,比较而言,SOI 的好处在于:

  • 定义良好而又基于标准的接口 - 服务的描述易于理解,而且标准一致
  • 实现技术和位置的透明 - 提供服务功能的应用,它的位置以及所使用的实现技术被接口所屏蔽,事实上,不需要一个固定的服务提供者
  • 灵活性 - 只要服务的接口不变,服务的提供者和服务的使用者都可以变化而不影响彼此,从而将变化带来的影响减少到了最少
  • 重用能力
  • 渐进式集成 - 在 SOI 中,通过将若干已有系统的相关功能转化为服务来进行集成。随着这些项目的进行,可重用的服务越来越多,最终,新的集成需求将绝大多数可以通过已有的服务来完成。所以,我们可以从当前重要的集成需求开始来封装已有系统的功能和开发必要的新服务,以渐进的方式逐步地扩展到整个企业范围内的集成。更重要的是,由于服务的灵活性,即使已有系统迁移到新的技术平台,甚至是被替代,都不会影响到依赖于这个应用所提供功能的那些应用,从而保证了集成对变化的适应能力,使得业务灵活性有一个坚实的基础。这也意味着从传统规模大、投入大、周期长、见效慢、风险高、专有技术,转向小步快跑、见效迅速、风险低、基于标准的集成方式。这对于如今面对业务需求快速变化的 IT 机构来说,SOI 在投入和工程方面的好处,是非常吸引人的






2. SOI解决方案

2.1. SOI解决方案的要素

通常,完整的SOI 解决方案包括如下要素:

  • 代表应用的功能和数据资源的服务;
  • 提供连接服务的基础设施即企业服务总线(Enterprise Service Bus, ESB),连接已有应用的连接器(Connector)和适配器(Adapter);
  • 元数据及其管理如服务描述和服务注册管理(Service Registry)等;
  • 将服务组合成业务流程的引擎如 BPEL4WS 引擎;
  • 业务流程管理和业务绩效管理的部分;
  • 一个基于标准的编程模型以及支持它的建模、开发和组装、测试、部署和管理的端到端工具环境;

IBM的 Websphere 业务集成参考架构(见图1,以下称参考架构)是典型的以服务为中心的企业集成架构,本文接下来的讨论都将以此参考架构为背景进行。



以服务为中心的企业集成采用"关注点分离"(Separation of Concern)的方法规划企业集成中的各种架构元素,同时从服务视角规划每种架构元素提供的服务,以及服务如何被组合在一起完成某种类型的集成。这里架构元素提供的服务既包括狭义的服务(WSDL描述),也包括广义的服务(某种能力)。从服务为中心的视角看来,企业集成的架构按图1所示的方式划分为六大类:

  • 业务逻辑服务(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):支持业务系统运行的各种基础设施管理能力或服务,如安全服务、目录服务、系统管理和资源虚拟化。

2.2. 连接服务 - 企业服务总线

企业服务总线(Enterprise Service Bus),以下简称ESB, 是过去消息中间件的发展,ESB 采用了"总线"这样一种模式来管理和简化应用之间的集成拓扑结构,以广为接受的开放标准为基础来支持应用之间在消息、事件和服务的级别上动态地互联互通。

ESB 的基本特征和能力包括:描述服务的元数据和服务注册管理;在服务请求者和提供者之间传递数据,以及对这些数据进行转换的能力,并支持由实践中总结出来的一些模式如同步模式,异步模式等;发现、路由、匹配和选择的能力,以支持服务之间的动态交互,解耦服务请求者和服务提供者。高级一些的能力,包括对安全的支持、服务质量保证、可管理性和负载平衡等。

ESB 所提供的基于标准的连接服务,将应用中实现的功能或者数据资源转化为服务请求者能以标准的方式来访问的服务;当请求者来请求一个服务时,ESB 中这种中介转化过程可能简单到什么也没有,也可能要很复杂的中介服务支持,包括动态地查找、选择一个服务,消息的传递、路由和转换、协议的转换。这种中介过程,是 ESB 借助于服务注册管理以及问题域相关的知识(如业务方面的一些规则等)自动进行的,不需要服务请求者和提供者介入,从而实现了解耦服务请求者和提供者的技术基础,使得服务请求者不需要关心服务提供者的位置和具体实现技术,双方在保持接口不变的情况下,各自可以独立地演变。

所以,ESB 采用总线结构模式简化了应用之间的集成拓扑,通过源自实践的模式,提供了基于标准的通用连接服务,使得服务请求者和服务提供者之间可以以松散耦合、动态的方式交互,从而在不同层次上使得SOI 解决方案是一个松散耦合、灵活的架构。

需要注意的是,ESB 是一种架构模式,不能简单地等同于特定的技术或者产品,但实现 ESB 确实需要各种产品在运行时和工具方面的支持。IBM 有很好的产品支持,运行时支持包括 WebSphere ESB 和 WebSphere Message Broker;而工具方面 IBM 则有 WebSphere Integration Developer,支持用户以图形界面的方式来完成相关的开发任务,如发布服务,使用各种模式,转换消息,定义路由等等。

2.3. 业务逻辑服务

整合已有应用 - 应用和信息访问服务。已有应用和信息是实现业务逻辑和业务数据的重要资产。通过集成已有的应用和信息将可以在已有企业系统上实现更多增值服务,所以集成已有应用和信息是企业集成中重要的一环。

以服务为中心的企业集成通过应用和信息访问服务(Application and Information Access Service)来实现对已有应用和信息集成。它通过各种适配器技术将已有系统中的业务逻辑和业务数据包装成企业服务总线支持的协议和数据格式。通过企业服务总线,这些被包装起来的业务逻辑和数据就可以方便的参与上层的业务流程,从而已有应用系统的能力可以得以继续发挥。这里的已有应用包括遗留应用、预包装的应用和各种企业数据存储。在参考架构中,主要有两类访问服务:

  • 可接入服务(On-Ramp Service): 通过各种消息通信模式(单向、请求/应答和轮询)将业务逻辑和业务数据包装成企业服务总线可以访问的功能。
  • 事件发现服务(Event Detect Service) : 提供事件通知服务将已有应用和数据中的变化通过事件框架发布到企业服务总线上。

整合新开发的应用 - 业务应用服务。和已有应用和数据类似,新开发的应用也作为重要的业务逻辑成为企业集成的目标。以服务为中心的企业集成通过业务应用服务(Business Application Service)实现新应用集成。一方面业务应用服务帮助程序员开发可重用、可维护和灵活的业务逻辑组件,另一方面,它也提供运行时的集成提供对业务逻辑组件的自治管理。在参考架构中,有三类业务应用服务:

  • 组件服务(Component Service):为可重用的组件提供应用的运行时容器管理服务,如对象持久化、组件安全管理和事务管理等。
  • 核心服务(Core Service):提供运行时的服务,包括内存管理、对象实例化和对象池、性能管理和负载均衡、可用性管理等。
  • 接口服务(Interface Service):提供和其他企业系统集成的接口,如其他企业应用,数据库、消息系统和管理框架。

整合客户和业务伙伴(B2C/B2B)-伙伴服务。以服务为中心的企业集成通过伙伴服务提供与企业外部的B2B的集成能力。因为业务伙伴系统的异构性,伙伴服务需要支持多种传输协议和数据格式。在参考架构中,提供如下服务:

  • 社区服务(Community Service): 用于管理和企业贸易的业务伙伴,支持以交易中心(Trade Hub)为主的集中式管理和以伙伴为中心的自我管理。
  • 文档服务(Document Service):用于支持和业务伙伴交换的文档格式,以及交互的流程和状态管理,支持主流的RosettaNet、EDI和AS1/AS2等。
  • 协议服务(Protocol Service):为文档的交互提供传输层的支持,包括认证和路由等。

2.4. 控制服务

数据整合-信息服务。企业数据的分布性和异构性是应用系统方便访问企业数据和在企业数据之上提供增值服务的主要障碍。数据集成和聚合技术在这种背景下诞生,用于提供对分布式数据和异构数据的透明访问。

以服务为中心的企业集成通过信息服务提供集成数据的能力,目前主要包括如下集中信息服务:

  • 联邦服务(Federation Service): 联邦服务提供将各种类型的数据聚合的能力,它既支持关系型数据,也支持象XML数据、文本数据和内容数据等非关系型数据。同时,所有的数据仍然在自己本身的方式管理。
  • 复制服务(Replication Service):复制服务提供远程数据的本地访问能力,它通过自动的实时复制和数据转换,在本地维护一个数据源的副本。本地数据和数据源在技术实现上可以是独立的。
  • 转换服务(Transformation Service):转换服务用于数据源格式到目标格式的转换,可以是批量的,或者是基于记录的。
  • 搜索服务(Search Service):提供对企业数据的查询和检索服务,既支持数据库等结构化数据,也支持象PDF等非结构化数据。

流程整合- 流程服务。企业部门内部的IT系统通过将业务活动自动化来提高业务活动的效率。但是这些部门的业务活动并不是独立的,而是和其他部门的活动彼此关联的。勿容置疑,将彼此关联的业务活动组成自动化流程可以进一步提高业务活动的效率。业务流程集成正是在这一背景下诞生的。

以服务为中心的企业集成通过流程服务来完成业务流程集成。在业务流程集成中,粒度的业务逻辑被组合成业务流程。流程服务提供自动执行这些业务流程的能力。在参考架构中,流程服务包括如下内容:

  • 编排服务(Choreography Service): 编排服务通过预定义的流程逻辑控制流程中业务活动的执行,并帮助业务流程从错误中恢复。
  • 事务服务(Transaction Service):事务服务用于保证流程执行中的事务特性(ACID)。对于短流程,通常采用传统的两阶段提交技术,对于长流程,一般采用补偿的方法。
  • 人工服务(Staff Service):人工服务用于将人工的活动集成到流程中,一方面它通过关联的交互服务使得人工可以参与到流程执行中,另一方面它需要管理由于人工参与带来的管理任务如:任务分派,授权和监管等。

用户访问整合 - 交互服务。将适当的信息,在适当的时间,传递给适当的人是一直是信息技术追求的目标。用户访问集成是实现这一目标的重要一环,它负责将信息系统中的信息传递给客户,不管它在那里,它以什么样的设备接入。

以服务为中心的企业集成通过交互服务来实现用户访问集成。参考架构中的交互服务包括如下类型:

  • 交付服务(Delivery Service): 交付服务提供运行时的交互框架,它通过各种技术支持同样的交互逻辑可以在多种方式(图形界面、语音和普及计算消息)和设备(桌面、PDA、无线终端等)上运行,比如通过页面聚合和标签翻译使得同一个Portlet可以在桌面浏览器和PDA浏览器上展现。
  • 体验服务(Experience Service): 通过用户为中心的服务增强用户体验, 其中的技术包括:个性化、协作、单点登录等。
  • 资源服务(Resource Service): 提供运行时交互组件的管理,如安全配置、界面皮肤等。

2.5. 开发支持

企业集成涉及面很广,不仅需要开发新的应用并使其成为可以被用于企业集成的功能组件,而且需要将被包装的已有的应用和数据用于集成;不仅有企业内部的集成,而且需要和企业外部的系统集成;不仅有交互集成和数据集成,还有功能和应用集成。考虑到这其中的每部分在技术上都会涉及到各种平台和中间件,企业集成的技术复杂性是普通应用开发不可比拟的。这种技术复杂性需要更强有力的开发工具支持。企业集成的开发工具需要有标准的工具框架,这些工具能够以即插即用方式支持来自多家厂商的开发工具。同时,企业集成的开发工具需要支持整个软件开发周期,以提高开发过程中各种角色的生产力。

在以服务为中心的企业集成中,除了需要支持整个软件开发周期和标准的工具框架以外,开发服务需要提供和服务开发相关的技术:

  • 用于支持以服务为中心的企业集成方法学和建模,如SODA和IBM的SOMA(Service Oriented Modeling and Architecture)
  • 用于服务为中心的编程模型,如WSDL, BPEL4WS,SCA和SDO等

开发环境和工具中为不同开发者的角色提供的功能被称为开发服务。根据开发过程中开发者角色和职责的不同,有如下四类服务:

  • 建模服务(Model Service):用于构建可视化的业务流程模型
  • 设计服务(Design Service):根据业务模型,进一步分解为服务组件;设计服务用于设计和开发这些服务组件。
  • 实现服务(Implementation Serivice):用于将设计和开发的服务组件部署到生产环境中
  • 测试服务(Test Service):支持服务组件的单元测试和系统的集成测试

2.6. 业务创新和优化

一方面,以服务为中心的企业集成通过各种集成提高信息流转速度,从而提高生产效率。另一方面,以服务为中心的企业集成也为业务创新和优化提供了支持平台-业务创新和优化服务。

业务创新和优化服务以业务性能管理(BPM)技术为核心提供业务事件发布、收集和关键业务指标监控能力。具体而言,业务创新和优化服务由以下服务组成:

  • 公共事件框架服务(Common Event Infrastructure Service):通过一个公共事件框架提供IT和业务事件的激发、存储和分类等。
  • 采集服务(Collection Service):通过基于策略的过滤和相关性分析检测感兴趣的服务。
  • 监控服务(Monitoring Service):通过事件与监控上下文间的映射,计算和管理业务流程的关键性能指标(KPI)

业务创新和优化服务与开发服务是紧密相关联的。在建模阶段被确定的业务流程的关键性能指标被转为特别的事件标志被构建到业务流程中,建模过程中的业务流程也被转换为用于监控服务的监控上下文。在业务流程执行过程中,这些事件标志激发的事件被公共事件框架服务截获,经过采集服务的过滤被传递给监控服务用于计算关键性能指标。关键性能指标作为重要的数据被用于重构或优化业务流程。这种迭代的方法使得业务流程处于不断的优化中。

2.7. 管理支持

为业务流程和服务提供安全、高效和健康的运行环境也是以服务为中心的企业集成重要的部分,它由IT服务管理来完成。IT服务管理包括如下两部分:

安全和目录服务(Security and Directory Service):企业范围的用户、认证和授权管理,如单点登录(SSO);系统管理和虚拟化服务(System Management and Virtualization Service):用于管理服务器,存储、网络和其他IT资源。

IT服务管理中相当一部分服务是面向软硬件管理的,而另外一部分服务,特别是安全和目录服务,以及操作系统和中间件管理,会通过企业服务总线和其他服务集成在一起,用于实现业务流程和服务的非功能性需求,如性能、可用性和安全性等。

2.8. SOI中技术标准和IBM产品支持

下面的表格列出乐SOI架构元素中的技术标准,和IBM的产品如何支持这些架构元素。


表 1:SOI架构元素中的技术标准以及支持架构元素的IBM的产品







3. SOI 实践

企业集成首先是一个战略性的活动,在我们的经验中,有很多的企业将重点放在集成技术上,这导致了很多失败的案例。作为一个战略性的活动,企业集成首先要从全局出发,制定整个企业集成的策略。这种策略包括业务目标,集成路线图,技术规范,和对开发管理提出的新要求。

企业集成的目的是为了整合 IT 资源,形成一个灵活的 IT 基础设施,来满足业务随需应变的要求。所以要充分考虑业务面的压力和痛点,未来发展和转型对 IT 带来的新需求,以确定集成的战略目标。在环境发生变化时,要随业务面的调整作必要的修改。在我们的观察中,企业 IT 组织往往由于缺乏高级业务管理人员的参与,而无法制定与业务对齐的集成战略,失去企业集成赖以成功的最重要的基础。

在制定集成的战略目标后,要根据目标的优先级,考察当前 IT 环境,确定集成远景,分析差距,定义集成路线图。考察当前可得到的技术、产品、相关技能和服务的可获得状况,定义高层技术规范,包括集成方法、参考架构、技术和产品的选择标准、所遵循的业界标准等等。然后结合人力、物力和资金的投入情况,导出项目群。在我们的观察中,很多企业为了应付业务需求,匆忙上马,缺乏统一规划,导致企业 IT 架构越来越混乱,不能适应业务的变化而日渐被动。

由于集成是一个企业范围内的活动,一个集成项目往往影响若干个部门,其结果也由多个部门所共享使用,所以需要企业级的协调机制。这要求企业调整其已有的 IT 管理(IT Governance)机制,要有一个角色来协调集成项目,并被授权,利用 IT 开发管理的过程,保证相应集成规范得到执行。

另外值得注意的是关于成熟度的考虑,不同企业有不同的成熟度,包括业务本身、IT 系统、IT 组织自身在技能和管理方面,它们的成熟度,对企业集成的成功与否,也都有很大的影响。对成熟度的考察,会帮助我们制定更稳健、实际的集成策略。

服务建模(Service Modeling)是 SOI 活动中至关重要的活动。它包括如何找到和确定服务,如何处理服务的粒度,如何通过服务体现和实现业务目标,如何详细说明服务,如何确定服务与已有系统的关系等。在我们的实践中,这对很多 IT 组织机构都是一个难题,可以考虑一些专业公司的培训,如 IBM SOA 设计中心基于丰富的实践所提供的各种服务。







4. 结束语

以服务为中心的企业集成方法是对以往企业集成技术的继承与发展。它基于关注点分离、松散耦合等源自最佳实践的架构原则,继承了EAI,消息总线,流程集成,数据集成等优秀技术,结合以服务为中心(Service Orientation)的先进思想,正在给企业集成领域带来巨大的变化。随着SOI及相关技术的逐渐成熟,SOI正在成为企业集成的新方向。本文的姊妹篇"以服务为中心的企业整合-案例分析",将用一个实际案例来说明基于 IBM 产品的实际 SOI 应用,帮助读者感性地理解 SOI。

posted @ 2006-04-21 19:43 wsdfsdf 阅读(194) | 评论 (0)编辑 收藏

4月21日-----任务:读《用于实现 Web 服务的 SOA 编程模型》系列文章

读完了《在企业级 SOA 中使用 Web 服务》7篇系列文章后,已经在概念上了解了一些SOA知识。所以现在要看一些编程实现方面的文章,《用于实现 Web 服务的 SOA 编程模型》正是不错的选择。

posted @ 2006-04-21 15:19 wsdfsdf 阅读(148) | 评论 (1)编辑 收藏

4月21日-----读完《在企业级 SOA 中使用 Web 服务》7篇系列文章总结

第一部分:
这部分的核心内容就是多重SOA。使用SOA来消除企业系统之前的差异需要很好的构架,需要提前规划,尤其要考虑到SOA数量的问题,不要出现SOA超载,要在开发的每个阶段都进行超载测试。
第二部分:
这部分涉及到了Web服务的互操作问题。如何使其最优化,进行了相关讨论。这里提出了一个动态服务链接的概念,我个人认为其基本思想和DLL(动态链接库)的思想是一致的,都是用来提高效率的。使用多平台SOA之间的外部Web服务互操作性最优需要事先计划好可以开发多少SOA。
第三部分:
这部分还是为了提高效率而写,不过针对的方面又有不同。将SOA合并成三维的,立体的架构。这样的整合思想可以提高速度和可靠性。在这个过程中可以采取复用的体系结构以及模块化的SOA库。
第四部分:
这部分讲解了使用Rational构建SOA中间件应用程序。列出了四种主要的方法:自顶向下、自底向上、旁路、嵌入式。把Web服务分为逻辑和物理两种。物理Web服务就是在存储库中所发布和找到的Web服务,逻辑服务是抽象的说法,创建一个逻辑Web服务后可以继续将一个逻辑服务与另一个物理Web服务组合起来,创建一个新的逻辑Web服务以供使用。
第五部分:
这部分讨论在优化 Web 服务和 SOA 的过程中具有最高优先级的 Web 服务的业务流程规则。一旦开发人员优化了流程规则,那么他们就可以开始减少:Web 请求的数量、执行时间、访问时间、不需要的数据、带宽量。这里提到了一个很重要的概念:Web 服务的业务流程执行语言(Business Process Execution Language for Web Services,BPEL4WS)。它可以创建新的业务逻辑、调用 Web 服务、操作数据、抛出错误或者终止流程。使用UML来消除语言的隔阂,减少由于缺乏交流带来的成本。最后提到了WebSphere Business Integration工具,她有效的支持这方面的开发。
第六部分:
这部分介绍了负载应用程序的某些问题如何影响了 Web 服务应用程序间的互操作方式。文中包含了一个流量瓶颈的实例,导致该瓶颈的原因是:在特定期间有太多的访问者基于业务流程发送了太多的请求到一个 Web 服务应用程序。接着又讲了如何从负载平衡技术中获益。作为一个类比,用上了购物车,生动地解释了基本原理。负载平衡技术包括以下几种:简单路由、DNS Round Robin、复杂算法、智能路由。最后提到了WebSphere Application Server,她就是一款基于服务器的软件,它在负载平衡和故障转移中同时使用了复杂算法和智能路由。
第七部分:
这部分主要在讲xml在SOA的应用,使用xml二进制打包规范加速 Web 服务应用程序。写了许多典型的xml代码,直接点出其高效之处。
总之,这一系列文章的主要目的是高效,高效,再高效。在许多不同方面提高SOA的效率,最终打造一款功能强大,效率很高的企业级工程。

posted @ 2006-04-21 13:54 wsdfsdf 阅读(367) | 评论 (2)编辑 收藏

4月21日-----Top100

进入了博客排名前100,以后被点击的几率就更大了。希望blog能越办越好

posted @ 2006-04-21 13:49 wsdfsdf 阅读(80) | 评论 (0)编辑 收藏

读《在企业级 SOA 中使用 Web 服务,第 3 部分: 将您的 SOA 合并成三维的整合中心以提高速度和可靠性》遇到的问题

原文链接:http://www.cppblog.com/zhangji198543/archive/2006/04/17/5695.html


第一个共享的 SOA 的三维中心 :
第一个共享的 SOA 的三维中心
 第二个共享的 SOA 的三维中心
第二个共享的 SOA 的三维中心
这两个图应该怎么看?
怎么看连接器从一个SOA到另一个SOA?

posted @ 2006-04-20 17:21 wsdfsdf 阅读(75) | 评论 (0)编辑 收藏

4月20日-------困

今天的困难就一个字-----困。睡得都太少了。我根本就没睡,Merlin和Tory也只睡了不足3个小时而已。
解决方法:还有啥办法?公司的免费茶和咖啡,呵呵!喝吧!

posted @ 2006-04-20 13:49 wsdfsdf 阅读(145) | 评论 (0)编辑 收藏

4月20日-----奋斗50篇技术文档

昨晚弄那个人才招聘的网站居然弄到了天亮,吃完早饭就出去上《软件工程》去了。一脸憔悴。
现在还没来得及睡觉,也不准备睡了,拼了!
今天的安排还是和前几天一样-----看技术文档!预计10天内都会在学习SOA之中。有感想了,就来blog上写下。

posted @ 2006-04-20 13:47 wsdfsdf 阅读(158) | 评论 (0)编辑 收藏

4月20日-----随感

posted @ 2006-04-20 13:27 wsdfsdf 阅读(78) | 评论 (0)编辑 收藏

仅列出标题
共19页: First 8 9 10 11 12 13 14 15 16 Last