WebServices及其在网络管理中的应用

PAGEPAGE27WｅbSerｖiceｓ及其在网络管理中的应用WeｂSｅrvicｅs概述WebＳｅrviceｓ的定义WｅbServｉcｅｓ技术通过借鉴和利用现有的Ｉntｅrnet开放互联标准,为运行在各种平台／框架上的不同软件应用程序之间进行互操作供应了一种标准方式.W3C（ＨＹPEＲLINＫ”ｈttp：／/wｗｗ.w３。orｇ／”WｏrldWideWｅｂConｓortｉuｍ)对WebSeｒｖiceｓ的定义是“Wｅb服务是一个可以支持网络上机器－机器之间互操作的软件系统,它的接口用一种机器可处理的格式（特指WＳDL：WｅｂSｅrviceＤesｃrｉptionLaｎgｕage)描述。其他系统依据服务描述中指定的方式使用SOAP消息与该Web服务进行交互，具有代表性的是使用HＴＴＰ，接受一个结合了其他Web相关标准的ＸML（ＥxｔｅｎｓｉｂｌeMarkｕpLａｎguａge）串行化序列进行传送。”（AWebsｅｒｖiｃeｉsasofｔｗaｒesysｔemdesignedtosuppoｒtinｔｅropeｒaｂlemａｃｈine－to－maｃｈiｎｅraｃtｉｏnoｖｅranetｗoｒk．Ｉtｈａｓaｎinｔｅrfacｅｄeｓcribediｎaｍachｉｎe-proｃｅｓsablｅｆｏrmat(ｓｐeｃifiｃaｌlyWSDＬ).ＯthｅｒsｙstemsintｅｒａｃｔwithｔｈeWebｓeｒvｉcｅｉnaｍannｅrｐｒescｒｉbedbyiｔsdｅscｒiptｉｏnusingＳOＡP－ｍeｓsages，tyｐｉcａlｌｙconveyedusingHTTPｗithanXＭＬｓｅriaｌｉzaｔionｉnconｊｕｎｃｔionwitｈｏtherＷｅb-relaｔedsｔandarｄs.)［1]ＩBM给WｅbSｅｒviceｓ的定义是“一个Ｗｅbseｒｖice是一个描述一组操作的接口,这些操作在网络上可通过标准化的XML消息传递进行访问。"（AWｅbseｒvｉcｅｉｓanｉnteｒｆａcethａtdesｃribesacolｌｅｃtiｏnoｆoperａtｉonsｔhatarenｅtwｏrk—ａcceｓsiｂlｅthｒoｕｇｈｓtandａrdiｚｅdXMＬｍeｓsaｇｉｎｇ。）［２]尽管目前对WｅbSerｖiｃes尚无一个公认的精准定义,但几乎全部的定义都有以下的共同点:ＷebSｅｒvｉcｅｓ可以通过标准的Wｅｂ协议访问从而向用户供应其实现的功能;WeｂＳｅrviｃｅs的接口使用一种标准的基于XML的方法描述;ＷebSｅrｖｉｃｅs可以通过注册以被潜在用户发现并使用.WebSerｖicｅs的体系结构ＷeｂSeｒvices体系结构模型是一个概念性框架,它包括三种角色[2］:服务供应者:实现服务并在Inｔernet上供应这个服务.服务恳求者:需要某种功能的商业团体和个人组织,与服务注册中心一起发现Web服务，然后调用这些服务以创建相应的应用程序。服务注册中心：为服务供应交换的场所。服务注册中心充当服务供应者与服务恳求者之间的中介。Wｅb上供应的各种服务在这里注册，服务供应者把各种服务说明存放于此，服务恳求者通过服务注册中心搜寻和发现所需要的服务,并得到与服务供应者的服务绑定信息，从而可以与服务供应者进行绑定。这三个角色之间主要有三种Ｗｅb服务操作：发布(Puｂｌｉsh）：发布是一种对服务进行描述,并将此描述置入注册服务器和注册中心的过程。在发布过程中，服务供应者需要通过身份验证，才能在服务器中进行服务描述。查找(Ｆｉnd):查找是服务恳求者向服务注册中心查询服务供应者所供应的服务所处位置的过程。服务恳求者在下述两种情况下使用查找操作:在服务设计时为了简化程序开发查找已有范围的接口描述；在要求服务时为了得到相应服务而查找服务的绑定和位置描述。绑定（Biｎd)：绑定是在服务恳求者在要求服务时，依据相应的描述信息进行服务定位、连接和调用的过程，用以启动服务的交互。绑定所基于的信息是一组服务恳求者和服务供应者之间的描述信息，包括服务的访问路径、调用参数、返回结果、传输协议、平安要求等。服务供应者将服务部署在Web上，通过使用WSDL来描述Ｗeb服务所供应的功能。服务供应者将所部署的服务发布在Web上，由服务注册中心帮助服务供应者和服务恳求者找到彼此。服务恳求者使用AＰＩ向服务注册中心寻求它所需要的服务,当服务注册中心返回结果时(将它们作为搜寻结果）,服务恳求者将这些结果与特定服务绑定起来以猎取服务。WebＳervicｅs体系架构模型如图１所示:图１：WｅbSｅrviｃｅs体系架构模型图１中显示了WeｂＳervｉces体系架构模型包括的三种角色和角色之间的三种操作。另外，相关的两个概念是服务和服务描述，服务是Iｎｔｅrｎeｔ上的软件,这些软件是服务供应者在Intｅrnet上发布的，服务恳求者通过调用或交互获得服务;服务描述包含接口和实现的简略细节，包括数据类型、操作、绑定信息和网络位置等。在有些服务描述中还包括分类和其他元数据信息，这些信息通常是为了协助服务恳求者发现和使用服务.服务供应者可以把服务说明直接发送给服务恳求者(一般是特定服务）,或者发送到服务注册中心,由服务恳求者到统一的注册中心来查找（一般是通用服务).国内外标准化组织的工作内容及进展情况目前从事WｅｂSｅrｖiｃｅs标准化工作的组织主要有国外的W3C，OＡSIS（ＨYPEＲLＩＮK"http：//wwｗ．oａｓｉs－opｅ／"OｒｇaｎｉzａtｉｏnfoｒｔhｅAdvanｃｅｍｅntofStrｕｃtureｄIｎforｍａtioｎＳtanｄａrdｓ)，ＷS-I(HYＰERLIＮK"hｔtp：//wwｗ。ws－ｉ．oｒg／＂WｅbServｉｃeｓＩnｔerｏperａbilityOｒｇaｎiｚaｔioｎ）和ＯGF（ＨＹＰEＲLＩＮＫ”http：／/wｗw．ｏｇｆ．org/”ＯpeｎＧrｉｄForuｍ).以及国内的万维网联盟。下面分别对这几个主要的标准化组织在Weｂserｖices方面的商量情况和进展进行总结。W３CW３C是一个国际化的开发万维网标准的联盟机构,W3C商量的技术以Acｔivitｉｅs来划分，每一项技术均属于一个Ａctｉvitｙ。W３CＡcｔivities通常分为以下几组［３]：工作组（WorｋiｎｇＧrｏup):从事技术开发工作,其产出通常包括技术报告、软件、测试套、及对其他组的产出进行评论等。爱好组（InteｒestGrouｐ)：负责一般性工作,其主要目的在于将那些盼望评估具有潜力的Web技术和策略的人们集中到一起，并向他们供应沟通想法的论坛。协调组（CｏordinａtioｎGｒｏｕp）：负责管理W3Ｃ内部组之间或与Ｗ３C之外实体之间的依靠关系并便利它们之间的通信。W３C中负责商量WeｂSｅrvｉcｅs技术的Actiｖity是体系结构域中的WｅbSeｒviｃesActivity。该Activity包含一个SeｍaｎtｉcWebＳerviceｓ爱好组，一个ＷebSｅrｖicｅｓ协调组,以及以下八个工作组:SeｍａｎticAnnotaｔiｏnsfｏrWebSeｒｖiｃｅsDeｓｃriptｉoｎLaｎｇuage工作组[4]:开发一个可以允许注释Ｗebsｅrｖｉceｓ描述的机制，该机制利用ＷSDL２。0扩展机制的优点以在Wｅｂserviceｓ中获得对语义既简洁又一般的支持.WｅbServicｅsAddresｓｉnｇ工作组［5］:通过提炼ＨYPEＲLＩＮK”ｈttｐ：／/wｗｗ．／Ｓubmiｓsioｎ/2０0４/SUBＭ-ws—addrｅｓｓing－2００4０810／"ＷS-Addressiｎg来标准化引用和寻址WｅｂSｅrvices的机制。WｅbＳerｖiｃｅsChoreoｇraｐｈy工作组［6］：创建Ｃhoreograｐhｙ的定义、描述Cｈoreｏｇrａｐhｙ的语言、以及在ChoreogｒａpheｄＷeｂserｖｉcｅs之间进行组合和交互的规章.ＷebServiｃesＤeｓcripｔion工作组［7]:设计接口的组件,包括消息、消息交换模式和协议绑定。WebServｉcesPoｌｉcy工作组[8]：标准化表达Webservicｅ的能力和需求的通用策略框架.该框架包括:表达Ｗｅbservｉce能力和需求的策略数据模型;合并和比较Ｗebserviｃｅ能力和需求的处理模型;表示策略数据模型的XMＬ信息集。XMLＳcheｍａPaｔｔerｎsｆｏrＤａtabiｎdｉnｇ工作组［9］:致力于识别一组通用的数据抽象并为它们定义一套推举的XMLScheｍa模式以简化XMLＳｃｈema到被识别的数据结构的映射。XMＬProtocｏl工作组[1０］:依据需要维护和开发SOＡP1。2规范及其扩展.WebSerｖｉceｓArｃｈitecｔｕｒe工作组(已结束)［11］：设计一个合理的WeｂSeｒvｉces体系结构。WebSｅｒvｉcesActiｖity各工作组的产出文档及相关实现如表1所示.表１WebＳeｒｖiceｓＡctiviｔy各工作组的产出列表工作组名称产出文档相关实现状态文档名称文档内容时间SemａntｉcAnnotatｉonsfｏｒWＳDLWDSeｍantｉｃＡnｎotatｉｏnｓfｏrＷSDＬ为ＷＳDＬ定义扩展属性来描述ＷSDL组件的附加语义2006—09—2８暂无SｅmantiｃＡnnoｔａｔｉonsｆorWSDL-UｓａｇeＧuideＳAＷSDL规范的伴随文档，给出描述如何将语义注释与Webseｒｖice联系起来的例子2006-09-2８WｅbSeｒviceｓAddｒessingRECWebSｅrviｃesＡddreｓsing1.0-Ｃorｅ定义一套抽象特性和一个ＸML信息集表示法来引用Webseｒｖiceｓ及便于消息中endｐｏｉnts的端到端寻址2006-０5-09１）CＲTestSuitｅ—CoｒeandSOAPｂｉｎdｉｎｇ２)CRＴestSuite-ＷＳDLbinｄinｇWｅbServicｅsAdｄreｓｓiｎｇ1．０－SOAPBiｎdinｇ定义WebSｅrviｃeｓAdｄrｅｓsinｇ1。0–Ｃoｒe中定义的抽象特性到SOAＰ消息的绑定２006-05-０9CRWebServｉcesAddｒｅssing1。0-ＷSDLＢinding定义如何使用WＳDL描述WｅbSｅrvｉｃｅｓAｄdressｉng１．０–Coｒe中定义的抽象特性２０06—05－29GNＳOＡP1.1RｅｑuestOptionalResponｓeHTTPBiｎdｉngSOＡP１．1为交换恳求和响应给出的HTTP绑定供应“恳求可选响应"，允许具有状态码20２的HＴTP响应具有一个SOAＰ包封或为空２006—03－21WeｂSｅrｖiｃｅsＣhoreogｒａpｈｙＣRWｅｂSeｒｖiｃeｓChｏｒeｏgrａphyＤescriｐtionLaｎgｕａｇｅ从全局视点定义参加者共同互补的行为，从而描述参加者端到端合作2005—１1—09暂无WDWｅｂServiｃesCｈorｅogｒaphyRequｉｒeｍeｎts基于一组代表性的用例，为ＷebSｅｒｖicｅsＣhｏrｅｏｇrａphｙ描述需求2００4－0３-11ＷeｂＳｅrvicｅｓChoreogｒaphyMｏdeｌOveｒｖｉｅw供应定义Choreograpｈy所需的信息模型来描述数据和数据间关系2０04—０3—24WebＳervicｅsCｈoreｏｇraphyDｅscriｐtｉonLanｇｕａge：Primｅｒ为理解WSCDL的用法和特性供应教程２0０6-06-19ＷebSｅｒvｉcesDｅscrｉptｉonCＲWeｂServicｅsDesｃrｉptｉoｎＬangｕａge（WＳDL）Ｖeｒｓiｏn2.0Ｐａｒt0:Ｐｒiｍer对WSDL简洁和非技术性的介绍2００6—03-271)HYＰERLINＫ"ｈttp:/／iｎｃuｂａtor.apａchｅ．ｏrg/ｗｏdｅn/＂ApacｈeＷoｄeｎ：WSＤL2。0的解析器和验证器;2）HYＰEＲＬＩNＫ＂ｈｔtp：//wｗw。ｗ３.oｒｇ／２００6/0２/ＷＳＤＬConverｔ.htｍl"WSDL1。1toWSＤＬ2．0conｖｅrｔｅrWebSeｒvicｅｓDescrｉｐtionLaｎｇｕaｇe（WSDL）Vｅrsion2.0Ｐａrt１:ＣｏreLａnｇuage描述WSDL2．０20０6—03-２７WebSerｖiｃesDｅscripｔionLanｇuagｅ（WSDL）Veｒsion2。0Ｐａrｔ2：Adjｕnctｓ定义WSＤＬ中用到的预定义扩展：消息交换模式、操作风格、绑定扩展2０06—03-27WＤWebSｅｒｖiceｓＤescriptiｏｎLａｎｇuage（WＳDL）Vｅrsion2.0ＳOAP1．1Bindinｇ描述ＷSＤＬ2．0与ＳOAP1。1协议一道使用的简略细节20０6-０3—２7ＷebSerｖiｃesＤescripｔｉonＬａnguaｇe（WSDL）Versｉon2．０:RＤFＭapping描述以RDF和OWＬ建模的表示法，以及将特定WSＤＬ转换到ＲDF格式的映射步骤2０06-０3-27WｅｂＳerviｃesＤescｒiｐｔiｏnRequiｒeｍents为ＷebＳｅｒvicesＤesｃｒiｐtiｏnSｐecｉfiｃａｔｉoｎ描述工作组的需求2０0２-１0—28WebServicｅsDesｃriptｉoｎＵｓａgeＳcenariｏｓ描述指导WSDL开发的使用场景2002－06—0４ＧNDescribｉｎgＭediａCｏnteｎtｏfＢiｎａｒyDatainXＭL需要在XＭＬ文档中表明及在ＸＭLSｃｈｅma中规定与二进制元素内容相关的内容类型２005－05—０4DiscuｓsioｎoｆAｌｔｅrnａtｉvｅSchemaLangｕaｇesandＴｙpｅＳｙｓｔｅmＳuppｏｒｔinWSDL2．0明确ＤTD（文档类型定义）和RｅlａxNG的基本扩展200５-08-17ＷeｂＳervicesPoｌｉcｙWDWebSerｖiｃeｓＰolｉcy1．５–Framｅwork供应通用模型和相应的语法来描述基于Weｂservicｅｓ的系统中实体的策略2０06－11—17暂无WｅbSeｒviceｓＰｏｌiｃy1.5-Ａttaｃｈmｅｎt定义两个通用机制来关联策略20０６－1１－17ＷｅbServicesPoｌiｃｙ1.5－Pｒｉｍeｒ对WeｂSｅｒvｉcesPoｌｉcy语言进行介绍性的描述２0０６—１０-1８XMLScheｍaＰatterｎｓfｏｒＤataｂｉｎdiｎｇWＤBaｓｉｃXＭLScheｍaPaｔｔerｎｓｆｏrDａtａbiｎｄinｇ1．0供应一套基本的在现有数据绑定实现之间是可互操作的ＸＭＬＳcｈeｍa１。0模式２0０６－11-２2监测XMLＳchｅma或WSDL文档所呈现的模式的HYPERLINK＂htｔp:／/wwｗ．w3。oｒｇ／２0０2/ｗs／dａtabｉndinｇ/ｄeｔｅctor”ＤｅtｅctｏrAdｖａncedＸMLSｃhemaＰatteｒnsｆorDａｔabiｎdｉｎg１.0供应一套通用的XMＬSｃｈema１.0模式2006-11-22XMＬSchｅmａPaｔterｎsforＣommoｎDaｔaStrｕcｔｕｒｅｓ1．０供应一套简洁的XMLＳchema１。0模式,可用于描述常常使用到的数据结构的XＭL表示法2０06－０5-１２XMLProｔｏｃolRECSＯAPＶｅrsiｏn１。２Ｐarｔ０:Ｐrimｅr供应理解ＳOAＰ1。２规范的教程２0０3-0６—241）HYPＥRＬIＮK”ｈｔtp:／／ws．apache。ｏｒg／axis/”ApａcheAxis：SOＡP的实现,最新版为ｖ1.４fｉｎal。２）HYPＥRLINＫ”hｔtp：//wｓ．aｐaｃｈ/axｉｓ2／”ApacｈeAxiｓ2:AｐaｃhｅAｘｉｓ的改进和扩展，最新版为v1．１。支持ＳOAＰ1.1，SＯAP１。2，以及WS—RｅｌiａｂleMeｓsａgｉnｇ（SｕpporｔeｄｂｙAｐａｃｈeＳａndesｈa２);ＷＳ-Coｏrｄinatｉon和WS－AtomiｃＴransactiｏｎ(SuｐporteｄｂyApａcheKａｎduｌａ2);ＷＳ－Ｓecｕrity（ＳｕｐｐｏrtedbyＡpacheRampａrｔ）；WS－Adｄreｓｓiｎg.SOAPＶｅｒsｉｏn1．２Pａrt1：MesｓａgｉngFrａmeｗorｋ使用ＸＭL技术定义可扩展的消息传递框架,包含可在多种底层协议上交换的消息结构200３-０6—24ＳOAPVｅrsｉon1．2Part2:Adjuｎcｔｓ定义ＳOAPVｅrsｉon1。２Paｒt1：MessagｉngＦrameworｋ中可能用到的一组附属物2003—０6－2４SOAＰVｅｒsiｏn1．2ＳpｅcifｉcaｔｉoｎAｓsertiｏnsａｎｄTｅsｔCｏｌleｃｔｉoｎ供应一套测试来推断SＯAＰ处理器是否实现了ＳOAP1.2中的断言2003-06－24ＳＯAＰＭesｓaｇeTraｎsmiｓｓiｏnＯpｔｉmiｚａtionMｅchanism描述优化SOＡP消息的传输和/或无线格式的抽象特性和简略实现2００5—01－２5XＭL－bｉnａｒyOｐtｉmiｚｅｄＰackaｇｉｎｇ定义一种更有效的序列化具有膜类内容的XML信息集的方式XＯP2００5-01-2５ResourceＲeｐresｅntａtiｏnSＯAPＨeadｅrBloｃk描述SOAP消息中承载资源表示的SOAP头的语义和序列化信息2０0５－0１－25ＷDXMLProtocｏlＡbstrａctMｏdeｌ（announcｅment）描述XML协议的抽象模型20０３-０2-２0SＯＡＰOptiｍｉｚedＳerializatｉｏｎUseCasesanｄＲeｑｕｉｒemenｔs记录用例并规定优化SOAP消息处理和序列化的需求2004—０6－08GNXＭLＰｒotocｏl（ＸMＬP)Ｒeｑuiremｅｎｔｓ描述XMLProtoｃｏl工作组的需求200３－０７－28XMＬPrｏｔocoｌUsagｅSｃenarios描述SOAＰ使用场景以及如何使用ＳOAＰ１.2规范实现之２0０3－07-３０SOＡP１.2AttaｃｈmentFｅatｕｒｅ为ＳOＡＰ附件定义表示抽象模型的SOAＰ特性2004-06-0８SＯAPＶeｒsioｎ1。２EmaiｌBiｎｄｉng说明白SＯAP1．２协议绑定框架应用到Ｅｍaｉl(RFC2８２2）上２002—０６—26ＳOＡPＶersion１．2MeｓｓａgeＮｏｒｍａlizａtiｏn定义同样的交付全部语义等同的SOＡＰ消息的转换算法2003-1０—08ＸOPIncｌuｓioｎMeｃhａｎisｍ－FrequｅntlｙAｓkedＱuｅｓtioｎｓ在建设XＯP的过程中，对ＸＭLProtocｏl工作组的包含机制的选择２0０4-06－08ＤescｒibingMedｉａCｏｎtentofBinａrｙDatainXＭＬ需要在XML文档中表明及在XMLＳcｈｅma中规定与二进制元素内容相关的内容类型2０05-05-04RFＣＴｈｅ”apｐlicatioｎ/sｏａｐ＋xml”medｉatｙpe（RFC３902）定义可被用来描述ＳＯAP1。2消息的“applｉcatioｎ/soａp+xｍl"媒介类型２00４－09WebSｅrvｉｃesＡｒchitecｔurｅGNWeｂＳｅｒｖｉcesArchitｅcturｅ定义WebＳeｒｖｉｃes体系结构，定义功能组件和这些组件之间的关系2０04—０２-11暂无ＷｅｂSerｖｉceｓAｒcｈitectureReｑuirementｓ为Wｅbｓervｉｃes标准参考体系结构描述一组需求2０0４－0２-11WebＳeｒvicesGlｏsｓaｒy定义ＷｅbSerｖiｃes体系结构定义和使用到的词汇表2004-0２－11WｅｂSｅｒvicｅｓArchｉtecturｅUsａgeScｅｎarios描述WｅbSeｒvicｅs体系结构的用例和使用场景2004－0２－１1ＷeｂSｅrｖｉceＭanａgemenｔ：ServｉceLifeCyｃle描述Websｅrvｉcｅ的生命周期，以及由Weｂｓeｒｖice执行的恳求处理２00４—０2－11注:ＣR：CandidateRｅｃoｍmendａtioｎ;REＣ:Recomｍendaｔiｏn；WＤ:WorkiｎgDrａｆｔ;GＮ:ＷｏrkinｇGroｕｐNoteＯＡSＩSOＡＳIS成立于１９9３年，是一个非营利的国际性团体，致力于驱动电子商务标准的开发、融合和接受。它产生全球性的标准，掩盖平安、WebServicｅs、全都性、商务交易、供应链等多个方面.ＯＡＳIS具有两个关于ＸML和Ｗｅbseｒviｃes标准的信息门户:HYPＥRLIＮK＂ｈｔtｐ:／/ｘml．ｃoveｒpaｇeｓ.ｏrｇ/”CoverPａｇeｓ和ＨYＰＥRLＩＮK”httｐ://ｗww．xml。ｏrg/＂ＸMＬ.ｏrg.OAＳＩＳ的工作通过技术委员会（ＴC:TｅchｎｉcａlCoｍmｉttee[12］)的形式展开,在ＷｅbSｅｒｖｉcｅs方面包括以下ＴC：AｓyｎｃｈronousSｅｒvｉceＡccessProtocol(ASＡP)TＣ[１3]:创建SＯAＰ协议的简洁扩展,用来支持异步或长期运行Ｗｅb服务的启动、管理和监控。ｅbXMLBuｓiｎｅｓsProceｓsＴＣ[１4］：供应基于标准的商务流程来提升使用ＸML定义的商务协作的自动化和可推测性。eｂＸＭＬＣoｌlaborationProｔocｏlPrｏｆileａｎdAgrｅeｍent（CＰＰA)TC［1５］：描述交易参加者如何通过交换电子信息进行电子商务交易。ebＸMＬＩｍｐlemｅｎtatioｎ,InterｏperabiliｔyandＣonfoｒmaｎｃｅ（ＩＩC）TC［16]：允许软件供应者创建遵守ｅｂXＭL规范并可与ebXMＬ规范进行交互的基础设施和应用。ｅｂXMLＭｅｓsagｉnｇServicesＴＣ［１７］:定义电子商务交易的传输、路由和封装机制.ebＸMLRｅgｉｓtryTＣ［1８］：定义和管理可互操作的注册中心及存储库。EｌｅctｒoｎｉｃBusinｅsｓServicｅOrienteｄＡrchitｅｃture(ebSOＡ）ＴC[19]：提出电子商务中使用SOＡ(面对服务体系结构)的架构模式。FramewoｒkｆoｒＷｅbServｉcesＩmｐｌementatｉon（FＷSI)TＣ［20］：定义主要的、多平台的、厂家中立的、跨行业的ＷebSeｒｖｉｃｅs实现方法和功能组件。OpenBｕildｉｎgInfｏrmaｔionＥxchaｎgｅ（ｏＢIＸ）TC［21]:定义支持建筑物中的机械和电子掌握系统与企业应用进行通信的协议。TransｌaｔionWｅbSｅrｖicｅｓＴC［22］：将自动化转化和定位的流程实现为WｅbServiｃe。ＵＤＤISｐecifｉcaｔiｏｎTC[23]:定义能够动态的发现和调用WebServicｅs的标准方法。WeｂServicｅsＢｕsｉｎｅssPrｏｃessEｘecuｔioｎLａnｇｕａge(WＳＢＰEL)ＴC[24]:使用户可以便利的将业务流程活动描述为ＷebＳeｒvｉｃes,并定义如何连接这些活动以完成特定的任务。WｅｂSeｒvｉcｅsCｏmpｏsｉteＡｐpliｃaｔionFramewｏrｋ(WＳ-CＡF)TC[２5]:定义一个开放框架用来支持多个WebＳｅrｖiｃeｓ应用之间进行协作的组合。WebＳｅｒｖicesDｉstｒｉbutedMａnagemｅnｔ（ＷＳDM)TC[26]：定义一个WｅbＳｅｒｖiceｓ体系结构来管理分布资源。ＷeｂＳｅｒvicesfoｒRemｏtePoｒtｌｅts(WＳRP）TＣ[２7］：通过汇聚诸如门户等媒介来标准化使用面对表述的WebSeｒvｉces的方法。ＷｅｂＳｅrvｉｃｅｓNotｉｆicａtion(WＳN)TC[28］:为WｅbSeｒvicｅs供应一种发布和订购通知/大事的标准方式.WｅｂSeｒvｉcesQuaｌitｙModｅｌTＣ［29]:定义通用的标准来衡量服务互操作性、平安和可管理性方面的质量水平。ＷｅｂServicesRｅlｉａｂleＥxｃhange(WＳ—ＲＸ)TC［３0]：提出访用WebＳeｒvｉｃes进行牢靠的信息交互的协议.WｅbSｅrvｉceｓＲelｉabｌeMessaｇｉng(WSRM)TC[31]:WＳ-Ｒeliabilitｙ1.1供应了一个标准的、可互操作的模型来保证消息传递到应用或ＷeｂＳeｒvicｅs。WｅbServｉcｅsResoｕrceＦrａｍeｗork(WＳＲF）TC[32]：定义一个使用WeｂSeｒｖｉces对有状态资源进行建模和访问的开放框架。WebSeｒviｃesSecureExｃｈａnge（ＷＳ—SX）ＴC［３3］：定义ＷS—Security扩展和策略来允很多个SOAＰ消息进行牢靠的交互。WebServiｃesＳecuritｙ(WSS）TC[34］：为实现平安功能供应技术基础，如在实现更高层WebServｉces应用的消息的完整性和平安性.WebＳeｒviｃesTransａction（WS－ＴX)TC［35]：定义用来协调分布式应用程序活动产出的协议。OＡSIＳWｅbservｉｃeｓ方面各ＴC的产出文档及相关实现如表2所示。表２OAＳIS在Ｗebsｅrｖicｅs方面各TC的产出列表工作组名称产出文档相关实现状态文档名称文档内容时间ASAPCＤAｓyncｈronousServicｅAｃcｅssProｔocol（ASAP)Vｅｒsｉon１.0创建SＯＡP协议的简洁扩展，用来支持异步或长期运行Web服务的启动、管理和监控200５－05—18ＥａsｙＡＳAＰ：C＋+实现;AｘｉsAＳAP:Jａva实现；ｅbXMＬBusinｅssProcesｓCＳｅbXＭLＢusｉneｓsＰrocｅsｓＳpecifｉcatiｏnSｃhemａTeｃhnｉcalSｐecifｉcationｖ2．0．4使用XＭL定义基于标准的促进业务合作定义自动化和可推测交换的业务流程基础２00６-10—13ebＸMLＣPPAOSColｌaborａtioｎ-PrｏtｏcolProｆｉｌeaｎdAgｒeｅmｅntＳpｅcｉfiｃａtｉｏnＶｅrsion2．0简略定义Collaｂoraｔion—PrｏtｏcoｌＰｒｏfiｌe和Collaｂoratioｎ－ＰrotocolAｇｒeｅmｅｎt200２-09-23ｅbXMLIICCSｅbXＭLTestFrameworkv１。0为ｅｂXＭＬ规范自动运行的测试套描述一个测试框架２004－10—11EDeｂXＭLEAＮ—ＵCCＤeployｍentGｕidefoｒebMSＧ描述为EＡNUCＣ规定的ｅbXML消息服务实现的细节20０３-0４－07ebXＭＬMｅssagｉｎｇServicｅｓWDeｂXMLＭesｓagiｎgSeｒviｃｅｓ3。0：Pａｒｔ1,CoreＦeatureｓ定义用于交换电子商务消息的与通信协议中立的方法2０06-1２－14ＣDebXＭＬMessａgiｎgＳervices3.０:ＣｏnfoｒmａｎceProfiｌes定义支持特定消息传递方式或使用上下文的全都性ｐｒoｆileｓ2006—０6—14ＯSｅｂXMLMesｓageＳerviceSpｅｃificatiｏn2．0定义用于交换电子商务消息的与通信协议中立的方法2０02－0４－０１ebＸＭLRｅgistryOSｅbXＭLRegisｔryInfoｒmaｔｉonMｏdｅlv3.０定义可存储在ebXＭL注册表中的元数据和内容类型200５－０5-０2ｅｂXMLRｅgisｔｒｙＳerviｃesａndPｒotｏcolsｖ3。0为eｂXML注册表定义服务和协议2005－05-0２ebSOＡ－--－-FWＳIＰRＤWｅbＳerviceImplementａtionMｅｔｈodｏlｏgy在ＷｅｂＳｅrviceｓ实现方法学中规定WebServｉce相关活动2005-０７-0６CDＦunｃtionalＥｌemｅntsＳpecifｉcａtｉｏｎ2.0描述了一组功能元素200６－０9—2１ｏＢIXCDoＢIＸＳpeｃｉfiｃation为机-机通信规定对象模型和ＸＭL格式2006－0３－31ＨYPEＲLINK”hｔｔｐ://soｕrceｆorgｅ。net/projeｃｔ/ｓｈowｆilｅs.php？groｕｐ_iｄ=１4８48０＂ＯbｉｘJavaToolkitTrａnsｌatｉonWｅbServiｃeｓ-—-－-UDDISpecifｉcaｔionＯSUDDIVｅrsｉon3描述UDＤI注册中心全部实例的WｅbSerｖｉcｅs、数据结构以及行为2０0５—02－０3JＡX—ＲPCClientfｏrUDDI3.0.2WSＢPELCDWｅbＳerviｃesＢｕｓｉｎessＰrｏcessExecutionLaｎgｕagｅVersｉon２.0定义描述基于ＷebＳeｒvices的业务流程行为的语言200５-1２-21WS－CＡＦＣDWS－CoorｄinａtｉｏnFｒameworksｐeciｆicatｉonaｎdａｓｓｏcｉatｅdXＭL供应一组基于标准组件服务定义机制来创建融和其他应用的多种服务2005-１0—24WSＤMＣDWSDMＰriｍerｓ帮助开发者理解WＳDM２006－０2－24ＯSWＳDM1.1将Wｅｂseｒviｃｅs体系结构及相关技术用于分布资源的管理2006－08—01ＡｐacｈｅMuｓeWＳRPOＳWSＲP1。０允许应用程序设计者或管理者选择符合的远端内容和应用程序供应者2003—08WSNＯSWS-BａsｅNotｉficａtion1。3使用基于主题的发布/定购模式定义标准的Wｅｂseｒｖiｃｅｓ通知方法2006-１０-01WＳ-ＢｒｏkereｄＮotificatiｏn1．３２0０6－1０—01ＷS-Topiｃｓ1.3200６-10－01WｅbSｅｒviceｓQualitｙMoｄｅlCＤQuａliｔyMｏdelfｏrWeｂSｅrｖiｃｅsv２.0供应在开发和使用WebServiｃｅs过程中的质量管理模型２0０5－0９WS-RXCDWｅbSｅrvicesＲeliabｌｅＭesｓaｇingv１.１描述允许消息在节点之间被牢靠传递的协议2０06—０8—11CＤＷebＳeｒviｃesReliableMessａgingPoliｃyAsseｒｔionv1．１为WＳ-ReｌiableMessａginｇ描述领域特定的策略断2006－08-11WSＲMOＳWebＳerｖｉcｅsReｌiaｂｌeMｅssａｇｉnｇTCWＳ-Rｅliａｂilｉｔy1。1定义基于SＯＡP的协议来交换具有保证的传递的、无重复的和保证消息序列的ＳOAＰ消息２0０4－１１—15AｐacｈeＳanｄesha2WSRＦCDWＳRFＰriｍer用简略实例介绍WＳＲF2006－０5—２３ＯSWＳRFv１.２定义Webseｒviｃeｓ可用全都并可互操作的方式来访问状态的框架2０06－０4-01CSWS-ReｓoｕrceMetadatａDeｓcｒiｐtoｒｓｐｅｃifｉcａtiｏｎ提出表示元数据的信息模型2０06-０6－27WS—SX—WSSOSWS－Secｕｒity1。１描述对SOAＰ消息传递的改进来供应消息的完整性和保密性2006—０2—01ApａcｈeＲampaｒｔWS－TXＰＲＤWS-Ｃoordｉnaｔｉonv１。1描述可扩展框架来供应协调分布应用动作的协议２006－08-３0ＷS－AtomｉcTraｎｓaｃtioｎv1。１定义与扩展协作框架一起使用的原子交易协作类型2006-08-３０ＷS—ＢｕsｉｎessＡctivｉｔyv1.1定义与扩展协作框架一起使用的业务活动协作类型2００6—1１—０8注:CD：CommｉｔteeＤrａｆt；ＣS：CｏmmitteｅＳpeｃｉｆｉcation;OＳ：ＯASISSｔａｎdaｒd;ＥD：Ediｔoｒ’sDｒafｔ；PRD：PublicｒeｖiewdraftsWS－ＩＷS-I是一个开放的组织,旨在推动ＷebServicｅｓ跨平台、跨操作系统、跨编程语言的互操作性。ＷＳ—Ｉ的目标在于获得WebSerｖiｃｅs的互操作性；加速WebServｉｃes的部署；以及鼓励WｅｂSｅrvices的应用等.WＳ-Ｉ的产出为Websｅｒviceｓ开发者供应资源来创建可互操作的Websｅrｖices以及验证他们的结果与ＷS—I指南的全都性［３６]。WS—I的产出主要包括:Ｐroｆilｅs：为如何同时使用相关Ｗebservｉces规范以获得最佳互操作性供应了实现指南。示例应用程序：展现与ＷＳ－I指南全都的Ｗebsｅrvｉｃeｓ应用程序，这些实现是使用多种不同的平台、编程语言和工具开发的，用于展现起作用的互操作性并为Wｅbｓｅrviｃes开发者供应可用的资源.示例应用程序用作开发者在他们的开发环境中遵循ＷＳ-I指南的工作示例.测试工具：用于推断与Wｅｂｓeｒviｃｅ的消息交互是否与WS—I指南全都.这些工具监视这些消息并分析产出日志来识别全部已知的互操作性问题。WS-I目前的工作组包括:ＢａsicＰroｆile工作组[37］:为WebＳeｒｖiｃes供应基础的核心规范集合。该工作组目前正在进行ＢａsicProfｉｌe１.2和ＢaｓicPｒofｉle2。0的工作.ＢasiｃSｅｃｕritｙPｒｏfile工作组[３8]:正在开发处理传输平安、SOＡP消息传递平安以及其他面对BａsiｃＰｒofile的Webｓeｒviｃes平安考虑的互操作性pｒoｆilｅ.ReliabｌeSecｕreＰroｆiｌｅ工作组［39]：开发关于Wｅbseｒvｉces的平安及牢靠消息传送能力的互操作ｐrofiｌe。RequirementsＧａthｅring工作组［40］：识别并理解Weｂｓｅrvicｅs互操作事宜并为新的WS-Ipｒofiｌｅｓ阐述需求。ＳａmpleApplｉｃation工作组[4１]：定义将从可互操作的Ｗeｂｓerｖicｅｓ应用程序中获利的示例场景，并设计示例应用程序来说明WS-Ｉprofileｓ在那些场景上的应用，为多厂商平台上的实现展现最佳实践。ＴestinｇＴooｌｓ工作组［４2]：开发自管理的测试来验证与WS—Ｉprｏｆilｅs的全都性。XＭＬSchemａWｏrｋPlan工作组[4３］：为XＭLScｈema互操作事宜计划合适的解决方案。WS-I各工作组的产出文档及相关实现如表３所示.表３WＳ-I各工作组的产出列表工作组名称产出文档类别状态文档名称文档内容时间BａsｉcＰrofｉleＰｒofｉｌeＷorｋingGｒoupＤｒaftBaｓiｃPｒoｆilｅ１．2在BasiｃProfｉｌｅ１．１的基础上引入了ＢasicProfilｅ1。1erraｔａ,来自SiｍpｌｅSOAPBｉnｄingＰｒoｆilｅ1.０的需求，并加上了对WＳ—Addresｓing和MTＯM的支持2006—10—１７FiｎalＢａｓiｃＰｒｏfile1．１SecｏｎdEditiｏｎ涵盖了全部目前的eｒratａ，为Ｗeｂserviｃes的基本SＯAP消息传递供应了互操作性指南２０06—04—10ＢasiｃＰroｆiｌｅ1．０为非私有Webserｖicｅｓ规范的核心集合（如ＳOAP、WSDL、ＵDDＩ）供应了互操作性指南，还有对这些规范提升互操作性的澄清和补充2０04—0４－１6ＡtｔachｍｅntsPｒｏfile1.0ＳecｏｎｄEdiｔiｏｎAｔtaｃhmｅntPrｏｆiｌe１.0对ＢasiｃProfile1。1进行了补充，为可互操作的SＯＡＰ消息增加了对基于附件的Ｗｅbsｅrｖiceｓ的支持，该其次版包括目前全部已知的errａta2006-０４－20SimｐleＳOＡPBindｉngProｆｉｌｅ1.0包含与包封序列化及其在消息中的表示法相关的ＢａsｉcPｒofｉlｅ1.0需求,涵盖了目前的ｅrｒaｔa2０04—０８—2４SpecifｉｃａtioｎFｉnaｌCｏnfirmancｅＣlaimＡｔｔachｍentMechaniｓm定义可用于对Wｅbservｉｃes产物声明附加全都性的机制2００４—1１-15ＢaｓｉｃSecｕｒｉtyＰroｆilePrｏfileＷorkｉngＧｒｏuｐDraftBａsiｃSeｃurityProｆilｅ1．1供应使用WS—Secｕrｉty１.1和ＲＥL,Ｋerbｅros，ＳAML，ＵsｅrNａmｅ和Ｘ．509平安令牌格式的指南20０6-1０－19ＷorkiｎgGｒoupAｐprｏvaｌDrａｆｔＢａsicSecｕrｉｔyPrｏｆilｅ１．０供应使用WS-Secuｒitｙ和ＲEＬ，Kerbｅroｓ，SAML，UseｒName和Ｘ.5０９平安令牌格式的指南2０0６—０8—1７SupeｒｓｅdｅdＫerｂｅrosToｋenＰrofilｅ与WS—Ｓecurity一起使用的Kerbeｒｏs平安令牌的互操作性prｏfilｅ２006－0１—10RELTokenＰroｆiｌe与WＳ—Seｃuｒity一起使用的REＬ（权利表示语言)平安令牌的互操作性ｐrｏfile2００6-０1－1０SＡMLTｏkｅnPｒofｉle与WＳ－Secｕrｉty一起使用的SＡＭＬ平安令牌的互操作性ｐrofｉle２00６-０1－１0ReliabｌeSecuｒｅProfileＳpeｃｉficａｔiｏnWorｋｉnｇＧｒoupDｒaftReliablｅSecｕｒePrｏfｉｌeUｓａｇｅScenaｒｉoｓversｉon1.0定义构成即将在RSP1．0proｆiｌｅ中描述的场景集合的互操作性场景20０6－11—06RｅｑｕirementｓＧathｅringTemplateWorｋingGｒoupDｒaftRｅｑuiｒementsＣoｖeｒSheet用于向WＳ－I提交互操作性需求２004—0９-27SｃｅnarｉoSｕｂｍiｓsｉoｎＰrocess指导如何向WS-Ｉ提交带考虑的互操作性场景20０4-09—27BdＡDＳpeｃiｆｉcａtionａｎｄＩssuｅＬiｓtTeｍpｌａtes用于使用XML书写规范和跟踪问题列表２0０4—01－２９ＢuｓinessScｅnａrｉｏＴｅmplａte用于记录商务场景2004—０１—27ＵｓeCasｅTemplate用于记录用例２0０4—０1—2７SampｌｅAppｌiｃａtioｎIｍｐｌementatiｏnWorkingGｒoｕｐＤｒａｆtＳａｍpleApplicaｔioｎＩmpleｍentaｔｉonsforBSＰ供应BaｓicSecｕrityProfilｅ1．０中给出的指南的实现200６－0５—2５FiｎalSaｍｐｌｅＡpplｉcaｔiｏnＩｍplｅmentａtｉoｎｓ以一组用例的形式给出一个供应链管理应用程的例子2003－12－０９ＳpｅcｉficａtioｎWorkiｎgGｒouｐＤrａfｔＳamｐleAppｌicａtionsSecuｒｉtｙＡｒcｈitectureＤｏcuｍentSCＭ平安体系结构文档的工作组草案200６—０4－10MｅｍｂerReviｅｗDrａftAtｔachmｅnｔＰｒofileUｓａｇeＳceｎａrｉosAtｔachmentProｆilｅ1。0使用场景的成员评审草案2004－0９02ＦiｎalSaｍpleＡｒchｉteｃtureUｓagｅＳceｎａrios定义在结构化交互中使用Webserｖiｃｅs，为这样的交互明确基本互操作性需求并将场景流程映射到ａsicＰroｆile1．0的需求上２003—12-09SupplｙChaiｎManaｇｅmｅntＳampleＡrcｈｉtecture用于示范２0０3—12—09UsｅCaｓｅｓFinalSｕppｌyＣhaｉnManaｇemｅntUseCases作为ＷS—ＩSａmpleＡppｌiｃatｉｏn1.０的一部分实现，用于示范20０3－１２－０1ＴeｓｔinｇＴｏolsTesｔToolｓWoｒkingGrｏuｐＤrａftBSP1。０EnhaｎｃｅｄLoggｉｎgSｐｅｃiｆiｃａｔｉoｎ定义由WS－Ｉ测试工具使用的增强日志设施来支持BasicSｅｃuriｔｙＰｒｏfiｌe２０06-0７-1３ＦｉｎalＩnteｒoｐerabilityTeｓｔingTools1.1测试BasicPrｏｆｉlｅ1。１和SSＢP1.０2０05—0６-１3ＢｏaｒｄApｐrovａlＤraftIｎtｅropｅrａbｉｌityＴｅｓtingTools1.１（SＳBＰ）测试ＢaｓｉcProfile１.１和SimｐlｅＳOAPBindｉｎgＰrofiｌe1。0２004—12-14SpｅcｉｆｉcatiｏnＦinalAｎａlyzerToｏlＦunctｉonalＳpｅcｉｆiｃaｔionＡnaｌyｚｅr工具v1.1的最终功能规范20０5-06－13MoｎｉtorToolFunctionalSpecｉficationMonitor工具v１．1的最终功能规范20０５－０6—１3TesｔTｏolTesｔAssｅrtionDocuｍｅｎt被Aｎaｌyｚer用于识别互操作性问题２004-01－01ＴAＤWｏrｋiｎgGroｕｐＤｒaｆtBＳＰ1。０TADVerｓion１．０由WＳ-Ｉ工具执行如互操作性Profilｅs规定的测试的正式规范，被Ａnａlyzer工具用来识别互操作性问题2００６—10－17FiｎalAP1。0ＳＳBP１．0ＴAＤＶerｓion1.0支持测试BasicPｒofｉle1．1，ＡｔｔａchmｅnｔｓＰrofile1.０和SimplｅＳOＡPBindinｇPrｏfiｌｅ１．０20０５-０6-1３BaｓiｃProfiｌｅ1.0TＡＤVｅrｓiｏn1．1由WS－I工具执行如互操作性Ｐｒofiles规定的测试的正式规范,被Anaｌｙｚｅr工具用来识别互操作性问题2005-０1－12BａsｉcPrｏfｉle1。1ＴADVeｒsｉon１。1由ＷＳ—I工具执行如互操作性Ｐrｏfilｅs规定的测试的正式规范,被Anａｌｙｚｅr工具用来识别互操作性问题２005－０1－12SSＢP1．０ＢP1.1ＴAＤＶeｒsｉon1.０由WS-Ｉ工具执行如互操作性Pｒoｆｉlｅs规定的测试的正式规范,被Aｎalyｚer工具用来识别互操作性问题200５-０１—1２OGＦＯＧＦ是GGF（GｌoｂａlＧridＦorｕm)和ＥGA（EnｔerpｒiｓｅＧridAｌliance）合并的产物。它是由引领网格计算全球标准化的用户、开发者和厂商组成的团体。OGF通过供应一个开放的关于网格创新的论坛以及开发网格软件互操作性的标准,致力于加速网格的应用［44，45］。ＯGF包括ｅScｉｅnceFuｎcｔｉｏｎ，EnterpriseＦuncｔion和StanｄａrｄＦunｃｔioｎ.eSｃｉenceFｕnctｉoｎ负责与科学、工程和教育团体一同工作，从而使富有成效的论坛识别和联结需求，商量解决方案，并且共享进展。EnterprisｅFｕnｃtｉｏn负责与商业、ＩＴ和厂商团体一起工作,使用富有成效的论坛识别和联结需求，商量解决方案,并且共享进展。StandardＦuｎctｉｏn负责开发体系结构、规范、路线图、词汇和相关活动,例如与网格软件标准化和互操作性相关的“inteｒopfｅsts”。SｔandａrｄFunctｉｏn包括与其他标准开发组织（ＳｔandarｄsDevelopmentＯrgａｎizaｔionｓ,SDOｓ）的技术联络，以及代表新的组织主持技术战略委员会（TeｃｈｎicalStraｔｅgyＣommittee，ＴSC）等。ＯGF产出的网格领域的架构基础OGSA（OpenＧriｄSｅrvｉcesArchiｔeｃtuｒe：开放网格服务体系结构）是基于ＷeｂSｅrｖiｃes的体系结构建立起来的,同时它也对ＷebSeｒvices体系结构的进展做出了相应的贡献.ＯGSA的架构师参加了定义WＳDL2．０和评阅WＳ－Ｓｅcｕｒitｙ等规范的工作，网格领域与WebSｅrｖices领域共同合作推出了建模和访问有状态资源的框架WSRＦ。网格领域的标准化工作与WebServices领域的标准化工作具有亲密的联系。国内相关商量组目前国内WｅbSｅrviｃeｓ标准化方面尚处于跟踪阶段。2０0５年10月，北航成功申请了W３Ｃ北京办事处的挂靠资格，成为中国内地第一家也是唯一一家W3C分支办事处［46],即“HＹPERLINK＂http：//www.ｃhｉnaｗ3c.orｇ/"万维网联盟中国办事处"，该办事处成立于200６年4月1日,现设址于北京航空航天高校(BUＡＡ)。万维网联盟中国办事处的中国会员包括：BｅｉhａnｇＵnivｅrｓity北京航空航天高校BeｉjiｎgUniversityｏｆTechnolｏgy北京工业高校ＣhｉnａＥleｃtroniｃsStａｎｄaｒdｉzatｉｏnＩｎstｉtute中国电子技术标准化商量所ＣhiｎeｓeＡcadｅｍyｏfＳｃiｅnces中国科学院GuangzhoｕＭｉｄdlewareReｓearchCeｎter广州中间件商量中心iＦLYTEK安徽中科大讯飞信息科技有限公司iflｙｔｅkIpeｄo,Iｎc．倍多科技UncｏverCｈｉnａ另外,还有一个联盟，为“中国万维网联盟（HYＰＥRＬINK”ｈttp://w3ｃhina．org/"W3CHIＮＡ)”［4７］,是一个致力于商量、传播、商议 W3Ｃ标准的开放组织，成立于２003年6月２0日.中国万维网联盟旨在为Wｅｂ应用的开发者和商量者供应一个学习、商量、商议 W3Ｃ与Wｅｂ技术的平台，它本身不产出标准.WebSｅrｖicｅs的技术及特点WｅbServｉｃes概念栈通过WｅbＳeｒvｉcｅs概念栈,可以比较直观地了解ＷｅbＳervices中的技术。WeｂServicｅｓ概念栈描述了WebServｉcｅs的规律分层结构,以及各层中可能使用的协议或描述方法，如下图所示:图7：ＷebSerｖiｃeｓ概念栈的构成简图ＷeｂSｅｒｖiｃｅs概念栈由下至上主要由以下四层组成:网络传输层:该层负责在应用程序间传输消息。目前这一层的协议主要有HTTP、ＳＭＴP、FＴＰ、IIOP等。其中HＴTＰ正成为WebSｅrviceｓ所使用的标准网络协议；不过在某些扩展应用领域中，也支持SMTＰ协议和FTP协议。消息传输层:该层在网络传输层之上负责对消息进行编码和传递。目前这一层的主要协议规范是SOＡP.服务描述层：该层负责描述Weｂ服务的公共接口,为调用Wｅb服务供应了简略的方法。目前该层通过基于XML格式的ＷSＤL来描述服务实现和服务接口。服务发现层：该层负责将服务集中到一个共同的注册中心，并供应容易使用的发布和查找功能。目前这一层通过UDDI处理。由图７还可以看出，消息传输层、服务描述层和服务发现层都是基于XML、DTＤ和Ｓcｈeｍa这些基础技术的，而WebＳeｒｖiceｓ的平安及管理也始终贯穿于整个概念协议栈中。WｅｂServiｃeｓ的特点体系结构方面的特点首先WｅｂSｅｒvices具备面对服务的体系结构所具备的特点。面对服务的体系结构（serviｃe－ｏｒｉentｅdａrcｈitｅｃｔure，SOＡ)是一个组件模型,它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来.接口是接受中立的方式进行定义的,它独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在这种系统中的服务可以以一种统一和通用的方式进行交互.ＷebSerｖicｅs是目前实现ＳOA的主要方式，这种体系结构带来的好处包括：ＷebSｅrｖｉces促进了互操作性:由于服务供应者和服务恳求者不知道彼此所使用的平台或语言,为了供应他们之间的互操作性,一个服务供应者和服务恳求者之间的交互需要被设计成完全独立于任何平台和语言。而使用WebＳｅｒvｉceｓ进行交互，仅需要一个ＷSDL文档，伴同网络协议一起（通常是HＴTP）来定义接口和描述服务即可,对供应者和服务者的平台或语言没有要求.ＷｅbSｅｒｖicｅｓ促进了即时集成:当服务恳求者通过服务注册中心查找到服务供应者时,发现服务就动态产生了。一旦恳求者和供应者发现了彼此，供应者的WSDL文档将被用来将恳求者和服务绑定在一起,这种即时集成可以使恳求者、供应者和代理构成了一个可自我配置的、自适应的、强健的系统。WebSｅrｖiｃｅs通过封装削减了简洁程度：服务恳求者和供应者只关注相互进行交互时所需的必要接口，对于服务恳求者,它不必知道服务供应者如何实现它的服务；对于服务供应者，它也不必知道服务恳求者如何使用他的服务。这些简略信息将被恳求者和供应者封装起来,封装对于削减系统的简洁度起到了格外关键的作用。WebSerｖices给予旧的应用程序以新的生命:将应用程序封装为ＷＥＢ服务是相对简便的，首先生成SOAＰ封装器，然后生成ＷSDL文档并将应用程序作为Wｅb服务。这种简易性意味着目前广泛存在的旧的应用程序可以以一种新的方式来使用。另外，与旧的应用程序相关的基础服务（平安性、名目服务、交易等)也可以“封装”成相应的服务.技术方面的特点WeｂServiｃes技术的特点主要表现在松耦合性、开放性和组合性上。松耦合性：ＷebＳｅrvｉces具有中立的接口定义（即没有强制绑定到特定的实现上）特征,我们将其称之为服务之间的松耦合。松耦合系统的好处有两点,一是它的灵敏性，另一个是当组成整个应用程序的每个服务的内部结构和实现逐渐发生转变时,它还能够连续存在.而紧耦合则意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得格外脆弱。目前,业务应用程序需要依据业务需要进行灵敏地变更以适应不断变化的环境,比如常常转变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素等,因此对松耦合系统的需要比较迫切.我们称能够灵敏地适应环境变化的业务为按需(Ｏndｅmａnd）业务,在按需业务中，一旦需要,就可以对完成或执行任务的方式进行必要的更改。开放性：ＷebServｉcｅ基于标准的XＭL语言,可以与其他ＷebＳeｒvice进行交互。它具有语言和平台无关性。支持ＣＯRBA、ＥＪB、DＣOM等多种组件标准.支持各种通信媒体如：HTTP、SMTＰ、MＱ、ＦTＰ、RMI等.组合性：WｅｂSｅｒvices具有可组合的特性。单个Weｂ服务功能单一,难以满意实际的应用需求,为了发挥Ｗeb服务的能力，实现组织内/间的服务发现、调用和实现，必须依据服务流程把各个Wｅｂ服务编排起来，形成有价值的组合服务。服务流程制定了一组Wｅb服务操作可能的执行挨次、共享的数据、涉及的伙伴／客户及其在业务流程中扮演的角色、共同的格外处理,及多服务和多组织如何参加等内容,刻画了服务流转的关系。服务流程管理的主要目标是通过解析和描述服务流程,对组织所供应服务的建模、组织、部署、执行和管理更加合理化,并最终优化它们.ＷｅbSｅｒvices与其他分布式技术的比较在WebServｉces技术消灭之前，主要的分布式技术有CＯM/ＤCOM,ＣOＲBA和EＪB等。COM（CoｍｐｏnｅntObｊｅｃtMｏdｅｌ,组件对象模型）是集成化的面对组件的软件系统体系结构规范，其核心是将软件中的可重用部分定义为含有全局惟一标识符ＧｌobａllyＵnｉｑueＩdenｔiｆier,GＵＩD)的组件对象，每个组件对象都有其特定的接口和所能供应的服务，供应跨编程语言(仅在Winｄows平台中)的通用组件对象访问途径,从而实现软件组件方式的集成.DCOM(ＤｉsｔｒibuteCｏmｐonentObjeｃｔＭoｄel,分布式组件对象模型)是COＭ在网络环境中的扩展，它对部署在网络中不同计算机上的COＭ对象供应互操作能力，从而使组件对象模型具有分布式功能。CＯＲBＡ是由OMG（OｂjectＭanagemenｔGｒoｕp，对象管理组织）提出的用于实现分布式技术的一种规范.它是编写分布式应用程序的一种规范，不是编程语言。ＣORBA规范的主要内容包括接口定义语言（IDL）,对象恳求代理（ORＢ）和ＯRＢ之间的通信协议IIＯP。接口定义语言(IＤL)用于描述ＣＯRＢA对象的接口,然后通过ＩDL编译器将其映射成特定编程语言类型的客户端存根和服务器端框架。ＥＪB（EnteｒｐrisｅＪaｖａＢean)是目前比较流行的分布式组件模型.EJB体系结构供应了一种管理运行在应用服务器上的服务的方法,为Java组件供应了中间件的支持,还供应了平安服务。作为一种分布式技术,WｅbSerｖice与CＯM/DCＯM,ＣOＲBA和EJB的比较如下表所示。表：WebServiｃes与ＣOM/DCＯＭ,CＯRBＡ和EJＢ的比较列表比较项目COＭ/DCOMＣORBAEJBWeｂServiｃeｓ适用平台仅Wiｎｄｏws系列支持绝大多数平台支持Jaｖａ虚拟机的全部平台支持绝大多数平台结构层次二层C／S结构三层（客户层/中间层/数据层)结构三层/多层结构三角结构编程实现语言支持VＣ、VBC、C++、Jaｖａ、Smａlltalk等接受JavaＲMI/IDLC、C++、C#、Javａ等接口和对象支持接受接口定义语言定义，使用了GＵIＤ标识，对管理的支持较好接受ＣＯＲＢAＩＤＬ定义,使用对象名称，定义较为简洁接受JａvaRMＩ/ＩＤＬ,支持命名服务接受WＳＤＬ定义描述接口数据类型各种均支持各种均支持无指针形式各种均支持对象引用接口指针ＩOR（对象引用）接受JNDＩEＰR(端点引用）对象存储系统存储表中的指针实现仓库接受Ｒegistrｙ和ＪNDI接受ＵＤDI传输协议RＰＣＩＩＯPＪＲMP和IIOＰＳOAP与其他技术的兼容性需要接受Bridge与ＣORＢＡ和ＥJB进行通讯，限制较多,且仅能在特定版本中实现CORBA与EJB之间接受ＩＩOP进行通讯，较易实现与COM／DCOＭ接受Bridge,与CＯRＢA接受IＩOP协议接受基于HＴTP的ＳＯAＰ协议，HTTＰ可穿透防火墙，适应性好支持厂商MｉcrosｏftＶiｓｉＢroｋer、IONA、BＥA、IBＭSUNIＢM、HP、Ｍｉcrosｏft等规范成熟度十分成熟十分成熟较为成熟较为成熟应用领域和主要特点与Winｄows系统操作系统结合十分紧密，适合于仅接受Wｉndｏws系统的分布式系统构建，实现较为简洁,管理较为便利,且有很多的第三方商业化AｃtｉｖeＸ控件支持跨操作系统能力十分优秀，适合于多系统下的分布式开发，但需要OＲB开发商的中间件软件的支持，且实现较为简洁,平安性能较好，适用于开发对平安要求较高的系统具有很好的平台无关性,编译一次就可以随处运行，针对接受纯Jａvａ开发的系统，格外适用于开发大型企业应用系统和基于Wｅｂ的系统，但运行速度较慢具有优良的平台无关性和编程语言无关性,由于ＷｅbServiｃeｓ/ＸML的开放和标准化,适用于信息交互较多的异构大型企业综合应用系统，运行效率有待进一步改进ＷebService与其他接口技术的比较ﻩWebSerｖiｃe除作为分布式技术之外,狭义地说，它可以作为管理系统之间的一种接口技术，在此之前网络管理系统之间常用的接口技术有SＮＭP和CORBA(由于ＣＭIP技术已经基本不使用，这里不再商议 ),下面对这几种技术作一比较。1、SNＭP接口随着大量网络设备在Inｔernet上的涌现，网络规模不断扩大，广泛应用于Ｉnternet上的传统网络管理协议ＳNMP(SimpｌeＮetwｏｒkMａnａｇeｍｅｎtＰｒｏtocol，简洁网络管理协议)在管理大型简洁网络时暴露出一些弱点，主要表现在：管理信息模型描述力较弱：由于SＭI不是面对对象的,因此使用SMI定义的管理信息模型难以表示更简洁的管理信息,如结构化数据类型、对象、方法或关系等.管理协议简洁和不行靠性：SＮMP只有三类简洁的管理操作：Gｅt、Sｅt、Ｔrap，加上ＳNＭP是基于UDＰ(UsｅrDaｔaPｒotｏｃol）的协议，不能以一种牢靠的方式传输大量数据。另外,ＳNMP缺乏足够的平安性，也不能用一种交易的方式来保持在信息之间变动的全都性，所以SＮＭＰ通常都用于监视而很少用于真正意义上的管理。缺乏分析手段：没有标准的分析APＩ，也不支持数据库，增加了对网络管理信息以及大事分析的简洁度。２、ＣORBA接口CＯRＢA技术最主要的一点是一个紧耦合技术，即客户端和服务器端必须都运行ORB,且使用相同的IＤL接口。COＲBＡ技术使用IIＯP协议进行通信，但并不是全部的客户端都支持IIOＰ，在没有做特殊设置的情况下，IＩOP包不能通过防火墙，可能会在到达相应的服务之前被防火墙过滤掉.相对于松耦合的ＷebServiｃes技术,CＯRＢA具有较高的应用门槛和相对受限的使用环境。3、WｅbServiｃeｓ与SNMP、ＣORBＡ的比较为了明确WｅｂSerｖicｅs技术在网络管理中的应用前景,以下对WｅbServices技术与SNMＰ和CORBA技术在网络管理方面各自具有的特点进行比较。体系结构的比较SNＭＰ：接受Mａnagｅr-Agｅnt层次结构。SNMP自身的框架结构简洁，易于实现。但由于ＳNMＰ的平安框架不够完善，且Mａnaｇeｒ-Maｎaｇer管理信息库被证明不太有用，管理者之间的通信不能由SNMP协议本身完成，故SＮMP通常被用于集中式管理环境中，即层次型管理环境,且可扩展性稍差。COＲBA：接受三层Ｃliｅｎt－Serｖer结构.CＯＲＢＡ作为面对对象技术，很好的利用了面对对象开发技术的优点。但CORBA自身的框架相对简洁，实现门槛较高，通信实体需要运行ORＢ并使用相同的IDL接口，任何一端接口发生变化，通信便无法完成。目前不同的CＯRＢA平台之间的互联互通还需要进行相应的调试和适应，CORBA的集成性和可扩展性受到了平台本身的限制.WebSeｒviｃｅｓ:接受Ｒｅquｅstｅｒ—Provｉｄeｒ－Registry三角色结构。基于ＸML的WｅbSerｖicｅs自身的框架比较简洁,容易部署,具有较低的实现门槛。ＷebSｅrｖｉcｅs的松耦合性削减了服务之间所共享的需求,有利于组件重用和削减整个开发和维护费用.WｅbＳervices具有组合性,这允许依据需求实现需要的功能，并在需求发生变化时随时对实现进行扩展和变更。但ＷeｂSeｒvｉce在作为接口技术时的性能受到质疑。通信协议的比较SＮMＰ:接受基于UＤＰ的SNMP协议进行通信。SNMＰ协议只定义了几种简洁的管理操作：Gｅｔ、GｅtNext、Ｓeｔ、Trａp等。且SNＭP协议的平安性稍差，不能以一种牢靠的方式传输大量数据。ＣORBA:接受ＧＩOP/IIＯP完成通信实体之间的通信。CORBＡ无法与其他分布式技术如RMI和DCＯＭ进行通信，与Web的通信需要添加附加层通过格外的套接字来完成，增添了COＲBA体系结构的简洁性。在客户端不支持ＩIＯP以及防火墙对IＩOP包进行过滤的情况下，CORBA的应用范围会受到限制。WebSerｖｉｃes：接受ＳＯAP作为通信协议。SＯAP协议与底层通信协议无关,可以是ＨTＴＰ、SMＴP、ＩＩOP等。基于XML与HTTP绑定的SOAP不受防火墙的限制,应用范围广泛。接口描述方法的比较ＳNMP:管理信息接受ＳMＩ描述.由于ＳＭI的简易性,使用ＳMI定义的管理信息模型难以表示简洁的管理信息,如结构化数据类型、对象、方法或关系等.SNMP中的管理操作由SNMP协议本身定义，管理信息不能定义新的接口操作。CORBA:接受IDL来描述接口.ＩＤL将对象实现与对象接口相分离,只描述接口，不描述实现；接口中包括属性、操作、模块等.IDL是静态的限制严格的语言，即客户端和服务器端的应用均要随着ＩＤL的变化而转变。IDＬ没有供应终端信息,在Wｅb应用中需要借助其他方式（如IOR或命名服务)来供应终端信息。ＷebＳｅrviceｓ：接受基于XML的WSDL描述接口.WSDＬ对接口的描述可以分为两个层次:抽象层次和简略层次,其中抽象层次部分可以重用。通信双方各自ＷSDＬ的变化一般不会引起全局的变动.服务发现的比较ＳNMＰ：SNＭP中没有服务发现的概念.ＣOＲBＡ：在CORBＡ中,服务定位标志是IＯR(InteｒoperabｌeOｂjectRefeｒｅnce),对服务的搜寻以公共对象服务的形式给出，主要是命名服务(NaminｇServicｅ）和交易服务(ＴｒaｎｓaｃｔionＳeｒｖｉce)，命名服务和交易服务本身的定位也是通过ＩOR来完成的。IＯＲ以二进制方式给出，可读性较差。ＷebSerｖiｃｅs:一般使用UDDI注册中心来发现服务,ＵDDI是一种以ＸＭL格式发布和发现ＷeｂServｉceｓ信息的方式,在Web上具有较好的兼容性。服务所在端点用WＳ-Aｄｄｒessing中的ＥPR(EnｄpointRefeｒｅnce，端点引用)来定位.通知机制的比较SNMＰ:由SＮMP协议定义的Tｒap原语实现。通知定购机制简洁,没有通知发布和通知过滤机制。CORBA:由大事服务和通知服务实现,具有完善的通知发布/订购机制.大事服务提出了大事的供应者和消费者,大事的转发在两者之间是透明的.通知的分发由大事通道来解决，支持Pulｌ和Puｓｈ两种工作模式.通知服务由大事服务演化而来，用一种公认的格式传送定义好的数据类型，同时还供应了相关的过滤机制。WｅbSeｒviｃｅｓ:使用ＷS—Notｉｆｉｃａtion技术组定义的通知机制，具有完善的通知发布/订购机制。支持Pｕll和Ｐush两种工作模式，并供应了通知过滤机制。平安机制的比较SＮＭP:SNMＰv１使用在消息中增加Ｃoｍｍunｉty名的平安机制,由于消息以明文方式传送，所以ＳNＭPv1不具有真正意义上的平安性。目前在SＮＭPv2和ＳNMPｖ３中增加的平安机制实现起来格外简洁，应用很少.COＲBA：具有完善的平安机制，ＯＭG为CORBA定义了一套规范来确保CＯRＢA的平安，包括CORBA平安服务、基于网络层的ＯRB-ＳSL平安服务以及CＯRBA防火墙规范。ＷebＳerviｃes:利用传输层的平安机制(如ＨＴTＰｏverSＳL)和消息层的平安机制（如WS—Sｅcuriｔｙ等)