BPM术语解释.docx

BPM中的IT术语解释目录BPM业务流程管理2工作流引擎6PORTAL（WEB应用）9企业门户10SOA面向服务的体系结构10EAI企业应用集成16ESB企业服务总线18EIP企业信息门户19SAAS软件在线服务20ASP应用软体租赁服务提供者28WEBSERVICE29MRP物料需求计划32MRPII制造资源计划35MRPIII、ERP和CIMS37ERP企业资源计划系统38BOM表45OA办公软件49CRM客户关系管理57PDM产品数据管理61PLM产品生命周期管理62PLM的发展历史以及与PDM的关系62CAM计算机辅助制造64CAD计算机辅助设计65ECM企业内容管理系统66SCM 供应链管理66HRIS人力资源信息系统69EHR70E-HR、HRIS、HRMS的含义是什么72BPM业务流程管理Business Process Management(BPM)，即业务流程管理，是一套达成企业各种业务环节整合的全面管理模式。BPM涵盖了人员、设备、桌面应用系统、企业级 Backoffice 应用等内容的优化组合，从而实现跨应用、跨部门、跨合作伙伴与客户的企业运作。 BPM通常以Internet方式实现信息传递、数据同步、业务监控和企业业务流程的持续升级优化。显而易见，BPM不但涵盖了传统“工作流”的流程传递、流程监控的范畴，而且突破了传统“工作流”技术的瓶颈。BPM的推出，是工作流技术和企业管理理念的一次划时代飞跃。 业务流程管理的优势1. 节省时间与金钱BPM是提供业务流程建模、自动化、管理与优化的准则与方法。一个成功的BPM方案包括正确商业领导和技术的组合，可以大幅缩短流程周期（有时高达90%）和降低成本。这种效果在跨部门、跨系统和用户的流程中尤为突出。从技术的角度看，一个独立的BPM系统能够轻易地与现有的应用软件如CRM、ERP和ECM相集成，而无需重新设计整个系统。2. 改善工作质量除了节省时间和成本的优点外，已经实施BPM 的企业也发现了其它几项关键优点。首先，可以大幅降低甚至消除造成企业损失的错误，如丢失表格和文件或错误存档、遗漏重要信息或必要审查。其次，显著改善流程的可视化程度，所有参与流程者不仅被授权了解自己在流程中的角色，而且确切地了解流程在任何时候的状态。第三，有了可视化，也就明确了职责，所有人都完全清楚地知道什么时候应当完成哪些工作。不再有借口造成延误、误会或疏忽。最后，可提高一致性，公司内部和外部各方对工作都有明确的期望。结果使得员工、客户和合作伙伴都有了更高的满意度和向心力。3. 固化企业流程只要不是单个人独立完成全部工作的个人作坊性质，企业从它的诞生起，就存在着流程，并且随着企业的不断成长，其流程越来越多，越来越复杂。几乎每个企业都针对各类业务流程和事务流程有一套规章制度，随着管理的细化和规范化，企业的规章制度是越来越厚，而执行这些规章制度的人却越来越坠入谜团中。可想而知，这些影响着企业生命的核心流程的执行效果会怎样了。有些企业已经认识到了这点，甚至花巨资请专业的咨询公司来重新肃清流程、规划流程，但很多企业中由于人的原因，如碍于情面、越级审批、不照章办事等，而造成应用的失败。企业业务流程管理系统就能在应用的初期阶段达到这样的首要应用目标，通过系统固化流程，把企业的关键流程导入系统，由系统定义流程的流转规则，并且可以由系统记录及控制工作时间，满足企业的管理需求及服务质量的要求，真正达到规范化管理的实质操作阶段。4. 实现流程自动化有人做过一个行为分析，发现一个流程的处理时间中90%是停滞时间，真正有效的处理时间很短。并且在流程处理过程中需要人员去用“腿”、用“电话”等其他手段去推进，不仅耗时耗力，而且效果差，时时有跟单失踪或石沉大海的情况发生。通过业务流程管理系统，利用现有的成熟技术、计算机的良好特性，很好地完成企业对这方面的需求，信息只有唯一录入口，系统按照企业需要定义流转规则，流程自动流转，成为企业业务流程处理的一个“不知疲倦”的帮手。5. 实现团队合作传统的职能式企业组织架构，自有它的应用范围和优势，但我们发现企业的很多流程不仅仅靠一个部门来完成，更多的是企业部门间的协同合作，特别是有些企业还存在着跨地域的合作，如采购流程，它涉及到生产部门、采购部门、库管部门、财务部门、商务部门、合同签署中的法律部门以及企业的高层管理部门。如果我们还以传统的职能部门的思维考虑流程，就可能患“近视眼”、注重部门利益忽视企业利益、重视部门上司的感觉忽视实效，并且还容易导致部门之间权责不清的灰色地带。而作为企业的业务流程存在着各业务部门的天然联系，其流畅的业务处理是需要各部门以企业的利益为最高利益，协同工作。业务流程管理系统以流程处理为面向，自动地串起各部门，即利用现在先进的互联网技术串起各地域，达到业务流程良好完成的目的，并且企业的很多高管人员的意识已远远超出一套业务流程管理系统，更多的希望凭借这样的系统，形成企业协同工作的团队意识，配合完成自己的企业文化。6. 优化流程流程在制定出来以后，没有人能保证这样的流程就是合理科学有效的，即使是当时合理科学有效的系统，由于我们身处的市场环境的变化、组织结构的随之变化、营销服务策略的随之变化，很难说能继续保持这种优势。一套好的业务流程管理系统不仅仅可以具备以上的诸多好处，而且随着流程的执行流转，系统能够以数据、直观的图形报表报告哪些流程制定得好，哪些流程需要改善，以便提供给决策者科学合理决策的依据，而不是单靠经验，从而达到不断优化的目的，呈螺旋式上升的趋势。7. 向知识型企业转变企业老板经常环顾员工下班后空荡荡的办公室，问自己我的企业还剩下什么，还值多少钱。而业务流程管理系统通过固化流程，让那些随着流程流动的知识固化在企业里，并且可以随着流程的不断执行和优化，形成企业自己的知识库，且这样的知识库越来越全面和深入，让企业向“有生命会呼吸”的知识型和学习型企业转变。如一个新进入公司的员工，他能够通过企业业务流程管理系统很快地熟悉企业及企业的业务处理，并且可以通过流程固化形成的知识库不断充实自己及提高处理流程的难度和水平。所谓BPM(Business Process Management), 即业务流程管理，是指根据业务环境的变化，推进人与人之间、人与系统之间以及系统与系统之间的整合及调整的经营方法与解决方案的IT工具。业务流程管理应该包括建模-实施-监控-管理等过程，要具备其所需的所有服务与工具才能叫作BPM。现在的信息系统开发方式的缺点在于对需求表达不清晰、效率不高。在这种思维方式下流程被固化在系统中，企业不能随着商业环境的变化而方便迅速地改变业务流程，而企业环境的变化促使企业必须快速地调整业务来响应。实时性企业将敏捷地使用最新信息，以积极地消除其关键性业务流程中的管理与执行层面出现的低效率延迟。BPM的出现正是为了解决企业流程实时改变所带来的敏捷性、实时效果评估、资源整合与优化等问题，而这些问题是不能为传统的OA和工作流所解决的。通过BPM，可以对业务流程进行自动化,并通过流程的分析及监控功能,对业务进行整合及计量,从业务角度、组织角度、IT角度都可得到可量化的改善效果，这种效果随着管理者通过BPM分析与优化流程，将越来越显著。研究表明，未来2年与J2EE平台结合紧密的BPM产品将占据主导地位。2、BPM的边界界定 BPM的目标是实现企业管理的有序化和企业运营的增值,在我看来,BPM包括如下内容:1)BPA(业务流程自动化)通常人们将流程的真正执行部件称为工作流系统，直到今天，传统的工作流系统仍然在BPM系统中扮演着中心角色,正是它实现了业务流程的自动化,BPA包括如下内容:a)流程建模技术 如Petri网、控制流语义、数据流图、UML中的序列图、协作图、状态转换图等b)流程定义技术 如XPDL,BPEL4WS等c)流程执行引擎 如我们谈过的jbpm,shark等2)BPI(业务流程集成)BPI（业务流程集成）系统是实现流程集成技术的具体载体,是它把我们的软件开发方式由面向过程、面向对象和面向构件等转变为面向服务,BPI包括如下内容:a)流程间通信技术 以前可以采用的有远程过程调用（RPC）、分布式对象（CORBA、DCOM/COM+、RMI）、面向消息的中间件（MOM）等,现在可以选用基于Web服务的动态、轻量级的服务协作中间件（Service Cooperation Middleware，SCM）b)EAI技术 主要实现企业内部的应用集成c)B2B技术 主要实现合作伙伴间的应用集成3)BPR(业务流程改进)BPM以优化管理为归宿，而不仅仅满足于业务的处理;BPR包括下面的内容:a)流程监控与分析b)流程优化c)流程改进3、 选择BPM系统 必须考虑建立BPM团队 BPM 众多成功的关键因素在于能组成执行团队，同时进行企业流程的设计、建置、模块化、优化及部署。有效率的 BPM 执行团队成员来自组织内各部门，分别都是在成功推动项目上，扮演着重要的角色。而影响 BPM 解决方案的重要因素在于：提供团队成员正确的工具组合，让他们的工作既简单又有效率。典型的执行团队成员包含：流程拥有者 即利用工作流程，以便更有效率执行工作职责的人。他们对工作流程感兴趣，但并不注重所使用的工具。他们只想改善流程并证实其效果，可说是联系 BPM 团队与工作流程实际需求间的重要环节。企业主可从图形流程设计工具获益良多，这套简单的工具可帮助他们发展最初始的详细的流程图，与分析师紧密合作。完成部署之后，流程拥有者可重新检讨该流程相关的报告，并对工作流程提出改进的建议。总而言之，流程拥有者拥有工作流程、重视结果，但不想花心思在相关技术面上。 业务流程分析师业务流程分析师是执行团队的重要成员，也是流程设计的专家。他在执行团队中并非软件开发者，因此使用的工具必须是直觉式操作，或具备基本、甚至毋需具备程序设计的专门知识。分析师需要整合的环境来进行下列事项： 勾勒或规划工作流程； 定义必须由自动化流程处里的特定情况及例外事项； 模块化流程，以工作周期展开前测试并界定潜在问题； 了解组织架构及从属关系； 提供团队成员、使用者及新进员工所属工作流程的各式文件； 在工作流程开始运行之后分析其产生的结果；以及 持续进行工作流程的改善。 IT 设计师他们与流程分析师紧密合作，建立自动化流程。IT 设计师最了解 IT 环境的功能架构，但他们不是程序设计师，他们须具备下列能力，进行相关事项： 轻易存取流程设计师建立的工作流程及流程的文件 (直接让他们分享分析师权限更佳)； 设计表单或使用现有电子表单，及定义表单的数据项，但不需专精于数据库设计； 设计工作流程路径的规则及异常情况的处理，但不需撰写程序； 与目录、其它应用程序、Web Services及数据库进行整合；以及在工作流程正式上线前，先行测试及模拟。为使流程获致最佳性能及灵活度，任何 BPM 解决方案皆应是 IT 设计师及分析师的工作目标及责任，而不是开发人员。 软件开发人员他们在 BPM 团队中扮演着重要角色，但是，除非整合情况复杂，或有其它必须透过程序解决的问题，否则不一定需要开发人员。需要开发人员时，他们需要相关工具进行下列事项： 在检视流程内容后，使用他们了解且惯用的开发工具； 开发程序代码及模块，方便日后只须简单使用 XML、Web Services或其它标准方法，就能呼叫表单或工作流程；以及轻而易举就能在 BPM 应用程序及 ERP、CRM与其它功能所用的后台系统之间建立数据交换。 我再重复一个重点，软件开发人员应对 BPM 具贡献，但不是实施流程管理的主要焦点。唯一例外的情况是，若整个工作流程是企业应用程序整合 (EAI) 所带动，而不需太多、甚至不需人力的投入及具有高复杂度的整合。 IT 管理人员 只要 BPM 系统开始执行，他们在维护管理上，就扮演着举足轻重的角色。他们需要能在其它管理控制环境下使用的工具，来进行下列事项： 监督系统的执行性能； 设定服务器环境； 管理磁盘空间及数据库使用情形； 授权企业使用者更多的流程行政管理责任； 分析日志文件；以及建立系统使用率及使用者作业的报表。 总结在选择并执行 BPM 系统时，您无疑必须考虑 BPM 团队。藉由结合团队能力及界定完整 BPM 系统的必备要素，您即可以部署符合所有使用者需求的解决方案、实现符合预期的投资报酬率 (ROI)，并为企业创造其它无形的利益。工作流引擎什么是工作流引擎（Workflow Engine ）所谓工作流引擎是指workflow作为应用系统的一部分，并为之提供对各应用系统有决定作用的根据角色、分工和条件的不同决定信息传递路由、内容等级等核心解决方案。例如开发一个系统最关键的部分不是系统的界面，也不是和数据库之间的信息交换，而是如何根据业务逻辑开发出符合实际需要的程序逻辑并确保其稳定性、易维护性（模块化和结构化）和弹性（容易根据实际业务逻辑的变化作出程序上的变动，例如决策权的改变、组织结构的变动和由于业务方向的变化产生的全新业务逻辑等等）。 Workflow 引擎解决的就是这个问题：如果应用程序缺乏强大的逻辑层，势必变得容易出错（信息的路由错误、死循环等等）。 就好比一辆汽车，外表做得再漂亮，如果发动机有问题就只是一个摆设。应用系统的弹性就好比引擎转速方面的性能，加速到100 公里需要1 个小时（业务流程发生变动需要进行半年的程序修改）还能叫好车吗？引擎动不动就熄火（程序因为逻辑的问题陷入死循环）的车还敢开吗？ 工作流解决方案与传统管理软件的关系传统的管理软件注重解决企业应用层现存的问题（例如提高企业的资源配置率或提高单一员工的生产效率）。例如：EXCEL 可以提高员工画表格的效率、财务软件可以规范财务人员的工作并提高账目查询的效率、CRM 可以规范客户管理从而使客户资源掌握在公司手中而不是被一部分业务人员把持并提高客户响应时间、ERP 解决的是如何配置企业资源：使企业的人力资源、财力资源和物资资源能够根据业务的需求实现最大化配置。 workflow 关注的是如何缩短流程闲置时间，从而提高企业的业务处理能力并使企业能够关注于真正对企业有意义的增值业务上。从建立企业神经系统的角度也许更能理解两者的区别。传统软件不能解决工作流的问题，例如ERP 关注的是企业的资源配置，但不可能解决资源传输过程中的损耗和降低传输（流程）的成本；同样workflow也不能完全解决传统管理软件所能解决的问题，例如对生产管理的MRP 系统所能解决的生产过程控制通过workflow很难实现。但一个好的传统软件如果希望能自动化地在整个企业中应用起来，必须有一个强大的逻辑层，用以解决信息传递的逻辑判断和自动流转，这个时候就需要workflow的平台。所以说： 1.workflow 和传统管理软件不是同一种软件，不具可比性； 2.workflow 对于已经有传统管理软件的企业的作用非常明显，可以籍此平台整合企业的各种应用系统，使之成为一个完整的企业级应用，也就是通常所说的EAI. 3. 具备workflow功能的管理软件（workflow与传统管理软件的结合）对于传统管理软件有绝对的优势；4.workflow可以根据企业的需要开发解决信息传递问题的流程以及帮助企业开发与现有应用系统的接口 工作流自动化并不复杂因为下述几个原因，工作流自动化业界有 适合处理复杂业务流程 的名声。 1.常规工作流自动化软件包及其部署相当昂贵。通常，伴随产品的是长时期的咨询关系。所以为了非常简单的业务流程购买和部署软件是被不被采纳的。这些软件通常只被用于复杂、关键和控制成本相对较高而工作流自动化带来的效益明显的量产型工作流应用。因此经销商和用户都会不自觉地关注于将复杂的业务问题自动化。 2. 处于类似原因，工作流研究人士首先会关注解决了哪些复杂的业务流程问题。 而对于大多数案例而言，为解决简单工作流程问题部署自动化软件的成本显然是不经济的。这里遵循一条简单的道理：走之前必须先会爬，跑之前必须先会走。 3. 最后一条原因，也是IT 业的尴尬.总经理对IT部门经理工作衡量的标准就是：能够解决复杂问题的能力。自然，IT经理就会不遗余力地解决那些复杂的问题，他们的方案通常也就复杂而且昂贵。 所有这些目前都在改变。针对桌面电脑的应用方案快速发展以及工作流解决方案的发展使解决日常工作流程问题成为可能。费用不再昂贵，部署更为简便。事实上，企业越来越意识到工作流的重要性，同时在部署复杂关键的流程自动化之前，愿意从一些简单的流程入手积累经验。 工作流会成为操作系统的一部分吗？ 有人认为工作流会成为操作系统平台（例如WINDOWS 平台）的一部分。我们的观点是，基于下述几个原因，在可预见的未来，工作流不会成为操作系统的一部分： 1. 扩展表格、文字处理程序和数据库存在了20多年，成了家喻户晓的名词。这些技术被广泛理解和应用，也相应形成了各自的标准和相关术语。然而因为很多原因，直到今天这些技术也没有成为操作系统的一部分。最重要的原因之一是用户需要差异和选择的自由。相比较而言，工作流自动化软件是较新的技术，也更有差异性、不易被广泛理解并且比这些技术更为先进。因为工作流程的差异性和复杂性，工作流自动化的用户需要更多的选择空间。 2.财务软件包从电脑发明后就迅速普及了。这是实施、术语和规则被普遍接受的另一个领域。然而至今也没有哪种操作系统吹嘘集成了多少财务软件的功能。而工作流自动化软件比财务软件更为复杂和有差异性。 3. 操作系统提供商，例如微软和Sun ，不会为了使其系统具备工作流自动化的功能而大量改变他们现有的系统。他们有什么必要为工作流自动化软件投入开发和支持的成本呢？ 4. 操作系统是为常规条件设计并使之最优化。正因如此，目前操作系统的开发成本几乎都要上亿美元。业务流程十分复杂并充满了例外情况，如在操作系统中内嵌工作流自动化程序会极大地增加开发成本和难度。因此，即便操作系统提供商决定做工作流软件，也会是巨额投入开发一套新的操作系统，而不是将工作流嵌入。 事实上，今天的很多优秀的工作流解决方案集成了短信息、页面服务、目标管理、文件管理和其他一些操作系统才提供的服务。 工作流自动化的主要成分工作流自动化如今成了管理的一句时髦话。市面上也有很多号称能激活工作流的自动化产品。只要他们的应用程序支持基本的E-mail功能，卖主就会随意地把 激活工作流 作为标签贴在产品上。然而，这类产品和真正工作流自动化软件之间的差别就如同写字版和Word之间的差别。我们相信，应用程序只有具备了下列主要特征，才能称其为工作流自动化解决方案： 能够画出工作流程图，当然以图形化界面设计的为佳；能为每个步骤设计电子表格；能将外部应用程序结合为工作流自动化的一部分；能与电子表格及企业数据库相连接；能设计基于复杂业务规则的条件型路由的工作流程图，最好无须编程；能根据功能、用户名称或上下级关系按规则传递信息；能够监控工作流执行状况；能够对工作流进行调节；能够模拟并测试工作流的行为；工作流的应用必须支持多用户并具高度可靠性；工作流的应用必须支持内部网或英特网及跨多种平台。 网友讨论工作流应该是一个中间件而不应该是一个完整的系统。工作流应该整合到其他系统中而不是单独使用。 工作流要完成的核心功能有流程设计，流程执行，流程和线程的调度，任务的分派与通知，集成已有信息系统（很多人忘了）。 工作流应该提供对组织机构，用户，权限管理，流程，任务的管理能力，但是对这些管理能力最基本实现方式是提供API ，而不是一个管理系统，即使把这些管理作为一个管理系统来实现（A ），也主要是用于演示，因为当工作流用于其它系统（B），因为B 需要一个统一的管理界面，所以通常不会直接使用A.而表单设计，报表之类根本就是外围功能，是二次开发商的任务。 我基本赞同wangtaoyy 的说法，再补充一点。我觉得工作流与其说是中间件，还不如说是一个应用整合和集成的框架。类似在j2ee规范下各产商开发的应用服务器，工作流也应当是在wfmc标准下开发出来的 容器 ，只要是满足了标准的应用程序或组件都能够在这个 容器 中按照预定的规则被调度和执行。我认为理想情况下工作流系统不应该提供API 作二次开发，工作流的内部对基于工作流的应用程序应当是完全不透明的，工作流应当提供给开发者的是一个类似于J2EE那样的标准，一套编程模型和接口模型。开发者在这个模型下去实现那些接口，开发出应用组件，再利用工作流提供的管理器进行 注册.总而言之，对开发者而言，工作流是黑箱，他需要做的事情是开发标准组件，在工作流提供的UI管理工具中配置业务流程，包括业务过程、资源、权限、时间、规则等等。 1. j2ee 应用服务器也是中间件的一种。 2. 工作流要做成j2ee哪样的标准还是比较困难的， j2ee 重点在于提供开发全新系统的能力，所以可以制定比较好的容器- 组件标准，而工作流的重点是整合已经存在的系统，要在这些各式各样的老系统上强加标准是不现实的。 3.工作流应该提供api ，因为其他系统中的一些事件可能会启动一个流程，或者触发其他与流程相关的东西 工作流分为两种类型，一种是嵌入式的，另一种是非嵌入式的。这在WFMC的文档中已经有所介绍，大家可以找找看一下。按照工作流管理联盟的文档，大家说的都没有什么错误，只是侧重点不同。wangtaoyy 的观点倾向于前者，而coffeewoo 的观点倾向于后者。 我的看法并不是趋向于嵌入式工作流。我理解的工作流提供的api 并不是一般软件包的API ，而是一种服务方式的API ，类似于操作系统中的系统调用。 我们在软件中大量使用了操作系统提供的系统调用API ，但是操作系统并不是嵌入到我们软件系统中的。我认为工作流系统与操作系统有很强的可比性，只是工作流层次更高。比如流程设计相当于编程，模型相当于程序，流程实例相当于进程，流程分支相当于线程，操作系统要对进程和线程进行调度，工作流引擎要对流程实例和分支进行调度，操作系统和工作流系统都应该对内存进行管理避免耗尽系统内存，操作系统提供系统调用API 而工作流引擎提供工作流API.何其相似。 从功能的角度看：工作流系统的本职工作就是管理和控制业务流程，例如：流程实例的启动、停止；环节实例的启动、结束；任务的分配等等。从工作流系统的组成看：工作流系统应该包括流程引擎、流程定义工具、运行管理工具、api 系统。工作流系统应该该不包括表单定义、组织机构定义及其管理、权限管理、数据流管理等等。 工作流系统虽然不包括上述功能，但是工作流系统一定会和上述功能发生交互关系，所以好的工作流产品并不是一个包办上述功能的产品，而是一个设计良好的能够和上述功能交互的系统。从和其他系统的关系看待工作流：如果站在基础业务平台的角度，那么，工作流系统、组织机构管理系统、表单自定义系统、权限管理系统、数据流管理系统、报表系统都是这个基础业务平台的服务。业务功能系统在运行的过程中会调用这些服务，这些服务之间本身也可能互相调用。例如：工作流服务和组织机构管理服务之间的关系就非常密切，尽管如此，如果认为工作流系统一定包含组织机构管理系统应该是不正确的。在oa系统中，表单自定义好像比较重要，而且流程常常需要引用表单上的数据，但是表单自定义绝对不是工作流系统的组成部分。流程在运行的过程中可能跨多个数据库系统，任务在流转的过程中需要“携带”大量的业务数据，但是这些也不是工作流要做的事情，完成这些工作的系统我称之为“数据流管理系统”。总之：从功能的角度，所有的功能都是必要的，但是从技术的角度，这些功能不可以做到一个“铁板一块”的所谓的“工作流”里面去。从技术发展的趋势看：工作流系统很可能发展成为一个类似关系型数据库管理系统的专职的系统。我那个工作流东东还在改进中，希望作出一个设计合理的（决对不是强行coding出来的），工程实用的东西出来Portal（web应用）一、在Portlet规范里是这样讲的：“portal是一种web应用，通常用来提供个性化、单次登录、聚集各个信息源的内容，并作为信息系统表现层的宿主。聚集是指将来自各个信息源的内容集成到一个web页面里的活动”。Portal的功能可以分为三个主要方面：1. Portlet容器：Portlet容器与servlet容器非常类似，所有的portlet都部署在portlet容器里，portlet容器控制portlet的生命周期并为其提供必要的资源和环境信息。Portlet容器负责初始化和销毁portlets，向portlets传送用户请求并合成响应。2. 内容聚集：Portlet规范中规定portal的主要工作之一是聚集由各种portlet应用生成的内容，我们将在“如何创建Portal页面”部分对此做进一步讨论。3. 公共服务：portlet服务器的一个强项是它所提供的一套公共服务。这些服务并不是portlet规范所要求的，但portal的商业实现版本提供了丰富的公共服务以有别于它们的竞争者。在大部分实现中都有望找到的几个公共服务有：o 单次登录：只需登录portal服务器一次就可以访问所有其它的应用，这意味着你无需再分别登录每一个应用。例如一旦我登录了我的intranet网站，我就能访问mail应用、IM消息应用和其它的intranet应用，不必再分别登录这些应用。Portal服务器会为你分配一个通行证库。你只需要在mail应用里设定一次用户名和密码，这些信息将以加密的方式存储在通行证库中。在你已登录到intranet网站并要访问mail应用的时候，portal服务器会从通行证库中读取你的通行证替你登录到mail服务器上。你对其它应用的访问也将照此处理。o个性化：个性化服务的基本实现使用户能从两方面个性化她的页面：第一，用户可以根据她的自身喜好决定标题条的颜色和控制图标。第二，用户可以决定在她的页面上有哪些portlets。例如，如果我是个体育迷，我可能会用一个能提供我钟爱球队最新信息的portlet来取代股票和新闻portlets。一些在个性化服务方面领先的商业实现版本允许你建立为用户显示什么样的应用所依据的标准（如收入和兴趣）。在这种情况下，可以设定一些像“对任何收入为X的用户显示馈赠商品的portlet”和“对任何收入为X的用户显示打折商品的portlet”这样的商业规则。此外还有一些公共服务，比如机器翻译，是由portal服务器将portlet生成的内容翻译为用户要求的语言。大部分的商业portal服务器都支持手持设备访问并具有针对不同的浏览终端生成不同内容的能力。企业门户业界认为企业门户就是一个联接企业内部和外部的网站，它可以为企业提供一个单一的访问企业各种信息资源的入口，企业的员工、客户、合作伙伴和供应商等等都可以通过这个门户获得个性化的信息和服务。企业门户可以无缝地集成企业的内容、商务和社区：首先，通过企业门户，企业能够动态地发布存储在企业内部和外部的各种信息；其次，企业门户可以完成网上的交易；此外，企业门户还可以支持网上的虚拟社区，网站的用户可以相互讨论和交换信息。企业门户可以为企业的信息系统提供稳定的、可伸缩和可靠的基础和框架结构。与传统的电子商务相比，企业门户的特点在于：多数企业的IT系统是由多个分散的内部和外部的IT系统构成的，企业门户可以将这些系统集成起来，从而更好地实现电子商务的功能。许多现有的商务站点都不能处理遗留系统，企业门户可以解决大型企业的遗留系统与电子商务应用集成的一系列问题。由于具有个性化的功能，因此可以为最终用户提供更加直观、易用的界面，并且能简化用户的使用并节省时间。企业从传统的运营方式转移到基于互联网的电子商务是大势所趋，而企业门户则是充分考虑到企业面临的特殊情况的电子商务系统，企业可以充分利用原有的在IT方面的投资，迅速建立起个性化的电子商务系统企业门户，满足企业用户的需求，从而在激烈的市场竞争中立于不败之地。SOA面向服务的体系结构面向服务的体系结构（Service-Oriented Architecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。我们称能够灵活地适应环境变化的业务为按需（On demand）业务，在按需业务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。虽然面向服务的体系结构不是一个新鲜事物，但它却是更传统的面向对象的模型的替代模型，面向对象的模型是紧耦合的，已经存在二十多年了。虽然基于 SOA 的系统并不排除使用面向对象的设计来构建单个服务，但是其整体设计却是面向服务的。由于它考虑到了系统内的对象，所以虽然 SOA 是基于对象的，但是作为一个整体，它却不是面向对象的。不同之处在于接口本身。SOA 系统原型的一个典型例子是通用对象请求代理体系结构（Common Object Request Broker Architecture，CORBA），它已经出现很长时间了，其定义的概念与 SOA 相似。然而，现在的 SOA 已经有所不同了，因为它依赖于一些更新的进展，这些进展是以可扩展标记语言（eXtensible Markup Language，XML）为基础的。通过使用基于 XML 的语言（称为 Web 服务描述语言（Web Services Definition Language，WSDL）来描述接口，服务已经转到更动态且更灵活的接口系统中，非以前 CORBA 中的接口描述语言（Interface Definition Language，IDL）可比了。Web 服务并不是实现 SOA 的惟一方式。前面刚讲的 CORBA 是另一种方式，这样就有了面向消息的中间件（Message-Oriented Middleware）系统，比如 IBM 的 MQseries。但是为了建立体系结构模型，您所需要的并不只是服务描述。您需要定义整个应用程序如何在服务之间执行其工作流。您尤其需要找到业务的操作和业务中所使用的软件的操作之间的转换点。因此，SOA 应该能够将业务的商业流程与它们的技术流程联系起来，并且映射这两者之间的关系。例如，给供应商付款的操作是商业流程，而更新您的零件数据库，以包括进新供应的货物却是技术流程。因而，工作流还可以在 SOA 的设计中扮演重要的角色。此外，动态业务的工作流不仅可以包括部门之间的操作，甚至还可以包括与不为您控制的外部合作伙伴进行的操作。因此，为了提高效率，您需要定义应该如何得知服务之间的关系的策略，这种策略常常采用服务级协定和操作策略的形式。最后，所有这些都必须处于一个信任和可靠的环境之中，以同预期的一样根据约定的条款来执行流程。因此，安全、信任和可靠的消息传递应该在任何 SOA 中都起着重要的作用。我可以用面向服务的体系结构做什么？对 SOA 的需要来源于需要使业务 IT 系统变得更加灵活，以适应业务中的改变。通过允许强定义的关系和依然灵活的特定实现，IT 系统既可以利用现有系统的功能，又可以准备在以后做一些改变来满足它们之间交互的需要。下面举一个具体的例子。一个服装零售组织拥有 500 家国际连锁店，它们常常需要更改设计来赶上时尚的潮流。这可能意味着不仅需要更改样式和颜色，甚至还可能需要更换布料、制造商和可交付的产品。如果零售商和制造商之间的系统不兼容，那么从一个供应商到另一个供应商的更换可能就是一个非常复杂的软件流程。通过利用 WSDL 接口在操作方面的灵活性，每个公司都可以将它们的现有系统保持现状，而仅仅匹配 WSDL 接口并制订新的服务级协定，这样就不必完全重构它们的软件系统了。这是业务的水平改变，也就是说，它们改变的是合作伙伴，而所有的业务操作基本上都保持不变。这里，业务接口可以作少许改变，而内部操作却不需要改变，之所以这样做，仅仅是为了能够与外部合作伙伴一起工作。另一种形式是内部改变，在这种改变中，零售组织现在决定它还将把连锁零售商店内的一些地方出租给专卖流行衣服的小商店，这可以看作是采用店中店（store-in-store）的业务模型。这里，虽然公司的大多数业务操作都保持不变，但是它们现在需要新的内部软件来处理这样的出租安排。尽管在内部软件系统可以承受全面的检修，但是它们需要在这样做的同时不会对与现有的供应商系统的交互产生大的影响。在这种情况下，SOA 模型保持原封不动，而内部实现却发生了变化。虽然可以将新的方面添加到 SOA 模型中来加入新的出租安排的职责，但是正常的零售管理系统继续如往常一样。为了延续内部改变的观念，IT 经理可能会发现，软件的新配置还可以以另外的一种方式加以使用，比如出租粘贴海报的地方以供广告之用。这里，新的业务提议是通过在新的设计中重用灵活的 SOA 模型得出的。这是来自 SOA 模型的新成果，并且还是一个新的机会，而这样的新机会在以前可能是不会有的。垂直改变也是可能的，在这种改变中，零售商从销售他们自己的服装完全转变到专门通过店中店模型出租地方。如果垂直改变完全从最底层开始的话，就会带来 SOA 模型结构的显著改变，与之一起改变的还可能有新的系统、软件、流程以及关系。在这种情况下，SOA 模型的好处是它从业务操作和流程的角度考虑问题而不是从应用程序和程序的角度考虑问题，这使得业务管理可以根据业务的操作清楚地确定什么需要添加、修改或删除。然后可以将软件系统构造为适合业务处理的方式，而不是在许多现有的软件平台上常常看到的其他方式。正如您可以看到的，在这里，改变和 SOA 系统适应改变的能力是最重要的部分。对于开发人员来说，这样的改变无论是在他们工作的范围之内还是在他们工作的范围之外都有可能发生，这取决于是否有改变需要知道接口是如何定义的以及它们相互之间如何进行交互。与开发人员不同的是，架构师的作用就是引起对 SOA 模型大的改变。这种分工，就是让开发人员集中精力于创建作为服务定义的功能单元，而让架构师和建模人员集中精力于如何将这些单元适当地组织在一起，它已经有十多年的历史了，通常用统一建模语言（Universal Modeling Language，UML），并且描述成模型驱动的体系结构（Model-Driven Architecture，MDA）。对于面向同步和异步应用的，基于请求/响应模式的分布式计算来说，SOA是一场革命。一个应用程序的业务逻辑（business logic）或某些单独的功能被模块化并作为服务呈现给消费者或客户端。这些服务的关键是他们的松耦合特性。例如，服务的接口和实现相独立。应用开发人员或者系统集成者可以通过组合一个或多个服务来构建应用，而无须理解服务的底层实现。举例来说，一个服务可以用。NET或J2EE来实现，而使用该服务的应用程序可以在不同的平台之上，使用的语言也可以不同。SOA有以下特性SOA服务具有平台独立的自我描述XML文档。Web服务描述语言（WSDL， Web Services Description Language）是用于描述服务的标准语言。SOA 服务用消息进行通信，该消息通常使用XML Schema来定义（也叫做XSD， XML Schema Definition）。消费者和提供者或消费者和服务之间的通信多见于不知道提供者的环境中。服务间的通讯也可以看作企业内部处理的关键商业文档。在一个企业内部，SOA服务通过一个扮演目录列表（directory listing）角色的登记处（Registry）来进行维护。应用程序在登记处（Registry）寻找并调用某项服务。统一描述，定义和集成（UDDI， Universal Description， Definition， and Integration）是服务登记的标准。每项SOA服务都有一个与之相关的服务品质（QoS， quality of service）。QoS的一些关键元素有安全需求（例如认证和授权），可靠通信（译注：可靠消息是指，确保消息“仅且仅仅”发送一次，从而过滤重复信息。），以及谁能调用服务的策略。为什么选择SOA？不同种类的操作系统，应用软件，系统软件和应用基础结构（application infrastructure）相互交织，这便是IT企业的现状。一些现存的应用程序被用来处理当前的业务流程（business processes），因此从头建立一个新的基础环境是不可能的。企业应该能对业务的变化做出快速的反应，利用对现有的应用程序和应用基础结构（application infrastructure）的投资来解决新的业务需求，为客户，商业伙伴以及供应商提供新的互动渠道，并呈现一个可以支持有机业务（organic business）的构架。SOA凭借其松耦合的特性，使得企业可以按照模块化的方式来添加新服务或更新现有服务，以解决新的业务需要，提供选择从而可以通过不同的渠道提供服务，并可以把企业现有的或已有的应用作为服务， 从而保护了现有的IT基础建设投资。如图1的例子所示，一个使用SOA的企业，可以使用一组现有的应用来创建一个供应链复合应用（supply chain composite application），这些现有的应用通过标准接口来提供功能。 服务架构服务架构为了实现SOA，企业需要一个服务架构，图2显示了一个例子： 在图2中， 服务消费者（service consumer）可以通过发送消息来调用服务。这些消息由一个服务总线（service bus）转换后发送给适当的服务实现。这种服务架构可以提供一个业务规则引擎（business rules engine），该引擎容许业务规则被合并在一个服务里或多个服务里。这种架构也提供了一个服务管理基础（service management infrastructure），用来管理服务，类似审核，列表（billing），日志等功能。此外，该架构给企业提供了灵活的业务流程，更好地处理控制请求（regulatory requirement），例如Sarbanes Oxley（SOX），并且可以在不影响其他服务的情况下更改某项服务。SOA基础结构要运行，管理SOA应用程序，企业需要SOA基础，这是SOA平台的一个部分。SOA基础必须支持所有的相关标准，和需要的运行时容器。图3所示的是一个典型的SOA基础结构。SOAP， WSDL， UDDIWSDL，UDDI和SOAP是SOA基础的基础部件。WSDL用来描述服务；UDDI用来注册和查找服务；而SOAP，作为传输层，用来在消费者和服务提供者之间传送消息。SOAP是Web服务的默认机制，其他的技术为可以服务实现其他类型的绑定。一个消费者可以在UDDI注册表（registry）查找服务，取得服务的WSDL描述，然后通过SOAP来调用服务。WS-I Basic ProfileWS-I Basic Profile，由Web服务互用性组织（Web Services Interoperability Organization）提供，是SOA服务测试与互用性所需要的核心构件。服务提供者可以使用Basic Profile测试程序来测试服务在不同平台和技术上的互用性。J2EE 和 .Net尽管J2EE和。NET平台是开发SOA应用程序常用的平台，但SOA不仅限于此。像J2EE这类平台，不仅为开发者自然而然地参与到SOA中来提供了一个平台，还通过他们内在的特性，将可扩展性，可靠性，可用性以及性能引入了SOA世界。新的规范，例如 JAXB（Java API for XML Binding），用于将XML文档定位到Java类；JAXR（Java API for XML Registry）用来规范对UDDI注册表（registry）的操作；XML-RPC（Java API for XML-based Remote Procedure Call）在J2EE1.4中用来调用远程服务，这使得开发和部署可移植于标准J2EE容器的Web服务变得容易，与此同时，实现了跨平台（如。NET）的服务互用。服务品质在企业中，关键任务系统（mission-critical system，译注：关键任务系统是指如果一个系统的可靠性对于一个组织是至关重要的，那么该系统就是该企业的关键任务系统。比如，电话系统对于一个电话促销企业来说就是关键任务系统，而文字处理系统就不那么关键了。）用来解决高级需求，例如安全性，可靠性，事物。当一个企业开始采用服务架构作为工具来进行开发和部署应用的时候，基本的Web服务规范，像WSDL，SOAP，以及UDDI就不能满足这些高级需求。正如前面所提到的，这些需求也称作服务品质（QoS，quality of services）。与QoS相关的众多规范已经由一些标准化组织（standards bodies）提出，像W3C