企业级架构和异构整合.docx

网络化制造企业的异构系统集成控制模型为提高制造系统的智能重构能力，快速地开发、设计和制造产品，本文提出了网络化制造企业的异构系统集成控制模型；构建了基于公共对象请求代理体CORBA与多智能体系统MAS的企业内部集成控制体系结构，并论述了内部通信的实现机制；利用Web services技术，通过构建SOAP远程服务代理来实现合作企业间远程协同生产控制；并通过联网加工试验验证了所构建的集成控制模的可行性和实用性。1 引言网络化制造中由于企业的开发语言、部署平台、通信协议等各种异构系统同时存在，使得企业各应用系统间信息的交互困难，造成了企业信息资源的网络化分散，降低了企业的生产率和综合竞争力。分布式对象技术的出现及应用为企业实现制造信息的跨平台交换和协同完成工作提供了有效途径。近年来，虽有不少学者提出了基于公共对象请求代理体CORBA和多智能体系MAS的网络化集成制造方案，但他们主要研究了企业内部的信息集成，没有解决系统外部的信息集成。为此，本文结合企业网络化制造的需求和CORBA、MAS与Web技术的特点，提出了通过CORBA与MAS构建企业内部的集成框架，实现制造车间制造设备的集中控制管理以及各应用系统的融合集成，从而实现企业内部的信息集成；同时，通过web服务技术构建企业外部的集成框架来实现企业外部信息的集成控制，为企业实施网络化制造、实现资源集成与共享提供了有价值的集成模式。2异构系统的集成控制模型在充分利用Agent理论技术及分布式对象计算规范CORBA的基础上，引入基于CORBA的MAS框架作为车间的网络化集成制造平台，很容易将符合CORBA接口规范的DNC等各应用系统中的有效资源，作为控制对象的智能体，并通过对象请求代理ORB软总线集成起来，实现信息资源的优化整合。平台通过ORB请求为外部应用系统或内部应用系统提供操作服务或请求服务，并通过智能体的相互协作求解，实现从制造设备到制造企业的集成控制，完成制造过程中的信息集成。在该体系结构中，企业与外网之间采用基于Web services的对等协议进行通信；企业内部平台上采用CORBAIIOP协议，与协议转换器的连接遵循TCMP协议：底层设备通过协议转换或直接联入企业网络，从而实现整个企业的集成控制。网络化制造企业的异构系统集成控制模型如图1所示。如MRPII、CADCAMCAPP等系统为信息交互平台提供生产计划、生产调度和加工控制信息等，通过DNC系统分配给各底层设各进行加工，而底层设备的生产进度信息和设备的工作状态信息等也可以由DNC系统实时反馈给平台，供上层ERP或其他管理系统查询和反馈信息。图1 网络化制造企业异构系统的集成控制模型3 企业内部集成控制31 基于CORBA与MAS的通信与协作模型CORBA通过ORB机制实现对象实体间透明地进行通信和访问，同时通过接口定义语言IDL来描述对象实体外部接口的属性和行为，0RB之问通过IIOP协议进行通信连接来实现异构或同构环境下应用间的互操作，具有良好的跨平台和跨越程序设计语言的特征。而MAS具各开放性、自主性、异构性、互操作性和分布性等特点。非常适合企业分布式应用系统集成。结合CORBA与MAS的特点，建立基于CORBA与MAS的通信协作模型(如图2所示)，以车间各异构系统为控制对象，采用点对点的控制模式，建立软通信总线及各控制对象智能体。通过核心智能体，即以控制Agent和协作Agent为核心的智能体的相互协作，将车间层各应用系统的集成问题转化为智能体之间的通信、协调和决策行为，完成车间的集成控制。在该协作模型中，每个Agent基于CORBA规范的互操作机制来相互传递KQMLXML消息，可以根据自己的知识库经过计算或推理，选用合适的标准词汇集生成相应的请求，然后将它嵌入KQML的内容层，使用XML封装器生成XML文档，并经ORB代理通过IIOP协议完成通信。同时，多Agent间采用客户机，服务器(ClientServer)方式交换信息来进行协作。以数据请求任务的会话协作过程为例，客户Agent向服务地的服务器Agent发出数据服务请求，ORB为客户查找和定位到该请求所标识的服务器Agent，二者建立连接并开始对话。客户Agent将请求传送给它，服务器Agent在接到请求后，首先进行解码，然后再根据请求中所包含的服务对象标识进行对象适配，在正确定位到所要访问的对象实例后，调用相应的方法，以满足客户Agent的请求，服务器Agent将要传递的数据(存于自己的数据库中)放入特定位置(消息体中或外部公用地方)中并将地址名称告诉客户Agent。客户Agent则在相应的地方取数据，或直接与客户Agent进行消息交互。同样，如果服务器Agent还要请求其他Agent才能完成任务时，也采用相似的会话过程进行信息交互、协作求解。协作中采用的是基于TCPIP的cORBMlOP通讯协议和XML交互信息。图2 基于CORBA的MAS通信协作模型32 基于CORBA与MAS的信息集成在CORBA信息集成平台上，车间各应用系统的功能模块基于TCPIP的CORBAIIOP通信协议和XML来交互信息。首先被封装成具有CORBA接口的Agent，这些Agent通过实体接口分别与其所代理的制造资源实体相连，每个成员Agent实际上是一个按CORBA规范封装、具有IDL接口形式的分布式应用对象，其内部结构如图1显示。各成员Agent采用一种动态客户端服务器(cs)结构，即每个成员Agent既可作为客户端应用程序来调用CORBA对象提供的服务，亦可作为服务器来为其他成员Agent提供透明服务。ORB技术使符合接口标准的Agent方便地以即插即用的方式到通信总线上，实现内部系统的扩展和集成。其中，DNC系统借助该平台起着连接上层管理系统和底层设备之间的桥梁作用，在DNC智能体内部又划分成多个子智能体，即各设备Agent。DNC智能体主要负责这些子智能体的统一管理、控制和协调，协同完成DNC系统的加工控制功能。针对不同类型的数控设各Agent利用“软插件技术”，通过测试、分析、开发不同的、模块化的通讯协议转换程序，构成通讯协议转换程序库，来实现异构数控设备的通信。异构设备Agent的通讯协议和通讯软件的实现流程如图3所示。图3 通讯协议和通讯软件的实现流程当有新的不同设备加入时，就可以根据其接口和通讯协议设计出相应的设备Agent并加入到DNC智能体中，同时采用全分布式的总线控制网将这些Agent联接起来，实现点对点的设备控制，从而实现异构设备的即插即用与集成控制。如具有异步串行通讯接口(如RS232、RS422、RS485等采用XON)(0FF、3964R等通讯协议)的设备Agent，可通过串口服务器的方式，利用串口通信的延缓机制和流控机制，来很好的保证信息的联网通信；而具有MAP接口的设备Agent，由于这种接口符合MAP标准，采用MAP21和MAP30制造自动化协议，因此可直接连入局域网进行信息的通信。4 企业外部的集成控制企业间利用Web services技术，通过基于对等网络P2P的Web服务方式进行远程生产协同控制管理。WebServices是采用面向服务架构SOA的新型分布式计算模型，利用开放标准和公共基础设施实现对象的描述、发现和访问来实现跨平台、跨语言的异构集成。基于Webservices的企业外部集成控制模型如图4所示。图4 基于Web services的企业外部集成控制模型企业间远程信息交互通过在HTTP上使用简单对象访问协议SOAP来进行。基于SOAP的远程服务代理，驻留在企业内部的应用Server内，主要提供通信连接、信息交互、任务分发等远程应用服务，而企业内部任务调用通过本地映射转换为CORBA方式进行。本地映射机制将远程客户所请求对话的服务Agent接口及参数等映射为本地的过程调用即ORB调用，在Windows环境下采用的是Web服务元语言WSML来描述远程调用和本地CORBA服务的映射关系，利用WSML文件中的信息，可将WSDL中描述的操作连接到CORBA服务对象的具体操作上。即SOAP服务器将SOAP信息包进行解析，获取本地远程服务Agent接口及参数等，然后根据WSML描述的映射关系，启动实际机制调用CORBA平台上的远程服务Agent，并把获取的参数等封装成Agent消息传递给该Agent。远程服务Agent间建立连接后开始通讯、交互各种消息，同时根据消息分发任务，调用核心Agent进行组织、协调本地Agent协同完成操作后返回结果。在该集成模型中，合作企业的协同生产控制业务(应用系统、功能模块及数据库资源等)通过建立远程服务代理来支持协作。企业制定的远程服务通过WEB服务封装，用WEB服务描述语言WSDL进行统一描述，并在UDDI注册中心进行注册。合作企业可以通过UDDI注册中心进行查询其WEB服务的WSDL描述文档进行绑定，并使用远程服务代理进行SOAP封装后与之进行交互。这样，企业之间的集成就转变为WEB服务的对接，从而完成企业之间的协同生产控制。5 集成控制应用实例为验证所建立的网络化制造的集成控制模型的可行性，笔者利用本校“河南省机械设计及传动系统重点实验室”资源进行联网加工试验，进行了网络的实际连接，并编写了相应的软插件和通信程序。试验联网方案如图5所示。图5 集成控制系统的联网方案实验室采用交换式以太网，网内主要有Web服务器.CAD/CAM工作站，MRPII资源管理器，串口服务器NPort5110，加工中心XH2412（FANUC Series oi -MC）数控车床CKJ6142、数控铣齿机YK22100F，齿轮测量中心JD45S等，底层的数控设备通过串口服务NPort5110与DNC服务器连接。联网系统中，MRPII资源管理器是系统内制造资源集成的基础，负责系统内制造资源的注册与管理，制造任务规划与分配，通信与协作等:CAD/CAM工作站通过网络进行数据传送与信息共享，从而实现设计的并行化，同时通过XML进行分布式协同作业，通过与DNC系统完成任务的设计与加工；同时DNC服务器通过路由器可与外界网络如Internet进行互联，通过路由器配置的包过滤功能来保障系统内的信息安全不受侵犯与破坏。网络调试完成后，在龙门式加工中心XH2412( FANUC Series oi-MC)上进行锻透齿轮毛环模具的实际加工，加工现场过程如图6所示。齿轮毛坯模具CAD/CAM在实验室网的其它计算机上完成，生成的NC程序存放在实验室服务器上，采取DNC主控计算机直接访问实验室服务器的方式边传程序边加工。整副模具的加工时间长达8小时，加工中没有出现因传输速度不够而停顿或NC程序传输出错的现象，后经多次可靠性试验，系统均运行正常。由此说明，基于上述面向网络化制造的集成控制系统模型能够实现企业内各异构系统的集成控制，满足产品网络化制造的要素。6 结论资源的共享和优化配置是实施网络化制造的基础和前提。本文结合信息技术和网络技术，提出的集成控制模型，将为实现企业制造信息的集成控制提供整体解决方案，可以真正实现各异构系统动态、松散、跨平台的信息交互，为企业解决网络化环境中制造信息孤岛问题，实现资源优化配置提供了良好的信息基础环境，同时也为更深入地进行网络化制造模式的研究和推广提供了有价值的参考。架构师和SOASOA(Service-Oriented Architecture)，即面向服务的架构，这是最近一两年出现在各种技术期刊上最多的词汇了。现在有很多架构设计师和设计开发人员简单的把SOA和Web Services技术等同起来，认为SOA就是Web Service的一种实现。本质上来说，SOA体现的是一种新的系统架构，SOA的出现，将为整个企业级软件架构设计带来巨大的影响。本系列两部分文章将根据作者自己的理解来帮助大家分析和了解什么是SOA架构，SOA将怎样对企业系统架构设计带来积极的影响，什么是SOA架构设计师的角色，以及SOA架构师在设计SOA系统架构时有哪些应该特别注意的地方。1.1 什么是架构从架构设计师的角度来看，架构就是一套构建系统的准则。通过这套准则，我们可以把一个复杂的系统划分为一套更简单的子系统的集合，这些子系统之间应该保持相互独立，并与整个系统保持一致。而且每一个子系统还可以继续细分下去，从而构成一个复杂的企业级架构。当一名架构设计师在构建某个企业级的软件系统时，除了要考虑这个系统的架构以及其应具有的功能行为以外，还要关注整个架构的可用性，性能问题，容错能力，可重用性，安全性，扩展性，可管理维护性，可靠性等各个相关方面。有的时候一名好的架构设计师甚至还需要考虑所构建的系统架构是否合乎美学要求。由此我们可以看到，我们衡量一个好的架构设计并不能只从功能角度出发，还要考虑很多其他的因素，对任何一个方面的欠缺考虑都有可能为整个系统的构建埋下隐患。1.2 什么是基于SOA的架构SOA本身就是一种面向企业级服务的系统架构，简单来说，SOA就是一种进行系统开发的新的体系架构，在基于SOA架构的系统中，具体应用程序的功能是由一些松耦合并且具有统一接口定义方式的组件（也就是service）组合构建起来的。因此，基于SOA的架构也一定是从企业的具体需求开始构建的。但是，SOA和其它企业架构的不同之处就在于SOA提供的业务灵活性。业务灵活性是指企业能对业务变更快速和有效地进行响应、并且利用业务变更来得到竞争优势的能力。对企业级架构设计师来说，创建一个业务灵活的架构意味着创建一个可以满足当前还未知的业务需求的IT架构。利用基于SOA的系统构建方法，一个基于SOA架构的系统中的所有的程序功能都被封装在一些功能模块中，我们就是利用这些已经封装好的功能模块组装构建我们所需要的程序或者系统，而这些功能模块就是SOA架构中的不同的服务（services）。因此，SOA架构本质上来说体现了一种复合的概念：它不仅为一个企业中商业流程的组织和实现提供了一种指导模式，同时也为具体的底层service开发提供了指导。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.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 端点，可以使服务具有更强的可伸缩性，并增强了系统整体的可靠性。一、什么是C/S和B/S 第一、什么是C/S结构。C/S （Client/Server）结构，即大家熟知的客户机和服务器结构。它是软件系统体系结构，通过它可以充分利用两端硬件环境的优势，将任务合理分配到Client端和Server端来实现，降低了系统的通讯开销。目前大多数应用软件系统都是Client/Server形式的两层结构，由于现在的软件应用系统正在向分布式的Web应用发展，Web和Client/Server 应用都可以进行同样的业务处理，应用不同的模块共享逻辑组件；因此，内部的和外部的用户都可以访问新的和现有的应用系统，通过现有应用系统中的逻辑可以扩展出新的应用系统。这也就是目前应用系统的发展方向。传统的CS体系结构虽然采用的是开放模式，但这只是系统开发一级的开放性，在特定的应用中无论是Client端还是Server端都还需要特定的软件支持。由于没能提供用户真正期望的开放环境，C/S结构的软件需要针对不同的操作系统系统开发不同版本的软件， 加之产品的更新换代十分快，已经很难适应百台电脑以上局域网用户同时使用。而且代价高， 效率低。如我院使用的上海超兰公司“案件统计”管理软件就是典型的CS体系结构管理软件。第二、什么是B/S结构。B/S（Browser/Server）结构即浏览器和服务器结构。它是随着Internet技术的兴起，对C/S结构的一种变化或者改进的结构。在这种结构下，用户工作界面是通过WWW浏览器来实现，极少部分事务逻辑在前端（Browser）实现，但是主要事务逻辑在服务器端（Server）实现，形成所谓三层3-tier结构。这样就大大简化了客户端电脑载荷，减轻了系统维护与升级的成本和工作量，降低了用户的总体成本（TCO）。以目前的技术看，局域网建立B/S结构的网络应用，并通过Internet/Intranet模式下数据库应用，相对易于把握、成本也是较低的。它是一次性到位的开发，能实现不同的人员，从不同的地点，以不同的接入方式（比如LAN, WAN, Internet/Intranet等）访问和操作共同的数据库；它能有效地保护数据平台和管理访问权限，服务器数据库也很安全 。目前我院内网（Intranet）、外网（Internet）和北京东方清大公司“案件、办公管理软件”就是B/S 结构管理软件，干警在局域网各工作站通过WWW浏览器就能实现工作业务。特别是在JAVA这样的跨平台语言出现之后，B/S架构管理软件更是方便、快捷、高效。第三、管理软件主流技术。管理软件技术的主流技术与管理思想一样，也经历了三个发展时期。首先，界面技术从上世纪DOS字符界面到Windows图形界面（或图形用户界面GUI），直至Browser浏览器界面三个不同的发展时期。其次，今天所有电脑的浏览器界面，不仅直观和易于使用，更主要的是基于浏览器平台的任何应用软件其风格都是一样的，使用人对操作培训的要求不高，而且软件可操作性强，易于识别；再者，平台体系结构也从过去单用户发展到今天的文件服务器（FS）体系、客户机服务器（CS）体系和浏览器服务器（BS）体系。二、C/S和B/S 之比较 C/S和B/S是当今世界开发模式技术架构的两大主流技术。C/S是美国 Borland公司最早研发，B/S是美国微软公司研发。目前，这两项技术以被世界各国所掌握，国内公司以C/S和B/S技术开发出产品也很多。这两种技术都有自己一定的市场份额和客户群，各家企业都说自己的管理软件架构技术功能强大、先进、方便，都能举出各自的客户群体，都有一大群文人墨客为自己摇旗呐喊，广告满天飞，可谓仁者见仁，智者见智。1、C/S架构软件的优势与劣势 （1）、应用服务器运行数据负荷较轻。最简单的C/S体系结构的数据库应用由两部分组成，即客户应用程序和数据库服务器程序。二者可分别称为前台程序与后台程序。运行数据库服务器程序的机器，也称为应用服务器。一旦服务器程序被启动，就随时等待响应客户程序发来的请求；客户应用程序运行在用户自己的电脑上，对应于数据库服务器，可称为客户电脑，当需要对数据库中的数据进行任何操作时，客户程序就自动地寻找服务器程序，并向其发出请求，服务器程序根据预定的规则作出应答，送回结果，应用服务器运行数据负荷较轻。（2）、数据的储存管理功能较为透明。在数据库应用中，数据的储存管理功能，是由服务器程序和客户应用程序分别独立进行的，前台应用可以违反的规则，并且通常把那些不同的（不管是已知还是未知的）运行数据，在服务器程序中不集中实现，例如访问者的权限，编号可以重复、必须有客户才能建立定单这样的规则。所有这些，对于工作在前台程序上的最终用户，是“透明”的，他们无须过问（通常也无法干涉）背后的过程，就可以完成自己的一切工作。在客户服务器架构的应用中，前台程序不是非常“瘦小”，麻烦的事情都交给了服务器和网络。在C/S体系的下，数据库不能真正成为公共、专业化的仓库，它受到独立的专门管理。（3）、C/S架构的劣势是高昂的维护成本且投资大。首先，采用C/S架构，要选择适当的数据库平台来实现数据库数据的真正“统一”，使分布于两地的数据同步完全交由数据库系统去管理，但逻辑上两地的操作者要直接访问同一个数据库才能有效实现，有这样一些问题，如果需要建立“实时”的数据同步，就必须在两地间建立实时的通讯连接，保持两地的数据库服务器在线运行，网络管理工作人员既要对服务器维护管理，又要对客户端维护和管理，这需要高昂的投资和复杂的技术支持，维护成本很高，维护任务量大。其次，传统的C/S结构的软件需要针对不同的操作系统系统开发不同版本的软件，由于产品的更新换代十分快，代价高和低效率已经不适应工作需要。在JAVA这样的跨平台语言出现之后，B/S架构更是猛烈冲击C/S，并对其形成威胁和挑战。2、B/S架构软件的优势与劣势（1）、维护和升级方式简单。目前，软件系统的改进和升级越来越频繁，B/S架构的产品明显体现着更为方便的特性。对一个稍微大一点单位来说，系统管理人员如果需要在几百甚至上千部电脑之间来回奔跑，效率和工作量是可想而知的，但B/S架构的软件只需要管理服务器就行了，所有的客户端只是浏览器，根本不需要做任何的维护。无论用户的规模有多大，有多少分支机构都不会增加任何维护升级的工作量，所有的操作只需要针对服务器进行；如果是异地，只需要把服务器连接专网即可，实现远程维护、升级和共享。所以客户机越来越“瘦”，而服务器越来越“胖”是将来信息化发展的主流方向。今后，软件升级和维护会越来越容易，而使用起来会越来越简单，这对用户人力、物力、时间、费用的节省是显而易见的，惊人的。因此，维护和升级革命的方式是“瘦”客户机，“胖”服务器。（2）、成本降低，选择更多。大家都知道windows在桌面电脑上几乎一统天下，浏览器成为了标准配置，但在服务器操作系统上windows并不是处于绝对的统治地位。 现在的趋势是凡使用B/S架构的应用管理软件，只需安装在Linux服务器上即可，而且安全性高。所以服务器操作系统的选择是很多的，不管选用那种操作系统都可以让大部分人使用windows作为桌面操作系统电脑不受影响，这就使的最流行免费的Linux操作系统快速发展起来，Linux除了操作系统是免费的以外，连数据库也是免费的，这种选择非常盛行。比如说很多人每天上“新浪”网，只要安装了浏览器就可以了，并不需要了解“新浪”的服务器用的是什么操作系统，而事实上大部分网站确实没有使用windows操作系统，但用户的电脑本身安装的大部分是windows操作系统。（3）、应用服务器运行数据负荷较重。由于B/S架构管理软件只安装在服务器端（Server）上，网络管理人员只需要管理服务器就行了，用户界面主要事务逻辑在服务器（Server）端完全通过WWW浏览器实现，极少部分事务逻辑在前端（Browser）实现，所有的客户端只有浏览器，网络管理人员只需要做硬件维护。但是，应用服务器运行数据负荷较重，一旦发生服务器“崩溃”等问题，后果不堪设想。因此，许多单位都备有数据库存储服务器，以防万一。Web服务作为炙手可热的技术，如何应用到企业的IT系统和商业流程之中、并给企业带来直接的经济效益，一直备受国内外企业管理者的高度关注和推崇。而在近两年，出现了一种技术架构被誉为下一代Web服务的基础架构，它就是SOA（Service-oriented architecture，面向服务架构）。1996年，Gartner最早提出SOA。2002年12月，Gartner提出SOA是现代应用开发领域最重要的课题，还预计到2008年，SOA将成为占有绝对优势的软件工程实践方法，主流企业现在就应该在理解和应用SOA开发技能方面进行投资。更好支持商业流程SOA并不是一个新事物，IT组织已经成功建立并实施SOA应用软件很多年了，BEA、IBM、等厂商看到了它的价值，纷纷跟进。SOA的目标在于让IT变得更有弹性，以更快地响应业务单位的需求，实现实时企业（Real-Time Enterprise，这是Gartner为SOA描述的愿景目标）。而BEA的CIO Rhonda早在2001年6月就提出要将BEA的IT基础架构转变为SOA，并且从对整个企业架构的控制能力、提升开发效率、加快开发速度、降低在客户化和人员技能的投入等方面取得了不错的成绩。SOA是在计算环境下设计、开发、应用、管理分散的逻辑（服务）单元的一种规范。这个定义决定了SOA的广泛性。SOA要求开发者从服务集成的角度来设计应用软件，即使这么做的利益不会马上显现。SOA要求开发者超越应用软件来思考，并考虑复用现有的服务，或者检查如何让服务被重复利用。SOA鼓励使用可替代的技术和方法（例如消息机制），通过把服务联系在一起而非编写新代码来构架应用。经过适当构架后，这种消息机制的应用允许公司仅通过调整原有服务模式而非被迫进行大规模新的应用代码的开发，使得在商业环境许可的时间内对变化的市场条件做出快速的响应。SOA也不仅仅是一种开发的方法论-它还包含管理。例如，应用SOA后，管理者可以方便的管理这些搭建在服务平台上的企业应用，而不是管理单一的应用模块。其原理是，通过分析服务之间的相互调用，SOA使得公司管理人员方便的拿到什么时候、什么原因、哪些商业逻辑被执行的数据信息，这样就帮助了企业管理人员或应用架构师迭代地优化他们的企业业务流程、应用系统。SOA的一个中心思想就是使得企业应用摆脱面向技术的解决方案的束缚，轻松应对企业商业服务变化、发展的需要。企业环境中单个应用程序是无法包容业务用户的（各种）需求的，即使是一个大型的ERP解决方案，仍然不能满足这个需求在不断膨胀、变化的缺口，对市场快速做出反应，商业用户只能通过不断开发新应用、扩展现有应用程序来艰难的支撑其现有的业务需求。通过将注意力放在服务上，应用程序能够集中起来提供更加丰富、目的性更强的商业流程。其结果就是，基于SOA的企业应用系统通常会更加真实地反映出与业务模型的结合。服务是从业务流程的角度来看待技术的-这是从上向下看的。这种角度同一般的从可用技术所驱动的商业视角是相反的。服务的优势很清楚：它们会同业务流程结合在一起，因此能够更加精确地表示业务模型、更好地支持业务流程。相反我们可以看到以应用程序为中心的企业应用模型迫使业务用户将其能力局限为应用程序的能力。企业流程（enterprise process）是流经企业框架的空气，它赋予业务模型里的组件以生命，并更加清晰地定义了它们之间的关系。流程定义了同业务模型进行交互操作的专门方法。例如，会计可能是企业服务系统的一个组件-但是将发票寄给客户却是一个业务流程。服务被定义用来支持业务流程，因而贯穿整个流程始终的是：各种服务组件在流程和逻辑实现过程中的装配操作。理解业务流程是定制服务的关键所在。有利于企业业务的集成传统的应用集成方法（点对点集成、企业消息总线或中间件的集成（EAI）、基于业务流程的集成）都很复杂、昂贵，并且不灵活。这些集成方法难于快速适应基于企业现代业务变化不断产生的需求。基于面向服务架构 (SOA) 的应用开发和集成可以很好的解决其中的许多问题。SOA 描述了一套完善的开发模式来帮助客户端应用连接到服务上。这些模式定制了系列机制用于描述服务、通知及发现服务、与服务进行通信。不同于传统的应用集成方法，在 SOA 中，围绕服务的所有模式都是以基于标准的技术实现的。大部分的通信中间件系统，如 RPC、CORBA、DCOM、EJB 和 RMI，也同样如此。可是它们的实现都不是很完美的，在权衡交互性以及标准定制的可接受性方面总是存在问题。SOA 试图排除这些缺陷。因为几乎所有的通信中间件系统都有固定的处理模式，如RPC 的功能、CORBA 的对象等等。然而，服务既可以定义为功能，又可同时对外定义为对象、应用等等。这使得 SOA 可适应于任何现有系统，并使得系统在集成时不必刻意遵循任何特殊定制。 SOA 帮助企业信息系统迁移到leave-and-layer架构之上，这意味着在不用对现有的企业系统做修改的前提下，系统可对外提供 Web 服务接口，这是因为它们已经被可以提供 Web 服务接口的应用层做了一层封装，所以在不用修改现有系统架构的情况下，SOA 可以将系统和应用迅速转换为服务。SOA 不仅覆盖来自于打包应用、定制应用和遗留系统中的信息，而且还覆盖来自于如安全、内容管理、搜索等 IT 架构中的功能和数据。因为基于 SOA 的应用能很容易地从这些基础服务架构中添加功能，所以基于SOA的应用能更快地应对市场变化，为使企业业务部门设计开发出新的功能应用。导读-SOA是为了解决在Internet环境下业务集成的需要，通过连接能完成特定任务的独立功能实体的软件系统架构。内容简介SOA是英文Service-Oriented Architecture，即服务导向架构的缩写。这个词汇最近一两年频频出现在各种技术期刊上。但是一直以来对于SOA到底是什么一直没有明确的回答；SOA有什么特点？适合用于解决哪些问题？与其他的技术有什么区别与联系？Web Service和SOA又是什么关系？SOA的出现对于软件架构设计有什么影响？本文将就上面提到的这些问题，尝试根据作者自己的理解给出SOA的定义；总结出SOA特有的三个基本特征；然后以HTTP协议为例对这些特征进行解释；最后简要的说明SOA对今后软件架构设计可能带来的影响。SOA定义下面是作者给SOA下的一个定义：SOA是指为了解决在Internet环境下业务集成的需要，通过连接能完成特定任务的独立功能实体实现的一种软件系统架构。从这个定义中我希望表达的前提有下面两点：1)软件系统架构： SOA不是一种语言，也不是一种具体的技术而是一种软件系统架构，它尝试给出在特定环境下推荐采用的一种架构，从这个角度上来说，它更像一种模式(Pattern)。因此它与很多已有的软件技术比如面向对象技术，是互补的而非互斥的。它们分别面向不同的应用场景，用来满足不同的特定需求。2)SOA的使用范围：需求决定同时也限制功能。SOA并不是包治百病的万灵单，它最主要的应用场合在于解决在Internet环境下的不同商业应用之间的业务集成问题。在下面我们会详细讨论Internet的各种特点是如何决定了SOA的特点，这里我们只需要先简单回顾一下Internet环境区别于Intranet环境的几个特点：a)大量异构系统并存，计算机硬件工作方式不同，操作系统不同、编程语言也不同；b)大量、频繁的数据传输仍然速度缓慢并且不稳定；c)版本升级无法完成，我们根本就无法知道互联网上有哪些机器直接或者间接的使用某个服务。基于上面的前提，下面就让我们一起看一下SOA的基本特征。SOA三大基本特征独立的功能实体在Internet这样松散的使用环境中，任何访问请求都有可能出错，因此任何企图通过Internet进行控制的结构都会面临严重的稳定性问题。SOA非常强调架构中提供服务的功能实体的完全独立自主的能力。传统的组件技术，如.NET Remoting， EJB，COM或者CORBA，都需要有一个宿主(Host或者Server)来存放和管理这些功能实体；当这些宿主运行结束时这些组件的寿命也随之结束。这样当宿主本身或者其它功能部分出现问题的时候，在该宿主上运行的其它应用服务就会受到影响。SOA架构中非常强调实体自我管理和恢复能力。常见的用来进行自我恢复的技术，比如事务处理(Transaction)，消息队列(Message Queue)，冗余部署(Redundant Deployment)和集群系统(Cluster)在SOA中都起到至关重要的作用。大数据量低频率访问对于.NET Remoting，EJB或者XML-RPC这些传统的分布式计算模型而言，他们的服务提供都是通过函数调用的方式进行的，一个功能的完成往往需要通过客户端和服务器来回很多次函数调用才能完成。在Intranet的环境下，这些调用给系统的响应速度和稳定性带来的影响都可以忽略不计，但是在Internet环境下这些因素往往是决定整个系统是否能正常工作的一个关键决定因素。因此SOA系统推荐采用大数据量的方式一次性进行信息交换。基于文本的消息传递由于Internet中大量异构系统的存在决定了SOA系统必须采用基于文本而非二进制的消息传递方式。在COM、CORBA这些传统的组件模型中，从服务器端传往客户端的是一个二进制编码的对象，在客户端通过调用这个对象的方法来完成某些功能；但是在Internet环境下，不同语言，不同平台对数据、甚至是一些基本数据类型定义不同，给不同的服务之间传递对象带来的很大困难。由于基于文本的消息本身是不包含任何处理逻辑和数据类型的，因此服务间只传递文本，对数据的处理依赖于接收端的方式可以帮忙绕过兼容性这个的大泥坑。此外，对于一个服务来说，Internet与局域网最大的一个区别就是在Internet上的版本管理极其困难，传统软件采用的升级方式在这种松散的分布式环境中几乎无法进行。采用基于文本的消息传递方式，数据处理端可以只选择性的处理自己理解的那部分数据，而忽略其它的数据，从而得到的非常理想的兼容性。HTTP协议：一个