51START

会议记录——5月20日

2006-05-23

Tag：工作日志

               SOA会议记录
——5月20日
1             会议时间
        5月13日，上午9:30~13:00
2             会议地点
        实验室会议室
3             参加者
        wordinsand，麦卡，SeraphZhang，flyingdonkeycn
4             会议主要内容
nkbxq师兄有事儿缺席，我们几个对于nkbxq师兄写的“凤凰的业务流程图”和“业务分析”进行了分析和解读。
大家认为在“业务描述”表中提出的“上下游”的关系很有意义。通过对“上下游”的分析，可以将企业的业务流程分析清楚。
根据“业务描述”表绘制了业务流程图。从图中可以直观的看出各个部门的连接和制约关系，以及整个业务流程。从而提出了，做业务流程分析的目的在于：增加关键路径数量，减少关键路径环节。
进一步讨论分析后，认为业务流程图可以在部门的基础上进行扩充。增加每个部门的子节点，这些节点的属性体现为该部门的功能。增加部门（部门功能节点）间的边，这些边的属性体现为业务上的流程。
本次讨论的上半场到底暂告以段落。在上半场的讨论中，大家主要围绕如何对企业业务流程进行分解，从而可以得到可互操作的、独立的、模块化的、位置明确的、松耦合的服务模块。
麦卡是下半场讨论的主角。他就自己这一段时间的研究，提出了自己对ESB的理解和看法。他主要阐述了以下几点（详见blog“头脑风暴—SOA中的ESB分析”）：
1.         计算机组成原理中的总线概念
2.         企业服务总线（ESB）的定义
3.         ESB的组成模块
在具体的讨论中，大家针对具体的概念和含义进行了探讨。比如，“通道”、“内部通道”两个概念的范围界定和功能在讨论中得到了细化。
在针对“内部通道”的讨论中，还引申出了智能决策的问题。从而联想到大赛题目中的8.1.3小节“扩展的业务需求”中“使用信息智能服务”需求。在这个需求上大家又展开联想，假设企业在全国各地都有办事处。可以在总部架设一个信息智能服务社区，各个办事处可以通过Internet访问该服务社区，并使用服务社区提供的信息处理服务，取得更好的工作效果。
5   会议结论
接下来，SeraphZhang负责业务流程图的绘制和细化工作，并确认企业价值路径；我负责ESB的具体技术调研工作。
通过本次会议的讨论，对企业的业务流程有了初步的认识，在此基础上可以进一步的分析和细化。对ESB有了较为深刻的理解，认识了ESB在SOA中的作用。

发表于09:34:04 | 阅读全文 | 评论 0 | 编辑 | 分享 0
面向服务的分析与设计原理

2006-05-21

Tag：他山之石

最初的面向服务体系结构（Service-Oriented Architecture，SOA）的实现项目的经验表明，诸如面向对象分析与设计（Object-Oriented Analysis and Design，OOAD）、企业体系结构（Enterprise Architecture，EA）框架和业务流程建模（Business Process Modeling，BPM）这样的现有开发流程和表示法仅仅涵盖了支持目前出现在SOA中的体系结构模式所需的部分要求。
在Info World最近的访谈中，Grady Booch宣称“像对问题的良好抽象和良好的分离这样的工程基础决不会过时”，不过，他也指出：还是有现实的机会提升抽象的级别。过去的经验表明，必须将抽象的级别提升到公司处理的业务领域，从而将整个企业IT前景都纳入考虑的范畴。
正如Mark Colan在文章《面向服务体系结构扩展Web服务的前景》中介绍的，SOA是一种新兴的企业结构形式，可以用于设计下一代企业应用程序。SOA方法在有力地加强已经制定的良好通用软件体系结构原则（如信息隐藏、模块化和问题分离）的同时，还增添了一些其他的主题，例如服务编排、服务库和服务总线中间件模式。
需要结构化方法或分析与设计方法来设计高质量的SOA。因为现有的方法中没有一种能够满足程序设计人员对最新的SOA项目的要求，所以他们建议将已经形成的良好实践（如OOAD、EA和BPM）中的原理组合起来，并且使用根据需要创新的原理来对其加以补充。
引言
面向服务体系结构（SOA）和Web服务的基本观念将成为我们日常语言的一部分，并可看作是适于设计现代企业应用程序的体系结构形式。在这种背景下，什么构成好的服务这个基本问题就成为确保成功实现SOA的关键。
像面向对象的分析与设计（Object-Oriented Analysis and Design，OOAD）、企业体系结构（Enterprise Architecture，EA）框架和业务流程建模（Business Process Modeling，BPM）这样的现有建模规则为我们提供了高质量的实践，可以长期帮助标识和定义体系结构内的适当抽象。然而经验表明，这些实践各自单独应用时达不到要求。
在本文中，我们将研究OOAD、EA和BPM中的适当原理。我们还将推动对混合方法的需求，这种方法把所有这些规则中的原理与许多独特的新原理组合起来。这样得到的交叉学科OOAD方法使成功地进行SOA开发更容易，我们称之为面向服务的分析与设计（Service-Oriented Analysis and Design，SOAD），它还有待正式定义。我们还只是刚刚跨入SOAD的殿堂。
面向服务的概念
在发现新的商机或威胁的预期下，SOA体系结构形式旨在提供企业业务解决方案，这些业务解决方案可以按需扩展或改变。SOA解决方案由可重用的服务组成，带有定义良好且符合标准的已发布接口。SOA提供了一种机制，通过这种机制，可以集成现有的遗留应用程序，而不管它们的平台或语言。
从概念上讲，SOA中有三个主要的抽象级别：
●操作：代表单个逻辑工作单元（LUW）的事务。执行操作通常会导致读、写或修改一个或多个持久性数据。SOA操作可以直接与面向对象（OO）的方法相比。它们都有特定的结构化接口，并且返回结构化的响应。完全同方法一样，特定操作的执行可能涉及调用附加的操作。
●服务：代表操作的逻辑分组。例如，如果我们将CustomerProfiling视为服务，则按照电话号码查找客户、按照名称和邮政编码列出顾客和保存新客户的数据就代表相关的操作。
●业务流程：为实现特定业务目标而执行的一组长期运行的动作或活动。业务流程通常包括多个业务调用。业务流程的例子有：接纳新员工、出售产品或服务和完成订单。
在SOA术语中，业务流程包括依据一组业务规则按照有序序列执行的一系列操作。操作的排序、选择和执行称为服务或流程编排。典型的情况是调用已编排服务来响应业务事件。
从建模的观点来看，由此带来的挑战是如何描述设计良好的操作、服务和流程抽象的特征以及如何系统地构造它们。这些相关问题都是当前行业内和学术界最常讨论的问题。据我们所知，最近几乎所有的SOA项目或专题研讨会都将这样的服务建模方面作为重要的主题，并引起了许多的争论。因此，让我们更近地作一番审视。
为什么BPM、EA和OOAD还不够？
早期的SOA实现项目经验表明，诸如OOAD、EA和BPM这样的现有开发流程和表示法仅仅涵盖支持SOA范式所需的部分要求。SOA方法在加强已经制定的良好通用软件体系结构原则（如信息隐藏、模块化和问题分离）的同时，还增添了附加的主题，例如，服务编排、服务库和服务总线中间件模式，在建模时需要对它们给予特别的关注。
图1 展示了现有的EA、BPM和OOAD建模方法的主要应用领域，也是我们随后讨论SOAD的出发点。图中的水平轴表示项目生命周期阶段；垂直轴表示不同抽象层或领域之间的区别，而建模活动通常就是在其上进行的。

SOA的远景是相当容易理解的，因为它的技术基础众所周知。例如，在任何SOA工作中，应用通用的软件体系结构原则和OO技术都是一个有效的开端。然而，正如我们已经提到的，早期采用者最常询问的问题是如何标识正确的服务。如前所述，OOAD、EA和BPM在各自独立地应用时不能提供满意的答案，而这正是我们现在要说明的。
在由 Booch和Jacobson 撰写的开创性的书（Object-Oriented Software Engineering: A Use Case Driven Approach，大约10年前出版的）中介绍的OOAD方法在定义SOA方面提供了非常好的起点。同样地，虽然许多年来在体系结构层次中应用OOAD技术和统一建模语言（Unified Modeling Language，UML）表示法是一个常见的实践，但是OOAD还是与像类和单独的对象实例这样的微观层次的抽象有关。由于每个问题域常常都创建单独的用况模型，因此，应用程序开发项目，这个企业的大方向在许多情况下变得模糊。此外，由于种种原因，用况模型并不总是与其对等的BPM保持同步。
诸如Treasury企业体系结构框架（Treasury Enterprise Architecture Framework，TEAF，http://www.software.org/pub/architecture/teaf.asp）、面向特征的领域分析（Feature-Oriented Domain Analysis，FODA，http://www.sei.cmu.edu/domain-engineering/FODA.html）和Zachman（http://www.zifa.com/）这样的EA方法都将城市规划级的观点加在解决方案体系结构之上，但是并没有解决如何找到易于重用且具有持久性的高质量企业抽象的问题。
虽然BPM方法（如BPMI，http://www.bpmi.org/）在功能工作单元之上提供了端到端视图，但是它们通常都没有触及体系结构和实现领域。例如，在像用于Web服务的业务流程执行语言（Business Process Execution Language for Web Services，BPEL，http://www.research.ibm.com/journal/sj/412/leymann.html）这样的语言出现之前，BPM表示法缺少操作语义。此外，我们还看到了许多流程建模与开发活动彼此分离的情况。
最后，现有的规则中没有一个可以解决如何为SOA启用现有的应用程序的问题；大部分时间都采用自顶向下流程。现有的系统通常都存放有大量的重要数据和业务逻辑，并且不能简单地加以替代。因此，为了研究包装和重构策略，必须对这些系统进行自底向上的分析。因此，对现有应用程序的考虑会将我们带到中间相遇的流程。
由于这些原因的存在，所以需要混合SOAD建模方法。这种方法以最佳的方式组合了OOAD、BPM和EA中的原理，并且融入了一些具有创新性的原理。图2 展示了这种新的方法的SOAD资源（原理和技术）：
EA
将企业应用程序和IT基础设施发展成SOA可能是一个大的负担，会影响多个业务线和组织单元。因此，需要应用EA框架和参考体系结构（如开放组织体系结构框架，The Open Group Architecture Framework，TOGAF，http://www.opengroup.org/architecture/togaf）以及Zachman，以努力实现单独的解决方案之间体系结构的一致性。
根据过去的经验，大多数现有的EA框架都在一个或多个方面有限制。例如，如果主要的问题是表示技术设备的低级构块如何在宏观层次互连，则无法获得业务层流程或服务视图。然而，在SOA的背景下，这种考虑问题的方式必须转换为以表示业务服务的逻辑构件为中心，并且集中于定义服务之间的接口和服务级协定（Service Level Agreements，SLA）。
此外，许多企业级参考体系结构和框架是相当普通的，并没有触及设计领域。这样的高级体系结构无法为架构师和开发人员提供具体的战术意见，并且常常导致企业体系结构和解决方案体系结构之间出现根本性的分歧。
SOAD必须帮助SOA架构师定义服务前景的整体业务级视图。这是当今的EA框架所无法提供的，它们需要未来特定于SOA的增强；按需操作系统（On Demand Operating Environment，ODOE，http://www-1.ibm.com/partnerworld/pwhome.nsf/weblook/ebod_environment.html）是IBM针对这种趋势制定的主要战略。
BPM
BPM是一个不完整的规则，其中有许多不同的形式、表示法和资源。另一种常用的技术是定义表示概念性流程流的事件驱动流程链，这第二种技术使用了不同于UML的表示法。
此外，还有许多专用方法（如BPM技术）可能被咨询公司和企业资源规划（Enterprise Resource Planning，ERP）软件包厂商视为具有竞争优势。ARIS Implementation Platform就是这样的产品的一个例子。其他的方法包括：Line of Visibility Enterprise Modeling （LOVEM）和IBM的组件业务建模（Component Business Modeling，CBM）战略。
最近的趋势是定义表示可执行流模型，如用于Web服务的业务流程执行语言（Business Process Execution Language for Web Services，BPEL）的标准方法。BPEL将流程的范围从分析扩展到实现。这样的可执行模型引发了一系列的新问题，其中包括：
●哪些方面应该用BPEL描述，哪些方面应该用WSDL描述？流程模型和传统的编程模型之间的区别在什么地方？
●如何将非功能性要求和服务质量特征这样的方面加入模型之中？
●同更传统的编码（例如在J2EE中）相比，在BPEL引擎的编程语言扩展中执行多少逻辑？
●如何评定可执行流程模型的质量，其应用的最佳实践是什么？
●什么工作角色进行BPEL流管理；是业务专家（分析人员），还是开发角色（软件架构师）？
必须利用所有现有的BPM方法作为SOAD的起点；然而，必须使用流程模型中用于驱动候选服务和它们的操作的附加技术来对其加以补充。此外，SOAD中的流程建模必须与设计层用况建模保持同步，并且必须给出与BPEL有关的问题的答案。
OO范式与面向服务（SO）范式
OO分析是一种非常强大且广为赞誉的方法，同样，SOAD应该尽可能多地利用OO分析技术。要将OO分析成功地应用于SOA项目，您就必须一次分析多个系统。用况模型必须继续扮演重要的角色。然而，SOAD必须主要是流程，而不是用户驱动的。因此，SOAD需要BPM和用况建模活动之间的强链接。
在设计层，OO的目标是能够进行快速而有效的设计、开发以及执行灵活且可扩展的应用程序。对象是软件构造，其行为就像它们建模的真实世界的实体。例如，顾客（Customer）将有名称和联系信息，并且还可能有一个或多个与之相关的帐户对象。从OO的角度看，每件事情都是对象。

OO的基本原则是：
●封装：软件对象就是包含模拟真实世界的对象的物理属性（数据）和功能（行为）的离散包。例如，帐户对象保持收支平衡并且包含平衡中的借贷机制。
●信息隐藏：结构良好的对象有简单的接口，并且不向外界显漏任何内部机制。真实世界信息隐藏的例子是，您不需要详细了解汽车的工作原理就能够驾驶它。
●类和实例：类是定义特定类型的软件对象具有什么类型的属性和行为的模板，而实例是具有这些属性值的个别对象。创建类的新实例称为实例化。利用生物学进行类比，人就是一个类。所有的人都具有一些属性，比如身高、体重、头发和眼睛颜色等等。我们中的每个人都是这个类HumanBeing的实例，具有一些特定的身高、体重以及其他的属性值。类是一直存在的，而实例具有有限的生命周期。
●关联和继承：在OO中，表达类和对象之间的关联的能力是一个关键的概念；继承是关联的强形式，用于表达有关系：按照同样的方式，生物物种由这样的层次构成：界（Kingdom）、门（Phylum）、纲（Class）、目（Order）、科（Family）、类（Genus）、种（Species）。我们常常发现软件对象的自然层次。例如，当您创建一个财务应用程序实体时，您可能需要构造像经常帐户（Checking Account）、储蓄帐户（Savings Account）和贷款帐户（Loan Account）这样的对象。如果您看得更仔细一点（请参见图3），您将发现这些类共享许多属性，比如都有收支平衡帐户、借方帐户和贷方帐户等等。

与其重复定义和管理这些属性的代码，不如创建一个通用的帐户（Account）类，该类具有现金收支平衡并且可以处理借贷事务。所有其他的类都是这个帐户（Account）类对象的专门形式。例如，贷款帐户（LoanAccount）将在零和某个约定的最大值之间具有负平衡，而储蓄帐户（SavingsAccount）将具有负平衡，并且将展示增加利息的行为，等等。
●消息传递：为了完成一些有用的工作，软件对象需要相互通信。它们通过相互发送消息来这样做。例如，假定我们想将$1000从经常帐户转到储蓄帐户，要达到此目的，可以将带有参数$1000的借消息发送到经常帐户（CheckingAccount）实例，并且将相应的贷消息发送到储蓄帐户（SavingsAccount）实例。当实例接收消息时，它执行相应的功能，称为方法，它有与消息相同的名称。
●多态：这个术语描述两个或两个以上的类接受相同的消息但是以不同的方式进行实现的情况。例如，自由经常帐户（FreeCheckingAccount）实例和经常帐户（CheckingAccount）实例将响应借（$100）消息，但是自由经常帐户（FreeCheckingAccount）实例将正好$1000记入它的帐户平衡的借方，而经常帐户（CheckingAccount）实例将$1000加上交易费记入它的帐户平衡的借方。
OO支持应用程序分析、设计和开发的完整生命周期：
●OOAD试图找到最优的对象和最自然的类继承来实现它们。
●OO开发集中于应用程序的渐进式开发，每次实现一个业务场景或用况。像IBM WebSphere Studio Application Developer这样的工具有助于开发人员快速地构造和测试OO应用程序。
●OO运行时环境，例如由Java虚拟机提供的，提供应用程序服务（如垃圾收集（删除因使用它们的对象已经被丢弃而不再使用的资源））以及框架（如J2EE）来为驻留在不同的服务器上的对象提供相互通信的机制。
目前与SO有关的OO设计实践的主要问题在于，它的粒度级别集中在类级，对于业务服务建模来说，这样的抽象级别太低了。诸如继承这样的强关联产生了相关方之间一定程度的紧耦合（因而具有依赖性）。与此相反，SO范式试图通过松耦合来促进灵活性和敏捷性。目前，在SOA中还没有服务实例的跨平台继承支持和一流的表示法来避免需要处理服务生命周期维护管理问题（如远程垃圾收集）。
这些考虑事项使OO难以与SO体系结构样式直接保持一致。然而，对于设计已定义的服务中的底层类和组件结构，OO仍然是一种有价值的方法。此外，许多OOAD技术（例如类、责任、协作（CRC）卡）也可以用于服务建模（如果它们提升到更高层次的抽象的话）。在本文后面，我们将回过头来讨论这一点。
图4 展示了可见性层次和OO、面向组件和SO设计提供的重点之间的对应关系。它还展示了在SOA和SOAD背景中它们之间的相互关系。

至于表示法，统一建模语言（Unified Modeling Language，UML）—通过一些附加的定型（Stereotype）和概要加以增强—自然成为SOAD的重要基础。
在使用 Rational Unified Process （RUP，

这些服务可能包括许多协作或编排服务。这并没有排除RUP采用的OO观点，而是在其上实现了另一个抽象层。这个超层的作用是封装作为正式的跨层接口结构中的RUP构件（软件服务）设计的组件。
SOAD原理
在这一部分中，我们将更详细地描述SOAD的需求，并且开始确定它的主题和原理。目的是将关于这个主题的讨论引到进一步的设计工作。进一步的工作无疑需要形式化SOAD方法。
SOAD必须提供什么？
已经为SOAD确定了下列需求：
●正如任何其他的项目和方法一样，必须正式（至少半正式）地定义流程和表示法。通过选择和组合OOAD、BPM和EA原理，就可以在需要时确定额外的原理。
●必须有结构化的方法来概念化服务：
         ☆OOAD为我们提供了应用程序层上的类和对象，而BPM具有事件驱动的流程模型。SOAD需要将它们结合在一起。
         ☆方法不再是面向用况的，而是由业务事件和流程驱动的。用况建模是在更低的层次上作为第二步进行的。
☆方法包括语法、语义和策略。这就需要特别的组合、语义代理和运行时发现。
●SOAD必须提供定义良好的品质因素和最佳实践（例如回答粒度问题）。必须回答BPEL提出的角色问题。例如，谁为哪部分工作负责：是开发人员、架构师，还是分析人员？
●SOAD活动还必须回答这样的问题：什么不是好的服务？例如：不可重用的任何东西都不可能成为好的一流SOA成员（即服务）。另一个例子就是带有挑战性的非功能要求的嵌入式实时系统，它们不能承受任何XML处理开销。
●SOAD必须易于进行端到端建模，并且有全面的工具支持。假如SOA给业务带来了灵活性和敏捷性，就应该对从企业到体系结构和应用程序设计领域产生的支持方法有相同的期望。
品质因素
一些通用原则或品质因素已经确定，并且可以作为SOAD中的设计基准：
●构思良好的服务给业务带来了灵活性和敏捷性；它们通过松散耦合、封装和信息隐藏使重构更加容易。
●设计良好的服务是有意义的，并且不只适用于企业应用程序；服务之间的依赖性减到最少，并且是显式声明的。
●服务抽象是内聚、完整和一致的；例如，在设计服务和它们的操作签名时应该考虑创建（Create）、读取（Read）、更新（Update）、删除（Delete）和搜索（Search）（CRUDS）隐喻。
●常常声明的假定是，服务是无状态的（例如非对话式的）；为了要求服务在特定的问题域和上下文中是无状态的，将削弱这种声明。
●领域专家无需深奥的专业知识就可以理解服务命名。
●在SOA中，所有的服务都遵循相同的设计体系（通过模式和模板连接的）和交互模式；底层体系结构形式可以容易地标识（例如在体系结构复审期间）。
●服务和服务使用者的开发除了领域知识之外只需要基本的编程语言技能；中间件专业知识只有少数的专业人员才需要，在理想的情况下，这种知识是为工具和运行时厂商所用，而不是为制作像SOA这样的企业应用程序的公司所用。
服务标识和定义
自顶向下的业务级建模技术（如CBM）可以为SOA建模活动提供起点。但是正如我们在前面提到的，SOA实现很少是在全新的项目中开始的；创建SOA解决方案几乎总需要涉及集成现有的遗留系统，方法是将它们分解成服务、操作、业务流程和业务规则（同时参见图6）：
●将现有的应用程序和厂商软件包分解成表示相关操作组的离散服务集（自底向上方法）。
●从应用程序中将业务流程和规则抽象为由业务编排模型管理的单独BPM。

所有的OOAD都同标识和定义服务有关；但是还需要具有更高层的观点。此外，当SOA致力于比经典开发项目层次更高的开发时，就有了发挥其他创造性思维的空间。
直接和间接业务分析
通过项目相关人员的会谈和CBM来进行BPM和直接需求分析是一个容易理解且非常合适的标识候选服务的方法。
过去的经验表明，这条主要的途径应该通过补充间接技术来加以改进。在选择候选服务时，产品经理和其他业务领导应该进行协商。例如，什么是计划付款和开票模型？应该商议假定使用正在构建中的系统的企业的组织结构图。建议还考虑一下非SOA项目中任何现有的用况模型。用于对正在构造的系统进行营销介绍的术语是另一个很好的关于服务操作候选者的来源（特别是动词，很少关注营销动词！）。
域分解
在Endrei（http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/sg246303.html?Open）中定义的域分解、子系统分析、目标模型创建和相关技术是SOA流程构造方法或服务概念化框架（它是基于Levi and Arsanjani先前完成的工作构建的）最有希望的提议。来自SEI的FODA（http://www.sei.cmu.edu/domain-engineering/FODA.html）工作也为这方面的讨论做出了贡献。
服务粒度
选择正确的抽象级别是服务建模的一个关键问题。您常常会听到进行粗粒度建模的建议。这有点过于简单化了。您应该将其改为在不损失或损害相关性、一致性和完整性的情况下尽可能地进行粗粒度建模。在任何SOA中，都有细粒度服务抽象的空间（假定有业务要求的话）。由于SOA并不等同于Web服务和SOAP，因此可以使用不同的协议绑定来访问抽象级别不同的服务。另一种选择就是将一些相关的服务捆绑成粗粒度的服务定义，这是门面模式的变种。
命名约定
应该定义企业命名模式（XML名称空间、Java包名、Internet域）。简单的例子就是始终用名词来命名服务，而用动词来命名操作。这种最佳实践来源于OOAD空间。
第一类SOAD原理
除了组合OOAD、BPM和EA技术之外，还有几个重要的SOAD概念和方面有待充实：
1、服务分类和聚合
2、策略和方面
3、中间相遇流程
4、语义代理
5、服务获取和知识代理
服务分类和聚合
服务有不同的用法和用途；例如，软件服务可以不同于业务服务（如前面的图5 所示）。此外，还可以将原子服务编排成级别更高、功能齐全的服务。
服务组合可以通过可执行模型（如BPEL建模的模型）来加以简化；这是传统的建模工具和方法不能处理的事情。
策略和方面
服务具有语法、语义和QoS特征，所有这些都必须进行建模；正式的接口契约必须涵盖的比Web服务描述语言（Web Services Description Language，WSDL）的多。因此，Web服务策略框架（WS-Policy，http://www.ibm.com/developerWorks/cn/webservices/ws-polfram/）是一个重要的相关规范。
除了已经制定的良好体系结构可跟踪性原则之外，业务可跟踪性也是一个理想的品质：应该有可能将所有的运行时构件直接与非技术领域专家可以理解的语言联系起来。这对于直接在业务和服务层公开的抽象非常重要。Sarbanes-Oxley （SOX）法案（请参阅来自Astor的文章，http://sys-con.com/author/?id=526）是需要这种业务可跟踪性的业务驱动程序的一个例子。
流程：中间相遇
在真实世界中，并没有全新的项目，必须始终考虑遗留系统（遗留系统是现有系统的同义词）。因此，需要中间相遇的方法，而不是单纯的自顶向下或自底向上的流程。
在设计取决于现有的IT环境而不是现在和将来的业务需要的情况下，自底向上的方法往往会导致不好的业务服务抽象。而自顶向下的方法可能会产生不足的非功能性需求特征，并且损害其他的体系结构品质因素（例如因域模型中缺乏标准化而导致的性能问题），另外，也会在服务和组件中产生不匹配的不良问题。
服务获取和知识代理
这是一个知识管理和生命周期问题：如何成功地准备好服务并且使其在概念化之后可以重用？
应该将重用看作是标识和定义服务最主要的推动标准之一。如果组件（或服务）不可能重用，就不无法将其作为服务进行部署。它可以连接到另一个与企业体系结构相关的服务，但是不能单独作为一个服务而存在。
然而，即使从开始就计划好了重用，还必须形式化服务获取流程。由多个使用者使用服务是明确的SOA设计目标。构建时服务注册中心（例如企业UDDI目录）可能能够解决部分问题。
示例：汽车工作订单
汽车工作订单（Automotive Work Order）描述了一家汽车维修公司管理其顾客运营的流程。我们将通过这个领域中的问题来阐述SOAD的观点。
工作订单代表汽车服务公司和顾客之间的约定，以进行一系列例行维修或应急维修，例如例行50,000英里服务，更换刹车片或轮胎，或者换油。
业务场景（如图7所示）如下：
●当顾客打电话预约时创建工作订单。
●为每个计划的维修活动或操作创建一个独立的工作订单项，其中包括需要使用的零件、备件和劳务的详细情况。
●在安排预约之前确保所有必需的零件都有库存。
●需要为每个工作订单项安排具有适当的装备的维修间以及具备适当的条件的机器。
●计算估计的总成本，接着顾客认可该预约；或者方案终止，随即取消工作订单。
●在预约之前，立即在选定的维修间装配必需的零件、备件、工具和设备。
●当顾客到达时，进行计划的活动以及在检查交通工具时显得有必要的任何其他活动。
●记录所用的零件和备件的实际价值以及劳务。
●在完成所有的维修时计算总费用。
●创建发票并且将其交给顾客。

如果您将此作为一个独立的应用程序从头开始创建，您就可能创建一组如图8所示的类。
如果您将工作订单构造为一个OO应用程序，这些软件对象将包含所有必需的业务规则，并且理解应该遵循的业务流程。
然而，这种方法在实践方面存在着一些缺点：
●许多步骤涉及与现有遗留系统和数据库（例如帐单编制、日程安排以及库存系统）的连接，它们不可能遵循OO范式进行设计（在这样的情况下，应用适配器或仲裁器会有所帮助）。
●为了使系统尽可能地灵活，将一些规则外化是有帮助的，这样就可以在不更改代码的情况下修改流程或工作流。例如像下面这样的规则：
         ○标准的24,000英里服务包括四公升油。只是在使用四升以上的油或顾客要求优质油（如合成油）时才应该收取额外的邮费。
         ○在遗留应用程序中有一套工业标准为普通汽车维修活动进行劳务估价。除非维修人员收取的费用超过该估价的X%并且报告产生差别的有根据的原因，否则顾客就应该支付标准的劳务费。
         ○如果超过估价的Y%以上，就应该联系顾客以进行确认。
SOAD为这些问题提供了极好的解决方案。由于它基于相关的行为对服务进行分组，而不是进行封装（行为及数据），所以这组服务与业务对象略有不同。
例如，您可能将工作订单（Work Order）和工作订单项（Work Order Item）一起分到工作订单服务（Work Order Services），并且创建日程安排（Scheduling）、目录（Catalog）和库存（Inventory）服务。另外，因为没有服务实例，所以没有与服务之间的关系等价的东西。工作订单的服务模型可能看起来如图9所示。

与OO范式不同，这个模型并不表示功能系统。既没有考虑流，也没有描述业务事件或规则。在SOA范式中，在服务外面维护的业务流程编排决定了执行服务调用的顺序和时间。
从概念上讲，从第一次顾客联系到完成工作和帐单支付的整个业务表示单个宏观层次的工作单元，并具有数天到数周不等的生命周期。毕竟，从企业的角度来看，工作单元会产生收入。
然而，实际出现的情况是在一段相对长的时间内单独发生的一系列集中活动，例如，定义活动、安排预约、选择零件和备件、进行维修活动等等。在IT系统中，没有实际的流程会持续几分钟以上；事件之间的业务流程状态以数据的形式保存在数据库中。
这种类型的流程可以用状态转换模型（例如UML中可用的）很好地进行表示。图10 显示了用有限状态机（Finite-State Machine）方法如何对业务流进行建模的示例。它是在业务流程进行时工作订单的状态如何改变的高级视图。

业务流程编排集中于状态之间的这些转变。单独的操作永久地记录相关的状态改变。
图11显示了部分编排的示例，其中包括图10 所示的业务场景中的步骤1到5（例如，顾客定义他们的交通工作所需的工作，并且安排预约以进行实施）。
总结和展望
在本文中，我们已经讨论和激发了对创新的中间相遇的方法的需求，这种方法搭建了业务和IT之间的桥梁，并且支持SOA项目的分析和设计阶段。我们还提议将这种新的交叉学科的SOAD方法作为一个整体的建模规则，它以现在构建良好且广为赞誉的OOAD、EA、和BPM为基础。
在详细定义SOAD表示法和流程的同时，还确定了关键的原理，比如服务概念化（或标识）、服务分类或聚合、策略和方面、中间相遇流程、语义代理和服务获取（以供重用）。
SOAD需要增强现有的软件开发方法，进一步提高企业应用程序开发项目的可用性和适用性。随着时间的推移，还将发展相关的最佳实践。
我们还认识到，UML在流程的表示法选择方面将继续占支配地位；可能需要进行增强以满足更广泛的SOAD的要求。
完成SOAD方法的下一步就是定义所需的端到端流程和表示法，复审活动中的角色和它们的责任，并且继续检查所提议的方法在项目中的有效性。
http://www-306.ibm.com/software/awdtools/rup/）—被认为是支持迭代软件开发的分析与设计的主流OOAD流程之一—的流程方面，使用UML模型具有首要价值。然而，RUP以OOAD的原则为基础，因而使其不容易与SOA设计保持一致。从RUP的角度来看，系统的体系结构是其通过已定义接口交互的主要组件的体系结构。此外，这些组件还由逐渐减小到类级粒度的更小组件组成。相反，在SOA中，系统的体系结构通常包括满足普通业务服务需要的无状态、全封装且自描述的服务组成，它更接近于映射到BPM，如图5所示。

SeraphZhang 发表于02:39:03 | 阅读全文 | 评论 0 | 编辑 | 分享 0
企业服务总线（ESB）技术与革新

2006-05-21

Tag：他山之石

企业服务总线（ESB）技术与革新
（用异步消息传递和智能路由选择扩展Web服务）
由于更大任务所带来的要求，消息传递技术现在正处于发展之中。为了给当今的实时企业提供其所需的灵活性，需要一种混合的消息传递模型将Web服务的优点与传统的异步消息传送结合在一起。
传统消息排队中间件将很快被企业服务总线（ESB）技术所取代，从而将消息传递带到新的高度。新的ESB骨干（催生了下一代集成和应用平台产品）将显著改善多数企业的软件基础架构。行业正转向消息传递和ESB，并以此作为核心应用平台基础架构模型，这将标志着一个转折点：围绕企业对其信息资源的使用而触发了新一轮巨大的革新浪潮；企业都正在利用事件架构。这都将消除最近人们对IT在战略性业务区分中可扮演关键角色的所有疑虑。
简介
在过去的10年中，竞争压力和日新月异的技术根本地改变了企业的运行节奏。在过去，企业可以根据月底的成批报告来进行决策。现在，实时流程意味着如果原材料在早上出现问题，或者有停电事故发生，那么就会造成下午无法交付和托运成品。于是，企业不得不以越来越快的速度应对突发事件；否则，它就要靠边站了。“零时延企业（zero latency enterprise）”的时代已经来临。
当今的企业环境正在一点一点地发展以应对这个挑战。异构存储、网络和硬件支持着“孤岛计算”（应用程序与数据相互孤立或者条块分割），这导致环境的利用和管理都过度复杂，并使之变为资源密集型。对于企业所必须面对的大多数关键挑战而言，这种复杂性无疑是一种障碍，这些挑战包括：
1、满足对利用多渠道传递大量信息服务的不断增长的需求。
2、实时管理基础架构以满足不断变化的业务需求。
3、使业务多样化以促进业务灵活地增长，并降低与固定产品线相关的经济风险。
4、确保对客户、合作伙伴和雇员的信息服务请求做出快速且高质量的响应。
在过去几年中，EAI、B2B和应用开发等方面的迅速发展推动了几种关键技术和标准的发展，这些技术和标准又推动了基础架构领域的显著进步：
1、XML作为通用的、自解释的数据交换格式，已经为大多数应用程序所采用。面向Web的信息交换以及其后的基础架构，与XML一起使 Web服务的使用成为不可避免的事情。
2、Java已经作为用于服务器端的一个主要技术而被接受，并且J2EE已经作为应用服务器的标准而被接受。
3、企业服务总线在事务性消息交换和实时事件通知领域的使用已经围绕Java消息服务（JMS）而被标准化了。
4、通过Java管理扩展（JMX）标准已经实现了服务器端组件的公共管理框架。
基础架构必须像业务一样运转
瞬息万变的市场需要通过多渠道传递大量的信息服务。下一代的企业要求松散耦合的资源能够共享跨越多领域的公共通信和管理基础架构。企业基础架构不得不象有形的业务那样运转，允许对资源进行动态管理以应对客户和合作伙伴的需求波动，同时处理系统资源的供应和可用性变化。企业应用程序也需要一个基于标准的协作模型以最大程度地利用该基础架构。为此，实时企业使用了来自实时基础架构的最好做法和服务器端的网格技术（grid technology）。
实时企业的组件
形成实时企业的一些概念与用于定义服务器端网格环境的概念相同，用来描述其核心组件（见表1）的结构类似于Gartner的5层网格技术模型。
一个建立在现有的而且是被广泛采用的技术和开放标准之上的ESB可为服务协作、管理和控制提供一个可适应的分布式架构。ESB支持在企业内部的任何地方进行业务服务的运行时部署，并提供协作和通知服务作为其核心基础架构的一部分。让我们看一下ESB技术是如何映射到 Gartner的5层模型的。
表1 实时企业模型
基础架构资源和虚拟操作系统
第0层由基础架构资源组成，包括网络、服务器、存储和每台服务器的操作系统环境。第1 层位于基础设施层之上，并建立了一个多资源的分布式操作系统，它支持的功能如进行工作计划、将资源名集成到总体结构中以及确保不同系统间的一致认证。
尽管Gartner将J2EE作为一个第2层的技术，我们相信分布式JMX和一台基于J2EE的应用服务器的结合会具有虚拟操作系统的特点。使用对所有组件和服务提供部署和完全JMX管理的容器或者微内核，从而允许对服务进行远程激活和管理。
JMX作为一种技术，最初被设计成用于管理单个代理，如一台应用服务器。JMX通过与JMS的结合，其范围就可以扩展到管理单个代理、群集或松藕合的联合体（如果您喜欢，亦可称之为超级群集），允许对联合的ESB基础架构进行全生命周期和部署管理。由于JMX同时也集成了许多传统的管理协议，如SNMP，因此ESB基础架构可以为 Java、Web服务和传统平台提供随需应变的（on-demand）的热部署和自我修复（self-annealing）式的基础架构。
分布式编程模型
分布式编程模型构成了实时企业的第1层：可在应用程序和服务（无论是内部还是外部）之间进行协作和通知的核心基础架构。ESB提供事件通知、动态路由选择和事务性确保传递；并且使用一个定义明确的过程语言以使应用程序通过一个公共API 进行活动协调。
实时企业要求在恰当的时间将正确的数据传递到正确的位置；JMS（Java消息服务）提供事件分布和事务性确保传递的方法。同时也需要智能数据结构（data fabric），它可以在需要的时候在网络范围内进行信息分发，目的是提高吞吐量和降低宝贵的后台系统的负载。该结构的骨干是通过 JCache（Java 通用缓冲框架）所形成的。
一个类似于 Linda的元组空间（tuple space）将消息队列的“一个且只有一个”传递语义与发布/订阅的广播功能和对等系统的松藕合结合到一起。元组空间就如同由无限数目的进程所共享的相连内存。进程可以向该空间中添加元组（本质上就是数据对象），或者从中取出元组来以独占的方式工作——如果需要的话，可以一直处于等待状态，直到匹配对象的出现。进程也可以读取元组而不需要将其从空间中删除。该范例（将消息队列的“一个且只有一个”传递语义与发布/订阅的广播功能和对等系统的松藕合结合到一起）被映射到Jcache的顶部，它提供一个该概念的高性能分布式实现。

应用程序
构成实时企业第3层的应用程序依赖于企业基础架构的资源，以及使用协作编程模型进行相互通信。架构师们已经意识到更松散藕合和多层组件模型的优越性，而不是开发独立或简单的两层客户/服务器（C/S）应用程序。为定义、发现和实际执行该模型（例如WSDL、UDDI以及用于Web服务的SOAP）而采用的标准有助于面向服务架构的实现。
作为虚拟操作系统基础的J2EE应用服务器为基础架构提供了一个基于事务性的安全服务的集成点。由于分布式ESB是一个像网格一样的使能技术，所以基于OGSI源代码组织定义的Web 服务接口是一个很自然的选择。OGSI当前是外化网格技术的事实标准，它允许在一个环境下所书写的网格服务可以很容易地部署在其他环境中。
此外，ESB可以提供一个基于优化Tete算法的可扩展规则引擎。外化业务规则使得在较低层对迅速变化的业务流程、决策机制进行管理以及使消息过滤和路由选择变得可能，而不需要对基础应用程序进行代码级的改变。它将业务从对缓慢的代码开发周期的依赖中解放出来，允许精通业务的分析师进行必要的变化以支持新产品或法规需求的引进，而无需中断系统的运行。
“在过去的10年中，竞争压力和日新月异的技术根本性地改变了企业运营节奏”
管理支持
实时企业要求服务在宏观和微观两个层面上管理和协调应用程序及其服务。第4层提供了实现安全策略、定义资源使用指南和集成操作流程所需的管理支持。基本功能包括：
监视：整理事件和统计数据以了解应用程序的性能、资源使用情况和操作行为。它允许对整个基础架构进行模拟、错误判定以及对资源利用进行手动和自动平衡。
反应协调：需要通过启发分析、动态规则和灵活的工作流对应用程序进行智能管理、控制、自我修复以及微调。通过使用有效的动态拓扑布局（在正确的位置运行正确数量的应用程序）、实时企业管理利用负载，并选择正确的硬件和位置来运行应用程序。
ESB管理结构将分布式JMX与统计事件收集和对比与用在应用级的基于相同标准的 Java 规范框架进行了结合。这为资源使用、性能监视和警告通知提供了位置透明性、发现、远程控制和统计数据的整理。这些技术允许对在整个实时企业中的智能性资源可视化、协同合作和供应环境进行预言性的决策，从而为IT经理和业务经理赋予了洞察力。

SeraphZhang 发表于02:31:15 | 阅读全文 | 评论 0 | 编辑 | 分享 0
迁移到面向服务的体系结构

2006-05-21

Tag：他山之石

本文旨在帮助您更好地理解面向服务的体系结构（SOA）的价值，制订出一个实际的计划来评估您现在的基础架构，并把它转变成一个真正的面向服务的体系结构。其目的在于，当您读完本文时，您将理解为什么声称SOA是把现有资产带到未来的最好的平台，同时也使得迅速而正确地开发未来的程序成为可能。另外，您将对在计划这样一次迁移的过程中主要考虑的事项有更好的理解。
开发面向服务的体系结构的情况
在过去的40年里，软件体系结构试图处理日益增长的软件复杂性。但是，复杂性仍在继续增加，传统的体系结构好像已经达到了它们处理此类问题的极限。同时，IT组织的传统需要仍然继续存在；比如，需要对新的业务需求进行快速的反应，需要不断地减少业务中IT的成本，以及吸收、集成新的业务伙伴和新的客户群。作为一个产业，我们经历了能够提供完全的分布式处理的多种计算体系结构和能够运行在任何平台上的编程语言，从而大大缩短了实现的时间表，我们还经历了无数的连接性产品，这些产品能够更快更好地集成应用程序。然而，我们还是没有找到完全的解决方案。现在，业界提出面向服务的体系结构（SOA）作为软件体系结构中下一个发展的阶段来帮助IT组织满足他们面临的越来越多的复杂性的挑战。可是，这种体系结构现实吗？即使它可以被概括和描述出来，它也能真的被实现吗？本文的论点就是断定SOA是现实的；在所有天花乱坠的宣传尘埃落定之后，所有夸大的期望又回到了现实之中，您将发现至少现在SOA是IT组织可以将其现有的资产带到未来，同时又构建新的应用程序系统最好的基础。本文旨在帮助您更好地理解面向服务的体系结构（SOA）的价值，并且制订出一个切实可行的计划来评估您现有的基础架构，然后将其迁移到一个真正的面向服务的体系结构。
曾几何时，现有的Web服务技术刺激了关于面向服务的体系结构（SOA）的讨论。这个讨论并不新鲜；从CORBA扩展到在完全不同的异类平台上应用程序一直到现在，这个概念已经发展10多年了。集成这样的应用程序的问题不断出现，通常是因为有那么多不同的（非CORBA兼容的）对象模型流行起来；因而，很多架构师和工程师都陷入了解决此类问题的泥淖中，开发一种更健壮的体系结构来实现简单、快速和安全的系统和应用程序集成的承诺并没有兑现。然而，问题却在继续增加，并且日益复杂。基本的业务需求，诸如降低成本、减少开发周期、跨企业集成、企业到企业（B2B）和企业到顾客（B2C）集成、更大的投资回报率（ROI）、创建自适应的和自响应的业务模型等等，使我们不停地寻找更好的解决方案；但是，我们越来越觉得“点解决方案（Point Solutions）”不能解决这样的基本问题。在很多情况下，问题在于缺乏一个一致的体系结构框架，在这种体系结构中，可以快速地开发、集成和重用应用程序。更重要的是，我们需要一个这样的体系结构框架，它能够装配组件和服务，以便快速甚至动态地交付应用程序。为什么像Web服务这样的某种技术是好的，但是我们真正需要的是一种不受技术约束的体系结构，有很多文章对此进行了讨论。让我们首先考虑一些基本的问题，这些问题是我们寻求更好的基础的依据，如何解决这些问题将决定我们工作的成败。
首要问题—复杂性
一些事情总是相同的，特别是IT组织所面对的业务问题。公司管理层总是努力争取更好地利用IT、获取更大的投资回报率（ROI）、集成历史上分离的系统和更快地实现新系统；但是时至今日，事情发生了些许变化。现在，您遇到的是更复杂的环境。必须重用而不是替换遗留系统，因为考虑到更有限的预算，替换的成本是高昂的。您将发现费用低廉、无处不在的Internet访问使得建立一个全新的业务模型成为可能。公司至少需要评估这个模型，因为竞争使然。合并和收购的增长已经成为家常便饭，因此必须将整个IT组织、应用程序和基础架构集成和融合在一起。在这样复杂的环境，点解决方案只会使问题进一步恶化，而决不会引导我们走出丛林。必须在一个以异构为基础的环境中开发系统，因为它们必须容纳种类繁多的硬件、操作系统、中间件、语言和数据存储。长达数十年的发展和演化积累起来的影响导致了严重的复杂性。面对所有这些对IT业务的挑战，很多CIO将应用程序集成作为首要任务也就不是令人惊讶的事情了，如下图所示。

另一问题—冗余和不可重用编程
考虑一个银行有一些分离的“地窖”—在银行内不为其他系统所知的自包含应用程序系统。这些应用程序系统中的第一个可能是优秀的设计，同样，第二个、第三个可能都是。但是每一个都是针对银行中不同业务的，是单独投资的孤立项目。因而，例如获取账户余额的功能在ATM系统、分行出纳员交付系统、信用卡计分系统都是重复的，即便它们存取相同数据库中的相同会计数据。现在，假设该银行必须为客户开发Internet服务、在线银行或在线贷款发放系统以保持竞争力，结果会怎么样。新系统只会给已经存在的冗余编程问题雪上加霜，除非通过某种方式使得现有的代码可以重用。
真正的集成难题—接口多样性
同样考虑n（n-1）集成问题。任何组织都会碰到某些类型的集成问题；或许是因为一次公司的合并、一个新的商业联盟或者仅仅是需要互连现有的系统。如果n个应用程序系统必须直接互连，那么将会产生n(n-1)个连接或接口。在下图中，每个箭头表示一个接口。

因此，如果另一个应用程序系统A（第n+1个）必须集成进来，将需要产生、文档化、测试和维护2n个新的接口。虽然在上图中，5个应用程序组成的集合需要20个直接接口，但是添加第6个应用程序将需要10个新接口！而更糟的是，必须修改每个已有的应用程序中的代码以包括进新的接口，因而将发生大量的测试费用。您可以立即为n个应用程序找到产生最小接口数目（n）的最优解决方案，只为每个附加的系统添加一个新的接口，但是，通过直接连接是做不到的。
将来会怎样呢？
在过去的40多年来，软件开发的实践经历了几个不同的编程模型。而进行的每一次转变在某种程度上都是为了处理更高级别的软件复杂性，并且使得可以通过部件、组件或服务来装配应用程序。近来，Java技术促成了平台中立的编程，而XML促成了自描述，因而也促成了平台中立的数据。现在，Web服务通过允许应用程序以对象模型中立的方式实现互连，从而克服了另一个障碍。使用简单的基于XML的消息传递Scheme，Java应用程序能够调用基于DCOM、遵循CORBA甚至是COBOL的应用程序。在新加坡的一台大型机上的CICS或IMS事务能够被一台在慕尼黑的Domino服务器上运行的Lotus脚本驱动的基于COM的应用程序调用。最好的情况是，调用程序很有可能根本不知道该事务在哪里运行、它是由哪种语言编写的以及消息的传输路径。只需提出服务请求，然后就会得到答案。
与其任何一个前身相比，Web服务更有可能成为提供有效的、可靠的和可扩展的机器到机器交互的标准，这是几个技术和文化上必须具备的先决条件适时结合的产物。这些先决条件包括：
l 无处不在的、开放标准的、低成本的网络基础架构和技术。它有助于一个分布式环境的形成，这个环境更有利于采用Web服务，而不是CORBA和DCE。
l 在一个以网络为中心的领域内达到的接受程度和技术成熟水平。它要求互操作性以实现关键的业务目标（比如，分布式协作）。
l 一致同意基于Internet的开放标准和相关技术是实现低成本互操作性的最好方法。
l 基于网络的技术（比如TCP/IP）、工具集（IDE、UML等等）、平台（比如J2EE平台）和相关的方法（比如OO、服务等等）的成熟水平。它们提供了简化松散耦合的、可互操作的、机器到机器的交互（一种比CORBA用户体验到的高级得多的状态）所需的基础架构。
面向服务的体系结构允许设计这样的软件系统，它通过发布的可发现的接口为其他的应用程序提供服务，而其中的服务可以通过网络进行调用。当您用Web服务技术来实现面向服务的体系结构时，您是在一个更强大、更灵活的编程模型中创建一种新的构建应用程序的方式，从而降低开发成本、持有成本以及实现风险。SOA既是体系结构模型，又是编程模型，是一种考虑构建软件的方式。
然而，还有更重要的机会刚刚出现。其中第一个就是网格计算，网格计算不仅是使用拥有大量MIPS的应用程序来进行计算的解决方案，而且还将提供一个框架，通过此框架可以动态地定位、重定位、平衡和管理大量的服务，这样，无论系统上的负载如何，总可以保证安全地获取所需的应用程序。而这又明显地需要按需计算的概念（On Demand Computing），按需计算可能是在任何配置下实现的，从简单的服务器集群到有1024个节点的SP2网络。用户需要解决问题和适当的用于解决问题的计算资源—不多也不少—并且为实际使用的资源付费。
这些新功能的有效使用将需要重新构造许多现有的应用程序。现有的单一应用程序能够在这些环境中运行，但没有以最优的方式来使用可用的资源。这个问题和先前讨论过的问题一起可以产生如下结论：必须作出根本的改变—迁移到面向服务的体系结构。
面向服务的体系结构的需求
根据上面讨论的问题，可以很明显地看出，应该开发一种体系结构来满足所有的需求，这些需求包括：
1. 首要的一点就是利用现有的资产。现有系统很难被抛弃，它们通常都包含对于企业很有价值的东西。从战略上讲，目标是构造一个新的体系结构来创造所有想要的价值，但是，从战术上讲，必须集成现有系统，以便随着时间的推移，可以在可管理、渐进式项目中分化或取代它们。
2. 支持所有必需的集成类型或“样式”。这包括：
l 用户交互—能够提供单一的、交互式的用户体验。
l 应用程序连接性—通信层构成了所有体系结构的基础。
l 流程集成—编排应用程序和服务。
l 信息集成—联合和移动企业数据。
l 依集成需求而构建—构建和部署新的应用程序和服务。
3. 允许渐进式实现和资产迁移—这将支持开发这种体系结构的一个最关键的方面：获得更大的投资回报率（ROI）的能力。数不清的集成项目由于它们的复杂性、成本和不切实际的实现进度安排而失败。
4. 包括一个以标准的组件框架为基础构建的开发环境，促进更好地重用模块和系统，允许将遗留资产转移到这个框架中，并且考虑到新技术的及时实现。
5. 允许实现新的计算模型，特别是新的基于Portal的客户端模型、网格计算和按需计算（On Demand Computing）。
面向服务的体系结构—不只是Web服务
Web服务的出现产生了根本的改变，因为很多Web服务项目的成功显示这种技术事实上确实存在，借此您可以实现真正的面向服务的体系结构。它使您又往回走了一步，不仅分析您的应用程序的体系结构，而且还要分析您正设法解决的基本业务问题。从业务的角度来看，它不再是一个技术问题，而是要开发一种应用程序体系结构和框架，可以在其中定义业务问题，还可以以一致的可重复的方式来实现解决方案。
不过，首先必须理解Web服务并不等同于面向服务的体系结构。Web服务是包括XML、SOAP、WSDL和UDDI在内的技术的集合，它使您能够针对特定的消息传递和应用程序集成问题构建编程解决方案。随着时间的推移，您有理由相信这些技术将逐渐成熟并最终为更好、更有效、更强大的技术所取代，但是，就目前的情况而言，它们可以发挥作用。至少，它们是SOA能够最终实现这种观念的证明。那么，面向服务的体系结构实际上是由什么组成的呢？
SOA只不过是一种体系结构。它不是任何诸如Web服务这样的特定技术的集合；而是超越它们的，在理想的情况下，是完全独立于它们的。在业务环境中，SOA的纯粹的体系结构定义可能会是这样的“一种应用程序体系结构，在这种体系结构中，所有功能都定义为独立的服务，这些服务带有定义明确的可调用接口，可以以定义好的顺序调用这些服务来形成业务流程”。请注意这里的表述：
1. 所有功能都定义为服务。这仅仅包括业务功能、由底层功能组成的业务事务和系统服务功能。这将会产生粒度问题，后面我们将对此进行讨论。
2. 所有的服务都是独立的。它们就像“黑匣子”一样运行：外部组件既不知道也不关心它们如何执行它们的功能，而仅仅关心它们是否返回期望的结果。
3. 在其最一般的意义上来说，接口是可调用的；也就是说，在体系结构的层面上，它们究竟是本地的（在本系统内）还是远程的（在直接系统外）、是用什么互连Scheme或协议来调用或需要什么样的基础架构组件来连接，都是无关紧要的。服务可能是在相同的应用程序中，也可能是在公司内部网内完全不同的系统上的不对称多处理器的不同地址空间中，还有可能是在用于B2B配置的合作伙伴的系统上的应用程序中。
在所有这些表述中，接口是最关键的，同时也是调用应用程序关注的焦点。它定义了必需的参数和结果的类型；因而，它定义了服务的类型，而不是实现服务的技术。系统的责任是实现和管理服务的调用，而不是调用应用程序。这使得可以认识到两个关键的特征：其一，服务是真正独立的；其二，它们是可以管理的。管理包括许多功能，其中有：
1. 安全性—请求的授权、加密和解密（在需要时）、确认等等。
2. 部署—出于性能、可用性冗余或其他方面的原因，允许服务在网络内重新部署（移动）。
3. 日志—用于审核、测量等等。
4. 动态重新路由—用于故障排除（Fail Over）或负载平衡。
5. 维护—管理服务的新版本。
服务的性质
什么是服务？如前所述，在一个典型的业务环境里，服务意味着业务函数、业务事务和系统服务。业务函数可能是getStockQuote、getCustomerAddress或者是checkCreditRating。业务事务可能是commitInventory、sellCoveredOption或scheduleDelivery。系统服务可能是logMessageIn、getTimeStamp或openFile。请注意各种类型服务之间的区别。从应用程序的角度来看，业务函数实际上是原子的非系统函数。业务事务很像是调用应用程序的简单函数，但是它们可能是作为自己的事务的上下文所包含的复合函数来实现的。它们可能包括多个底层函数，这些底层函数对调用者来说是透明的。系统函数是能够从诸如Windows或者Linux这样的特定平台中抽象出来的广义函数。应用程序框架可能提供像OpenFile这样的广义函数来有效地虚拟化数据源，从而可以在不考虑真实数据源的类型和位置的情况下使用这类函数。
这看起来像人为地规定服务之间的区别，您可以从应用程序的角度断言，所有的服务都是原子的，而与它是业务服务还是系统服务无关。做出这样的区别仅仅是为了引入粒度这个重要的概念。将业务程序分解成服务不仅仅是一个抽象的过程；它具有非常真实的现实含义。根据定义，服务可能是低级（细粒度的）函数，也可能是复杂的高级（粗粒度的）函数，并且在性能、灵活性、可维护性和可重用性方面都有很现实的折衷选择。定义服务的过程通常是在更大的作用域（应用程序框架的作用域）内完成的。这才是必须做的实际工作：也就是开发基于组件的应用程序框架，其中，服务定义为一组可重用的组件，而这些组件又可以用来构建新的应用程序或集成现有的软件资产。
现在，可以获得很多这样的框架。在IBM，一些像EWA、JADE和Struts（来自Jakarta）的这样的框架正用在客户集成场景中。以EWA（读作“Eva”）为例（它来自IBM Software Group Advanced Technology Solutions组），在一个较高的层次上，框架看起来如下图所示。在这个框架中，配置定义了一个应用程序，描述了该应用程序的组件以及它们调用的顺序和方法。以源中立的方式接收输入并将其传送到应用程序。因此，举例来说，用现有的ATM访问将因特网连接添加到一个银行应用程序，对应用程序逻辑来说是透明的。前端设备和协议处理程序使其成为可能。核心提供系统级服务，而特定用途的使得能够连接后端企业应用程序，这样它们就可以保持原来的状态，或者在一段时间以后进行迁移。虽然EWA是完全遵循J2EE，但是它可以连接到外部基于DCOM或CORBA组件的系统。

现在，EWA包括超过1500个的常规和特定用途的组件，从而大大地减少了编写新的应用程序所需的代码数量。本系列的另一篇文章将详细地研究应用程序框架以及用户在开发这样一个应用程序框架的过程中需要什么。
解决前面的问题
现在，让我们回到讨论第一个集成场景，寻找一个将所需的接口数量减到最少的Scheme，如下图所示。

这张图看起来可能过于简化，但是现在可以很清楚地看出，在像EWA这样的框架中，这张图是一个起点。现在，添加属于体系结构概念范围的服务总线（Service Bus）（在下图中用深色的中线表示）和服务或流管理器来连接服务和提供服务请求的路径。流管理器处理定义好的执行序列或服务流，它们将按照适当的顺序调用所需的服务来产生最后的结果。业务流程执行语言（Business Process Execution Language，BPEL）就是这种将流程定义为一组服务调用的技术的例子。

在这里，您需要确定如何调用服务，因而您将添加应用程序配置。接着，虚拟化输入和输出。最后，提供到后端流程的连接，以便使它们可以按“仅此状态”运行，并且还可以在将来进行迁移。现在，这个高层次的图至少在结构上是完整的了，如下图所示。

这张图与EWA框图有一些类同之处是毫不奇怪的。在最高的层次上，任何强大的应用程序框架都必须提供这些功能。然而，从现在起，真正的工作开始了——构建1500个组件来丰富这个骨架。这就是为什么很多IT架构师选择在一个现有的框架中进行实现的原因；把现有的应用程序分解成用于框架的组件就够了，而不必重新开发所有其他已知将要用到的通用用途组件和系统组件。无论您如何使用它，您都可以使用现有的技术和框架来实现该体系结构，所以您绕了一整圈，现在又回到了开始的地方，在这里，流程首先分析必须解决的业务问题。如果您敢肯定您的体系结构事实上是可实现的，您现在就可以这样做。
体系结构中的集成需求
讨论至此，集成已限定为通过基于组件的服务进行的应用程序的集成，但是集成这个主题比这要宽泛得多。在估计一个体系结构的需求时，必须考虑一些集成的类型或“方式”。您必须考虑如下几方面：
l 应用程序集成
l 终端用户界面集成
l 应用程序连接
l 流程集成
l 信息集成
l 构建集成开发模型
终端用户界面集成涉及如何集成特定用户访问的全部应用程序和服务来提供可用、高效、一致的界面。它是一个正在发展的主题，而新的发展在近期将主要取决于Portal服务器使用方面的进展。虽然Portlet已经可以通过Web服务调用本地服务组件，但是新技术（比如用户远程Portlet的Web服务）将使内容和应用程序提供者能够创建交互式服务，这些服务在因特网上可以通过Portal即插即用，从而为很多新的集成提供了可能。
应用程序连接是一种集成方式，它涉及体系结构必须支持的所有类型的连接。在一个层次上，这意味着数据的同步和异步通信、路由、转换和高速分布、以及网关和协议转换器等等。而在另一个层次上，它还与输入和输出或源（Sources）和汇（Sinks）的虚拟化有关，正如您在EWA的通道（Channel）和协议转换程序（Protocol Handlers）中所看到的，这里的问题在于数据移入、移出以及在实现体系结构的框架中移动的方式。
流程集成涉及开发映射到业务流程和为业务流程提供解决方案的计算流程、将应用程序集成到流程以及集成一些流程与其他一些流程。虽然第一项需求可能看起来似乎无关紧要，不过就是体系结构提供一个模拟基本业务问题的环境，但是，如果在这一层中不进行充分的分析，体系结构的任何实现注定都将失败，不管它采用的技术是多么的巧妙。将应用程序集成到流程可能包括企业中的应用程序，也可能涉及调用远程系统中的应用程序或服务，而这些远程系统多半属于业务合作伙伴。同样地，流程层集成可能涉及整个流程的集成而不仅仅是来自外部源的单个服务，比如供应链管理或金融服务这样横跨多个机构的流程。为了满足这样的应用程序和流程的集成需求，可以使用像BPEL4WS这样的技术，而应用程序框架也可以使用程序配置Scheme（比如在EWA中看到的）。实际上，可以在底层使用BPEL4WS来构造一个高层配置Scheme，然后通过一个引擎来驱动，这个引擎不仅提供流管理，而且还提供其他功能。然而，在构建这一切之前，您应该首先了解体系结构方面的需求，然后，再构建合适的基础架构。
信息集成是一个流程，其作用在于为所有需要它的应用程序提供对企业中全部数据的一致访问，而不管这些应用程序是以什么形式需要它，也不受数据的格式、来源或位置的限制。在实现时，这项需求可能包括适配器和转换引擎，不过它通常要比这复杂。而关键的概念往往是数据的虚拟化，这可能包括数据总线（Data Bus）的开发，企业中的所有应用程序都通过标准服务或接口从数据总线中请求数据。因此，不管数据是来自电子数据表、本地文件、SQL或DL/I数据库，还是来自内存中的数据存储，都可以将数据提供给应用程序。永久存储中的数据格式可能还不为应用程序所知。应用程序更不知道管理数据的操作系统，因而访问AIX或Linux系统中的本地文件的方式与这些文件放在Windows、OS/2、ZOS或其他系统中时访问它们的方式相同。同样地，数据的位置也是透明的；由于它是由共同的服务提供的，所以是由访问服务而不是由应用程序来负责查询数据（无论是本地的还是远程的），然后按照请求的格式提供数据。
应用程序开发环境的最后一项需求是，必须考虑可能在企业中实现的集成的所有方式和层次，并且为它们的开发和部署做好准备。要想真正做到健壮，开发环境必须包括（和执行）一种方法来明确地规定如何设计和构建服务和组件，以便促进重用、消除冗余和简化测试、部署和维护。
上面列出的所有集成方式在任何企业中都有一定程度的体现，尽管在某些情况下它们可能是简化的，或者没有明确地进行定义；因而，在着手设计新的体系结构框架时，您必须全面的考虑它们。特定的IT环境可能只有很少的数据源类型，因此，消息集成可能会很简单。同样地，应用程序连接的作用域可能也很有限。虽然如此，如果希望框架能够随着企业的成长和变化成功地继续得以保持，则框架中的集成功能仍然必须由服务提供，而不是由特定的应用程序来完成。
部署面向服务的体系结构的好处
面向服务的体系结构可以基于现有的系统投资来发展，而不需要彻底重新创建系统。如果组织将开发力量集中在创建服务、利用现有的技术、结合基于组件的方法来开发软件上，将获得如下几方面好处：
l 利用现有资产—这是首要的需求。通过使用适当的SOA框架并使其可用于整个企业，可以将业务服务构造成现有组件的集合。使用这种新的服务只需要知道它的接口和名称。服务的内部细节以及在组成服务的组件之间传送的数据的复杂性都对外界隐藏了。这种组件的匿名性使组织能够利用现有的投资，从而可以通过合并构建在不同的机器上、运行在不同的操作系统中、用不同的编程语言开发的组件来创建服务。遗留系统可以通过Web服务接口来封装和访问。
l 商品化基础架构—在所有不同的企业应用程序之间，基础架构的开发和部署将变得更加一致。现有的组件、新开发的组件和从厂商购买的组件可以合并在一个定义良好的SOA框架内。这样的组件集合将被作为服务部署在现有的基础构架中，从而使得可以更多地将基础架构作为一种商品化元素来加以考虑。
l 更快的产品上市速度—组织的Web服务库将成为采用SOA框架的组织的核心资产。使用这些Web服务库来构建和部署服务将显著地加快产品的上市速度，因为对现有服务和组件的新的创造性重用缩短了设计、开发、测试和部署产品的时间。
l 减少成本—随着业务需求的发展和新的需求的引入，通过采用SOA框架和服务库，为现有的和新的应用程序增强和创建新的服务的成本大大地减少了。同样，开发团队的学习难度也降低了，因为他们可能已经熟悉了现有的组件。
l 降低风险—重用现有的组件降低了在增强或创建新的业务服务的过程中带来的风险。如前所述，这也减少了维护和管理支持服务的基础架构的风险。
l 持续改进业务过程—SOA允许清晰地表示流程流，这些流程流通过在特定业务服务中使用的组件的顺序来标识。这给商业用户提供了监视业务操作的理想环境。业务建模反映在业务服务中。流程操纵是以一定的模式重组部件（构成业务服务的组件）来实现的。这将进一步允许更改流程流，而同时监视产生的结果，因此促进了持续改进。
l 以流程为中心的体系结构—现有的体系结构模型和实践往往是以程序为中心的。应用程序是为了程序员的便利而开发的。通常，流程信息在组件之间传播。应用程序很像一个黑匣子，没有粒度可用于外部。重用需要复制代码、合并共享库或继承对象。在以流程为中心的体系结构中，应用程序是为过程开发的。流程可以分解成一系列的步骤，每一个步骤表示一个业务服务。实际上，每个过程服务或组件功能都相当于一个子应用程序。将这些子应用程序链接在一起可以创建能够满足业务需求的流程流。这种粒度允许利用和重用整个组织中的子应用程序。
未来—新模型，新需求
到目前为止，讨论集中在满足现有业务的需求、更好地利用和重用资源以及集成现有的和新的应用程序的相关概念上。但是，一个全新的应用程序模型究竟是什么样的呢？面向服务的体系结构的观念是否仍然有意义或者是必不可少的呢？实际上，两种新的概念已经开始实现了：网格计算（Grid Computing）和按需计算（On Demand Computing）。虽然这两个模型是截然不同的，并且是独立开发的，但是它们之间的关系又是非常的紧密，而每个模型都使SOA的发展更加势在必行。
网格计算
深入讨论网格计算超出了本文的范围，但是有几个要点值得提及的。
其一，网格计算不仅是使用拥有大量MIPS的应用程序来进行计算的解决方案，它还涉及包括硬件、应用程序和数据在内的所有系统资源的虚拟化，因此，在网格中，无论在什么地方，用什么方法，只要需要就可以利用这些资源。
其二，前面部分已经讨论了虚拟化数据源和将应用程序分解成基于组件的服务的重要性，所以很容易理解在网格环境中，一个真正的SOA应该更好地获得最多的资源。
按需计算
On Demand也不在我们讨论的范围之内，但是如果在这里不简要地介绍一下On Demand和SOA之间的关系，那将是不负责任的。Web服务是实现SOA的技术，而SOA是实现On Demand应用程序的体系结构。应用程序必需运行在SOA框架内，以便获得On Demand的好处。
On Demand Web服务On Demand是涵盖宽谱系的On Demand消息的一部分。谱系的一端集中于应用程序环境，而另一端则集中于包括像基础架构和自主计算在内的操作环境。业务转换利用应用程序和操作环境来创建On Demand业务。On Demand业务最核心的是On Demand Web服务，应用程序层的服务可以按照准时制（Just-in-Time）集成能力的要求来发现、重构、装配和交付。
Web服务作为一项切实可行的技术的希望在于，它将通过提供诸如按需服务这样的能力提高业务价值，并且随着时间的推移将转变IT组织开发软件的方式。它甚至完全有可能通过Web转变在利益共同体（包括贸易合作伙伴、客户和其他类型的合作关系）中经营业务以及提供产品和服务的方式。
如果您所有的应用程序共享相同的传输层协议？如果它们都理解相同的接口？如果它们能够参与并理解相同的事务模型？如果您的伙伴也一样？当这一些都实现的时候，展现在您面前的将是什么样的场景呢？相信到那时，您将拥有应用程序和基础架构来支持不断变化的业务情况；您将获得On Demand。而Web服务和SOA会使这一切对应用程序成为可能。
总结
面向服务的体系结构是下一步应用程序开发的重点。服务和面向服务的体系结构都是关于使用异构网络可寻址的软件组件来设计和构建系统的。面向服务的体系结构是一种具有特殊性质的体系结构，它由强调互操作性和位置透明度的组件互连而成。它常常是在现有系统投资的基础上发展起来的，并不需要彻底重新开发全部的系统；它通过利用当前的资源（包括开发人员、软件语言、硬件平台、数据库和应用程序）来利用组织现有的投资，从而在提高生产力的同时降低成本和风险。这种可适应的、灵活的体系结构类型为在开发和维护中缩短产品上市时间以及降低成本和风险提供了基础。Web服务是一些实现SOA的技术，而SOA正在成为开发响应性好、可适应的新型应用程序所选择的体系结构。

SeraphZhang 发表于02:16:05 | 阅读全文 | 评论 0 | 编辑 | 分享 0
SOA头脑风暴点滴（二）

2006-05-21

Tag：头脑风暴

     SOA不仅仅是一个概念，更应该是一种实践一种应用，应该更加良好地体现在企业信息系统集成方面而不是作为所谓专家们嘴上说说技术新名词和简单的趋势而已。
     面对现实环境下的的SOA架构与部署，最重要的是在注意企业运营的基本原则之下搞清两个问题：1、目前企业有哪些已有的系统？2、企业的价值链是如何构成的？这两个问题是企业信息系统集成时的基础性的关键问题，作为技术人员应该学会在遇到实际问题时，深入到领域内部从领域专家的角度来衡量问题所在，然后才是在找到问题之后从技术角度设计出合理的解决方案，否则只能是盲人摸象与管中窥豹。很性情，我们的团队中有bxq师兄这样一位在企业运营管理领域内的专家，他能提纲挈领地总结出由企业价值链导向的信息流和事务流，通过大家的头脑风暴就能更加明确地了解实际领域中的很多从来没有关注和理解问题。
    至于基本原则，其实说穿了只有一点：如何让企业价值最大化！这也是企业运营的根本目的和追求所在，任何信息系统的建设或整合都不能不考虑甚至违反这条原则，这样就真的成为舍本逐末了。以这个基准点去考虑问题，相信而且已经对我们的工作产生帮助的。例如在企业价值链的分析中，我们衡量某些服务“是否应该存在”、“应该怎么样存在”这些问题的时候都会先考虑这样做是不是能是企业价值增值以及其增值幅度，然后就能很清醒的得出那些行为是不需要我们去做的，甚至推论中题目本身某些要求是不符合实际情况企业运营需求的，换句话说这些东西都是我们根本不用耗费任何心思去考虑的。
     发现自己成长很多，尤其学会从企业运营管理的角度来考虑很多技术问题，这要尤其感谢bxq师兄和worldinsand老师，相信我们的团队会快速成长并最终取得我们所希望的成功的。

SeraphZhang 发表于01:34:19 | 阅读全文 | 评论 0 | 编辑 | 分享 0