| SOA>Worldcup's profileSOA>WorldCupBlogLists |  Tools  Help |
|
|
June 26 SOA-理解企业服务总线场景和解决方案2--HDESB 的功能模型 表 1对现有文献中确定的一些 ESB 功能进行了总结和分类（请参见参考资料）。虽然有一些功能非常基础，但是其他的功能（如自动化功能或智能化功能）代表着向按需操作环境转变的重要步骤。重要的是认识到，当前的大多数场景只需要部分类别中的部分功能。ESB 实现所需的最低功能将在下面支持 SOA 的最低功能的 ESB 实现部分中进行探讨。
表 1：在现有的文献中定义的 ESB 功能
上面的许多功能既可以使用专有技术实现，也可以通过利用开放标准实现。然而，使用不同的技术来实现 ESB 可能会使它们的性能、可伸缩性和可靠性这些特性显著不同，同时 ESB 功能和所支持的开放标准也会有所不同。由于这些原因，再加上最近制订和正在兴起的一些相关标准，当今实现 ESB 的许多关键决策都涉及到成熟的专有技术和不成熟的开放标准之间的权衡。
在本系列文章中，我们不打算详细讨论上面的每一个功能类别。相反，我们将集中讨论采用或实现 ESB 的不同方法之间的驱动策略。特别是在下一部分，我们将讨论 ESB 为支持 SOA 所需的最低功能由什么构成。
支持 SOA 的最低功能的 ESB 实现
如果在前面确定的功能中只有一部分和大多数 SOA 场景相关，我们可能会问：实现 ESB 所需的一组最低功能由什么构成？为此，考虑最被普遍认同的 ESB 定义的原理： 1.ESB 是一种逻辑体系结构组件，它提供与 SOA 的原则保持一致的集成基础架构。 2.SOA 原则需要使用与实现无关的的接口、强调位置透明性和可互操作性的通信协议、相对粗粒度和封装可重用功能的服务定义。 3.ESB 可以作为分布式的异构基础架构进行实现。 4.ESB 提供了管理服务基础架构的方法和在分布式异构环境中进行操作的功能。 表 2展示了根据这些原则定义的最低 ESB 功能 表 2: 最低的 ESB 功能
请注意这些最低功能并不需要使用特别的技术，比如 EAI 中间件、Web 服务、J2EE 或 XML。这些技术的使用非常接近也非常符合需求，但是不必强制要求使用它们。相反，最低功能几乎只需简单地使用 SOAP/HTTP 和 WSDL 就可以实现（当然不是所有的情况都这样）：
1.URL 寻址和现有的 HTTP 和 DNS 基础架构提供了一个具有路由服务和位置透明性的“总线（bus）”。 2.SOAP/HTTP 支持请求-响应（Request-Response）通信规范。 3.HTTP 传输协议被广泛地使用。 4.SOAP 和 WSDL 是开放、与实现无关的服务通信和连接模型。 然而，这些 SOAP/HTTP 和 WSDL 的基本应用只是点到点（point-to-point）的集成，并不能实现一些 ESB 需要的关键功能： 1.目前还没有用于控制服务寻址和命名的管理功能。服务名称通过每个适配器单独进行控制的，服务路由控制则分散在由服务客户端调用的地址、HTTP 基础架构和分配给适配器的服务名称之间。 2.虽然这种方法依赖于实现细节，但是它往往并不能使服务实现的替代变得简单；服务请求者代码（也可能是开发工具生成的）通常通过特定地址的特定协议直接绑定到具体的服务提供者实现。如果想要用另一个服务实现来替代原来的服务实现，就需要修改应用程序代码并重新部署这些代码。 当然，在许多甚至是大多数情形中往往需要其他的功能，并且这种需要变得越来越常见。特别地，不管是现在还是以后，下面的需求类型可能会导致更复杂高级的技术的使用： 1.服务质量和服务级别功能。 2.高级 SOA 概念，例如服务编排、目录、转换等等。 3.按需操作环境需求，比如管理与自治功能以及基础架构智能功能。 4.跨越具有不同所有权的多个网络、多个协议以及多个域的真正意义上的异步操作。 影响 ESB 的安全问题 我不想在这里直接提出安全需求，不过它们对选择 ESB 的实现技术非常重要。例如，如果服务请求不需要提供身份验证或授权，实现技术的选择就可以非常的广泛。更有可能的情况是，如果需要一些安全级别，则评估什么形式的安全是可以接受的就非常重要。例如： 1.是否可以接受通信基础架构中的安全性，例如，是否在 EAI 中间件服务器之间使用安全套接字层（Secure Socket Layer，SSL）互相验证，或者是否在使用 HTTPS 协议？ 2.是否可以接受在参与系统之间单独的点到点（point-to-point）安全性，或者是否需要端到端（end-to-end）模型？例如，是否有必要通过类似于代理的中间件系统来把客户端身份传递到服务实现的最终提供者？ 3.是否可以接受应用层中的安全性，例如，客户端代码是否能够执行带有用户 ID 和密码的基本 HTTP 身份验证，或者是否能够把这些信息作为应用程序数据传递给服务？ 4.是否需要遵守行业安全标准，例如 Kerberos 或 WS-Security？ 虽然所有这些都是可能的，但是行业的发展方向是基础架构和中间件支持的符合标准的安全性（例如 Web 服务安全性（WS-Security））功能。然而，相比之下，这些安全标准也是最近才提出的，而且对它们的产品支持仍在发展的过程中，而不是已经确定了，这里尤其需要特别考虑的就是它们的互操作性。因此，任何 ESB 架构都需要尽可能早地确定安全需求，以便在选择实现技术时可以将它们包括进来。 结束语 在本文中，我讨论了大多数通用的 SOA 原则，以及它们与 Web 服务技术的关联。基于这些原则，我提出了需要一个基础架构组件，这个组件可以提供路由功能，以便使服务能够彼此交互，同时还能够支持使用另一个服务实现来替换原有的服务实现。这些功能都是通过 ESB 实现的。 ESB 在维持集中控制的同时提供分布式的基础架构，因而需要一些形式的服务路由目录，并且还可能需要业务服务目录。Business Service Choreographer 从 ESB 调用服务，然后通过 ESB 把这些流程作为新的服务公开。 ESB 的许多功能包括提供： 1.通信 2.服务交互 3集成 4.质量服务 5.安全 6.服务级别 7.消息处理 8.管理及自治服务 9.建模 10.基础架构智能 从这些不同的功能中，我确定了建立 ESB 所需的最低功能，包括通信、集成和服务交互。 在这个系列的下一个部分中，我将讨论一些通用的场景，以及与这些场景相关的解决方案模式，同时指出影响这些场景最一般的问题。 SOA-理解企业服务总线场景和解决方案--HD【IT168 技术文档】引言 最新的 IT 集成是使用 Web 服务技术实现面向服务的体系结构（SOA），有许多优秀的文章讲述了该技术的好处和相关的实践。最近，企业服务总线（Enterprise Service Bus，ESB）的概念被表述为 SOA 基础架构的关键组件。然而，有必要阐明 ESB 究竟是一个产品、技术、标准，还是别的什么。特别是，当前是否可以构建 ESB？如果这样，该如何构建？ 本文将 ESB 描述为由中间件技术实现并支持 SOA 的一组基础架构功能。ESB 支持异构环境中的服务、消息，以及基于事件的交互，并且具有适当的服务级别和可管理性。为了达到此目的，需要将多种功能集中起来并加以分类。然而，并不是 ESB 能够传递值的每一种情形都需要所有的功能。 本文确定了一组最低功能，可以满足 ESB 与 SOA 的原则保持一致的基本需要。通过确定这些最低功能，您可以确定利用何种现有技术来实现支持 SOA 的 ESB。通过考虑特定情形下的需求如何确定对额外功能的需要，您可以选择最适合这种情形的实现技术。 在接下来的文章中，我将在 SOA 中定义一组 ESB 场景，以定义 ESB 或 SOA 实现的共同起点。而解决方案模式又为选择适当的实现技术提供了指南。 随着 ESB 解决方案的发展和成熟，它所需要的功能也在不断地发展。同样，可见的 ESB 产品的可用性和功能也日趋完善。因此，在本系列的最后一篇文章中，我将考虑 SOA 和 ESB 的发展路线，以指导 ESB 功能和技术的最初应用，并且阐述如何选择循序渐进的方法。 ESB 在 SOA 内的工作角色 虽然我不打算深入讨论 SOA 的定义（请参见参考资料），但是在这里概括一下大部分对 SOA 的描述所适用的原则是很有用的： 1.利用显式的与实现无关的接口来定义服务。 2.利用强调位置透明性和可互操作性的通信协议。 3.封装可重用业务功能的服务的定义。 图 1说明了这些原则。注意，虽然 Web 服务技术非常符合这些原则，但它并不是唯一符合这些原则的技术。 图 1: SOA 的原则 为了实现 SOA，应用程序和基础架构都必须支持 SOA 原则。启用 SOA 应用程序涉及到创建服务接口，服务接口可以直接也可以间接地通过使用适配器用于现有的或新的功能。从最基本的级别来看，启用该基础架构涉及到规划功能来将服务请求路由和传递给正确的服务提供者。然而，基础架构支持在不影响服务的客户端的情况下由另一个服务实现替代原有的服务实现也是至关重要的。这不仅需要根据 SOA 原则指定服务接口，而且需要基础架构允许客户端代码以独立于所涉及的服务位置和通信协议的方式来调用服务。这样的服务路由和替代是 ESB 的许多功能中的一部分。 ESB 支持这些服务交互功能，并提供集成的通信、消息传递以及事件基础架构来支持这些功能。因此，它将当今正在使用的主要企业集成模式组合成一个实体。ESB 为 SOA 提供与企业需要保持一致的基础架构，从而提供合适的服务级别和可管理性、以及异构环境中的操作。 本文剩余部分将讨论 ESB 在 SOA 中的角色，包括它提供的除了基本的路由和传输以外的功能，如下面的ESB 功能模型部分中所述。 ESB 结构 ESB 有时被描述为分布式基础架构，这与其他的解决方案形成了对比，比如消息代理技术一般被描述为中心辐射型（hub-and-spoke）。然而，这并不是真正的差别。正在研究两个不同的问题：控制的集中和基础架构的分布。ESB 和中心辐射型（hub-and-spoke）解决方案都集中控制配置，比如服务交互的路由、服务命名等等。同样，这两个解决方案可能部署在简单的集中式基础架构中，也可能采用更复杂的分布式方式进行部署。图 2展示了这一点。 毫无疑问，不同的技术对它们所支持的物理部署模式有不同的约束——有些可能适合于非常广泛的分布，以支持在很大的地理范围内进行的集成，而其他的可能更适合于部署在本地群集中，以支持高可用性和可伸缩性。使物理分布需求与候选技术的功能相匹配是 ESB 设计的一个重要方面。另外的一种能力也是非常重要的，就是以增量方式扩展最初的部署来反映不断变化的需求、集成附加的系统或扩展基础架构的物理范围。 图 2: 分布式 ESB 基础架构的集中控制 我还应该定位在 SOA 基础架构中 ESB 与其他组件之间的关系，特别是与 Service Directory、Business Service Choreography、以及 Business-to-Business (B2B) Gateway 这些组件之间的关系。由于上述 SOA 原则对这些组件并没有严格的要求，所以我们可以将它们视为可选组件。图 3展示的 SOA 说明了这些组件之间的关系。 图 3: SOA 中的 ESB 角色 ESB 需要某种形式的服务路由目录（service routing directory）来路由服务请求。然而，SOA 可能还有单独的业务服务目录（business service directory），其最基本的形式可能是设计时服务目录，用于在组织的整个开发活动中实现服务的重用。Web 服务远景在业务服务目录和服务路由目录的角色中都放置了一个 UDDI 目录，因而使得可以动态发现和调用服务。这样的目录可以视为 ESB 的一部分；然而，在这样的解决方案变得普遍之前，业务服务目录可能与 ESB 是分离的。 Business Service Choreographer 的作用是通过若干业务服务来组合业务流程；因此，它将通过 ESB 调用服务，然后再次通过 ESB 将业务流程公开为客户端可用的其他服务。然而，Business Service Choreographer 在编排业务流程和服务中所扮演的角色确定了这种业务工作流技术是一种与基础架构技术 ESB 分离的技术。 最后，B2B Gateway 组件的作用是使两个或多个组织的服务在受控且安全的方式下对彼此可用。这有助于查看这些连接到 ESB 的组件，但它们并不是 ESB 的一部分。虽然有一些网关技术可以提供适合于实现 B2B Gateway 组件和 ESB 的功能，但是 B2B Gateway 组件的用途是将其与 ESB 分离。事实上，这种用途可能需要附加的功能（如合作伙伴关系管理），这些功能不是 ESB 的一部分，并且不一定受到 ESB 技术的支持。 组件设计模板 -HD组件设计模板
下载部分中提供的示例设计模板包括九个部分（将在下面进行说明）。第一部分和最后一部分用于在组件与整个门户之间建立联系。在门户项目的早期，确定了任务和组件后，团队负责人将创建一组设计文档，并将其分发给组件所有者。这些组件所有者将使用设计文档来记录组件级的需求、定义组件体系结构、列出测试用例、模拟组件的 UI，诸如此类的工作。他们的文档将随时间而不断改进，并将在其中包含组件的概要设计和详细设计。 此模板是一个起点；请根据您的需要对其进行调整。重要的是，要具备与每个组件、Portlet、服务或门户项目的主要部分关联的设计文档！ 第一部分提供组件或组件集的基本介绍。文档的任何读者（如管理人员、团队成员、编码人员、测试人员、营销人员、相关项目团队成员）应能轻松地明白组件的用途及其完成的工作，而不用过于深入功能、需求或技术细节。请将其视为摘要。 可以考虑添加其他一些跟踪性信息，如：
再次强调：需求非常重要。无论将其作为用例或用户案例进行记录，都请将需求作为对团队提出要求的客户。这些内容说明组件提供的功能应如何工作以及组件为整个门户提供何种价值。正是由于这个原因，需要将驱动组件的需求与该组件的设计一起记录。 如果需求是在创建设计文档之前收集的，可能会存储在业务分析团队创建的独立文档中。我们建议不要链接或引用另一个文档，而将其从原始文档中复制并粘贴到组件设计文档中，以便将组件的所有信息都存储在同一个位置。需要在您的文档中保存需求和任何用例以及相关的用户界面设计、测试场景和任何其他部分，以便开发人员能方便地进行参考。 利用这一部分来确定组件的总体体系结构（采用与项目适应的格式）。以下是可以包含的内容的一些示例：
对于技术专家而言，这是模板的核心。好的详细设计将使用类、序列、组件交互关系图来描述如何实现组件。当然，您所决定要包含的内容取决于所设计的组件类型和可能用于进行文档设计的组织标准。 很多组件有自己的数据库表，或依赖于现有数据库模式。这一部分描述组件使用的模式和数据，可以包含：
用户界面文档大多数情况下是由信息架构师、人类工程学工程师或图形设计师提供的。可以将组件设计文档提供给担任此类角色的人员，以便他/她添加描述用户流的模型。开发人员可使用这些模型来实现组件。 事实上，有些项目并没有任何信息架构师、人类工程学工程师或图形设计师，因此开发人员必须创建用户界面。不管谁最终创建 Portlet 皮肤设计，都应在设计文档的这一部分进行记录。如果没有任何设计，在这一部分插入一个最终界面的屏幕截图，并附上描述性文本。 不过，用户界面设计实际不应由开发人员负责。在非常简单的情况下可以这样，但设计用户界面所要求的技能与实现界面背后的功能所需的技能并不相同。您的团队应具有信息架构师或用户界面设计师提供服务，担任此类角色的人员可以与客户进行沟通，以理解和建模任务流，并随后设计用户界面。 过去，测试是项目中最常被忽略的阶段之一。我们将这一部分包含在设计文档，目的是为了帮助在项目内强制实施一些测试要求。面对所有不同类型的测试类型（如单元测试、功能测试、集成测试、黑盒测试和白盒测试等），可能让人不知所措，不知道应进行哪种类型的测试以及何时进行测试。在大多数项目中，单元测试是计划中的一个常规项；不过，执行不易理解的单元测试却是最难的。随着敏捷方法的出现，对很多项目都可以成功进行单元测试了。 开发人员在开发过程中运行的测试通常称为单元测试，可帮助确保代码的正确性。集成和功能测试在不同组件组合到一起并已可以部署时进行。（很多情况下这不过是确定那些测试如何执行，以及计划何时进行测试。） 功能测试在门户和门户组件的生命周期中非常重要；当对代码进行了更改时，要求进行回归测试。在以后的文章中，我们将集中讨论测试的执行。开发团队务必与质量保证 (QA) 或测试团队密切合作，以确保开发阶段的平稳过渡，并促进对潜在问题的沟通。将代码组件直接抛给测试人员，然后甩手不管，无疑会带来问题，相反，应让测试人员和开发人员时常碰头，以便测试人员编写测试脚本。开发人员将会了解到他们从来没有想到的问题，而这样做将帮助团队成员学习如何彼此进行沟通。 如果您的项目测试要求很多，就可以很容易地完成这一部分。至少应让开发人员在这一部分中包含一些手动编写的测试，他/她将运行这些测试来确保组件按照需求中描述的方式工作。这些测试用例可以非常简单，如一组可以在必要时应用到组件的输入和结果值。请包括失败的用例和通过的条件。此文档不仅可以确保开发人员能更深入地了解组件，还可以提供一组初始工作测试集，以供以后的团队了解和评估组件。 即使最简单的组件也有需要采用在部署和配置期间进行的步骤。利用用这一部分来描述如何创建数据源、配置参数和定义部署顺序。尽管开发人员凭直觉就能理解此流程，但可能在将项目投入生产时进行开发和操作交接的过程中丢失这些信息。因此，这一部分的目的在于帮助在项目整个生命周期中捕获此信息。 在任务繁重而时间又紧急的项目中，开发人员经常抱怨没有时间更新文档。开发人员至少需要对组件部署的一些基本信息进行记录。开发团队负责人或构建和部署管理人员需要确保开发人员完成了所需的文档，且其详细程度符合团队的要求。这一部分提供方便团队捕获此信息的机制；不过不能对任何项目的执行情况进行编造或假设。 这一部分向团队成员提供记录关于组件的问题和顾虑的集中位置。其目标是在出现问题时实时地捕获问题。很多团队通过电子邮件报告问题。此方法的问题在于，必须对众多电子邮件进行搜索，才能收集到所有出现的问题。依赖关系是在这一部分列出的另一个内容。例如，很多 Portlet 和组件都具有后端依赖关系，需要对此加以记录，以供将来参考。 SOA 架构的分层模型--HD1. SOA 为企业级架构设计带来的影响 1.1 SOA 的特点及其使用范围 SOA 既不是一种语言，也不是一种具体的技术，它是一种新的软件系统架构模型。 SOA 最主要的应用场合在于解决在Internet环境下的不同商业应用之间的业务集成问题。Internet环境区别于Intranet环境的几个特点主要是: (a)大量异构系统并存，不同计算机硬件工作方式不同，操作系统不同、编程语言也不同; (b)大量、频繁的数据传输的速度仍然相对较缓慢并且不稳定; (c)无法完成服务(service)的版本升级，甚至根本就无法知道互联网上有哪些机器直接或者间接的使用某个服务。 SOA 架构具有一些典型特性，主要包括松耦合性，位置透明性以及协议无关性。松耦合性要求 SOA 架构中的不同服务之间应该保持一种松耦合的关系，也就是应该保持一种相对独立无依赖的关系;位置透明性要求 SOA 系统中的所有服务对于他们的调用者来说都是位置透明的，也就是说每个服务的调用者只需要知道他们调用的是哪一个服务，但并不需要知道所调用服务的物理位置在哪里;而协议无关性要求每一个服务都可以通过不同的协议来调用。通过这些 SOA 架构所具有的特性我们可以看到，SOA 架构的出现为企业系统架构提供了更加灵活的构建方式，如果企业架构设计师基于 SOA 来构建系统架构，就可以从底层架构的级别来保证整个系统的松耦合性以及灵活性，这都为未来企业业务逻辑的扩展打好了基础。 1.2 SOA 架构的分层模型 接下来简要介绍一下 SOA 系统中的分层模型，整个 SOA 架构的分层模型如图2所示。
在 SOA 系统中不同的功能模块可以被分为7层:第一层就是系统已经存在的程序资源，例如ERP或者CRM系统等。第2层就是组件层，在这一层中我们用不同的组件把底层系统的功能封装起来。第3层就是 SOA 系统中最重要的服务层，在这层中我们要用底层功能组件来构建我们所需要的不同功能的服务。总的来说，SOA 中的服务可以被映射成具体系统中的任何功能模块，但是从功能性方面可以大致划分为以下三种类型:(1)商业服务(business service) 或者是商业过程(business process)。这一类的服务是一个企业可以暴露给外部用户或者合作伙伴使用的服务。比如说提交贷款申请，用户信用检查，贷款信用查询。(2)商业功能服务(business function service)， 这类服务会完成一些具体的商业操作，也会被更上层的商业服务调用，不过大多数情况下这类服务不会暴露给外部用户直接调用，比如说检索用户帐户信息，存储用户信息等。(3)技术功能服务(technical function service)，这类服务主要完成一些底层的技术功能，比如说日志服务以及安全服务等。在服务层之上的第4层就是商业流程层，在这一层中我们利用已经封装好的各种服务来构建商业系统中的商业流程。在商业流程层之上的就是第5层表示层了，我们利用表示层来向用户提供用户接口服务，这一层可以用基于portal的系统来构建。以上这5层都需要有一个集成的环境来支持它们的运行，第6层中的企业服务总线(ESB)提供了这个功能。第7层主要为整个 SOA 系统提供一些辅助的功能，例如服务质量管理，安全管理这一类的辅助功能。 2. SOA 架构中的非功能性服务级别(service-level)需求 除了系统的业务需求，架构设计师还必须要保证构建出来的系统架构能够满足系统中的非功能性服务级别(service-level)需求以及服务质量(QoS)方面的需求。在项目初始及细化阶段，架构设计师应该与系统所有涉及方(Stakeholders)一起，为每一个服务级别需求定义其相关的衡量标准。构建出的系统架构必须要能满足以下几方面的服务水准要求:性能、可升级性、可靠性、可用性、可扩展性、可维护性、易管理性以及安全性。架构设计师在设计架构过程中需要平衡所有的这些服务级别需求。例如，如果服务级别需求中最重要的是系统性能，架构设计师很有可能不得不在一定程度上牺牲系统的可维护性及可扩展性，以确保满足系统性能上的要求。随着互联网的发展，新构建的系统对于服务级别需求也变得日益重要，现在基于互联网的企业系统的用户已经不仅仅局限于是本企业的雇员，企业的外部客户也会成为企业系统的主要用户。 架构设计师的职责之一就是要尽可能地为提高系统设计人员和系统开发人员的工作效率考虑。在构建整个企业系统架构的过程中，需要充分重视各种服务级别需求，从而避免在系统开发和运行的时候出现重大问题。一个企业级系统中的服务级别需求往往是十分错综复杂的， SOA 架构设计师需要凭借丰富的专业经验和扎实的理论知识来分离和抽象系统中不同的服务级别需求，图3展示了这种分析的过程。
图3 经过 SOA 架构设计师分析和抽象的服务级别需求主要分为以下几类: 性能是指系统提供的服务要满足一定的性能衡量标准，这些标准可能包括系统反应时间以及处理交易量的能力等; 可升级性是指当系统负荷加大时，能够确保所需的服务质量，而不需要更改整个系统的架构; 可靠性是指确保各应用及其相关的所有交易的完整性和一致性的能力; 可用性是指一个系统应确保一项服务或者资源永远都可以被访问到; 可扩展性是指在不影响现有系统功能的基础上，为系统填加新的功能或修改现有功能的能力; 可维护性是指在不影响系统其他部分的情况下修正现有功能中问题或缺陷，并对整个系统进行维护的能力; 可管理性是指管理系统以确保系统的可升级性、可靠性、可用性、性能和安全性的能力; 安全性是指确保系统安全不会被危及的能力。 1) 性能 我们通常可以根据每个用户访问的系统响应时间来衡量系统的整体性能;另外，我们也可以通过系统能够处理的交易量(每秒)来衡量系统的性能。对于架构设计师来说，无论采取哪种衡量系统性能的方法来构建系统架构，这些对于性能的考虑对系统设计开发人员来说都应该是透明的，也就是说对于系统整体架构性能的考虑应该是架构设计师的工作，而不是系统设计开发人员应该关注的事情。在较传统的基于EJB或者XML-RPC的分布式计算模型中，它们的服务提供都是通过函数调用的方式进行的，一个功能的完成往往需要通过客户端和服务器来回很多次的远程函数调用才能完成。在Intranet的环境下，这些调用给系统的响应速度和稳定性带来的影响都可以忽略不计，但如果我们在基于 SOA 的架构中使用了很多Web Service来作为服务提供点的话，我们就需要考虑性能的影响，尤其是在Internet环境下，这些往往是决定整个系统是否能正常工作的一个关键决定因素。因此在基于 SOA 的系统中，推荐采用大数据量低频率访问模式，也就是以大数据量的方式一次性进行信息交换。这样做可以在一定程度上提高系统的整体性能。 2) 可升级性 可升级性是指当系统负荷加大时，仍能够确保所需的服务质量，而不需要更改整个系统的架构。当基于 SOA 的系统中负荷增大时，如果系统的响应时间仍能够在可接受的限度内，那么我们就可以认为这个系统是具有可升级性的。要想理解可升级性，我们必须首先了解系统容量或系统的承受能力，也就是一个系统在保证正常运行质量的同时，所能够处理的最大进程数量或所能支持的最大用户数量。如果系统运转时已经不能在可接受时间范围内反应，那么这个系统已经到达了它的最大可升级状态。要想升级已达到最大负载能力的系统，你必须增加新的硬件。新添加的硬件可以以垂直或水平的方式加入。垂直升级包括为现在的机器增加处理器、内存或硬盘。水平升级包括在环境中添置新的机器，从而增加系统的整体处理能力。作为一个系统架构设计师所设计出来的架构必须能够处理对硬件的垂直或者水平升级。基于 SOA 的系统架构可以很好地保证整体系统的可升级性，这主要是因为系统中的功能模块已经被抽象成不同的服务，所有的硬件以及底层平台的信息都被屏蔽在服务之下，因此不管是对已有系统的水平升级还是垂直升级，都不会影响到系统整体的架构。 3) 可靠性 可靠性是指确保各应用及其相关的所有交易的完整性和一致性的能力。当系统负荷增加时，你的系统必须能够持续处理需求访问，并确保系统能够象负荷未增加以前一样正确地处理各个进程。可靠性可能会在一定程度上限制系统的可升级性。如果系统负荷增加时，不能维持它的可靠性，那么实际上这个系统也并不具备可升级性。因此，一个真正可升级的系统必须是可靠的系统。在基于 SOA 来构建系统架构的时候，可靠性也是必须要着重考虑的问题。要在基于 SOA 架构的系统中保证一定的系统可靠性，就必须要首先保证分布在系统中的不同服务的可靠性。而不同服务的可靠性一般可以由其部署的应用服务器或Web服务器来保证。只有确保每一个 SOA 系统中的服务都具有较高的可靠性，我们才能保证系统整体的可靠性能够得以保障。 4) 可用性 可用性是指一个系统应确保一项服务或者资源应该总是可被访问到的。可靠性可以增加系统的整体可用性，但即使系统部件出错，有时却并不一定会影响系统的可用性。通过在环境中设置冗余组件和错误恢复机制，虽然一个单独的组件的错误会对系统的可靠性产生不良的影响，但由于系统冗余的存在，使得整个系统服务仍然可用。在基于 SOA 来构建系统架构的时候，对于关键性的服务需要更多地考虑其可用性需求，这可以由两个层次的技术实现来支持，第一种是利用不同服务的具体内部实现内部所基于的框架的容错或者冗余机制来实现对服务可用性的支持;第二种是通过UDDI等动态查找匹配方式来支持系统整体的高可用性。在 SOA 架构设计师构建企业系统架构的时候，应该综合考虑这两个方面的内容，尽量保证所构建的 SOA 系统架构中的关键性业务能具有较高的可用性。 5) 可扩展性 可扩展性是指在不影响现有系统功能的基础上，为系统添加新的功能或修改现有功能的能力。当系统刚配置好的时候，你很难衡量它的可扩展性，直到第一次你必须去扩展系统已有功能的时候，你才能真正去衡量和检测整个系统的可扩展性。任何一个架构设计师在构建系统架构时，为了确保架构设计的可扩展性，都应该考虑下面几个要素:低耦合，界面(interfaces)以及封装。当架构设计师基于 SOA 来构建企业系统架构时，就已经隐含地解决了这几个可扩展性方面的要素。这是因为 SOA 架构中的不同服务之间本身就保持了一种无依赖的低耦合关系;服务本身是通过统一的接口定义(可以是WSDL)语言来描述具体的服务内容，并且很好地封装了底层的具体实现。在这里我们也可以从一个方面看到基于 SOA 来构架企业系统能为我们带来的好处。 6) 可维护性 可维护性是指在不影响系统其他部分的情况下修改现有系统功能中问题或缺陷的能力。同系统的可扩展性相同，当系统刚被部署时，你很难判断一个系统是否已经具备了很好的可维护性。当创建和设计系统架构时，要想提高系统的可维护性，你必须考虑下面几个要素:低耦合、模块性以及系统文档记录。在企业系统可扩展性中我们已经提到了 SOA 架构能为系统中暴露出来的各个子功能模块也就是服务带来低耦合性和很好的模块性。关于系统文档纪录，除了底层子系统的相关文档外，基于 SOA 的系统还会引用到许多系统外部的由第三方提供的服务，因此如果人力资源准许的话，应该增加专职的文档管理员来专门负责有关整个企业系统所涉及的所有外部服务相关文档的收集、归类和整理，这些相关的文档可能涉及到第三方服务的接口(可以是WSDL)、服务的质量和级别、具体性能测试结果等各种相关文档。基于这些文档，就可以为 SOA 架构设计师构建企业 SOA 架构提供很好的文档参考和支持。 7) 可管理性 可管理性是指管理系统以确保整个系统的可升级性、可靠性、可用性、性能和安全性的能力。具有可管理性的系统，应具备对服务质量需求(QoS)的系统监控能力，通过改变系统的配置从而可以动态地改善服务质量，而不用改变整体系统架构。一个好的系统架构必须能够监控整个系统的运行情况并具备动态系统配置管理的功能。在对复杂系统进行系统架构建模时， SOA 架构设计师应该尽量考虑利用将系统整体架构构建在已有的成熟的底层系统框架(Framework)上。对于 SOA 架构设计师来说，可以选择的底层系统框架有很多，可以选用基于MQ, MessageBorker，WebSphere Application Server等产品来构建企业服务总线(Enterprise Service Bus)以支持企业的 SOA 系统架构，也可以选用较新的基于WebSphere Application Server 6中内嵌的Sibus来构建企业的ESB以支持 SOA 系统架构。具体选择哪种底层框架来实施 SOA 系统架构要根据每个系统各自的特点来决定，但这些底层的框架都已经提供了较高的系统可管理性。因此，分析并选择不同的产品或底层框架来实现企业系统架构也是架构设计师的主要职责之一。有关于如何利用已有底层架构来构建 SOA 系统，中国 SOA 设计中心已经发表了一系列相关的文章，大家可以在DeveloperWorks中的 SOA 专栏看到它们。 8) 安全性 安全性是指确保系统安全不会被危及的能力。目前，安全性应该说是最困难的系统质量控制点。这是因为安全性不仅要求确保系统的保密和完整性，而且还要防止影响可用性的服务拒绝(Denial-of-Service)攻击。这就要求当 SOA 架构设计师在构建一个架构时，应该把整体系统架构尽可能地分割成各个子功能模块，在将一些子功能模块暴露为外部用户可见的服务的时候，要围绕各个子模块构建各自的安全区，这样更便于保证整体系统架构的安全。如果一个子模块受到了安全攻击，也可以保证其他模块相对安全。如果企业 SOA 架构中的一些服务是由Web Service实现的，在考虑这些服务安全性的时候也要同时考虑效率的问题，因为WS-Security会为Web Service带来一定的执行效率损耗。 3.结束语 本系列两部分介绍了有关架构设计师以及 SOA 架构的知识，分析了 SOA 架构师在设计 SOA 系统架构时有哪些应该特别注意的地方并在最后简要介绍了在构建基于 SOA 架构的企业系统时应该怎样保证所构建的系统架构能够满足系统中不同的服务级别需求。从架构设计师的角度， SOA 是一种新的设计模式，方法学。因此， SOA 本身涵盖了很多的内容，也触及到了系统整体架构设计、实现、维护等各个方面。本文的内容只是涉及到了有关于架构方面的一部分内容，希望能对广大的 SOA 系统开发设计人员起到一定的帮助作用。 发表于 @ 2005年12月09日 1:39 AM | 评论 (1)
1. 什么是架构?什么是基于SOA的架构? 1.1 什么是架构 从架构设计师的角度来看，架构就是一套构建系统的准则。通过这套准则，我们可以把一个复杂的系统划分为一套更简单的子系统的集合，这些子系统之间应该保持相互独立，并与整个系统保持一致。而且每一个子系统还可以继续细分下去，从而构成一个复杂的企业级架构。 当一名架构设计师在构建某个企业级的软件系统时，除了要考虑这个系统的架构以及其应具有的功能行为以外，还要关注整个架构的可用性，性能问题，容错能力，可重用性，安全性，扩展性，可管理维护性，可靠性等各个相关方面。有的时候一名好的架构设计师甚至还需要考虑所构建的系统架构是否合乎美学要求。由此我们可以看到，我们衡量一个好的架构设计并不能只从功能角度出发，还要考虑很多其他的因素，对任何一个方面的欠缺考虑都有可能为整个系统的构建埋下隐患。 1.2 什么是基于SOA的架构 SOA本身就是一种面向企业级服务的系统架构，简单来说，SOA就是一种进行系统开发的新的体系架构，在基于SOA架构的系统中，具体应用程序的功能是由一些松耦合并且具有统一接口定义方式的组件(也就是service)组合构建起来的。因此，基于SOA的架构也一定是从企业的具体需求开始构建的。但是，SOA和其它企业架构的不同之处就在于SOA提供的业务灵活性。业务灵活性是指企业能对业务变更快速和有效地进行响应、并且利用业务变更来得到竞争优势的能力。对企业级架构设计师来说，创建一个业务灵活的架构意味着创建一个可以满足当前还未知的业务需求的IT架构。 利用基于SOA的系统构建方法，如图1中所示的一样，一个基于SOA架构的系统中的所有的程序功能都被封装在一些功能模块中，我们就是利用这些已经封装好的功能模块组装构建我们所需要的程序或者系统，而这些功能模块就是SOA架构中的不同的服务(services)。
图1 因此，SOA架构本质上来说体现了一种复合的概念:它不仅为一个企业中商业流程的组织和实现提供了一种指导模式，同时也为具体的底层service开发提供了指导。 2. SOA架构设计师的角色 2.1 SOA架构设计师应该具备什么? 谈到SOA架构设计师的角色，我们首先要了解架构设计师应具有的能力。总体上来说，一个好的架构设计师不仅应该是一个成熟的，具有实际经验的并具有快速学习能力的人，而且他还应该具有良好的管理能力和沟通能力。只有具备了必需的能力，架构设计师才能在关键的时刻作出困难的决定，这就是一名架构设计师应该承担的责任。从角色上来看，SOA 架构师不仅会负责端到端的服务请求者和提供者的设计，并且会负责对系统中非功能服务请求的调研和表述。 对于任何一名经验丰富的架构设计师来说，不论他是采用基于传统的架构设计方法(基于J2EE架构或者.NET架构)还是采用基于SOA的架构设计方法来构建一个企业级的系统架构，具有相关商业领域的知识对于架构设计师来说都是必不可少的，架构设计师往往可以通过实际的工作经验积累以及接受相关的专项培训来获得这些商业领域的知识。除了具有相关商业领域的知识以外，一名合格的架构设计师必须具有较广泛的技术背景，这可能包括软硬件，通信，安全等各个方面的知识。但这并不是意味着要成为一名架构设计师就必须熟悉每一门具体技术的细节，架构设计师必须至少能对各种技术有一个整体上的了解，能够熟知每种技术的特点以及优缺点，只有这样架构设计师才能在特定的应用场景下正确地选择各种技术来设计企业整体架构。 2.2 什么是SOA架构设计师的职责? 那什么是企业级SOA架构设计师的具体角色呢?什么是SOA架构设计师与设计和开发人员之间的差别呢?相信这些都是使大家最容易产生迷惑的问题。举个实际的例子来说，当构建一个基于SOA架构的系统的时候，针对一个具体的 service，系统设计人员主要应该关注的是这个service能够为外部用户提供什么样的服务，也就是说系统设计人员关注的是这个service所提供的功能。而对于SOA架构设计师来说，他们更关心的可能是当有一千个用户同时调用这个 service的时候，什么会发生?也就是说架构设计师关注的应该是一些商业需求和服务级别(service-level)需求。所有的架构设计师的角色都包含了在构建一个系统的一开始就应该尽量减少可能存在的技术风险。而技术风险一般指的是一切未知的、未经证明的或未经测试所带来的风险。这些风险通常与服务级别(service-level)需求相关，偶尔也会与企业具体的业务需求相关。无论是哪种类型的风险，在项目初期设计整体系统架构的过程中更易于发掘这些风险，如果等到架构实施时再发觉这些风险，那么很可能会致使大量的开发人员等在那里，直到这些风险被妥善解决。如果进一步的细化，我们可以看到SOA架构设计师的主要任务包括对整个系统解决方案轮廓的构建，需求分析，对体系结构的整体决策，相关组件建模，相关操作建模，系统组件的逻辑和物理布局设计。 作为SOA架构设计师必须要能够领导整个开发团队，这样才能保证设计和开发人员是按照构建好的系统架构来开发整个系统的，这一点十分的重要。这就要求一名架构设计师不仅要有很好的技术洞察力，同时还要具有一定的项目管理和项目实施的能力。在系统开发的过程中，架构设计师必须要有良好的沟通和表达能力，这就体现在由架构设计师构建的系统模型是否具有很好的可读性和易理解性。如果由架构设计师构造出的系统模型不是很清晰的话，就可能会影响设计和开发人员对于整个系统架构的理解。为了避免这种情况的出现，定期由架构设计师主持的开发团队内部讨论是十分重要的。 3. 构建SOA架构时应该注意的问题 3.1 原有系统架构中的集成需求 当架构师基于SOA来构建一个企业级的系统架构的时候，一定要注意对原有系统架构中的集成需求进行细致的分析和整理。我们都知道，面向服务的体系结构是当前及未来应用程序系统开发的重点，面向服务的体系结构本质上来说是一种具有特殊性质的体系结构，它由具有互操作性和位置透明的组件集成构建并互连而成。基于SOA的企业系统架构通常都是在现有系统架构投资的基础上发展起来的，我们并不需要彻底重新开发全部的子系统;SOA可以通过利用当前系统已有的资源(开发人员、软件语言、硬件平台、数据库和应用程序)来重复利用系统中现有的系统和资源。SOA是一种可适应的、灵活的体系结构类型，基于SOA构建的系统架构可以在系统的开发和维护中缩短产品上市时间，因而可以降低企业系统开发的成本和风险。因此，当SOA架构师遇到一个十分复杂的企业系统时，首先考虑的应该是如何重用已有的投资而不是替换遗留系统，因为如果考虑到有限的预算，整体系统替换的成本是十分高昂的。 当SOA架构师分析原有系统中的集成需求的时候，不应该只限定为基于组件构建的已有应用程序的集成，真正的集成比这要宽泛得多。在分析和评估一个已有系统体系结构的集成需求时，我们必须考虑一些更加具体的集成的类型，这主要包括以下几个方面:应用程序集成的需求，终端用户界面集成的需求，流程集成的需求以及已有系统信息集成的需求。当SOA架构师分析和评估现有系统中所有可能的集成需求的时候，我们可以发现实际上所有集成方式在任何种类的企业中都有一定程度的体现。针对不同的企业类型，这些集成方式可能是简化的，或者没有明确地进行定义的。因而，SOA架构师在着手设计新的体系结构框架时，必须要全面的考虑所有可能的集成需求。例如，在一些类型的企业系统环境中可能只有很少的数据源类型，因此，系统中对消息集成的需求就可能会很简单，但在一些特定的系统中，例如航运系统中的EDI(Electronic Data Interchange 电子数据交换)系统，会有大量的电子数据交换处理的需求，因此也就会存在很多不同的数据源类型，在这种情况下整个系统对于消息数据的集成需求就会比较复杂。因此，如果SOA架构师希望所构建的系统架构能够随着企业的成长和变化成功地继续得以保持，则整个系统构架中的集成功能就应该由服务提供，而不是由特定的应用程序来完成。 3.2 服务粒度的控制以及无状态服务的设计 当SOA架构师构建一个企业级的SOA系统架构的时候，关于系统中最重要的元素，也就是SOA系统中的服务的构建有两点需要特别注意的地方:首先是对于服务粒度的控制，另外就是对于无状态服务的设计。 服务粒度的控制 SOA系统中的服务粒度的控制是一项十分重要的设计任务。通常来说，对于将暴露在整个系统外部的服务推荐使用粗粒度的接口，而相对较细粒度的服务接口通常用于企业系统架构的内部。从技术上讲，粗粒度的服务接口可能是一个特定服务的完整执行，而细粒度的服务接口可能是实现这个粗粒度服务接口的具体的内部操作。 举个例子来说，对于一个基于SOA架构的网上商店来说，粗粒度的服务可能就是暴露给外部用户使用的提交购买表单的操作，而系统内部的细粒度的服务可能就是实现这个提交购买表单服务的一系列的内部服务，比如说创建购买记录，设置客户地址，更新数据库等一系列的操作。虽然细粒度的接口能为服务请求者提供了更加细化和更多的灵活性，但同时也意味着引入较难控制的交互模式易变性,也就是说服务的交互模式可能随着不同的服务请求者而不同。如果我们暴露这些易于变化的服务接口给系统的外部用户，就可能造成外部服务请求者难于支持不断变化的服务提供者所暴露的细粒度服务接口。而粗粒度服务接口保证了服务请求者将以一致的方式使用系统中所暴露出的服务。虽然面向服务的体系结构(SOA)并不强制要求一定要使用粗粒度的服务接口，但是建议使用它们作为外部集成的接口。通常架构设计师可以使用BPEL来创建由细粒度操作组成的业务流程的粗粒度的服务接口。 无状态服务的设计 SOA系统架构中的具体服务应该都是独立的、自包含的请求，在实现这些服务的时候不需要前一个请求的状态，也就是说服务不应该依赖于其他服务的上下文和状态，即SOA架构中的服务应该是无状态的服务。当某一个服务需要依赖时，我们最好把它定义成具体的业务流程(BPEL)。在服务的具体实现机制上，我们可以通过使用 EJB 组件来实现粗粒度的服务。我们通常会利用无状态的Session Bean来实现具体的服务，如果基于Web Service技术，我们就可以将无状态的Session Bean暴露为外部用户可以调用的到的Web服务，也就是把传统的Session Facade模型转化为了 EJB 的Web服务端点，这样，我们就可以向 Web 服务客户提供粗粒度的服务。 如果我们要在 J2EE的环境下(基于WebSphere)构建Web服务，Web 服务客户可以通过两种方式访问 J2EE 应用程序。客户可以访问用 JAX-RPC API 创建的 Web 服务(使用 Servlet 来实现);Web 服务客户也可以通过 EJB的服务端点接口访问无状态的Session Bean，但Web 服务客户不能访问其他类型的企业Bean，如有状态的Session Bean，实体Bean和消息驱动Bean。后一种选择(公开无状态 EJB 组件作为 Web 服务)有很多优势，基于已有的EJB组件，我们可以利用现有的业务逻辑和流程。在许多企业中，现有的业务逻辑可能已经使用 EJB 组件编写，通过 Web 服务公开它可能是实现从外界访问这些服务的最佳选择。EJB 端点是一种很好的选择，因为它使业务逻辑和端点位于同一层上。另外EJB容器会自动提供对并发的支持，作为无状态Session Bean实现的 EJB 服务端点不必担心多线程访问，因为 EJB 容器必须串行化对无状态会话 bean 任何特定实例的请求。 由于EJB容器都会提供对于Security和Transaction的支持，因此Bean的开发人员可以不需要编写安全代码以及事务处理代码。 性能问题对于Web服务来说一直都是一个问题，由于几乎所有 EJB 容器都提供了对无状态会话 Bean 群集的支持以及对无状态Session Bean 池与资源管理的支持，因此当负载增加时，可以向群集中增加机器，Web 服务请求可以定向到这些不同的服务器，同时由于无状态Session Bean 池改进了资源利用和内存管理，使 Web 服务能够有效地响应多个客户请求。由此我们可以看到，通过把 Web 服务模型化为 EJB 端点，可以使服务具有更强的可伸缩性，并增强了系统整体的可靠性。 4. 本文简要介绍了有关架构设计师以及SOA架构的知识，分析了SOA架构师在设计SOA系统架构时有哪些应该特别注意的地方。 本文的第二部分将向您介绍在构建基于SOA架构的企业系统时应该怎样保证所构建的系统架构能够满足系统中不同的服务级别需求。从架构设计师的角度，SOA是一种新的设计模式，方法学。因此，SOA本身涵盖了很多的内容，也触及到了系统整体架构设计、实现、维护等各个方面。本文的内容只是涉及到了有关于架构方面的一部分内容，希望能对广大的SOA系统开发设计人员起到一定的帮助作用。 发表于 @ 2005年12月09日 1:37 AM | 评论 (1)
对于SOA，尤其是像开发人员和CIO等仍有若干关键问题需要回答。 问：SOA的前提是能够使应用程序像服务那样工作。软件如何像服务一样工作呢？ 答：没有SOA，软件包是被编写为独立的（self-contained）软件，即在一个完整的软件包中将许多应用程序功能整合在一起。实现整合应用程序功能的代码通常与功能本身的代码混合在一起。我们将这种方式称作软件设计"单一应用程序"。与此密切相关的是，更改一部分代码将对使用该代码的代码具有重大影响，这会造成系统的复杂性，并增加维护系统的成本。而且还使重新使用应用程序功能变得较困难，因为这些功能不是为了重新使用而打的包。 SOA旨在将单个应用程序功能彼此分开，以便这些功能可以单独用作单个的应用程序功能或"组件"。这些组件可以用于在企业内部创建各种其他的应用程序，或者如有需要，对外向合作伙伴公开，以便用于合作伙伴的应用程序。 "服务"的概念是要使用与实施细节无关的标准化接口来构建这些"组件"。针对一套应用程序服务的Web服务描述语言文档，描述需要作为请求特殊服务（例如，"检查库存"功能可能需要零件数）输入来传输的数据名称和类型，并描述服务响应的细节（它可能返回表示库存中零件数量的一个整数）。 这些详细信息看上去好像与 Java、C++、COBOL 等中实施的功能相同，因此，服务的请求程序无需知道使用的何种语言，而且可以使用任何语言来编写请求程序。这就使一个平台上的服务可以和为另一个平台编写的应用程序集成。互操作性的关键是请求和响应消息，例如，使用SOAP消息发送，其消息使用 XML 编写代码。 问：请举例说明 SOA 如何使企业受益。 答：关键的优势是互操作性，可以使用任何平台之间的功能，而与编程的语言、操作系统和计算机类型等等无关。在上述示例中，"检查库存"功能可能已经编写为一个应用程序要求的服务，例如，监控库存并在需要时自动重新定购的服务，但我们后来发现，同样的服务无需修改即可用于支持由员工使用的基于 Web 的库存监控工具。 就内部而言，应用程序的重复使用是一项关键优势，因为它可以降低开发成本。服务的重复使用，其长期作用在于减少企业中冗余的功能，简化基础架构，从而降低维护代码的成本。通过按服务的使用者来组织应用程序，与传统的编程技术相比，我们获得一个要灵活敏捷得多的集成模型，使我们可以迅速修改业务流程模型。 就外部而言，为服务交互而详细定义的"合同"使业务合作伙伴之间的交互"自由联合"，提供集成所必需的稳定性，并提供更改基层软件（underlying software）问题的一个解决方案。当保留了相同的消息格式时，支持该格式的软件只要仍然支持消息合同，则可以按需进行更改。只要它支持相同的消息格式，甚至可以使用另一种编程语言的实施来完全替换系统，请求程序无需更改。当消息合同不断发展而必须更改时，与相当困难的任务，即支持多个版本的程序 API 和文件格式相比，它使用版本控制（versioning），更容易作为过渡策略支持多个版本的应用程序。 这些是部分关键益处，还有许多其他益处。 问：SOA与Web服务以及SOA和网格计算之间是何关系。 答：SOA是一种面向业务应用程序系统的体系架构设计风格，但可以应用于其他系统，包括中间件技术，例如网格计算。 Web服务是可以用于创建SOA的一套标准。尽管没有Web服务标准也可能创建SOA（例如，在SOAP之前，人们已经在HTTP或JMS上使用XML来实现相似的结果），但运用Web服务标准却是我们目前针对与外部软件交互的最佳方法。 网格计算是一种系统管理策略，其目标是最大限度地减少硬件资源的使用。例如，当突然的需求溢出指定的服务器时，它可能临时将一些请求转向相对没那么繁忙的服务器。网格计算设计为一种面向服务架构（用于调整网格计算的服务叫做网格服务）。 随着我们转向SOA，我们将看到该方法用于支持各种其他新的系统功能。另外一个示例是自主计算伙子管理系统。事实上，SOA是Web服务高级功能的基础，例如WS-Trust和联合身份识别管理规范。 问：因为还没有通用互操作性标准，SOA最大的问题不仍然是供应商中心性（vendor-centricity）吗？ 答：有一些基本标准正好适用于Web服务，它们可以用于实施面向服务架构。XML和XML方案分别自1998年和2001年就已成为标准。SOAP 1.2自2003年6月成为标准。UDDI在2003年夏天标准化。WS-Security在2004年4月成为标准。 除了著名标准机构（例如W3C和OASIS）支持的这些正式标准以外，许多"技术建议书规范"也被广泛接受，并作为事实标准得到充分支持。例如，直到 W3C完成WSDL 2.0为止，要求在其产品中支持Web服务的大多数供应商都支持WSDL 1.1规范。 事实上，目前大部分软件供应商对Web服务标准的支持，已导致使用Web服务来广泛实施SOA。 问：SOA如何影响SLA？而您如何让SLA适合您的SOA？ 答：当前企业之间的SOA实施通常侧重于改善合作伙伴之间现有业务的效率。同样，性能保证的概念并不是像方便的互操作性和自由联合集成那样的问题，它们可以借助Web服务标准来实现。 当服务成为企业付费的产品时，对特定水平的性能或可用性的保证，以及其它服务质量注意事项具有更为重要的作用。我们可以想象这在将来会成为一个常见要求，正在进行这方面的工作以支持该模型。 问：我如何着手构建 SOA？ 答：最佳的方法时开始构建较小的SOA，侧重于提高当前缺乏效率的交互性。例如，假设使用一个系统上需要重新键入到另一个系统的打印报告，将两个计算机系统紧密联系在一起，这会消耗时间、浪费成本，导致出错，而且数据无法保持罪行。可以设计一个简单的基于Web服务SOA项目，直接链接信息，将含更新的SOAP消息发送到合作伙伴系统，而不是打印报告。 开始简单的SOA使企业可以在作出大投资之前先衡量ROI，并在出现大的问题之前获得小改善的经验。 CIO在购买软件时应该询问供应商关于对Web服务和SOA的支持，作为一个重要的注意事项。应该检查新应用程序的开发，以便考虑是否某些应用程序功能可能需要用于其他目的，以及可以嵌入对Web服务标准的支持以支持重复使用。 最终要完成大规模的企业转型，可能需要通过建立企业服务总线（形成SOA的骨干网或神经系统）来开始该工作。然后以企业合理的节奏，将服务提供商何服务请求程序逐渐添加到ESB。随着IT的SOA的增长，ESB成为在服务水平上连接应用程序，并调节消息流量以提高效率和可靠性的一种有力方式。 问：管理SOA需要哪些新的服务管理技能？ 答：在运用Web服务之前，因缺乏标准和自由联合的策略，合作伙伴整合受到严重限制。随着我们开始使用Web服务和SOA来整合合作伙伴，我们可以发现，使用业务合作伙伴所提供的功能的IT系统已经开始依赖于这些功能的可用性。我们从内部管理我们自己服务的可用性转向要求监视和管理（可能有许多）企业之间的可用性。这明显大大增加了管理IT系统的复杂性，但它也带来了巨大的价值，这就是为什么许多企业要转到这个方向的原因。 Web应用程序系统正在不断发展以支持Web服务标准。"Web服务分布式管理"或WSDM标准正在由OASIS开发，对Web服务管理提供标准化的支持，通过使用Web服务来实现对不同平台的管理，满足涉及独立业务实体的大规模SOA对分布式管理的要求。 发表于 @ 2005年12月09日 1:05 AM | 评论 (0)
摘要：面向服务的体系结构（SOA）表示您可以如何使用 Web 服务的大图景。Web 服务规范定义了实现服务以及与它们的交互所需要的细节。 （全文共3339字）——点击此处阅读全文 发表于 @ 2005年12月09日 1:03 AM | 评论 (0)
摘要：在VC.Net中使用默认设置/clr编译时，一个托管函数会产生两个入口点，一个是托管的，供托管代码调用，另外一个是非托管的，供非托管代码调用。 （全文共1955字）——点击此处阅读全文 发表于 @ 2005年12月07日 11:15 AM | 评论 (0)
摘要：传统的生产模式越来越难以满足飞速增长的软件需求。提高软件生产效率，必须研究软件生产模式。本文对当前提出的新的软件生产模式（MDA、软件工厂）进行了剖析，提出了进行改进软件生产模式实践的要点。 （全文共5648字）——点击此处阅读全文 发表于 @ 2005年12月07日 2:02 AM | 评论 (2)
csdn .net blog 专家群 正确回答此问题说明您对Directory.GetFiles之中的searchPattern的使用有较深的认识。 假定在path之中有且仅有3个文件。其文件名分别是Blog.h, Blog.htm和Blog.html。试试看，您能不能正确得到下面3句指令的输出。 Console.WriteLine(System.IO.Directory.GetFiles(path, "Blog*.h").Length); Console.WriteLine(System.IO.Directory.GetFiles(path, "Blog*.htm").Length); Console.WriteLine(System.IO.Directory.GetFiles(path, "Blog*.html").Length); 在命令行下使用DIR命令可以得到相似的结果。 发表于 @ 2005年11月29日 10:54 AM | 评论 (3)
摘要：无意中发现这么个地方:Ten Essential Tools,上面介绍了十个很好用的插件,以前用过几个,比如:TestDriven.NET,CodeKeep,于是使劲下了下来,但是还有两个找不到下载连接一个是PInvoke.NET 一个是VSMouseBindings,有那位朋友有或知道下载连接的提供一下,谢谢,我把下下来的打了个包,免得后来的朋友一个个找 （全文共6883字）——点击此处阅读全文 发表于 @ 2005年11月29日 10:49 AM | 评论 (7)
转自 dudu blog Windows Workflow Foundation简介(翻译)： Windows Workflow Foundation为开发和执行各种基于工作流的应用程序提供了编程框架和工具。 Windows Workflow Foundation是一个帮助你开发基于Windows平台的工作流解决方案的可扩展的框架。作为将来Microsoft WinFX的一部分，Windows Workflow Foundation提供一组API和工具以支持基于工作流的应用程序的开发和执行。Windows Workflow Foundation为创建跨越不同应用程序的端到端解决方法提供了一个简单、统一的模型。 其他Windows Workflow Foundation相关文章： 发表于 @ 2005年11月29日 10:20 AM | 评论 (0)
摘要：首先，我們開啟VS.NET2005，建立一個新的Sequential WorkFlow專案，並利用WWF提供的Activity，建立如下的流程，分別於DOS模式下輸出"FIRST"及"SECOND"字眼… （全文共1976字）——点击此处阅读全文 发表于 @ 2005年11月29日 10:13 AM | 评论 (0) 面向服务的架构+功能模块的作用---HD(ervice-Oriented Architecture)，即面向服务的架构，这是最近一两年出现在各种技术期刊上最多的词汇了。现在有很多架构设计师和设计开发人员简单的把SOA和 Web Services技术等同起来，认为SOA就是Web Service的一种实现。本质上来说，SOA体现的是一种新的系统架构，SOA的出现，将为整个企业级软件架构设计带来巨大的影响。 1. 什么是架构?什么是基于SOA的架构? 1.1 什么是架构 从架构设计师的角度来看，架构就是一套构建系统的准则。通过这套准则，我们可以把一个复杂的系统划分为一套更简单的子系统的集合，这些子系统之间应该保持相互独立，并与整个系统保持一致。而且每一个子系统还可以继续细分下去，从而构成一个复杂的企业级架构。 当一名架构设计师在构建某个企业级的软件系统时，除了要考虑这个系统的架构以及其应具有的功能行为以外，还要关注整个架构的可用性，性能问题，容错能力，可重用性，安全性，扩展性，可管理维护性，可靠性等各个相关方面。有的时候一名好的架构设计师甚至还需要考虑所构建的系统架构是否合乎美学要求。由此我们可以看到，我们衡量一个好的架构设计并不能只从功能角度出发，还要考虑很多其他的因素，对任何一个方面的欠缺考虑都有可能为整个系统的构建埋下隐患。 1.2 什么是基于SOA的架构 SOA 本身就是一种面向企业级服务的系统架构，简单来说，SOA就是一种进行系统开发的新的体系架构，在基于SOA架构的系统中，具体应用程序的功能是由一些松耦合并且具有统一接口定义方式的组件(也就是service)组合构建起来的。因此，基于SOA的架构也一定是从企业的具体需求开始构建的。但是，SOA 和其它企业架构的不同之处就在于SOA提供的业务灵活性。业务灵活性是指企业能对业务变更快速和有效地进行响应、并且利用业务变更来得到竞争优势的能力。对企业级架构设计师来说，创建一个业务灵活的架构意味着创建一个可以满足当前还未知的业务需求的IT架构。 利用基于SOA的系统构建方法，如图1中所示的一样，一个基于SOA架构的系统中的所有的程序功能都被封装在一些功能模块中，我们就是利用这些已经封装好的功能模块组装构建我们所需要的程序或者系统，而这些功能模块就是SOA架构中的不同的服务(services)。 图1 因此，SOA架构本质上来说体现了一种复合的概念:它不仅为一个企业中商业流程的组织和实现提供了一种指导模式，同时也为具体的底层service开发提供了指导。 2. SOA架构设计师的角色 2.1 SOA架构设计师应该具备什么? 谈到SOA架构设计师的角色，我们首先要了解架构设计师应具有的能力。总体上来说，一个好的架构设计师不仅应该是一个成熟的，具有实际经验的并具有快速学习能力的人，而且他还应该具有良好的管理能力和沟通能力。只有具备了必需的能力，架构设计师才能在关键的时刻作出困难的决定，这就是一名架构设计师应该承担的责任。从角色上来看，SOA 架构师不仅会负责端到端的服务请求者和提供者的设计，并且会负责对系统中非功能服务请求的调研和表述。 对于任何一名经验丰富的架构设计师来说，不论他是采用基于传统的架构设计方法(基于J2EE架构或者.NET架构)还是采用基于SOA的架构设计方法来构建一个企业级的系统架构，具有相关商业领域的知识对于架构设计师来说都是必不可少的，架构设计师往往可以通过实际的工作经验积累以及接受相关的专项培训来获得这些商业领域的知识。除了具有相关商业领域的知识以外，一名合格的架构设计师必须具有较广泛的技术背景，这可能包括软硬件，通信，安全等各个方面的知识。但这并不是意味着要成为一名架构设计师就必须熟悉每一门具体技术的细节，架构设计师必须至少能对各种技术有一个整体上的了解，能够熟知每种技术的特点以及优缺点，只有这样架构设计师才能在特定的应用场景下正确地选择各种技术来设计企业整体架构。 2.2 什么是SOA架构设计师的职责? 那什么是企业级SOA架构设计师的具体角色呢?什么是SOA架构设计师与设计和开发人员之间的差别呢?相信这些都是使大家最容易产生迷惑的问题。举个实际的例子来说，当构建一个基于SOA架构的系统的时候，针对一个具体的 service，系统设计人员主要应该关注的是这个service能够为外部用户提供什么样的服务，也就是说系统设计人员关注的是这个service所提供的功能。而对于SOA架构设计师来说，他们更关心的可能是当有一千个用户同时调用这个 service的时候，什么会发生?也就是说架构设计师关注的应该是一些商业需求和服务级别(service-level)需求。所有的架构设计师的角色都包含了在构建一个系统的一开始就应该尽量减少可能存在的技术风险。而技术风险一般指的是一切未知的、未经证明的或未经测试所带来的风险。这些风险通常与服务级别(service-level)需求相关，偶尔也会与企业具体的业务需求相关。无论是哪种类型的风险，在项目初期设计整体系统架构的过程中更易于发掘这些风险，如果等到架构实施时再发觉这些风险，那么很可能会致使大量的开发人员等在那里，直到这些风险被妥善解决。如果进一步的细化，我们可以看到 SOA架构设计师的主要任务包括对整个系统解决方案轮廓的构建，需求分析，对体系结构的整体决策，相关组件建模，相关操作建模，系统组件的逻辑和物理布局设计。 作为SOA架构设计师必须要能够领导整个开发团队，这样才能保证设计和开发人员是按照构建好的系统架构来开发整个系统的，这一点十分的重要。这就要求一名架构设计师不仅要有很好的技术洞察力，同时还要具有一定的项目管理和项目实施的能力。在系统开发的过程中，架构设计师必须要有良好的沟通和表达能力，这就体现在由架构设计师构建的系统模型是否具有很好的可读性和易理解性。如果由架构设计师构造出的系统模型不是很清晰的话，就可能会影响设计和开发人员对于整个系统架构的理解。为了避免这种情况的出现，定期由架构设计师主持的开发团队内部讨论是十分重要的。 |
||||||||||||||||||||||||||||||||
|
|
