专利名称：用于提供Web服务的方法、装置以及程序产品的制作方法
技术领域：
本发明涉及一种用于提供Web服务的方法、装置以及程序产品。更具体地，本发明涉及一种用于提供作为Web服务的Web应用的方法、代理装置以及控制程序产品应用。
背景技术：
近年来，用于提供作为Web服务的Web应用(到Web服务的转换)的方法是公知的。Web应用是用户诸如通过Web浏览器访问的Web服务器上的应用软件，并且主要由集中于用户和Web服务器上的应用之间的接口上的技术所构建。另一方面，Web服务是集中于系统间接口上的技术，其允许一个信息系统通过网络使用另一个信息系统，或者Web服务的意思是使用这种技术创建以及部署的软件的群集。
如果现有Web服务可以被用作系统间的Web服务，则对于Web服务提供商以及Web应用开发者和用户来说是很有用的。例如，当提供Web应用和Web服务两者时，经常是这种情况，在提供Web应用之前强化开发公共Web应用。这样做是为了通过快速地开发必要的Web应用，然后由于对所述应用的大量需求的原因而提供Web服务，从而降低开发成本。对于使用第三方提供的Web应用的应用开发来说，使用第三方Web应用作为Web服务有利地允许利用用于Web服务开发的环境和丰富的技术诀窍。
因此，用于将Web应用转换到Web服务而不改变所述Web应用的技术是已知的(例如，专利文献1和2)[专利文献1]已公开的未审查专利申请No.2005-149131[专利文献2]已公开的未审查专利申请No.2005-56058
本发明将解决的问题然而，传统技术仅仅是针对Web应用中的单一用户会话，而无法被应用于维护跨多个网页的用户会话的Web应用，即所谓的“全状态(stateful)”Web应用。即，这些技术假设对每次网页交换都重新建立用户会话。例如，专利文献1公开了在Web应用与Web服务之间的协议分析和转换方法，但是没有描述用户会话管理。
专利文献2是可应用于全状态Web应用的例子，然而，它需要在代理服务器上管理会话状态，使得在代理服务器与Web服务客户端之间的会话管理变得复杂。它还需要通过明确指定会话信息是如何传递的而对代理服务器进行配置，从而需要配置工作。此外，由于会话信息是通过Web服务的传输层(HTTP)从代理服务器传送到Web服务客户端，因此需要适合于特定传输层的Web服务客户端。
因此，所期望的是一种简单的方法，其将Web应用转换到Web服务而不会对代理服务器施加沉重的负担，并可以配置不需要复杂编程或者在请求服务的客户端上的特定中间件的灵活的Web服务客户端。
本发明的目的是提供一种解决上述问题并使得对于全状态的Web应用的简单并且灵活的Web服务客户端能够进行配置的方法。
发明内容
本发明提出了一种用于提供Web服务的方法，在所述Web服务中，代理装置响应于来自Web服务客户端的请求而访问Web应用服务器，所述方法包括以下步骤响应于来自所述Web服务客户端的请求，传送HTTP请求到所述应用服务器；将从所述Web应用服务器返回的HTTP响应中的实体头部和实体主体中提取的用户会话信息，以及从所述HTTP响应中的所述实体主体中提取的应用信息，嵌入对所述Web服务客户端的响应中；以及将来自所述Web服务客户端的请求中包含的所述用户会话信息嵌入到实体头部和实体主体中，作为HTTP请求中的应用数据的一部分，并将所述HTTP请求传送到所述Web应用服务器。
根据上述发明，代理装置响应于来自Web服务客户端的请求，发出HTTP请求到存储Web应用的HTTP服务器。当所述代理装置接收到从所述HTTP服务器发给它的HTTP响应时，所述代理装置从所述HTTP响应中提取出用户会话信息，并将所述用户会话信息嵌入到对所述Web服务客户端的响应中。所述Web服务客户端可以将所述用户会话信息作为应用数据的一部分嵌入到随后的请求中，并以所述用户会话信息能够区别于其他应用数据的方式传送所述请求。所述代理装置将接收自所述Web服务客户端的请求中包含的所述用户会话信息嵌入到HTTP请求中，并将所述HTTP请求传送到所述HTTP服务器，从而允许所述原始用户会话能够恢复(resume)。因此，所述Web服务转换能够以简单的方式实现，而且不会通过用户会话管理增加所述Web服务客户端或者所述代理装置的负担。
本发明的优点本发明允许将现有的全状态的Web应用转换为Web服务，而不需要复杂的编程。此外，通过应用本发明的Web服务转换，对应于多个HTTP会话的多个操作可以被合并到一种语言(例如BPEL4WS(用于Web服务的商业过程执行语言))中，以将其作为单一服务进行提供。即，跨多个HTTP会话的一系列Web应用操作可以作为以简单方式作为单一服务进行提供。
图1示出了根据本发明的系统配置图；图2示出了无状态Web应用和用户之间的传送和接收；图3示出了传统的无状态Web应用的Web服务转换；图4示出了根据本发明的Web服务转换；图5示出了使用Web服务转换在两个Web服务之间的会话管理信息的传送和接收过程；图6示出了示出了具有HTTP消息结构的示例性消息；
图7示出了SOAP消息结构(左边使用传统技术，右边使用根据本发明的技术)；图8示出了根据本发明的会话信息段的结构；图9示出了根据本发明的Web服务转换算法的概述；图10示出了用于生成HTTP请求的算法；图11示出了用于对于请求处理用户会话信息的算法(1)；图12示出了用于对于请求处理用户会话信息的算法(2)；图13示出了用于对于请求处理用户会话信息的算法(3)；图14示出了用于对于响应处理用户会话信息的算法(1)；图15示出了用于对于响应处理用户会话信息的算法(2)；图16示出了用于对于响应处理用户会话信息的算法(3)；图17示出了被提供给根据本发明的技术的Web服务转换代理的设置信息；图18示出了WSDL生成器；图19示出了WSDL生成算法；图20示出了转换代理的示例性设置；图21示出了从给定设置自动生成的示例性WSDL；图22示出了用于“search”操作的示例性消息；图23示出了用于示例性的简单的Web应用“Shop”的屏幕转变图；图24示出了通过将根据本发明的技术应用到Web应用“Shop”而实现的五个Web服务端口；图25示出了Web服务客户端上的示例性BPEL4WS程序列表；以及图26示出了示例性BPEL4WS程序列表中的数据流。
具体实施例方式
现在，将要通过本发明实施例来描述本发明。以下的实施例目的不是限定权利要求中阐述的本发明。此外，实施例中所述的部件的组合中，不是所有的组合都对于本发明的解决方案是必要的。
图1示出了用于提供根据本发明的Web服务的系统配置的概图。请求提供Web服务的Web服务客户端30通过因特网20与代理装置10通信。代理装置10通过通信路径50与提供Web应用的Web应用服务器40通信。通信路径50可以是局域网(LAN)。因此，代理装置10充当Web服务客户端30与Web应用服务器40之间的媒介。典型地用于代理装置10与Web服务客户端30之间的通信协议是SOAP(简单对象访问协议)，尽管其他协议也是适用的，例如CORBA(公共对象请求代理体系结构)。在Web应用服务器40与代理装置10之间使用的是普通的HTTP协议。尽管以下的实施例是采用作为用于Web应用服务器的示例性协议的HTTP进行描述的，但其基本配置与其他协议类似。
代理装置10包括SOAP请求接收器11b、请求分析器11a、响应生成器14a以及SOAP响应发送器14b，用于处理来自Web服务客户端30的SOAP请求以及对其的响应。代理装置10还包括HTTP请求生成器12a、HTTP请求发送器12b、HTTP响应接收器13b以及HTTP响应分析器13a，用于处理到Web应用服务器40的请求以及来自Web应用服务器40的响应。还包括了控制整体操作的控制器15。
请求分析器11a通过SOAP请求接收器11b从Web服务客户端接收对于Web服务的请求，并且分析该消息内容。
基于所述SOAP请求，HTTP请求生成器12a通过HTTP请求发送器12b传送HTTP请求到Web应用服务器40。
HTTP响应分析器13a提取会话管理所需的信息，该信息嵌入在对来自Web应用服务器的HTTP请求的HTTP响应中。下面将会详细描述关于该提取的细节。
响应生成器14在控制器15的控制之下将由HTTP响应分析器13a提取的会话管理所需的信息嵌入到对Web服务客户端的SOAP响应的SOAP主体中。接收包含用户会话信息的SOAP响应的Web服务客户端将会把该用户会话信息不做改变地嵌入随后的SOAP请求中。该用户会话信息还将由HTTP请求生成器12a嵌入随后的HTTP请求中。
图4示出了上述的传送和接收过程。在下面的描述中，图1中的代理装置10、Web服务客户端30以及Web应用服务器40分别被称为转换代理64、WS客户端63以及Web应用62。作为对照，图2示出了通过Web浏览器61在无状态Web应用(即，为每次网页切换重新建立用户会话的Web应用)和用户之间的传送和接收过程。如所示，每次用户输入或点击使得HTTP请求(S02、S06)被发布到Web应用。根据对该HTTP请求的HTTP响应(S03、S07)，Web浏览器61显示表格、结果等等。
图3示出了在WS客户端63和Web应用62之间通过转换代理的传送和接收过程，该转换代理通过使用传统技术将这种无状态Web应用转换为Web服务。在图3的过程中，对于SOAP请求S11发布HTTP请求12。然而，不会从HTTP响应S13中提取所述用户会话信息，也不会将所述用户会话信息嵌入到SOAP响应S14中。另一方面，在图4所示的过程中，对于初始SOAP请求S21发布HTTP请求S22。然后，从所述Web应用服务器返回对HTTP请求S22的HTTP响应S23。从HTTP响应S23中，分析并且(自动地)提取所述用户会话信息。
嵌入在SOAP请求S25中的用户会话信息被(自动地)嵌入到HTTP请求S26中(以适当的方式)。因此，由于在S24中返回的该用户会话信息在S25中被嵌入并传送，所以S26-S27的传送和接收可以继续S22-S23的会话。用户会话信息被再次(自动地)从HTTP响应S27中提取并且在S28中被嵌入和传送。其后，采用相似的方式，所返回的用户会话信息被嵌入到SOAP请求中，这样相应的HTTP传送和接收可以继续最初的HTTP传送和接收会话。这消除了为每个SOAP请求重新建立用户会话的必要性，并且允许恢复先前的用户会话。
WS客户端63的功能(参见图4)典型地由配置在工作流引擎上的程序(例如BPEL4WS)实现，或者由用通用编程语言编写的软件(例如Java(R))实现。图5示出了其传送和接收过程的示例。工作流引擎65可以使用从转换代理64提供的Web服务端口返回(S34)的会话管理信息，并且将该信息不做改变地传送(S35)到该Web服务转换代理提供的另一个Web服务端口。
图6示出了用于解释根据本发明的转换代理的操作的HTTP请求和响应的消息体系结构。在根据本发明的转换代理中，如上所述，从HTTP服务器传送的HTTP响应72中包含的会话信息被提取，并且被作为要从HTTP服务器返回的用户会话信息。该信息作为实体主体73中的应用数据，以可辨识信息序列的形式被嵌入到对HTTP客户端的响应中。
将用户会话信息作为应用数据嵌入到实体主体中简化了转换代理和Web服务客户端之间的会话信息管理。就是说，会话管理信息不是作为例如HTTP的Cookie头部等的元数据在Web服务客户端和转换代理之间转送的，所述元数据是SOAP的传输层，或SOAP头部。Web服务客户端需要知道该会话信息的存在，但不需知道其内容。Web服务客户端可以简单地将从会话的一系列消息中的第一Web服务响应中获得的会话信息直接包括到下一个Web服务请求中。这允许灵活的Web服务客户端的配置，例如，在若干客户端应用之间共享所获得的会话信息。
提取下面三项作为会话信息。
1)设置Cookie(Set-Cookie)头部信息，以及当模拟实体主体中的SCRIPT元素时设置的Cookie值。
2)在实体主体中的FORM元素中指定的“action”属性值的URI，或者常规超链接的目标URI(在后面的描述中，假定常规超链接采用特殊的形式，使得其成为不需要INPUT控制的GET方法)。
3)在FORM中的INPUT控制的属性值对“name”和“value”，其中“type”属性被设置成“hidden”。
转换代理将所提取的用户会话信息嵌入到SOAP响应的SOAP主体中，以允许Web服务客户端将该用户会话信息不做改变地嵌入和传送到随后的Web服务请求中。转换代理还通过使用适当的会话信息管理技术将所接收的用户会话信息嵌入到HTTP请求73中，并将该请求传送到HTTP服务器。
<数据结构>
作为对照，图7示出了传统的Web服务转换中的SOAP请求100和SOAP响应110的数据结构，以及根据本发明的Web服务转换的SOAP请求和响应的数据结构。基本上，可以认为会话信息104只被添加到SOAP主体101。在这些结构中，会话信息总是作为应用数据被嵌入到SOAP请求100的SOAP主体101中。因此，会话信息不需要由转换代理检查其内容，并且可以不做改变地被嵌入到HTTP请求中。
图8示出了会话信息段的结构。在这些元素中，“action”(零或一)包含Form标志的“action”属性的值，“cookie”(零或一)包含由设置Cookie头部设置的“Cookie”值，Cookie头部或脚本以及“hidden”(零或更大)包含“name”和“value”的对，其在INPUT控制处被设置成具有“hidden”属性。
通过使用上述技术，由转换代理自动地执行所有对于会话管理的信息的设置，并且通过URI的会话管理的存在不需要由用户(Web服务客户端)明确指定。此外，通过重写表格中的“action”属性值可以调节(accommodate)会话管理，而且通过重写表格中的隐藏字段可以调节会话管理。
<算法>
图9示出了根据本发明由Web服务转换代理执行的Web服务转换算法的概述。首先，当接收到SOAP请求时(步骤S100)，请求分析器11a(参见图1)并行化并且分析该SOAP消息(步骤S101)。
然后HTTP请求生成器12a(参见图1)生成对于SOAP请求的HTTP请求(步骤S102)。如果在SOAP消息中存在“action”元素，则根据该元素值修改请求URI(步骤S103)。如果存在“Cookie”元素，则使用该“Cookie”元素值将Cookie头部添加到实体头部(步骤S104)。如果存在“hidden”元素，则在GET方法的情况下将属性值对“name”和“value”添加到请求URI，或在POST方法的情况下将属性值对“name”和“value”添加到实体主体。然后，HTTP请求被传送(步骤S106)。
HTTP响应分析器13a(参见图1)接收对所传送的HTTP请求的响应(步骤S107)，并分析其内容(步骤S108)。如果状态码是表示重定向的“3XX”(步骤S109是)，则传送重定向HTTP请求(步骤S111)。如果状态码是表示正常状态的“200”(步骤S110是)，则该处理过程被传递到响应生成器14a(参见图1)。
响应生成器14a生成SOAP响应(步骤S113)并且将会话信息(sessionInfo段)添加到所生成的SOAP响应(步骤S114)。然后，分析并模拟HTML以添加关于应用段自身的信息(步骤S115)。此外，对于处理实体头部(步骤S116)、处理HTML脚本(步骤S117)和处理HTML表格(步骤S118)的处理过程被分别执行(将在后面描述)。最后，传送该SOAP响应(步骤S119)并且结束该处理过程。
图10示出了生成HTTP请求(步骤S102)的细节。首先，根据适配器配置的设置(在后面描述)设置HTTP请求行(步骤S102a)，并与例如用户代理的头部一起设置HTTP实体头部(步骤S102b)。HTTP实体主体被设置成空白(步骤S102c)。从应用段(不是“sessionInfo”的一部分)中提取属性值对“name”和“value”(步骤S102d)。在GET方法的情况下属性值对“name”和“value”被添加到请求URL(步骤S102f)，或者在POST方法的情况下属性值对“name”和“value”被添加到实体主体(步骤S102g)。
图11到13示出了对每个处理“action”、“cookie”和“hidden”的处理过程(S103、S104和S105)，由于其在图9的描述中已经很清楚了，因此省略了对其的描述。
图14到16示出了从所接收的HTTP响应生成Web服务响应的算法的细节。对于处理实体头部(步骤S116)，如果在实体头部中存在设置Cookie头部(步骤S116a是)，则根据该头部添加“cookie”元素(步骤S116b)。对于处理HTML脚本(步骤S117)，如果存在已经由该脚本设置的“cookie”(步骤S117a是)，则根据模拟该脚本的结果来添加“cookie”元素(步骤S117b)。对于处理HTML表格(步骤S118)，根据HTML表格中的“action”属性值来添加“action”元素(步骤S118a)。然后，如果存在“hidden input”(步骤S118b是)，则根据该“hidden input”添加“hidden”元素(步骤S118c)。
<设置>
如图17所示，使用设置信息(适配器配置)提供根据本发明的Web服务转换代理。“要适应的HTTP服务器”部分500提供了HTTP服务器的主机名或IP地址，以及TCP端口。“WSDL设置”部分501指定了要生成的名称空间和WSDL(Web服务描述语言)名称。WSDL是用于描述Web服务内容的XML语法，并且由Web服务客户端所引用。
虽然一个HTML页面可以包含多个表格(FORM元素)，但为了简便起见，下面的描述假定一个HTML页面只包含一个表格。为了允许多个表格，每个表格与一个Web服务操作相关联。
“状态认知标记”部分502指定了是否允许全状态Web应用。如果其设置为false，则执行仅允许传统的无状态Web应用的Web服务转换。如果其设置为true，则执行允许根据本发明的全状态Web应用的Web服务转换。
对于每个HTTP会话(HTTP请求和响应对)，设置“HTTP请求方法”部分503、“WSDL操作名称”部分504、“请求设置”部分505和“响应设置”部分506。在上述部分中，“HTTP请求方法”部分503指定GET或POST，而“WSDL操作名称”部分504指定相应的WSDL操作的名称。
“请求设置”部分505指定用户最初输入的哪部分信息被适应成为将要作为Web服务请求而接收的信息，以及哪部分固定不变。“响应设置”部分506指定从服务器返回的哪部分HTML内容将要作为Web服务响应被返回。
这里省略了关于如何检索HTML的某一部分的详细描述，因为其与现有技术相关，例如在“A Brief Survey of Web Data Extraction Tools”(Alberto H.F.Laender和Berthier A.Ribeiro-Neto，ACM SIGMODRecord，第31卷，第2期，2002年6月)中介绍的现有技术。任何现有技术都是可适用的。例如，一种现有技术可描述出，由某种XPath指定的一部分HTML应当被转换成String类型的XML(可扩展标记语言)方案，并且包括指定元素。
<生成WSDL>
基于上述的设置信息，并且在关于额外的用户指定设置(例如命名的映射)的某些情况中，生成由Web服务转换提供的用于服务的WSDL。基本上，“请求设置”部分505中指定的信息被映射到Web服务请求中的消息部分，而“响应设置”部分506中指定的信息被映射到Web服务响应中的消息部分。此外，不考虑设置信息，适当地定义错误事件中的消息。一般而言，上述处理过程对于用于执行Web应用的Web服务转换的工具来说是很通用的。
图18的上半部分示出了这样的典型的WSDL生成器。然而，在图18的下半部分，根据本发明的技术引用全状态认知标记(510)并向WSDL添加对于传递会话信息(520)来说必需的部分。根据本发明的技术自动地定义用于传递会话信息的消息部分，并将其添加到WSDL描述中。具体地，生成的WSDL包括具有如图6所示的结构的数据，作为其常规消息部分的一部分或者作为独立消息部分。
图19示出了该算法。首先，根据给定的设置信息生成WSDL描述(常规过程)(步骤S541)。然后，读出全状态认知选项(对应于图17中的502)(步骤S542)。如果该全状态认知选项是真(步骤S543真)，则会话信息(sessionInfo段)被添加到WSDL描述中的每个消息(步骤S544)。
这在下面参照特定示例进行描述。
<生成WSDL的示例>
假定给定如图20所示的设置信息。从该设置信息，生成图21所示的WSDL。
这里，会话信息是独立的消息部分(SessionInfo段)，而关于主表格输入和结果的信息是另一消息部分(RequestDocument/ResponseDocument段)。可替换地，一个部分包括会话信息元素(html2ws:sessinInfo)和表格输入元素(app:searchRequestelement)的内容，而另一部分可包括会话信息元素(html2ws:sessionInfo)和结果元素(app:searchResponseElement)的内容，以便这些部分可分别成为searchRequest和searchResponse消息的内容。虽然后一个表格基本上是更典型的Web服务并且易于进行处理，但为了清楚地表现会话信息元素，在这里的例示中使用前一方法。
在根据图21的WSDL创建并且从Web服务客户端传送的消息中，对应于WSDL操作“搜索”的一个消息如图22所示。
这里，根据本发明的代理已将方案1(Formula 1)的SOAP请求转换成方案2的HTTP请求，并且将方案3的HTTP响应转换成方案4的SOAP响应。
方案1<s:Envelope xmlns:ss=”http://schemas.xmlsoap.org/soap/envelope/”>
<s:Body>
<html2ws:sessionInfo xmlns:html2ws=”uri:html2ws.xsd”>
<html2ws:action>/order/Submit.jsp;j sessionid=OqXn3Ab9</html2ws:
action>
<html2ws:cookie>ahfodada:adfaxlkjdfa:OqXn3Ab9</html2ws:cookie>
<html2ws:hidden name=”id”>OqXn3Ab9<html2ws:hidden>
</html2ws:sessionInfo>
<m:searchRequestElement xmlns:m=”uri:app.xsd”>
<m:query>Britney Spears</m:query>
</m:searchRequestElement>
</s:Body>
</s:Envelope>
方案2
POST/order/Submit.jsp;session=OqXnb9HTTP/1.1Host:scholar.google.comUser-Agent:Mozilla/5.xCookie:ahfodada:adfaxlkjdfa:OqXn3Ab9q=Britney Spears;id=OqXn3Ab9方案3HTTP/1.1200OKDate:Fri,22Oct 200420:59:30GMTSet-Cookie:ahfodada:adfaxlkjdfa:OqXnb9Content-Type:text/htmlContent-Length:1234<html>
<form action=”/scholar;session=EF01234567”..>
<input..name=”q”value=”>
<input type=”hiddeh”name=”lang”value=”en”>
<input type=”submit”value=”Search”>
...</form>
...
</html>
方案4<s:Envelope xmlns:s=”http://schemas.xmlsoap.org/soap.envelope/”>
<s:Body>
<html12ws:sessionInfo xmlns:html2ws=”uri:html2ws.xsd”>
<html2ws:action>/order/Submit.jsp;jsessionid=OqXn3Ab9</html2ws:
action>
<html2ws:cookie>ahfodada:adfaxlkjdfa:OqXn3Ab9</html2ws:cookie>
<html2ws:hidden name=”id”>OqXn3Ab9<html2ws:hidden>
</html2ws:sessionInfo>
<m:searchResponseElement xmlns:m=”uri:app.xsd”>
<m:queryResults>
<m:queryResult>
<m:url>http://www.britneyspears.com/</m:url>
<m:rank>100</m:rank>
</m:queryResult>
...
</m:queryResults>
</m:searchResponseElement>
</s:Body>
</s:Envelope>
<实现Web服务的示例>
以下示出了通过使用BPEL4WS来组合多个Web服务端口以实现单个Web服务的示例，其中Web服务端口是通过利用根据本发明的Web服务代理，从简单的全状态Web应用获得的。图23是用于目标Web应用“Shop”的屏幕(页面)转变图。然而，这里省略与Web服务转换无关的页面，并且在下面的描述中未使用与Web服务转换无关的页面转变(由虚线所指示)。
该Web服务的操作如下。
1)当用户访问公知的URI时，显示登录页面(Login)701。
2)在登录页面(Login)701，从表格接收用户名(Username)702以及口令(Password)703。如果登录成功，则显示目录页面(Catalog)704。
3)当从目录页面(Catalog)704上的表格中的列表选择物品(Item No.)705时，显示示出了关于该物品的信息的页面(Item)706。然而，如果该物品已脱销，则显示指示该物品已脱销的页面(No Stock)707。
4)当在物品信息页面(Item)706上的表格中按下“购买”按钮时，显示示出了装载物品的购物车的页面(Shopping Cart)708。
5)当在购物车页面(Shopping Cart)708上的表格中按下“订购”按钮时，购物车上的物品被订购，并且显示订购信息页面(Order)709。订购信息页面(Order)709示出了指示期望的递送日期(Delivery Date)710的信息。
当使用适当的设置信息(对于转变到下一个页面所必需的输入表格中的信息、要从下一个页面提取的数据和提取方法、WSDL上的命名等)来提供根据本发明的Web服务转换代理时，对应于图24所示的虚线矩形(711到715)的五个Web服务端口被实现。在每个虚线矩形的左边指示出每个端口的操作。
以下五个端口是对应于上述Web应用操作而实现的Web服务端口。
1)start()其返回会话管理信息(上下文(context))(res0)。(实际上，上下文的内容通常为空白。)2)login()其接收会话管理信息(上下文)、用户名(username)以及口令(password)(req1)，并且返回会话管理信息(上下文)(res1)。
3)showItem()其接收会话管理信息(上下文)和物品号(item number)(req2)，并且返回会话管理信息(上下文)和该物品是否有库存(is instock？)(res2)。从转变目标页面(物品或无库存(Item or No stock))，提取出其是否是脱销页面(例如，基于XPath指定的评估结果)。
4)putItemIntoCart()其接收会话管理信息(上下文)(req3)，并且返回会话管理信息(上下文)(res3)。
5)orderItemsInCart()其接收会话管理信息(上下文)(req4)，并且返回会话管理信息(上下文)和期望的递送日期(delivery date)(res4)。从转变目标页面(订购(Order))，提取指示所述期望的递送日期的部分(例如，基于XPath指定的评估结果)。
访问得出的五个Web服务端口以提供单个Web服务的BPEL4WS程序可以如下编写。
方案51 <process name=”buyItemProcess”..>
2 ...
3 <sequence>
4 <receivename=”receive” parter=”customer”portType=”app2:buyItemPT”5 Operation=”buyItem”variable=”request”/>
67 <invoke name=”invokeStart”partner=”adaptationProxy”8 portType=”app:startPT”operation=”start”9 outputVariable=”res0”/>
1011 <assign>
12 <copy>
13 <from variable=”res0”part=”http2ws:SessionInfo”/>
14 <to variable=”req1”part=”http2ws:SessionInfo”/>
15 </copy>
16 <copy>
17 <from variable=”request”part=”app2:username”/>
18 <to variable=”req1”part=”app:username”/>
19 </copy>
20 <copy>
21 <from variable=”request”part=”app2:password”/>
22 <to variable=”req1”part=”app:password”>
23 </copy>
24 </assign>
2526 <invoke name=”invokeLogin”partner=”adaptationProxy”27 portType=”app:loginPT”operation=”login”28 inputVariable=”req1”outputVariable=”res1”/>
2930 <assign>
31 <copy>
32 <from variable=“res1” part=“http2ws:SessionInfo”>
33 <to variable=“req2” part=“http2ws:SessionInfo”/>
34 </copy>
35 <copy>
36 <from variable=“request” part=“app2:itemNumber”/>
37 <to variable=“req2” part=“app:itemNumber”>
38 </copy>
39 </assign>
4041 <invoke name=”invokeShowItem”partner=”adaptationProxy”42 portType=”app:showItemPT”operation=”showItem”43 inputVariable=”req2”outputVariable=”res2”/>
44 <assign>
45 <copy>
46 <from variable=”res2”part=”http2ws:SessionInfo”/>
47 <to variable=”req3”part=”http2ws:SessionInfo”/>
48 </copy>
49 </assign>
50方案651 <switch>
52 <case condition=”!bpws:getVariableProperty(res2,app:isInStock)”>
53 <throw faultName=”app2:outOfStock”/>
54 </case>
55 </switch>
5657 <invoke name=”invokePutItemIntoCart”partner=”adaptationProxy”58 portType=”app:putItemIntoCartPT”operation＝”putItemIntoCart”59 inputVariable=”req3”outputVariable=”res3”/>
6061 <assign>
62 <copy>
63 <from variable=”res3”part=”http2ws:SessionInfo”/>
64 <to variable=”req4”part=”http2ws:SessionInfo”/>
65 </copy>
66 </assign>
6768 <invoke name=”invokeOrderItemInCart”partner=”adaptationProxy”69 portType=”app:orderItemInCart”operation=”orderItemsInCart”70 inputVariable=”req4”outputVariable=”res4”/>
7172 <assign>
73 <copy>
74 <from variable=”res4”part=”app:deliveryDate”/>
75 <to variable=”response”part=”app2:deliveryDate”/>
76 </copy>
77 </assign>
7879 <reply name=”reply”partner=”customer”portType=”app2:buyItemPT”80 operation=”buyItem”variable=”response”/>
81 </sequence>
82 </process>
由该BPEL4WS程序所实现的Web服务(操作名“buyItem”)接收物品号(app2:itemNumber)、用户名(app2:username)和口令(app2:password)(“request”变量，行4-5)，并且返回期望的递送日期(app2:deliveryDate)(“response”变量，行79-80)。虽然省略了详细描述，但是将会在下面描述对于例示本发明的适用性来说很重要的这些部分。
每个“invoke”部分(行7到9、26到28、41到43、57到59以及68到70)访问由根据本发明的Web服务转换得出的Web服务端口。例如，第一个调用部分(行7到9)设置operation＝”start”，并且调用该“start”操作。通过设置outputVariable＝”res0”而将作为调用该服务的结果而返回的值存储在变量res0中。对其他属性的指定仅仅用于命名或在WSDL中指示描述，因此在这里不需要考虑。虽然在第一个调用部分(行7-9)中没有被使用，但设置inputVariable＝”x”可导致存储在变量x中的值在调用该服务时被传递。
每个“assign”部分(行11到24、30到39、44到49、61到66行以及72到77)设置要在所述先前的和接下来的两个Web服务调用(“invoke”部分)之间传递的数据(会话管理信息)，以及当所述接下来的“invoke”部分(用户名、口令和物品号)被访问时要提供的其他数据。例如，第一个“assign”部分(行11到24)的操作如下。
1)位于“start”操作(行7到9)和“login”操作(行26到28)之间，其将(行12到15)会话信息部分(http2ws:SessionInfo)从包含“start”的结果的变量res0复制到由要传递到“login”的变量req1所指示的值中。
2)其将用户名(app2:username)和口令(app2:password)从已存储了从由该程序实现的操作“buyItem”接收的值的变量“request”复制(行16到23)到要被传递到“login”操作(行26到28)的变量“req1”指示的值中。
因此，借助根据本发明的技术，当调用下一个操作时，仅通过不做改变地使用和传递所接收的会话信息，可以毫无困难地访问被转换成Web服务的全状态Web应用。该处理过程的其余部分与组合多个Web服务的典型处理过程相似，并且对于根据本发明的技术来说并不特别。基本上，所需要的对应用特定的输入可以在操作调用中被传递，并且所需要的对应用特定的输出可以从操作调用接收。
使用根据本发明的技术获得的服务不仅可以简单地被顺序调用，还可以根据每个服务的操作调用结果自由地改变控制流，或者自由地使用该调用结果而不是用于下一个调用的会话信息。例如，在“invokeShowItem”调用之下和“assign”部分之上的转换部分(行51到55)，使用转换语法来在通过调用showItem操作获得的结果(res2)中检查关于物品是否有库存的信息。如果该物品脱销，则返回SOAP错误作为buyItem调用的结果(即，该程序实现的Web服务)。
图25是同一程序的图解的表示。第一个<receive name>部分801定义了将要由所实现的Web服务接收的消息，而最后的<reply name>802部分定义了将要由所实现的Web服务返回的消息。<inovke>部分901到905指示到Web服务的请求和来自Web服务的响应。图26示出了具有用于指示数据流的附加箭头的同一程序。虚线箭头指示会话管理信息的流，短划箭头指示从页面提取的数据的流，点划线指示用于在表格中输入的数据的流。
会话管理信息(http2ws:session)基本上与程序控制流一起使用。虽然这里的程序控制除了某些分支之外都是线性的，但可以存在环路和分支，并且会话管理信息(http2ws:session)将与上述流一起使用。
此外，虽然从页面提取的数据的流(虚线箭头)和用于在表格中输入的数据的流(点划线)在这里是相互独立的，但在某些程序中这些流可以是连接的(提取的数据可以用于在表格中输入)。
虽然这里已经使用实施例和示例描述了本发明，但是本发明的技术范围并不限于上述实施例所描述的范围。更确切地，可以对上述实施例做出各种修改和改进。从权利要求中可以很明显看出，这些经修改和改进的实施例也可以被包括在本发明的技术范围中。
在一实施例中，本发明可以主要由驻留于代理装置或代理服务器上的计算机程序实现。存储该程序的存储媒体可以是硬盘；例如软盘(R)的磁记录媒体；例如CD-ROM、DVD或PD的光记录媒体；例如MD的磁光记录媒体；磁带媒体；例如ID卡的半导体存储器等等。而且，可以通过包括在连接于因特网的服务器系统中的存储器设备(例如硬盘或RAM)将该程序提供给计算机系统。
权利要求
1.一种用于提供Web服务的方法，其中代理装置响应于来自Web服务客户端的请求而访问Web应用服务器，该方法包括以下步骤响应于来自所述Web服务客户端的请求，传送HTTP请求到所述应用服务器；将从所述Web应用服务器返回的HTTP响应中的实体头部和实体主体中提取的用户会话信息，以及从所述HTTP响应中的所述实体主体中提取的应用信息，嵌入对所述Web服务客户端的响应中；以及将来自所述Web服务客户端的请求中包含的所述用户会话信息嵌入到实体头部和实体主体中，作为HTTP请求中的应用数据的一部分，并将所述HTTP请求传送到所述Web应用服务器。
2.如权利要求1所述的用于提供Web服务的方法，其中所述来自Web服务客户端的请求是简单对象访问协议请求，并且对于所述请求的所述响应是简单对象访问协议响应。
3.如权利要求1所述的用于提供Web服务的方法，其中所述用户会话信息是URI信息、设置Cookie信息和隐藏标志信息。
4.如权利要求3所述的用于提供Web服务的方法，包括由所述代理装置基于用户预先提供的配置信息而生成作为Web服务接口信息的Web服务描述语言的步骤。
5.如权利要求4所述的用于提供Web服务的方法，其中所述配置信息包含向所述代理装置指示出Web应用是否包括多个会话的信息。
6.如权利要求4所述的用于提供Web服务的方法，其中向Web服务描述语言添加描述，所述描述指引出，嵌入HTTP请求的所述用户会话信息被嵌入到所述简单对象访问协议请求中作为其一部分。
7.如权利要求4所述的用于提供Web服务的方法，其中向Web服务描述语言添加描述，所述描述指引出，嵌入HTTP响应的所述用户会话信息被嵌入到所述简单对象访问协议响应中作为其一部分。
8.一种代理装置，其通过响应于来自Web服务客户端的请求而访问Web应用服务器，来提供Web服务，所述代理装置包括响应生成器，其将从所述Web应用服务器返回的HTTP响应中的实体头部和实体主体中提取的用户会话信息，以及从所述HTTP响应中的所述实体主体中提取的应用信息，嵌入对所述Web服务客户端的响应中；HTTP请求生成器，其将来自所述Web服务客户端的请求中包含的所述用户会话信息嵌入到实体头部和实体主体中，作为HTTP请求中的应用数据的一部分；以及HTTP请求传送器，其响应于来自所述Web服务客户端的请求，将由所述HTTP请求生成器生成的所述HTTP请求传送到所述Web应用服务器。
9.如权利要求8所述的代理装置，其中来自所述Web服务客户端的所述请求是简单对象访问协议请求，并且对于所述请求的所述响应是简单对象访问协议响应。
10.如权利要求8所述的代理装置，其中所述用户会话信息是URI信息、设置Cookie信息和隐藏标志信息。
11.一种用于实现如权利要求1-7中的方法之一的计算机程序产品。
全文摘要
需要一种提供现有的Web应用作为Web服务的简单的方法，其可被应用到跨多个页面维持用户会话的Web应用，并且其对于转换代理和Web服务客户端来说是简单的。从自存储了Web应用的HTTP服务器传送的HTTP响应中提取嵌入了典型使用的会话管理技术的会话信息。所提取的信息被嵌入Web服务响应中，作为从HTTP服务器返回的用户会话信息。用户会话信息还被适应为被嵌入和传送到Web服务请求中。因此，使用适当的会话管理技术将从Web服务客户端接收的用户会话信息嵌入HTTP请求中并传送到HTTP服务器。
文档编号H04L12/46GK1901490SQ20061010150
公开日2007年1月24日 申请日期2006年7月18日 优先权日2005年7月19日
发明者立堀道昭 申请人:国际商业机器公司