| Profiel van SOA>WorldcupSOA>WorldCupWeblogLijsten |  Extra  Help |
|
26 juni 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架构设计师必须要能够领导整个开发团队，这样才能保证设计和开发人员是按照构建好的系统架构来开发整个系统的，这一点十分的重要。这就要求一名架构设计师不仅要有很好的技术洞察力，同时还要具有一定的项目管理和项目实施的能力。在系统开发的过程中，架构设计师必须要有良好的沟通和表达能力，这就体现在由架构设计师构建的系统模型是否具有很好的可读性和易理解性。如果由架构设计师构造出的系统模型不是很清晰的话，就可能会影响设计和开发人员对于整个系统架构的理解。为了避免这种情况的出现，定期由架构设计师主持的开发团队内部讨论是十分重要的。 重要设计原则 -HD3. 构建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 服务客户提供粗粒度的服务。 13 juni 考完英语了，讨论今天我们小组的三个人终于考完了英语口语和听力，算是减轻一门负担吧，大家要努力了！！！
昨天我们按照17号ibm讲座上的步骤再次审视了我们的业务流，发现划分不详细，以至于上次没能很好地提取服务，这次我们按照服务建模的过程又走了以便，发现容易多了。不过真的体会到自顶向下及自底向上双向建模的流程了。 09 juni 会议总结－－－孟彦今天讨论了一下总体框架，并且进一步划分服务，在这个过程中，大家多服务层和组件层的界定有些迷惑，毕竟没做过多服务的系统，大家还很难分析得清楚，再意见不一致得情况下，决定每人设计一个自己认为合理的框架，过两天一起讨论。 08 juni 讨论总结－－孟彦今天又进行了一次会议，成果是讨论出了最终的业务流，并且从中发现了服务模块，不过还要进一步细化。现在感觉已经没时间让大家细细品味了，只能集体力量大了，不过感觉整体是大于局部之和的，之前每个人的不解，到了一起就迎刃而解了，不过这也是没办法的办法，要是像其他组那样早些开始，现在也能精益求精了，不过我们决不是不负责任的，每个组员都有信心做到最好，加油！
最近天气热，考试逼近，大家一定要坚持到最后～～～～！ 值得提倡的几点－－孟彦1. 会议. 相对于别的小组，我们是刚上研一的，没有接触过商业项目的学生，自然个人能力方面都不太理想，但是像前几次会议的讨论方式，通过互相讲解和idea的讨论，我们还是能学习到不少东西，并且确定出解决方案。四个脑袋当一个使。
2. 项目管理，这次大赛之所以要把大家按小组分配，并且建议管理学专业的人做项目负责人，我想可能是希望在大学里能多出一些有team work 能力的人才，而不是自身研究的“学究”。通过我对这次大赛所提供的资料及其他团队的blog，我根据我知道的实在是太少了，所以作为负责人，我想如果完整地进行项目的一个个步骤的开发，恐怕会不太适合，还是采用“迭代”的开发方式比较好，:-P
3. 设计问题. 对于咱们时间紧任务重的这种情况，我想设计方案就不能像其他小组那样广而全了。采用最适合凤凰公司需求的设计方案才是最好的，毕竟对于企业来说，它没时间等待it部门或it产品提供者来为它设计经久不衰的系统，而是要立杆见影的，所以我们在设计上也应该考虑到这一点，随需应变是必须做到的，但可以把一些暂时效益不大的服务只是做一些畅想，并留下扩展余地。 咱们这个小组所面临的问题1. 4名组员都没有大型项目的经验，虽然都对软件体系结构有所了解，但只是停留在初级，这就使得咱们小组在架构设计上显得幼稚些。
2. 开始的时间晚，为了能尽快进入设计阶段，从五月底到前两天都在进行知识的充实，看看其他小组的blog，人家早就开始设计了，并且干劲十足。咱们的设计如何要成熟的话就必须再业务和功能方面进一步分析。咱们没有大型项目经验只能构按照老师讲的方法进行分析设计了。
3. 现在面临的最紧迫的问题是多门期末考试，大家都希望能把大赛比好，对得起ibm为我们提供的机会；也希望能把考试弄好，毕竟研一的学生考试是最大的问题，而且是不能调配的。
4. 世界杯来临，大家都有些小兴趣要满足，但这对项目的完成带来了不便，大家看来要忍痛割爱了，毕竟咱们的队名是soa>worldcup。不过我会尽量让大家即比好赛，又考好试，还要娱乐一下。似乎真的很难哦。
阶段总结－－孟彦昨天，刚刚进行完小组讨论会议，韩丹和李萌准备的不错，对于开始分配给她们的业务流程及需求扩展方面的研究搞的不错。另外昨天会议因为实验室关门而不得不中止了，今天下午继续，争取能把咱们的功能划分搞清楚，目标系统的雏型描绘出来。
06 juni 诚邀参加IBM技术讲座－6月14号开源技术和6月17号SOA技术--carol技术讲座详情如下： 1)IBM 免费社区版软件 - 以零成本开始您的随需应变业务 通过此次讲座，您将了解到IBM 对于WAS CE 产品的市场定位和策略，以及可供客户选择的技术支持方案。还将介绍WAS CE 的产品特性和系统架构，并详细阐述WAS CE 服务器管理的基本知识。 会议日程安排: 13:00 - 14:00 会议签到 14:00 – 14:20 会议致词 14:20 – 14:30 Apache Geronimo和WAS CE介绍 14:30 – 14:40 WAS CE架构简介 14:40 – 15:20 WAS CE服务器管理 15:20 – 15:35 休息 15:35 – 16:15 WAS CE应用程序部署和开发环境 16:15 – 17:00 自由工作在红旗Linux工作站 时间及地点： 日期 城市 时间 酒店 地址 会议室 2006-6-14 北京 14:00 - 17:00 京广新世界饭店 朝阳区呼家楼 3层1号大宴会厅 2)创新业务,拓展商机 - 为您打下坚实的SOA基础 通过现场演示和技术讨论，您将了解到 IBM WebSphere优于其他供应厂商的解决方案,以及如何更好地实现面向服务的架构。您还将了解到如何提高您当前的业务流程的速度、准确性和成本效益。同时,您将了解 IBM WebSphere 信息管理解决方案是如何支持提供准确的、一致的、及时而连贯的业务信息。在讲座中，我们还将讨论主数据管理，并说明如何对通常分散在整个企业范围内的产品、位置、贸易合作伙伴、组织和贸易条款信息等数据进行链接。最后，您将了解到可用于构建、部署、运行和管理的 IBM WebSphere 应用程序的各种工具。 会议日程安排： 08:00 – 09:00 会议签到 09:00 – 09:30 简介——通过 SOA 进行创新 09:30 – 10:30 使用 SOA 创建新的业务流程 10:30 – 10:45 业务现状如何？——企业现状概况 10:45 – 11:00 休息 11:00 – 11:30 使用 WebSphere 的企业服务总线 11:30 – 12:00 使用 WebSphere 进行主数据管理 12:00 – 13:00 午餐 13:00 – 14:10 信息集成服务 14:10 – 15:00 开发新的服务 15:00 – 15:15 休息 15:15 – 16:10 WebSphere SOA Foundation——为何 IBM 软件优于 NetWeaver 和 .NET 16:10 – 17:00 管理 SOA 环境 17:00 – 17:15 总结 时间及地点： 日期 时间 城市 酒店 地址 会议室 6月17日 09:00 - 17:15 北京 亮马河大厦 朝阳区东三环北路8号 万黛厅 一些可以借鉴的解决方案 左边的那个制造业比较适合我们。 02 juni ERP一、ERP系统的管理思想 ERP的核心管理思想就是实现对整个供应链的有效管理，主要体现在以下三个方面： 1、体现对整个供应链资源进行管理的思想 在知识经济时代仅靠自己企业的资源不可能有效地参与市场竞争，还必须把经营过程中的有关各方如供应商、制造工厂、分销网络、客户等纳入一个紧密的供应链中，才能有效地安排企业的产、供、销活动，满足企业利用全社会一切市场资源快速高效地进行生产经营的需求，以期进一步提高效率和在市场上获得竞争优势。换句话说，现代企业竞争不是单一企业与单一企业间的竞争，而是一个企业供应链与另一个企业供应链之间的竞争。ERP系统实现了对整个企业供应链的管理，适应了企业在知识经济时代市场竞争的需要。 2、体现精益生产、同步工程和敏捷制造的思想 ERP系统支持对混合型生产方式的管理，其管理思想表现在两个方面：其一是“精益生产LP（Lean Production）”的思想，它是由美国麻省理工学院（MIT）提出的一种企业经营战略体系。即企业按大批量生产方式组织生产时，把客户、销售代理商、供应商、协作单位纳入生产体系，企业同其销售代理、客户和供应商的关系，已不再简单地是业务往来关系，而是利益共享的合作伙伴关系，这种合作伙伴关系组成了一个企业的供应链，这即是精益生产的核心思想。其二是“敏捷制造（Agile Manufacturing）”的思想。当市场发生变化，企业遇有特定的市场和产品需求时，企业的基本合作伙伴不一定能满足新产品开发生产的要求，这时，企业会组织一个由特定的供应商和销售渠道组成的短期或一次性供应链，形成“虚拟工厂”，把供应和协作单位看成是企业的一个组成部分，运用“同步工程（SE）”，组织生产，用最短的时间将新产品打入市场，时刻保持产品的高质量、多样化和灵活性，这即是“敏捷制造”的核心思想。 3、体现事先计划与事中控制的思想 ERP系统中的计划体系主要包括：主生产计划、物料需求计划、能力计划、采购计划、销售执行计划、利润计划、财务预算和人力资源计划等，而且这些计划功能与价值控制功能已完全集成到整个供应链系统中。 另一方面，ERP系统通过定义事务处理（Transaction）相关的会计核算科目与核算方式，以便在事务处理发生的同时自动生成会计核算分录，保证了资金流与物流的同步记录和数据的一致性。从而实现了根据财务资金现状，可以追溯资金的来龙去脉，并进一步追溯所发生的相关业务活动，改变了资金信息滞后于物料信息的状况，便于实现事中控制和实时做出决策。 此外，计划、事务处理、控制与决策功能都在整个供应链的业务处理流程中实现，要求在每个流程业务处理过程中最大限度地发挥每个人的工作潜能与责任心，流程与流程之间则强调人与人之间的合作精神，以便在有机组织中充分发挥每个的主观能动性与潜能。实现企业管理从“高耸式”组织结构向“扁平式”组织机构的转变，提高企业对市场动态变化的响应速度。 总之，借助IT技术的飞速发展与应用，ERP系统得以将很多先进的管理思想变成现实中可实施应用的计算机软件系统。 二、应用ERP与企业的关系 ERP是借用一种新的管理模式来改造原企业旧的管理模式，是先进的、行之有效的管理思想和方法。ERP软件在实际的推广应用中，其应用深度和广度都不到位，多数企业的效果不显著，没有引起企业决策者的震动和人们的广泛关注。 1．实施ERP是企业管理全方位的变革 企业领导层应该首先是受教育者，其次才是现代管理理论的贯彻者和实施者，规范企业管理及其有关环节，使之成为领导者、管理层及员工自觉的行动，使现代管理意识扎根于企业中，成为企业文化的一部分。国外企业实施ERP 似乎没有讨论的余地，全盘接受，自觉性强。其实，办企业这样做是天经地义的，而我们还要等待思想提高，观念更新，有时还要避开锋芒，迁就陈腐，互相推诿。如果我们不坚决向这些陋习告别，这场全方位的变革就会反复、甚至夭折。 2．企业管理班子要取得共识 要眼睛向内，练好内功，做好管理的基础工作，这是任何再好的应用软件和软件供应商都无法提供的，只能靠自己勤勤恳恳地耕耘。把ERP的实施称为"第一把手工程"，这说明了企业的决策者在ERP实施过程中的特殊作用。ERP是一个管理系统，牵动全局，没有第一把手的参与和授权，很难调动全局。 3．ERP的投入是一个系统工程 ERP的投入和产出与其他固定资产设备的投入和产出比较，并不那么直观、浅显和明了，投入不可能马上得到回报，见到效益。ERP的投入是一个系统工程，并不能立竿见影，它所贯彻的主要是管理思想，这是企业管理中的一条红线。它长期起作用、创效益，在不断深化中向管理要效益。 此外，实施ERP还要因地制宜，因企业而别，具体问题具体分析。首先，要根据企业的具体需求上相应的系统，而不是笼统地都上小型机，或者不顾企业的规模上 WindowsNT，这样长期运作，对企业危害性极大。其次，这种投入不是一劳永逸的，由于技术的发展很快，随着工作的深入，企业会越来越感到资源的紧缺，因此，每年应有相应的投入，才能保证系统健康地运转。 4．ERP的实施需要复合型人才 他们既要懂计算机技术，又要懂管理。当前高校对复合型人才的培养远远满足不了企业的需求。复合型人才的培养需要有一个过程和一定的时间，但企业领导者常把这样不多的人才当作一般管理者，没有把他们当作是企业来之不易的财富，是一支重要的队伍。这与长期忽视管理有关，这些复合型人才在企业中的地位远远不及市场开拓人员和产品开发者，而是"辅助"角色，不是政策倾斜对象，这种因素是造成人才流失的重要原因。另外，当企业上ERP时，这些复合型人才起到了先导作用，而一旦管理进入常规，他们似乎又成为多余的人，这已成为必然规律。在人才市场上，复合型人才最为活跃，那些有眼力的企业家都会下功夫挖掘人才，而这也不利于实施队伍的稳定。 总之，条件具备的企业要不失时机地上ERP管理系统，不能只搞纯理论研究、再研究，长时间地考察。要首先整理好内部管理基本数据，选定或开发适合自己企业的ERP软件，条件成熟了就上。 如何实施CRM 系统 在信息系统的实施方面，国内的软件商、咨询公司已经有了大量的实践经验。CRM 的实施虽然在国内刚刚起步，但它的实施方法、步骤符合信息系统的一般规律，如ERP 的实施和应用的经验就可以为CRM 借鉴。我们为CRM 的实施设计了几个基本组成部分：
（一）经营理念的形成 因为CRM 系统首先是一个经营理念的形成过程，同其它大的系统一样，CRM 系统涉及到公司内很多业务领域，如销售、营销、客户服务、财务、分销等，它的实现离不开工作岗位上的员工的支持、推动、努力和合作。获得公司范围的支持包括：从上到下的承诺，从下到上地获得系统用户的支持；能全心全力投入系统的实施的项目小组；在整个企业中贯彻以客户为中心的经营理念，将客户就是上帝的思想真正灌注到企业的员工中去。 （二） 成立项目小组 一旦获得了公司内上下的支持，就可以从各部门选择适当的人员组成CRM 小组。项目小组是CRM 系统实施的原动力，他们要就CRM 的实施做出各种决策，给出建议，就CRM 的细节和带来的好处与整个公司的员工进行沟通。一般来讲，项目小组应该包括高层领导、销售和营销部门的人员、IT 部门的人员、财务人员，还要包括所有的最终用户的代言人。
（三） 业务需求分析 业务需求分析阶段是实施CRM 系统的关键，在业务需求分析阶段，药筒销售、营销和客户服务经理就CRM 系统的要求和策略进行讨论，最终达成对理想中的CRM 系统的一致看法。这样做的目的是充分地识别每个部门对CRM 的期望，并把各个部门的需求和信息整合起来，形成关于理想的CRM 方案的总的看法。通过CRM 调查和业务分析，可以发现是哪些业务领域最需要自动化，哪些领域需要业务流程的改善， 在选择CRM 解决方案时应该考虑哪些技术特点。 （四）CRM 实施与行动 为了把CRM 从理想变成现实，必须有实施和行动计划；具体应考虑以下几点： 确定适合于本公司的CRM 解决方案。目前，CRM 解决方案非常的多，但是应结合本公司的实际情况来确定；CRM 行业有很多专业的咨询人员和研究人员，他们的主要工作就是研究和评价各种CRM 方案，可以提供对市面上主要的CRM 解决方案的系统支持。CRM 软件选型应用CRM 系统的目标是支持和推动优化过的销售、营销和客户服务流程，这意味着软件的选择应该建立在现有的IT 技术和业务要求的基础之上。主流的软件一般提供下列功能： 联系人和客户管理 销售管理 电话营销和电话销售 客户服务 营销 商业智能 潜在客户管理 电子商务 系统的实施阶段 项目是实施阶段是将需求分析转变成为现实系统的过程，有效的实施管理是项目成功的基础： 项目的计划和管理 系统配置和客户化 测试和试运行 最终实现和项目的铺开对系统运行的支持最后，CRM 系统也要向领导小组和项目组提供反馈，如哪些功能运行良好、哪些功能难以驾驭，可以采用哪些措施来充分利用现有的技术投资。 （五）相关的技术知识需求 数据仓库(DataWareHouse) 数据挖掘（Data Mining） 什么是CRM？ 摘自http://www3.it168.com/solution/20040921/200409215271.pdf，详细信息可以参考此网址
CRM（Customer Relationship Management）就是在企业文化同业务系统结合的同时，形成的以客户为中心的经营理念；CRM 是一种旨在改善企业与客户之间关系的新型管理机制，它主要实施于企业的市场营销、销售、服务与技术支持等与客户相关的领域，使客户时时感觉到企业的存在，企业随时了解到客户的变化。这种思想将推动企业最大限度的利用其与客户有关的资源，实现企业从市场营销到销售到最后的服务和技术支持的交差立体管理。CRM 的目标是一方面通过提供更快速、周到和准确的优质服务吸引和保持更多的客户，达到个性化的服务；另一方面通过对业务流程的全面管理来降低企业的成本。CRM 既是一种理念，也是一套管理软件和技术。
如果把ＥＲＰ比做企业练好内功，ＳＣＭ比做管道，那么CRM 就是企业从以产品为中心逐步转向以客户为中心的外功了。
CRM 作为一种软件系统它与ERP 软件不一样，它广泛实施与企业的市场营销(Marketing)、销售(Sales)、服务与技术支持(Service)等与客户有关系的办公领域，我们把这种办公领域叫做企业的前端办公领域(FrontOffice)。在CRM 软件系统中，以客户作为系统组织的主线。
良好的CRM 可以提高用户的忠诚度、改进信息提交方式、加快信息提交速度和简化客户服务过程。在提高用户忠诚度方面，CRM 不仅可使企业更好地挽留现存的客户，而且还可使企业找回已经失去的客户。例如，全球最大、访问人数最多的网上书店---亚马逊公司，面对其越来越多的竞争者能够保持长盛不衰的法宝之一就是CRM。当您在亚马逊购买图书以后，其销售系统会记录下您购买和浏览过的书目，当您再次进入该书店时，系统识别出您的身份后就会根据您的喜好推荐有关书目。显然这种有针对性的服务对维持客户的忠诚度有极大帮助。据悉，CRM 在亚马逊书店的成功事实给它赢得了65%的回头客。
CRM 是一座桥梁，架起了企业和客户之间的纽带，为企业带来了利润和更大的上升空间；同时为客户带来了上帝般的感受，您就会感到企业好象是仅仅为您自己服务似的；从而达到了"双赢"。 WebSphere Live大会，有空去参加吧--carol一年一度的WebSphere Live!大会将在6月6日于北京五洲皇冠假日酒店开展，现场介绍IBM对SOA的最新阐述，以及WebSphere产品亮相、解决方案纵览、SOA开发实践。欢迎北京地区所有报名参加本次SOA大赛的参赛团队参加。 参会注册网址： http://www-900.ibm.com/cn/software/websphere/events/wslive2006/index.shtml 会议议程（以当天安排为准）： 6月6日 北京五洲皇冠假日酒店二层宴会厅 地址：北京市朝阳区北四环中路8号 电话：010-84982288 当日议程 主会场 08:45 - 09:00 注册 09:00 - 09:15 欢迎致词 李永财 09:15 - 10:30 切入 SOA ： WebSphere 引领创新之路 Dan Power 10:30 - 11:00 动态企业还有多远? – SOA 助力业务创新 万宁 11:00 - 12:00 利用 WebSphere 建立的 SOA 架构高效能系统助力 eBay 实现高效创新 叶萌 12:00-12:10 SOA 问答 12:10 - 13:30 午餐及合作伙伴演示 分会场一：技术与创新 13:30 - 14:15 使用 J2EE 技术开发核心业务系统 李珂嘉 14:15 - 15:00 DataPower 高效、安全应用的最佳伴侣 崔鹏 15:00 - 15:15 茶歇及合作伙伴演示 15:15 - 16:00 WebSphere Process Server 实现随需应变的业务流程 方国伟 16:00 - 16:30 WebShpere ESB 帮您打造企业级服务总线 张诚 16:30 - 17:00 PM4Data 分步式应用中的信息交换 顾冉 17:00 - 17:10 SOA 问答 分会场二：实施与落地 13:30 - 14:15 如何构建 SOA 的企业IT 模型 －从实例出发，企业如何实现SOA 金戈 14:15 - 15:00 15:00 - 15:15 茶歇及合作伙伴演示 15:15 - 16:00 同 IBM 合作， 构建 SOA 应用 －展示 IBM 成熟的技术、产品、服务对企业实施 SOA 的强大支持 姚辉 16:00 - 16:45 SOA 业务流程应用的成功案例演示：中远集装箱运输有限公司 卜冠英 16:45 - 16:55 SOA 问答 分会场三：行业解决方案 13:30 - 14:15 切入SOA ：WebSphere 电子政务创新解决方案介绍 寇卫东 14:15 - 15:00 SOA 实践：山西移动 SOA 整合之道 15:00 - 15:15 茶歇及合作伙伴演示 15:15 - 16:00 基于 WebSphere 的信息交换平台：中国人民银行的国库联网系统 李徽翡 唐彬 16:00 - 16:30 WebSphere 合作伙伴网关：供应链管理最佳实践 李东 16:30 - 17:00 Workplace 整合工作环境与 SOA 关系 陆晓鹏 17:00 - 17:10 SOA 问答 29 mei 参考的网站--carol我看到另外几个参加soa大赛的blog，大家可以看看其它小组的进度，对我们也是一种鞭策阿。
ComityHit 哈尔滨工业大学 http://www.blogjava.net/team/comityhit.html
北京北大方正软件技术学院 http://www.blogcn.com/u/63/62/pfcglilac/index.html
AccelerateSOA 上海交通大学 http://sparkle.blog.xdnice.com
下面是清华bbs的链接，都是讨论这个问题的，还有最新的报名情况，不知道那天我发的报名邮件大家都收到没有，我怕附件太大发不出去，查了一下最新的报名统计上面没有我们组阿，可是我也没有收到任何失败的邮件通知，非常奇怪阿，在网站上面报名也是写了successfully，总是担心ing.
还有，以后如果大家添加项的时候，最好把自己的名字写在后面，否则就不知道是谁写的了：）
实在很担心报名的问题，今天又发了一次报名的文件，也同时cc给每个人了，如果你们收到的话请尽快告诉我，之前的那封似乎没有人收到：（ |
|||||||||||||||||||||||||||||
|
|
