铁路互操作性技术规范

铁路互操作性技术规范（精选4篇）

铁路互操作性技术规范 第1篇

在传统的移动设备上,应用程序的开发一般有两种模式。一种是基于自身系统进行开发,需要各自厂商提供的开发工具(SDK),这种开发方式与设备平台紧密相连,虽然在功能与性能上有较大的优势,但是因为平台之间的不兼容性,需要为每个平台开发各自的版本,从而增加了开发和维护的成本。另一种开发模式是使用具有跨平台特性的J2ME进行开发,J2ME具有很多优点,比如开发效率高、程序可以跨平台等等,但同时J2ME也存在着执行效率低、不支持系统独有的一些本地功能等问题。而目前,随着移动设备性能的增强,在移动设备上使用浏览器作为本地应用(Native Application)的平台成为可能。iphone、Android、Palm WebOS等在产品中都已经有了实际的应用。

在传统的浏览器上,使用脚本语言作为应用开发工具有一定的先天局限性。出于安全性方面的考虑,JavaScript脚本并不具备访问本地资源的能力,对于网络的访问也受到同源策略(Same Origin Policy)的严格限制。所以基于浏览器的应用在获取外部资源和外部程序的支持时,需要对浏览器进行额外的扩展。为了拓展JavaScript的功能,各大主流浏览器都实现了自己的插件式本地扩展机制,比如IE的ActiveX插件、Firefox的NPAPI插件、Google的Native Client技术等[1]。当浏览器作为本地应用的平台时,工作在浏览器中的JavaScript脚本成为本地应用中的一部分,而不只是丰富网页逻辑、弥补HTML不足的工具。

为了增强JavaScript的处理能力,Google开发了具有更强本地应用计算特征的JavaScript引擎V8[2],但V8作为一个动态脚本解释器,无法在计算效率、内存使用上有质的提高,JavaScript作为一种脚本语言也有其先天局限性。针对这种情况,本文提出了基于CAR技术的V8扩展技术。CAR作为一种二进制构件技术,可以在运行时动态加载、反射。利用CAR的本地计算能力,通过实现V8与CAR的无缝衔接,过到扩展V8的计算能力的目的。从而使得使用浏览器作为平台的应用具有更加强大的功能。

2 Elastos平台上的CAR构件概述

Elastos是一种构件化操作系统,CAR构件技术是在Elastos平台上面向构件编程的编程模型,它规定了一组构件间相互调用的标准,使得二进制构件能够自描述,能够在运行时动态链接。[3]

构件自描述简单来说是构件能够描述自己的信息数据,它通过元数据(metadata)的方式来实现,是Elastos实现CAR构件技术重要技术之一。元数据是描述数据的数据(data about data),是对数据的抽象,主要描述了数据的类型信息。对CAR构件来说,模块信息(ModuleInfo)、接口信息(InterfaceInfo)、类信息(ClassInfo)等数据就是描述构件的元数据,这些元数据与CAR构件的可执行代码存储在一起,是CAR构件的二进制描述。

通过元数据,CAR构件可以实现反射(reflection)机制。反射机制是CAR构件实现动态性的关键,也是我们实现与JavaScript引擎交互的关键功能之一。基于CAR构件的程序在运行时可以动态加载、探知CAR构件,获取CAR构件的信息,包括模块信息、类信息、接口信息、方法信息等。

在与JavaScript引擎的交互中所需的另外一个特性是CAR构件的回调机制。回调机制本质上是一种事件机制,使用CAR构件的程序向CAR构件注册自己的事件处理函数(即回调函数),构件对象在某个时机出发事件,如果这个事件被注册了回调函数,那么该回调函数就会被调用。

3 CAR构件与JavaScript引擎的交互模型的设计

3.1 JavaScript引擎V8概述

V8引擎是由Google开发的开源JavaScript引擎,提供了一个高效的JavaScript脚本的解析与运行环境。V8目前用于Google的开源浏览器项目Chrome。

作为一个独立的JavaScript引擎,V8提供了丰富的API接口供外部程序调用。通过操作这些API接口,可以实现在JavaScrip环境中创建和销毁对象、调用外部方法等等功能。

V8引擎的API分为两种。第一种可以直接操作JavaScript环境内部的数据与对象、执行脚本。第二种是设置一些回调,可以对某些特定的事件设置回调,当JavaScript环境内部产生某个特定事件时,JavaScript引擎就会调用相应的回调。

3.2 JavaScript脚本调用CAR构件的模型

要在V8中实现JavaScript脚本与CAR构件的互操作,我们需要额外实现一个对V8引擎的扩展。这个扩展的主要实现两个功能:

1)将CAR构件的元数据注册到JavaScript引擎中,然后通过反射调用CAR构件以及在CAR构件回调JavaScript方法时提供代理功能。

2)对所有加载的CAR构件以及CAR构件所映射的JavaScript对象进行生命周期与缓存的管理。

加载CAR构件的策略有两种。第一种是在初始化时,将CAR构件中的所有信息全部通过反射获得,并全部注册到JavaScrip环境的全局对象中去。[4]这种策略的优点是流程直观且实现比较简单,但是缺点是在初始化时需要消耗大量的时间,同时由于一次性将CAR构件所有的元信息注册到JavaScript环境中,使得内存消耗过于巨大。

第二种策略是在初始化时,并不将CAR构件的所有元信息全部注册到JavaScript环境中,而是只将CAR构件的模块信息进行注册。也就是说,JavaScript脚本将只会访问到CAR构件的模块信息,而其它元信息将在JavaScript脚本需要访问时通过模块信息根据需要加载。比如当JavaScript脚本需要实例化一个CAR类时,首先通过CAR构件的模块信息反射得到CAR类的元信息,再通过类信息反射得到一个CAR类的实例对象,最后将该对象使用JavaScript对象进行包装之后返回到JavaScript运行环境中。

同时,我们还可以使用一些缓存策略提高程序运行的效率。当CAR类的元信息被反射后,我们可以将其放入缓存区中,当JavaScript端再次请求相同的元信息时,就可以直接读取缓存区中的元信息而不必再次进行反射,从而提高效率。

4 具体设计与实现

4.1 将CAR中的类注入JavaScript运行环境

我们需要将CAR构件的信息注入JavaScript的运行环境,才能使CAR构件与网页应用中的JavaScript脚本交互。在V8引擎初始化完成之后,获取其全局的Context对象,然后从全局Context对象中获得其全局对象,通过对这个全局对象进行操作,即可将CAR构件的信息注入JavaScript环境中。

我们可以通过一个额外的manifest.xml文件来指定需要加载的CAR构件,manifest.xml文件的地址可以在页面文件中特别指定,然后再manifest文件中指定页面所需要加载的CAR构件的文件名与存放地址。获取所需的CAR构件后,我们再使用反射获得CAR构件的模块信息,并在JavaScript环境中创建一个对象表示这个模块。该对象在JavaScript脚本中的使用类似于一个名字空间,所有该CAR构件中的元信息,如类、接口、枚举等数据都可以看做这个JavaScript对象的属性。

4.2 在JavaScript运行环境中创建CAR对象并调用CAR对象的方法

在JavaScript脚本中调用CAR构件分为两种情况:

1)将一个CAR的类实例化为一个CAR对象,并将其作为一个JavaScript对象映射到JavaScript运行环境中。

2)调用一个由CAR对象映射的JavaScript对象的方法,实际上是调用该CAR构件对象的方法。

这两种情况的本质都是对一个JavaScript对象的某个属性的访问,并将该属性作为函数进行调用。要实现这两种不同的调用,就需要V8中的拦截器(Interceptor)机制。拦截器是V8引擎中的一种回调机制,当设置了拦截器的一个JavaScript对象被访问时,V8引擎将触发特定的回调函数,回调函数中可以获得该JavaScript对象、需要访问的属性的属性名等一系列信息,通过对这些信息的进一步操作,就可以实现对CAR构件的各种操作。

在程序初始化加载CAR模块时,每个CAR模块都会被映射为一个JavaScript对象,这些JavaScript对象可以看做是各自CAR类等的名字空间。每个这样的JavaScript对象将被设置一个拦截器,对每个CAR构件的操作都可以通过各自的拦截器完成。

在实例化一个CAR对象时,拦截器首先获得需要实例化的CAR类的名字,然后通过反射获得CAR类的元信息,并将其实例化,再将被实例化的CAR对象使用JavaScript对象进行包装后返回到JavaScript环境中。

当一个CAR对象的方法被调用时,拦截器首先获得需要调用的CAR方法的名字,然后通过反射获得这个CAR方法的元信息,并将JavaScript端传入的参数转化为CAR类型的参数,再通过反射调用指定的CAR方法,最后将调用结果包装为JavaScript类型的对象并返回到JavaScript环境中。

在以上过程中,通过反射得到的CAR类与CAR方法的元信息都可以通过缓存机制进行缓存。当再次请求这些元信息时,就不必再使用反射机制进行获取,而可以直接从缓存中获取元信息,从而提高效率。

4.3 CAR对象回调JavaScript中的函数

CAR对象回调JavaScript中的方法指的是当CAR构件中触发了某个事件时,CAR对象反向调用在JavaScript脚本中的所注册的响应函数的过程。

要实现CAR对象对JavaScript函数的调用,需要利用V8引擎中的访问器(Accessor)机制。访问器也是V8引擎中的一种回调机制,每个JavaScript对象都可以设置若干个访问器,每个访问器都会针对该对象的一个特定的属性,当这个属性被设置或读取时,访问器将被触发,从而调用预先设置的回调函数。在一个CAR对象被包装为JavaScript对象后,可以将这个CAR对象的所有回调接口都映射到JavaScript对象的访问器上,这样,当CAR对象的回调接口在JavaScript脚本中被设置时,就可以通过访问器通知CAR对象。CAR对象再将设置到回调接口上的JavaScript函数保存,就可以在CAR构件触发特定事件时调用相应的JavaScript函数。

在CAR构件的回调接口被触发后,程序将找到保存的JavaScript函数,这时将CAR构件中的参数转换为JavaScript类型的参数后,即可调用JavaScript函数。

4.4 CAR与JavaScript数据类型的映射

CAR构件与JavaScript脚本的数据类型之间存在着很大的差异,数据的存储方式也是完全不同的,所以要实现CAR构件与JavaScript引擎的互操作,就必须实现CAR数据类型与JavaScript数据类型之间的映射与相互转换。

在JavaScript中的数据类型分为Number、Boolean、String和Object,另外还有两种特殊的数据类型undefined和null[5],CAR的数据类型是标准的C++数据类型。

由于CAR构件使用C++编译,是一种强类型语言,所以在JavaScript端调用CAR构件的方法以及CAR构件回调JavaScript方法时,参数类型都由CAR方法决定。

CAR构件的方法在定义时,参数都带有[in]和[out]属性,[in]表示传入的参数,[out]表示传出的参数。在CAR方法与JavaScript函数映射时,JavaScript函数的参数列表将被映射为CAR方法去掉[out]参数的参数列表形式,而所有[out]参数将作为函数的返回值。即当CAR方法有n个[in]参数与m个[out]参数时,对应的JavaScript方法就有n个参数,返回值为一个长度为m的Array对象。当CAR方法没有[out]参数时,JavaScript函数返回undefined,当CAR方法只有1个[out]参数时,JavaScript函数返回这个[out]参数的类型所对应的JavaScript类型的对象。

当JavaScript脚本调用CAR方法时,首先通过反射确定CAR方法的所有参数类型,依次将JavaScript脚本中的参数转换为CAR的参数类型,然后进行调用。如果JavaScript脚本中传入的参数与CAR方法的类型不同,则在JavaScript环境中抛出一个异常。当CAR构件回调JavaScript方法时,先将所有从CAR传入的参数转换成JavaScript的数据类型,然后用这些参数直接调用JavaScript方法。

5 总结与展望

通过对开源的JavaScript引擎V8的扩展,我们使得JavaScript脚本有了与CAR构件交互的能力。通过这样的的扩展,基于浏览器的应用就可以突破浏览器本身的限制,进行一些跨域或本地的交互与代码调用,这可以使应用从交互性、性能、可扩展性等诸多方面获得提升。如果在移动设备上使用这种架构,就可以在一定程度上实现应用的跨平台,同时又可以获得比较好的运行效率。

目前的工作也依然存在不足,CAR构建本身是一种二进制的运行组件,这样就带来了一定的安全隐患。同时,因为在V8运行环境中引入了Elastos这个系统,使得系统的稳定性降低,当CAR构件运行崩溃时,将会造成整个运行环境的崩溃。所以提高CAR构件的安全性与稳定性,将是今后工作的重点。

参考文献

[1]Bennet Yee,David Sehr,Gregory Dardyk,ed al.Native Client:A Sandbox for Portable[M].Untrusted x86 Native Code.Google Inc,2009.

[2]V8 Open Source Project[EB/OL].http://code.google.com/p/v8/.

[3]Elastos资料大全[Z].上海科泰世纪科技有限公司,2008.

[4]蒋章概,陈榕.基于CAR构件的WebKit本地扩展策略[J].计算机应用,2009(S2).

互操作联邦数字图书馆研究 第2篇

3.1 基于中介（mediation）系统的结构

中介（mediation）结构为实现异构DLs的互操作联邦提供了一条有效途径。它利用一个中介层（mediator）为每种数据源提供一个通用的数据模型和查询界面，使用包装层（wrapper）屏蔽各种数据源之间的异构性。中介层负责接受用户的查询，并将其转换成通用模型。包装层将中介层提供的通用模型转换成针对具体数据源的查询并执行。中介层收集来自包装层转换后的查询结果，将其归并后返回给用户。其代表是文献[4]中介绍的体系结构，它利用面向对象的数字图书馆系统MARIAN作为网上学位论文联邦数字图书馆（NDLTD）的中介层中间件（mediation  middleware），以期提供一个公共的查询界面和集成平台；使用5SL（一种基于XML的描述语言）描述每个联盟DLs的馆藏服务能力及其内部文档结构。这些描述信息不仅可以为中介层（mediator）提供数据结构，而且允许包装层（wrappers）的半自动化生成。NDLTD体系结构集成了多种采用不同协议（包括Harvest系统、Dienst协议、Z39.50协议和OAI协议）的异构DLs系统，允许使用多种方法定期地从联盟DLs的馆藏中提取信息，经过处理、合并后集中保存在一个联合文档（union  archives）中，用户对保存在联合文档中的数据进行查询。NDLTD体系结构实现了结构（异构的）、系统（使用Dienst、Z39.50和OAI等不同的协议）、语法（包含有不同的数据格式）及语义四个层次上的互操作。

中介（mediation）结构为馆藏自治、结构异构的DLs之间的互操作提供了强有力的支持。目前这方面的主要研究工作是将中介结构（包含有实现低层信息到高层抽象转换的组件）同基于agent的系统（包含有控制复杂协商任务的智能对象）相结合。为了更好地支持互操作，各组件之间的通信通常采用标准协议（如HTTP、Z39.50、KQML或CORBA）实现。

3.2 基于数据驱动的结构

基于数据驱动的结构是一种以数据为中心的结构，它既不要求对现有DLs的结构做任何修改，也不要求联盟成员的DLs遵从某种互操作协议，只要求使用数字图书馆描述语言（DLDL）描述各自的馆藏资源（DLs的元数据及其内容）、访问方法和服务能力，并将这些描述信息登记到注册服务器中。当用户通过联邦数字图书馆（FDL）查询时，FDL根据注册服务器中保存的信息，选择出最合适的DLs执行用户的查询，并收集这些DLs返回的结果，合并整理后返回给用户。其代表是美国弗吉尼亚大学的数字图书馆研究小组提出的FDL结构，它包括三个主要部分[2]：①异构DLs的收集及其DLDL描述；②一个基于LDAP的注册服务及主XML归并agent；③一个联邦数字图书馆（即一个基于Java的应用程序，它能够支持不同DLs的集成，使用户感觉到如同使用单个数字图书馆一样）。其中，注册服务允许任何DLs通过向LDAP服务器提交其DLDL描述而成为FDL的一员。

基于数据驱动的结构要求所有加盟的DLs使用统一的数字图书馆描述语言描述各自的馆藏内容、访问方法和服务能力，其查询响应时间是应当考虑的主要因素，服务质量通常由所选择的DLs中服务最差者决定。

3.3 基于Agent的结构

Agent（包括多Agent、智能Agent和移动Agent）的理论、技术，特别是多Agent的理论、技术，为分布式开放系统的分析、设计和实现提供了一条崭新的途径，被誉为“软件开发的又一重大突破”[6]。将Agent技术引入到数字图书馆领域，不仅可以为用户提供个性化的服务，而且使系统具有较好的开放性、可扩展性和可伸缩性。基于Agent的FDL体系结构通常包括用户Agent、中介（mediated）Agents和资源Agents，它们之间通过协商、合作完成某项任务。中介Agents负责与用户Agent、资源Agents和其他中介Agents的交互。用户Agent向用户提供接口界面，接受用户输入的查询请求，转换成通用的查询语言后交给合适的中介Agents。资源Agents作为每个DLs的智能前端接口，负责执行用户的查询，其功能与中介结构中的包装层（wrappers）类似，主要用于隐藏每个DLs的异构性，使用户感到如同使用单个数字图书馆一样。美国密执根大学的数字图书馆原型系统（UMDL）[7]是这种结构的代表，它包括用户接口Agents（UIAs）、中介Agents、馆藏接口Agents（CIAs）和馆藏四个部分。其中，UIAs提供用户使用UMDL资源的接口，并负责维护用户的profiles，以便提供个性化的服务。中介Agents提供信息服务的中介，负责将来自UIAs的查询送往最合适的CIAs，并监控查询的进展情况，传递处理结果以及进行数据格式的转换等。CIAs负责管理UMDL的馆藏接口以及馆藏内容的发布等功能。UMDL利用上述三类Agents，实现了对异构信息源的跨库检索。

3.4 基于OAI互操作框架的结构

开放存档倡导（Open  Archives  Initiative――OAI）是一个讨论和解决DLs互操作问题的论坛，其目标是为实现DLs的互操作提供简单、有效的机制。OAI的第一次会议于10月在美国新墨西哥州的圣达菲召开，会上制定了关于元数据Harvesting的技术协定――圣达菲协定[8]。该协定主要包括两部分：定义一个简单的元数据元素集――开放存档元数据集（OAMS），以便在存档之间大粒度地发现文档；定义一个公共协议――开放存档Dienst协议的子集（OA-Dienst），以便在存档之间提取OAMS和指定存档的元数据。另

外，圣达菲协定还定义了数据提供者（data  providers）和服务提供者（service  providers）模型。前者指存档的管理者，允许外界通过OAI协议访问其元数据；后者指从数据提供者那里获取元数据，并向用户提供高层服务的实体。目前，圣达菲协定已得到扩充和修改[9]，存档内容由起初的电子版资料（e-print  material）扩充到一般的学术数据（scholarly  data），选用Dublin核心元素集作为公共元数据集，并将元数据Harvesting协议作为数据提供者和服务提供者之间的通信协议。

OAI为解决DLs的互操作问题提出了一种简单的互操作框架。它要求数据提供者按照标准的元数据格式（如Dublin  core）建立其馆藏元数据，要求服务提供者利用OAI的元数据Harvesting协议与数据提供者进行通信。这种结构的代表是Arc[10]，它是第一个采用OAI互操作框架实现的联邦搜索服务。Arc能够从遵从OAI协议标准的存档中获取（Harvesting）元数据，经过处理后存入一个基于关系型数据库（如MySQL或Oracle）的搜索服务中。NDLTD[4]联邦数字图书馆也选用OAI互操作框架作为其元数据互操作的部分解决方案，以克服联盟DLs之间的异构性障碍。

OAI互操作框架实际上是通过在数据提供者和服务提供者之间定义一个标准接口来实现DLs之间的互操作，但并没有规定如何选择数据源，也没有强调如何实现服务提供者。另外，利用OAI互操作框架实现的联邦数字图书馆也存在元数据的同步更新问题，目前主要利用基于日期戳（datestamp）的“拉”（Pull）模型解决数据提供者和服务提供者之间的数据同步问题。

4 结束语

建立全球范围的互操作联邦数字图书馆是一项十分艰巨的任务，不仅包含一系列的关键技术，而且还存在着知识产权、经济、社会和法律等方面的问题。目前许多DLs都是自治的信息系统，它们具有不同的搜索界面、体系结构、通信协议和管理策略。在这些异构的DLs之间建立互操作联邦面临着以下挑战：①提供统一的接口界面以及将每个DLs映射到该界面的通用映射机构；②提供灵活的集成方式及工具以支持各种异构DLs的集成；③用户对联邦数字图书馆中每个DLs的访问应当透明。这些是建立互操作联邦数字图书馆需要进一步研究和解决的问题。

【参考文献】

1 EU-NSF  digital  library  working  group  on  interoperability  between  digital  libraries（position  paper）,  1999,  www.  iei.  pi.  cnr.  it/DELOS/NSF/interop.  htm

2 Barry  M.  Leiner.  The  NCSTRL  approach  to  open  architecture  for  the  confederated  digital  library.  D-Lib  Magazine,  December  1998

3 Hussein  Suleman,  Anthony  Atkins,  etc.  Networked  Digital  Library  of  Theses  and  Dissertations.  D-Lib  Magazine,  September  2001

4 Goncalves  Marcos  A.,  Robert  K.  France  and  Edward  A.  Fox.  MARIAN:  Flexible  interoperability  for  federated  digital  libraries.  proceedings  of  5[th]  European  conference  on  research  and  advanced  technology  for  digital  libraries（  ECDL2001  ）,  Darmstadt,  September  2001,  173～186

5 Erik  Selberg  and  Oren  Etzioni.  Multi-service  search  and  comparison  using  the  Metacrawler.  proceedings  of  4[th]  world  wide&

nbsp; web  conference,  Boston,  MA  USA,  December  1995

6 刘大有，杨鲲，陈建中.Agent研究现状与发展趋势.软件学报，2000，11（3）：315～321

7 Daniel  E.  Atkins,  et  al.  Toward  inquiry-based  education  through  interacting  software  agents.  IEEE  Computer,  1996,29  （5）:  69～76

8 Van  de  Sompel,  Herbert  and  Carl  Lagoze.  The  Santa  Fe  convention  of  the  Open  Archives  Initiative.  D-Lib  Magazine,  February  2000

9 Lagoze,  Carl  and  Herbert  Van  de  sompel.  The  Open  Archives  Initiative  protocol  for  metadata  harvesting,  2001  http:/www.  openarchives.org/OAI/openarchivesprotocol,  htm

铁路互操作性技术规范 第3篇

石建表示, 未来多制式终端、多制式系统都将长期共存。随着移动网络技术的发展演进、终端的自然淘汰和用户对新业务体验不断追求, GSM终端将逐步过渡到GSM、TD-SCDMA和LTE等多种制式。

当然, 这种终端多模化和网络多制式会使运营商面临一个问题:如何在保证用户体验前提下达到网络的均衡?对此, 石建表示, 网络互操作是多网协同工作的基础, 可以保证用户感知、均衡网络负载。另外, 基于单待多模终端的有效互操作策略也可以使业务和流量在不同网络之间达到均衡调度, 从而助力运营商做好网络负载均衡和用户使用平衡。

铁路互操作性技术规范 第4篇

Web Services是一个由URI标识的软件系统, 其中URI的公共接口和绑定都是用XML定义和描述的, 其定义可以被其他软件系统发现。这些系统就可以按照定义中预先描述的方式, 使用Internet协议传输基于XML的消息与Web Services进行交互[1]。Web Services提供了语言无关、环境无关的编程模型, 使用该模型可以高效、快速地实现面向服务架构 (SOA) 。该编程模型包括三个关键部分:集成松散耦合网络的可访问资源的服务模型, 一组定义协议和标准化应用程序编程接口 (APIs) 的规范, 使用松散耦合组件和消息创建分布式、可伸缩和可集成的应用程序分布式架构模型。

Web Services的语言和环境中立特性和规范标准使得应用程序之间的互操作有所好转。但是单纯地遵守规范并不能确保Web Services无缝地实现互操作, 各个Web Services实现平台对Web Services的规范标准的理解不一致, 导致了在实际应用中无法确保各个平台之间实现无缝的互操作, 其互操作仅限于在一个较高的抽象级别上进行而已。

1 Web Services互操作性概要

WS-I (Web Services Interoperability organization , Web Services互操作组织) 是为提高跨平台、跨应用程序和跨编程语言的 Web 服务互操作性而专门设立的一个开放组织。这个组织为开发可互操作的 Web 服务提供指导、推荐实践以及支持资源。WS-I提供的可交互包括提高Web Services之间的互操作性的用例和使用情况、概要、样本应用程序和测试工具。

1.1 概 要

WS-I概要是由一组Web Services规范组成, 并且还包括互操作实现指南, 以及关于如何利用这些规范跨越独立开发的Web Services标准, 从而达到互操作的一些建议。WS-I概要主要包括基本概要、附件概要和简单SOAP绑定概要。

WS-I基本概要[2]主要是为了对提高互操作性的基本规范提供约束和说明。如果概要规定了需求或约束, 它便会取代底层的基本规范。概要施加这些约束的目的是为了限制或要求那些可选的行为和功能, 从而减少潜在的互操作性问题。同时明确化那些基本规范中可能产生歧义的语言, 这些歧义也是导致互操作性问题的根源。基本概要应用在消息传递、服务描述、服务发现和安全性方面等领域中。WS-I附件概要将“支持带附件的SOAP消息”补充到WS-I基本概要中。WS-I简单SOAP绑定概要, 扩大了Web Services规范并提升其互操作性。

1.2 基本Web Services交互模式

遵循WS-I基本概要在Web Services应用程序中有三种交互模式:单向、同步请求与响应、基本回调模式。其中单向模式是Web Service消费者向提供者发出请求消息, 提供者处理这些消息, 但是并不返回响应消息, 同时消费者也不期待消息。同步请求和响应模式中消费者向提供者发送请求消息, 提供者接收这些消息并处理, 然后将响应信息发送回消费者。基本回调模式是Web Services的异步消息交换模式。它由一对同步的请求/响应交互组成。回调服务的描述被提供者定义和发布。消费者提供回调服务的实现和向服务提供者提供端点信息。提供者接收请求并立即回送一个确认信息。提供者根据消费者初始化请求, 用一个响应数据来启动回调请求/响应。

2 Web Services互操作性设计

2.1 Web Services互操作原理

Web Services互操作性的共同点是在不同平台之间传递数据, 这需要一个机制来控制不同平台之间的函数调用和数据传输。在基于Web Services的应用场景中一般有三个核心互操作性元素[10]:针对互操作性不同功能分类的应用程序互操作性栈、一组由栈内各个功能分别执行的活动、确保上述活动最佳互操作性的约束。互操作性设计需要结合关键元素的活动和约束。

(1) Web Services的活动

Web Services有两个基本类型的活动:描述活动和调用活动。

1) 描述活动

Web Services利用WSDL定义Web Services端点, 包括抽象定义 (操作和消息) 和具体定义 (网络协议和消息格式) , 该描述栈由以下组成:类型、消息、端口类型、绑定、端口、服务。

2) 调用活动

互操作性栈和四层结构联合起来就是Web Services的调用活动, 活动标识了从呼叫端到目标端工作流中特定Web Services互操作性功能。应用层:Web Services的应用程序接口。数据层:在数据层中定义了交换的XML消息数据的写和处理。控制层:SOAP协议的绑定和SOAP消息输入输出过程的语法语义的定义。传输层:对发送和接收消息的下层协议的定义。

(2) Web Services约束规范

WS-I基本概要为描述和调用活动提供了约束规范, 遵循这些约束有利于Web Services解决方案达到最好的互操作性。

2.2 Web Services描述

一个Web Services描述是开发任何新应用程序的互操作接口定义的基础[8]。创建描述有两个方法:第一个方法是从一个已经存在的应用程序开始;第二个方法是从WSDL开始, 使用IDE生成与WSDL相符的应用程序。从编程的角度出发, 如果没有详细处理WSDL细节问题, 从应用程序生成WSDL的方法就更容易。但是, 这样产生的WSDL文件可能包括平台特定的结构和行为, 因此可能违背互操作性。使用WSDL到应用程序的最好方法是先定义数据和接口, 这样应用程序可以很好地遵循公用接口, 从而达到更好的互操作性。

作为Web Services交互的起点, WSDL接口有大量的响应性问题需要仔细考虑, 其中包括状态管理、服务粒度、参数类型和交互。其中状态管理和多线程访问处理问题是为了满足多用户并发访问Web Services。对于服务粒度, 主要考虑方法的功能性, 试图平衡细粒度方法接口的灵活性与粗粒度方法接口的高效性。细粒度接口灵活, 但可能较繁琐, 结果导致网络开销增大而性能降低。粗粒度接口高效, 但需仔细考虑才能确保将逻辑操作聚合在一起。数据类型则是一个交互性问题的主要根源。在Web Services暴露的方法中, 需要仔细考虑方法的参数类型。对于交互则需要考虑关联每个暴露方法的处理类型。

2.3 类型定义

类型是Web Services的关键元素, 同时也是Web Services互操作设计中的一个重点。类型定义指定了Web Services所交换消息的数据类型。为了体现最大的互操作性和平台无关性, 可以使用XSD XML Schema Definition (XML模式定义) 为WSDL的首选规范类型系统。

Web Services互操作性问题就集中在暴露的数据类型和传递的参数。而数据类型产生互操作性问题的关键因素是由各个平台下层实现不同, 其主要表现在本地类型和XSD之间的映射。因此从一个平台发送的数据也许不会被接收方精确解释。例如, 在Java中所有的数组、类和接口都是引用类型。因此java.util.Data和java.util.Calendar类型是引用类型。而在.NET平台中System.DateTime却是值类型。有很多的已知类型定义方面都影响互操作性。在Web Services互操作设计时类型定义方面还要考虑类型不匹配、不可用类型、精度问题和值/引用等方面。

(1) 类型不匹配

各个Web Services实现平台中很多数据类型都不匹配, 如果这些不匹配的数据类型通过Web Services暴露, 就会产生互操作性问题, 例如Java和.NET都支持丰富的集合类型。Java中如: java.util.Hashtable、 Vectors、 Hashmap、Set、 ArrayList 。在.NET 中有System.Collections.Hashtable、SortedLists、Queue、 Stack、 ArrayList。虽然这些集合类型在Java和.NET之间看起来很相似, 但是当通过Web Services暴露时, 它们就成了互操作性的问题了。这个问题的根源在于接收端的XML Schema的解释上。集合对象的弱类型导致和本地数据类型映射时错误。为了使集合对象更具有互操作性, 处理的办法是把弱类型的集合对象映射成具体类型的简单数组[3]。

(2) 不可用的类型

当构造WSDL定义时, XSD提供了一个到 (或从) 本地类型映射的宽松范围。在本地类型和XSD类型之间一一对应是不可能的。例如.NET平台中无符号整形 (byte、ushort、unint、ulong) 和十进制类型在Java中都不存在。尽管XSD提供了对无符号类型的支持, 比如xsd:unsignedInt xsd:unsignedLong, xsd:unsignedShort, 和 xsd:unsignedByte, 为了互操作性的状态, 在Web Services方法中暴露这些数值数据类型是不可取的。可以考虑使用xsd:string (在C#中使用System.Convert.ToString) 来转换这些值。

(3) 精度问题

各个平台的类型可能存在精度的差异, 所以平台之间可能要丢失运算精度。在互操作解决方案中可以先行测试基本类型与xsd:decimal、xsd:double和xsd:float等类型之间的精度差异, 然后确定适当的精度类型。

(4) 值/引用类型

各种语言在数据类型的值/引用上处理可能不一致, 例如在Java语言中有两种类型:原子类型和引用类型。而.NET类型系统中则包括:值、引用和指针类型。相应的值类型可以被当作参数或者通过方法返回赋值给变量。如果一个语言的值类型被映射成另一个语言的引用类型就有可能发生互操作失败。例如:xsd:dateTime被映射成.NET中的一个值类型。可以对一个没有引用的对象赋值为null, .NET Web Services在接收到一个值类型的空值null时将会抛出一个System.FormatException异常。避免这类问题的方法是定义一个复合类型去包装值类型。然后设置复合类型为null表明一个空引用。

2.4 Web Services调用

Web Services支持SOAP、HTTP和MIME等传输绑定。使用SOAP/HTTP绑定是WS-I基本概要中的关键约束。绑定在SOAP1.2上的WSDL端点支持下列协议细节的规范:必须使用SOAP1.2协议的指示、指定SOAP端点地址的方法、绑定了SOAP消息HTTP SOAPAction头的URI、作为SOAP信封传输的一系列头部定义等[11]。

(1) SOAP编码

SOAP编码定义了数据值如何和协议格式的转换[4]。这些转换步骤被称为序列化和反序列化, 或者被称为编码和反编码。SOAP编码描述了在特定的编程语言中构造的数据结构与SOAP XML格式之间的转换。在设计中可以使用的编码模式有四种:SOAP编码、Literal、Literal XML和XMI。SOAP编码允许从SOAP数据模型到值类型的编码/反编码, 这个编码在SOAP1.2标准中定义。Literal编码是一个不带有编码信息的简单XML消息, 通常XML Schema描述这个XML消息的数据格式和类型。Literal XML编码允许现有的XML DOM (XML文件对象模型) 到SOAP消息内容之间的直接转换。这个编码风格在SOAP标准中没有定义, 但是在Apache SOAP2.3中实现了。XMI (XML metadata interchange) 在Apache SOAP中得到实现。

(2) 消息模式

在调用SOAP消息模式时, 两种风格 (RPC, document) 和两种最公用的编码可以自由组合[4,8]。尽管SOAP支持4种模式, 但只有3种模式是常用的, 同时在WS-I基本概要中只推荐了document/literal 和RPC/literal这两种模式。Document/literal提供了Java和Java应用程序之间的最好互操作性, 同时也提供了Java和非Java实现之间的最好互操作性。RPC/literal在Java实现之间可以选择, 尽管RPC/literal是WS-I允许的, 但是很少在实际中应用。RPC/encoded这种方式在早期的Java实现支持, 但是不提供和非Java中实现之间的互操作性。Document/encoded这种方式则在实际中从来没有使用过。

尽管WS-I基本概要需求都允许document/literal 和RPC/literal这两种绑定[2], 但是特定的Web Services实现平台却并不一定为这两种方式都提供支持, 例如.NET平台中就没有明确地对Web Services使用RPC/literal绑定提供支持。在设计过程中可以利用相应的一些转换工具将WSDL从RPC/literal转换为document/literal[5]。但需要注意的是从RPC/literal WSDL到转换包装成document/literal有一些限制。

2.5 Web Services约束

WS-I以Web Services相关规范开始创建的概要解决了大量的互操作性问题。它指定这些可适用的Web Services标准 (包括版本号) 列表成为互操作性实现指南规则。在进行互操作设计的时候可以参照WS-I基本概要1.1 (包括增强WS-I基本概要和简单SOAP绑定概要) 的基本要求;对于含有附件信息的SOAP在进行互操作设计时可以参照WS-I附件概要1.0中的约束。

2.6 J2EE和.NET的Web Services的互操作设计

J2EE和.NET平台是现阶段使用最为广泛的两个支持Web Services开发和运行的主流平台。但这两个平台对Web Services标准规范的支持却有着一定的差异, 所以导致这两平台上的Web Services之间存在着一定的互操作性问题[9]。虽然J2EE和.NET中的签名方法是一样的, 但是这两种平台上产生的Web Services的有效性还是有很多的不同。在互操作设计过程中必须特别考虑其产生的服务文件中的以下差异:异常处理、对象数组管理、参数规范。

异常处理提供了处理业务逻辑组件方法在运行时出现的任何意外或异常情况的方法。因为可以在Java方法签名中使用throws子句, 所以在J2EE生成的WSDL文件中, 一个复杂的类型被定义成一个自定义的异常, 而且SOAP故障可直接处理该异常类型。而在C#语言的方法签名中不支持throws字句[6], 所以必须对SOAP故障作专门的处理[7], 在设计中可以利用System.Web.Services.Protocols.SoapException将错误信息、错误代码和SOAP actor包含其中。在对象数组的处理上, 例如一个字符数组需要作为输入参数。两平台中Web Services的源代码都是使用了基本String[]类型, 但是生成WSDL文件时, 其参数声明却不同。J2EE生成的WSDL使用基类xsd:string, 而.NET生成的WSDL却转换成复合类型ArrayOfString。

3 结 论

Web Services互操作性问题是基于Web Services的应用成功运行的关键因素之一, WS-I概要和Web Services基本规范是进行有效互操作设计的基础。在深入理解概要和规范的基础之上, 充分掌握各个开发和运行平台对标准规范的实现程度, 才能最大程度地体现Web Services语言和环境的中立性, 构建出可靠的基于Web Services面向服务架构 (SOA) 的应用。

摘要：异构Web Services间的无缝互操作是成功构建基于Web Services应用的关键之一。讨论了Web Services互操作性概要和Web Services基本交互模式, 详细分析了Web Services互操作原理和Web Services描述;说明了Web Services的类型定义中的类型不匹配、不可用类型、精度和值/引用类型等问题对互操作性的影响, 并给出了处理方案;同时还分析了在Web Services的调用过程中采用的SOAP编码和消息模式、Web Services约束等问题。最后针对当前应用较广泛J2EE和.NET的两个平台的Web Services的互操作设计作了简要设计。

关键词：Web Services,WS-I概要,互操作性,SOAP

参考文献

[1]Michael Champion, Chris Ferris, etc.Web Services Architecture.ht-tp://www.w3.org/2002/ws/arch/2/08/wd-wsa-arch-20020821.html[EB/OL].2002-08-21.

[2]WS-I.Basic Profile Version 1.2.http://www.ws-i.org/Profiles/Ba-sicProfile-1.2.html[EB/OL].2006-10-03.

[3]Wangming Ye, Software Engineer.Web services programming tips andtricks.http://www-128.ibm.com/developerworks/webservices/librar-y/ws-tip-j2eenet2.html[EB/OL].2005-10-21.

[4]W3C.Simple Object Access Protocol (SOAP) 1.2.http://www.w3.org/TR/SOAP/[EB/OL].2003-6-24.

[5]Yasser Shohoud.RPC/Literal and Freedom of Choice[DB/J].MSDN.2003-4.

[6]Microsoft.The C#ProgrammingLanguage forJava Developers.http://msdn2.microsoft.com/en-us/vstudio/aa700844.aspx[EB/OL].2004-7-23.

[7]Scott Seely.Using SOAP Faults.http://msdn.microsoft.com/library/en-us/dnservice/html/service09172002.asp[EB/OL].2002-9-20.

[8]柴晓路.Web服务架构与开放互操作技术[M].北京:清华大学出版社, 2006.

[9]Eric Newcomer, Greg Lomow.Understanding SOA With Web Services[M].US:Addison-Wesley.2004-12.

[10]王明文, 朱清新, 卿利.Web服务架构[J].计算机应用研究, 2005 (3) :93-94.