精彩的人生

Applying the Web services invocation framework

Calling services independent of protocols

獨立于協(xié)議的服務(wù)調(diào)用

Paul Fremantle (pzf@uk.ibm.com)
Senior Software Engineer, IBM Application and Integration Middleware
01 Jun 2002

Web 服務(wù)調(diào)用框架，提供了一種與傳輸協(xié)議和服務(wù)所在地?zé)o關(guān)的 web 服務(wù)調(diào)用方式。某種程度上可以把 WSIF 叫做不基于 SOAP 的簡單應(yīng)用開發(fā)。了解 Apache Software Group 發(fā)布 WSIF 的最新變化。

?

Introduction

Web 服務(wù)調(diào)用框架（ WFIS ）是一種用來調(diào)用 Web 服務(wù)的簡單的 Java API ，而且不論服務(wù)在何時何地被提供。它把開發(fā)者，從必須為一些特定的傳輸協(xié)議和服務(wù)環(huán)境提供服務(wù)的束縛中解放出來。因此，它提供一個 API 提供獨立綁定，來訪問各種 Web 服務(wù)。它允許無存根或完全動態(tài)地調(diào)用 Web 服務(wù)，這是基于一種在運(yùn)行時檢查服務(wù)元數(shù)據(jù)的技術(shù)。它也允許允許在運(yùn)行時插入一個升級的任務(wù)綁定。如果你使用的 WSIF 提供者允許，也可以實時插入一個新的綁定。它也能選擇一個綁定延來期調(diào)用服務(wù)，直到運(yùn)行時再綁定。最后，它是基于 WSDL 的，所以他可以調(diào)用任何 WSDL 中描述的服務(wù)。

WSIF 最初發(fā)布在 2001 年 10 月份的 alphaWorks 。 AlphaWorks 自從被發(fā)布以來被下載了 4000 多次。 WSIF 的創(chuàng)立者之一寫了兩篇很優(yōu)秀的文章，來描述其建立 WSIF 的動機(jī)和它的使用，推薦大家讀一下 (See Web service invocation sans SOAP, Part 1 and 2 ) 。

這篇文章符合 Apache 軟件基金會對 WSIF 捐贈要求。 WSIF 源碼是由 Apache XML 項目捐贈，并且在 Axis work 贊助下完成。可以在 Apache CVS 目錄下獲得，目錄名是 xml-axis-wsif 。代碼在 http://cvs.apache.org/viewcvs.cgi/xml-axis-wsif 。

在這篇文章中，我將關(guān)注 WSIF 的 Motivation ，使用和構(gòu)架。自從 alphaWorks 發(fā)布后 WSIF 的變化就被總結(jié)概括，這篇文章也包含一些實驗性的和未來的觀點。但是在此之前，我將快速的回故一下 WSDL 。

?

Some background on WSDL

Web 服務(wù)描述語言（ WSDL ）從一開始就具有可擴(kuò)展性。在 WSIF 中，設(shè)計者把接口和服務(wù)執(zhí)行分離。

?

在 WSDL 中一個服務(wù)被清楚地定義為三個部分：

1． The PortType 它定義了服務(wù)提供的抽象接口。一個 PortType 定義了一系列操作。每個操作能被 In-Out （請求－響應(yīng)）， In-only ， Out-only, 和 Out-in （征求－響應(yīng)）。每個操作都定義了輸入或輸出消息。一個消息被定義為一系列部分（ part ），每個部分包含一個 Schema 定義類型。

2． The Binding 一個綁定定義了抽象 PortType 與一個服務(wù)的數(shù)據(jù)格式和協(xié)議是如何映射的。例如， SOAP 綁定定義了編碼方式， SOAP Action header ， body 的名字空間（目標(biāo) URI ）等等。

3． The port 它定義了服務(wù)所在的實際位置（ endpoint ），比如，在 SOAP 服務(wù)器上可獲得的 HTTP URL 。

?

現(xiàn)在的 WSDL ，每個 port 有且只有一個綁定，每個綁定只有一個 PortType 。相反（更重要的是），每一個服務(wù)（ PortType ）能包含多個端口，每個端口代表一種可以供選擇的位置和綁定用以訪問那個服務(wù)。

當(dāng)我們設(shè)計 WSIF 時我們先把它做為 WSDL 的鏡像，因為我們需要基于 WSDL 的 API 而不是直接基于 SOAP 。 WSIF 是一個框架有效地支持傳輸和格式化。 WSIF 中的 provider 支持 SOAP 。

?

WSDL 加上了可擴(kuò)展元素后，和 SOAP 相比，它能夠建立其它的服務(wù)。典型地， web 服務(wù)是用已有的應(yīng)用組建構(gòu)造，比如 JAVA 類，企業(yè)級 JAVA BEAN ，或 COM 對象。這些組件有時被封裝成應(yīng)用程序運(yùn)行在特定的系統(tǒng)，比如大型機(jī)事務(wù)處理系統(tǒng)。通過擴(kuò)展 WSDL 來描述已有的組件模型，我們能獲取被暴露的 SOAP － available 服務(wù)和下面的組件之間的繼承關(guān)系， ….. 。事實上，為已存在的組件加上可擴(kuò)展元素有更多的用途——它為已有的組件模型加上了面向服務(wù)構(gòu)架的描述能力。

?

Motivation for WSIF

提出 WSIF 的動機(jī)是我們希望看到“面向構(gòu)架的服務(wù)”應(yīng)用更加廣泛，而不是僅僅的 SOAP 。現(xiàn)在，有大量不同的協(xié)議，傳輸和分布式計算技術(shù)能夠提供比 SOAP 更多的東西，尤其是在管理，交易安全，和服務(wù)質(zhì)量（ QoS ）方面。而 SOAP 之所以能夠后來居上，主要是原因是資金投入。許多公司已經(jīng)投入了大量資金在的技術(shù)上，比如 CORBA ，他們當(dāng)然希望能夠繼續(xù)使用這些技術(shù)。另一方面，使用 SOAP 的 Web 服務(wù)有一個獨特的優(yōu)勢——描述和發(fā)現(xiàn)的構(gòu)架。任何人都可以從 UDDI 目錄或一個 inspection 文檔中下載 WSDL 文檔，并且使用一個普通的工具生成的代碼就可以使用服務(wù)，不論服務(wù)是在局域網(wǎng)還是通過 Internet 。腳本語言的使用也使其它工具得到發(fā)展——比如一些組成和設(shè)計服務(wù)的語言（ XLANG 和 WSFL ）。

We really wanted to make the extensibility and structure of WSDL real. WSDL allows us to describe existing systems using extensibility elements. For example, we have written WSDL extensions to describe transactions in CICS and IMS using connectors, calls to remote stateless session Enterprise JavaBeans, as well as SOAP and non-SOAP messages over JMS-based messaging systems. However, while describing things is useful, it isn't as useful as executing them.

?

現(xiàn)在， WSDL 不僅僅是一個描述層——它已經(jīng)用于一些工具中，這些工具使用 WSDL 描述來生成訪問服務(wù)的存根。所以，如果我們?yōu)榉?/span> SOAP 系統(tǒng)加上描述，我們將失去那些好處。 WSIF 是一個可插入的框架，它允許 provider 插入。一個 provider 就是一段代碼，它支持 WSDL 擴(kuò)展，并且通過特定的執(zhí)行可以調(diào)用服務(wù)。這就意味著客戶端的代碼是和（服務(wù)器端）執(zhí)行無關(guān)的，它僅僅依賴服務(wù)的 PortType 。 WSIF 同時也支持延遲綁定，即一個新的 Provider 和描述可在運(yùn)行時獲得，而已有的客戶端可使用這個新的 implementation 。最后， WSIF 允許客戶端為 infrastructure 和 runtime 代理端口的選擇，這使用戶在服務(wù)質(zhì)量特性和商務(wù)策略的基礎(chǔ)上選擇 implementation 。

?

WSDL 的結(jié)構(gòu)允許一個 Web 服務(wù)有多個 implementation ，多個端口共享一個 PortType 。換句話說， WSDL 允許同樣的端口綁定到 SOAP 和 IIOP 。我們希望我們的 API 允許同樣的客戶端代碼訪問任何可以獲得的綁定——如果代碼為 PortType 而寫，那么它在端口和綁定被使用時應(yīng)該能被部署或配置（或代碼選擇）。

?

我們?yōu)?/span> WSIF 提出了一下要求，它必須：

1． Support any valid WSDL extensions. 支持任何合法的 WSDL 擴(kuò)展。

2． Support dynamic invocation of WSDL-described services. 支持 WSDL —描述服務(wù)的動態(tài)調(diào)用。

3． Support an API based on WSDL PortTypes. 支持基于 WSDL 端口類型的 API 。

4． Allow late binding to different formats and transports. 允許延遲綁定不同的數(shù)據(jù)格式和傳輸。

5． Support both compiled and dynamic approaches. 支持編譯和動態(tài) approaches 。

6． Support minimum code deployment scenarios (n providers, no per-service code). 支持最小代碼部署方案（ n provider ， no persevice 代碼）。

7． Support different in-memory representations of service request data.

?

WSIF usage

WSIF 的用法有兩種：基于存根的模型和動態(tài)調(diào)用接口（ DII ）。

Stub model
基于存根的模型允許使用者使用泛型編程模型，調(diào)用服務(wù)器上的業(yè)務(wù)函數(shù)。從 WSDL接口到JAVA定義接口的映射已經(jīng)被規(guī)范花——在JAX－RPC標(biāo)準(zhǔn)中。有些人試圖通過JCP/JSR過程把WSIF模型有JAX－RPC整合起來，但是從這個角度上看WSIF總是顯得太試驗化了。我們所能做的只能是松散的整合。JAX-RPC定義了服務(wù)定義接口（SDI）——存根的業(yè)務(wù)接口。WSIF也定義了一個接口想JAX－RPC一樣來使用同樣的SDI。所以，盡管WSIF和JAX－RPC不能共享接口，他們卻共享工具（比如，Axis WSDL2Java）。Listing 1是一個存根模型的例子。

Dynamic invocation interface
DII 和WSDL十分相近。在WSDL中，每個操作都有一個輸入消息和可選的輸出或錯誤消息。在WSIF中，我們劃分了相似的層次。基本上是對應(yīng)的。事實上，我們的第一次迭代是一一對應(yīng)的，但是我們歸納的更有邏輯性更（簡便）簡單。對應(yīng)關(guān)系如Table 1: Correspondence of WSDL and WSIF entities所示。

Table 1: Correspondence of WSDL and WSIF entities

WSDL	WSIF
(WSIL/UDDI)	WSIFServiceFactory or JNDI
Service	WSIFService
Port	WSIFPort
Binding	( 無對應(yīng)項)
Operation	WSIFOperation
Message	WSIFMessage
Part	( 無對應(yīng)項)

使用DII你需要：

1. Select a port. 選擇一個端口

2. Create an operation. 建立一個操作

3. Create and populate the in-message. 建立并組裝輸入消息。

4. Execute the operation. 執(zhí)行操作

5. Read the response data from the out-message. 從輸出消息中讀取響應(yīng)數(shù)據(jù)。

一個簡單的例子如 Listing 2所示。

AlphaWorks發(fā)布的WSIF的特性之一是有一個命令行參數(shù)工具——Dynamic Invoker，這個工具能調(diào)用任何接口具有簡單類型的Web服務(wù)。我們通常請求的服務(wù)是，參數(shù)使用了復(fù)雜類型的動態(tài)調(diào)用服務(wù)。WSIF就是基于這個思想設(shè)計的，但是對于第一次迭代我們僅僅支持使用JavaBean組件的服務(wù)，所以如果沒有先產(chǎn)生一個合適的JavaBean組件，你將不能調(diào)用服務(wù)。作為補(bǔ)救，我們開發(fā)了一系列的名為JROM的類（起初它是支持Java記錄對象模型（JROM），由Jay－Rom聲明，但是現(xiàn)在它僅僅是個名字而已）。JROM是一個抽象的樹狀結(jié)構(gòu)，這種結(jié)構(gòu)能代表內(nèi)存中很多schema復(fù)雜類型。JROM作為輕量級的DOM，它的樹裝結(jié)構(gòu)的每個葉子節(jié)點都是一個基本類型（不像DOM都是字符串）。

通過和WSIF一起使用JROM，動態(tài)調(diào)用甚至容許在Classpath中沒有與Schema復(fù)雜類型相匹配的Java類型。這是一種十分有力的方式，尤其是在建立一個動態(tài)web服務(wù)系統(tǒng)時，如網(wǎng)關(guān)，流引擎，測試客戶端。不是所有的Provider都支持JROM，但是我們在ApacheSOAP Provider中加入了對JROM的支持。

JROM 不是WSIF開源項目發(fā)布的一部分，但是它可以從alphaWorks中獲得，見 www.alphaworks.ibm.com/tech/jrom.

WSIF architecture
WSIF 的架構(gòu)是基于一些工廠類的。使用工廠類的原因是，這樣可以隱藏對象是所使用的是“靜態(tài)”還是“動態(tài)”。在靜態(tài)的情況下，對象被創(chuàng)建以提供特定的端口，消息或操作。靜態(tài)時implementation可以快速建立。在動態(tài)情況下，對象使用WSDL描述在運(yùn)行時控制特定的端口，操作或消息傳遞。目前WSIF主要用于動態(tài)對象，就像我們最初怎樣設(shè)計它們的一樣。我們把WSIF分為不同的動態(tài)度。

Fully dynamic architecture 完全動態(tài)架構(gòu)

在流控制引擎中可能用到，流的描述作為一個XML文檔被提供。流引擎在發(fā)送消息給其他的操作之前處理消息，以聚合成一個新的服務(wù)。被部署的代碼是每個綁定類型一個Provider。因此,這是一個b結(jié)構(gòu)，b是一些不同的WSDL綁定擴(kuò)展。

Semi-dynamic architecture 半綁定構(gòu)架
定義了PortType的消息被靜態(tài)編譯，但是綁定本身是動態(tài)的。這就要求代碼部署基于PortType，且每個綁定一個Provider。因此，這是一個p＋b結(jié)構(gòu)，其中p是一些PorType，b是一些WSDL綁定。當(dāng)接口變化時，編譯的消息必須被部署。

Static architecture 靜態(tài)構(gòu)架
WSDL 綁定和端口都是靜態(tài)編譯。在這種情況下，在tooling time被定義的默認(rèn)端口被編譯。代碼部署是每個綁定實例一個實體，因此，可看作是p×b 結(jié)構(gòu)。

Changes since the alphaWorks release 自alphaworks發(fā)布后的變化
There are a number of changes since the alphaWorks release. You are encouraged to look at the open source code tree yourself. The main changes are:

• Simplification of the WSIFMessage and WSIFPart model. We removed the WSIFPart interface and merged it into WSIFMessage. In order to capture different styles of using WSIFMessage, we added a method getRepresentationStyle().

• Renaming of the PortFactory object to Service.

• Addition of a ServiceFactory interface.

• Change from using the PortTypeCompiler to using the J2SE 1.3 dynamic proxy support.

• Addition of new bindings and transports -- SOAP over JMS, EJB binding, Apache Axis-based SOAP provider.

• Support for tracing and logging activity.

• Support for dynamic registration of new providers using the J2SE JAR service provider spec (see Resources).

Experimental additions to WSIF
目前WSIF有許多研究領(lǐng)域，異步請求－響應(yīng)消息和context－aware消息是其中的兩個。

Asynchronous request-response
現(xiàn)在有一個異步請求－響應(yīng)模型，響應(yīng)（response）在由請求引發(fā)的不同運(yùn)行線程中被處理。為了支持它，請求者注冊一個返回對象或句柄，它們在響應(yīng)到達(dá)時被調(diào)用。

當(dāng)請求消息被發(fā)送之后，句柄對象被傳遞給WSIFOperation。WSIF提供一個相關(guān)的服務(wù)來存儲句柄而不是提供一個identifier。WSIFOperation調(diào)用WSIF相關(guān)的服務(wù)，這個服務(wù)存儲了服務(wù)本身和請求句柄使用的相應(yīng)的ID。這都發(fā)生當(dāng)前事務(wù)的內(nèi)部。如果用戶請求指定了一個事務(wù)隊列，那么這些工作在當(dāng)前事務(wù)內(nèi)完成。

WSIFOperation 和WSIFResponseHandle對象是序列化的，所以句柄對象的狀態(tài)能被保持，即使萬一在響應(yīng)和請求時系統(tǒng)出錯也可以被保持。相應(yīng)的服務(wù)也是可插入的，而其他的特性，比如原子事務(wù)和持續(xù)性都能保證高可靠性。

當(dāng)某個延遲端口響應(yīng)到來時，監(jiān)聽線程將捕獲它并傳遞給用作存儲的WSIFOperation。操作包括把響應(yīng)散列成WSIFMessage邏輯，并執(zhí)行句柄函數(shù)executeAsyncResponse()，此函數(shù)以outMessage為參數(shù)。監(jiān)聽線程運(yùn)行在不同事務(wù)上，這些事務(wù)源自原始的請求。響應(yīng)也因此把事務(wù)和請求分割開來。

例如, Listing 3顯示了一個句柄如何通過實現(xiàn)（implement）接口類WSIFResponseHandler而來。此Handler是用來解釋響應(yīng)消息和使用響應(yīng)值的。

Listing 3. Implementing an asynchronous handler in WSIF

服務(wù)調(diào)用如 Listing 4示：

Listing 4. Invoking a service asynchronously with WSIF

Content-aware message內(nèi)容－提醒消息
我們也希望支持設(shè)定和使用上下文。W3C的web服務(wù)工作小組也就這個主題討論過，但是沒有規(guī)定語法和語義。

例如，一個SOAP/HTTP端口可能要求得到HTTP用戶名和密碼。這些信息對于服務(wù)調(diào)用來說十分特殊，但是通常又并非是服務(wù)參數(shù)的一部分。在總體上，上下文被定義成一系列name-value對。但是，Web服務(wù)需要使用XML schema類型定義數(shù)據(jù)類型，用“name－value對”表示上下文的方法可用表示 WSIFMessage 的方法來替代——即一組被命名的Part，每個part等價于一個XML Schema類型實例。這雖然稍稍超出了使用屬性的概念，但是更多的保持了WSDL和WSIF的特點。

The methods setContext() and getContext() on a WSIFPort and WSIFOperation allow the application programmer or stub to pass context information to the binding. The Port implementation may use this context -- for example to update a SOAP header. There is no definition of how a Port may utilize the context.

WSIFPort 和 WSIFOperation 上的 setContext() 和 getContext() 函數(shù)允許應(yīng)用程序員或者存根通過上下文信息綁定。 Port 的實現(xiàn)也會用到這些上下文——比如升級一個 SOAP 頭。但 Port 怎樣使用上下文沒有定義。

Ideas for the future
There are a number of areas in WSIF we would like to see work on to improve its functionality and usefulness. First, we would like to have refactoring capabilities to separate the transport from message formatting. We have defined a WSIFFormatter class to allow access to and conversion of the data into a native format.

Next, an abstract tree representation of the data in a a message would be useful. Currently, we mainly use compiled classes from the schema to carry the service parameters in WSIFMessage. However, in one implementation of WSIF, the Web Services Gateway (see Resources), we use an abstract tree notation called JROM that closely maps to an XML Schema.

We would also like to see more and better providers for the many types of transports and object systems that exist. Finally, an implementation of WSIF in C or C++ would certainly be helpful to developers creating services in those languages.

Summary 小結(jié)
WSIF 是一個開源的面向服務(wù)的框架，它允許SOAP和非SOAP服務(wù)在WSDL中定義并用普通的方式調(diào)用。WSIF定義了可插入的接口（Provider接口）來支持新的傳輸和協(xié)議。通過支持代理接口和動態(tài)調(diào)用接口，WSIF能夠使最終用戶和系統(tǒng)軟件開發(fā)者這使用多種些協(xié)議支持WSIF提供的接口。WSIF支持延遲綁定，這樣服務(wù)可以被重新綁定到一個新的協(xié)議上而不需要改變代碼。The open source WSIF codebase includes providers for Java, EJB, and SOAP (over HTTP and JMS). WSIF has been used in WebSphere Enterprise Edition 4.1 and Versata's Logic Server WebServices Add-On.

Acknowledgments
The main contributors to the WSIF release, in alphabetical order, are: Aleksander A. Slominski, Anthony Elder, Dieter Koenig, Gerhard Pfau, Jeremy Hughes, Mark Whitlock, Matthew J. Duftler, Michael Beisiegel, Nirmal Mukhi, Owen Burroughs, Paul Fremantle, Piotr Przybylski, and Sanjiva Weerawarana

Resources

• Check out Web services invocation sans SOAP, Part 1 and Part 2.

• Web Services invocation framework on Apache Software Foundation.

• Check out the JROM project on alphaWorks.

• The W3C Note on WSDL.

• The J2SE JAR service provider specification allows dynamic registration of new providers.

About the author Paul Fremantle is an architect in IBM's Hursley Laboratory, working on Web services components in IBM WebSphere Application Server, as well as open source projects such as WSDL4J and WSIF. Paul is the co-lead of the Java standard JSR110: Java APIs for WSDL. Paul previously worked as a WebSphere specialist in the software group and as an architect in IBM Global Services. Before joining IBM, Paul worked as a consultant in the pharmaceutical industry. His publications include articles on porting EJBs from WebLogic to WebSphere, and a Redbook, "The XML Files: Using XML and XSL in WebSphere." Paul has presented at ApacheCon, XML Europe, Software Architecture, and other industry conferences. He has an M.A. in Mathematics and Philosophy and an M.Sc in Computation from OxfordUniversity. You can contact Paul at pzf@uk.ibm.com.

轉(zhuǎn)載自：http://it.jiulove.com/inc/news/20050731/11292026111.asp