What is a REST Web Service

The acronym REST stands for Representational State Transfer, this basically means that each unique URL is a representation of some object. You can get the contents of that object using an HTTP GET, to delete it, you then might use a POST, PUT, or DELETE to modify the object (in practice most of the services use a POST for this).

Who's using REST?

All of Yahoo's web services use REST, including Flickr, del.icio.us API uses it, pubsub, bloglines, technorati, and both eBay, and Amazon have web services for both REST and SOAP.

Who's using SOAP?

Google seams to be consistent in implementing their web services to use SOAP, with the exception of Blogger, which uses XML-RPC. You will find SOAP web services in lots of enterprise software as well.

REST vs SOAP

As you may have noticed the companies I mentioned that are using REST api's haven't been around for very long, and their apis came out this year mostly. So REST is definitely the trendy way to create a web service, if creating web services could ever be trendy (lets face it you use soap to wash, and you rest when your tired). The main advantages of REST web services are:

• Lightweight - not a lot of extra xml markup
• Human Readable Results
• Easy to build - no toolkits required

SOAP also has some advantages:

• Easy to consume - sometimes
• Rigid - type checking, adheres to a contract
• Development tools

For consuming web services, its sometimes a toss up between which is easier. For instance Google's AdWords web service is really hard to consume (in CF anyways), it uses SOAP headers, and a number of other things that make it kind of difficult. On the converse, Amazon's REST web service can sometimes be tricky to parse because it can be highly nested, and the result schema can vary quite a bit based on what you search for.

Which ever architecture you choose make sure its easy for developers to access it, and well documented.




原文：http://www.petefreitag.com/item/431.cfm

I will first provide a brief introduction to REST and then describe how to build Web services in the REST style.

What is REST?

REST is a term coined by Roy Fielding in his Ph.D. dissertation [1] to describe an architecture style of networked systems. REST is an acronym standing for Representational State Transfer.

Why is it called Representational State Transfer?

The Web is comprised of resources. A resource is any item of interest. For example, the Boeing Aircraft Corp may define a 747 resource. Clients may access that resource with this URL:

http://www.boeing.com/aircraft/747

A representation of the resource is returned (e.g., Boeing747.html). The representation places the client application in a state. The result of the client traversing a hyperlink in Boeing747.html is another resource is accessed. The new representation places the client application into yet another state. Thus, the client application changes (transfers) state with each resource representation --> Representational State Transfer!

Here is Roy Fielding's explanation of the meaning of Representational State Transfer:

"Representational State Transfer is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through an application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use."

Motivation for REST

The motivation for REST was to capture the characteristics of the Web which made the Web successful. Subsequently these characteristics are being used to guide the evolution of the Web.

REST - An Architectural Style, Not a Standard

REST is not a standard. You will not see the W3C putting out a REST specification. You will not see IBM or Microsoft or Sun selling a REST developer's toolkit. Why? Because REST is just an architectural style. You can't bottle up that style. You can only understand it, and design your Web services in that style. (Analogous to the client-server architectural style. There is no client-server standard.)

While REST is not a standard, it does use standards:

• HTTP
• URL
• XML/HTML/GIF/JPEG/etc (Resource Representations)
• text/xml, text/html, image/gif, image/jpeg, etc (MIME Types)

The Classic REST System

The Web is a REST system! Many of those Web services that you have been using these many years - book-ordering services, search services, online dictionary services, etc - are REST-based Web services. Alas, you have been using REST, building REST services and you didn't even know it.

REST is concerned with the "big picture" of the Web. It does not deal with implementation details (e.g., using Java servlets or CGI to implement a Web service). So let's look at an example of creating a Web service from the REST "big picture" perspective.

Parts Depot Web Services

Parts Depot, Inc (fictitious company) has deployed some web services to enable its customers to:

• get a list of parts
• get detailed information about a particular part
• submit a Purchase Order (PO)

Let's consider how each of these services are implemented in a RESTful fashion.

Get Parts List

The web service makes available a URL to a parts list resource. For example, a client would use this URL to get the parts list:

http://www.parts-depot.com/parts

Note that "how" the web service generates the parts list is completely transparent to the client. All the client knows is that if he/she submits the above URL then a document containing the list of parts is returned. Since the implementation is transparent to clients, Parts Depot is free to modify the underlying implementation of this resource without impacting clients. This is loose coupling.

Here's the document that the client receives:

<?xml version="1.0"?>
<p:Parts xmlns:p="http://www.parts-depot.com" 
         xmlns:xlink="http://www.w3.org/1999/xlink">
      <Part id="00345" xlink:href="http://www.parts-depot.com/parts/00345"/>
      <Part id="00346" xlink:href="http://www.parts-depot.com/parts/00346"/>
      <Part id="00347" xlink:href="http://www.parts-depot.com/parts/00347"/>
      <Part id="00348" xlink:href="http://www.parts-depot.com/parts/00348"/>
</p:Parts>

[Assume that through content negotiation the service determined that the client wants the representation as XML (for machine-to-machine processing).] Note that the parts list has links to get detailed info about each part. This is a key feature of REST. The client transfers from one state to the next by examining and choosing from among the alternative URLs in the response document.

Get Detailed Part Data

The web service makes available a URL to each part resource. Example, here's how a client requests part 00345:

http://www.parts-depot.com/parts/00345

Here's the document that the client receives:

<?xml version="1.0"?>
<p:Part xmlns:p="http://www.parts-depot.com"   
        xmlns:xlink="http://www.w3.org/1999/xlink">
      <Part-ID>00345</Part-ID>
      <Name>Widget-A</Name>
      <Description>This part is used within the frap assembly</Description>
      <Specification xlink:href="http://www.parts-depot.com/parts/00345/specification"/>
      <UnitCost currency="USD">0.10</UnitCost>
      <Quantity>10</Quantity>
</p:Part>

Again observe how this data is linked to still more data - the specification for this part may be found by traversing the hyperlink. Each response document allows the client to drill down to get more detailed information.

Submit PO

The web service makes available a URL to submit a PO. The client creates a PO instance document which conforms to the PO schema that Parts Depot has designed (and publicized in a WSDL document). The client submits PO.xml as the payload of an HTTP POST.

The PO service responds to the HTTP POST with a URL to the submitted PO. Thus, the client can retrieve the PO any time thereafter (to update/edit it). The PO has become a piece of information which is shared between the client and the server. The shared information (PO) is given an address (URL) by the server and is exposed as a Web service.

Logical URLs versus Physical URLs

A resource is a conceptual entity. A representation is a concrete manifestation of the resource. This URL:

http://www.parts-depot.com/parts/00345

is a logical URL, not a physical URL. Thus, there doesn't need to be, for example, a static HTML page for each part. In fact, if there were a million parts then a million static HTML pages would not be a very attractive design.

[Implementation detail: Parts Depot could implement the service that gets detailed data about a particular part by employing a Java Servlet which parses the string after the host name, uses the part number to query the parts database, formulate the query results as XML, and then return the XML as the payload of the HTTP response.]

As a matter of style URLs should not reveal the implementation technique used. You need to be free to change your implementation without impacting clients or having misleading URLs.

REST Web Services Characteristics

Here are the characteristics of REST:

• Client-Server: a pull-based interaction style: consuming components pull representations.
• Stateless: each request from client to server must contain all the information necessary to understand the request, and cannot take advantage of any stored context on the server.
• Cache: to improve network efficiency responses must be capable of being labeled as cacheable or non-cacheable.
• Uniform interface: all resources are accessed with a generic interface (e.g., HTTP GET, POST, PUT, DELETE).
• Named resources - the system is comprised of resources which are named using a URL.
• Interconnected resource representations - the representations of the resources are interconnected using URLs, thereby enabling a client to progress from one state to another.
• Layered components - intermediaries, such as proxy servers, cache servers, gateways, etc, can be inserted between clients and resources to support performance, security, etc.

Principles of REST Web Service Design

1. The key to creating Web Services in a REST network (i.e., the Web) is to identify all of the conceptual entities that you wish to expose as services. Above we saw some examples of resources: parts list, detailed part data, purchase order.

2. Create a URL to each resource. The resources should be nouns, not verbs. For example, do not use this:

http://www.parts-depot.com/parts/getPart?id=00345

Note the verb, getPart. Instead, use a noun:

http://www.parts-depot.com/parts/00345

3. Categorize your resources according to whether clients can just receive a representation of the resource, or whether clients can modify (add to) the resource. For the former, make those resources accessible using an HTTP GET. For the later, make those resources accessible using HTTP POST, PUT, and/or DELETE.

4. All resources accessible via HTTP GET should be side-effect free. That is, the resource should just return a representation of the resource. Invoking the resource should not result in modifying the resource.

5. No man/woman is an island. Likewise, no representation should be an island. In other words, put hyperlinks within resource representations to enable clients to drill down for more information, and/or to obtain related information.

6. Design to reveal data gradually. Don't reveal everything in a single response document. Provide hyperlinks to obtain more details.

7. Specify the format of response data using a schema (DTD, W3C Schema, RelaxNG, or Schematron). For those services that require a POST or PUT to it, also provide a schema to specify the format of the response.

8. Describe how your services are to be invoked using either a WSDL document, or simply an HTML document.

Summary

This article described REST as an architectural style. In fact, it's the architectural style of the Web. REST describes what makes the Web work well. Adhering to the REST principles will make your services work well in the context of the Web.

In a future article I will write about the evolution of the Web using the REST principles.

Acknowledgement

Thanks to Robert Leftwich and Philip Eskelin for their very helpful comments in creating this document.

References

[1] http://www.ebuilt.com/fielding/pubs/dissertation/top.htm

原文：http://www.xfront.com/REST-Web-Services.html

1.1 下载

1.2 数据库安装

1.3 安装juddi及配置

<Context path="/juddi" docBase="juddi" debug="5" reloadable="true" crossContext="true">
  <Logger className="org.apache.catalina.logger.FileLogger" prefix="localhost_juddiDB_log" 
  suffix=".txt" timestamp="true"/>
  <Resource name="jdbc/juddiDB" auth="Container" type="javax.sql.DataSource"/>
  <ResourceParams name="jdbc/juddiDB">
    <parameter>
      <name>factory</name>
      <value>org.apache.commons.dbcp.BasicDataSourceFactory</value>
    </parameter>
    <!-- Maximum number of dB connections in pool. Make sure you
         configure your mysqld max_connections large enough to handle
         all of your db connections. Set to 0 for no limit. -->
    <parameter><name>maxActive</name><value>100</value></parameter>
    <!-- Maximum number of idle dB connections to retain in pool.
         Set to 0 for no limit. -->
    <parameter><name>maxIdle</name><value>30</value></parameter>
    <parameter><name>maxWait</name><value>10000</value></parameter>
    <!-- MySQL dB username and password for dB connections 帐号密码根据数据库安装配置修改 -->
    <parameter><name>username</name><value>root</value></parameter>
    <parameter><name>password</name><value>****</value></parameter>
    <!-- Class name for mysql JDBC driver -->
    <parameter>
      <name>driverClassName</name>
      <value>com.mysql.jdbc.Driver</value>
    </parameter>
    <!-- The JDBC connection url for connecting to your MySQL dB.
         The autoReconnect=true argument to the url makes sure that the
         mm.mysql JDBC Driver will automatically reconnect if mysqld closed the
         connection.  mysqld by default closes idle connections after 8 hours. 
        数据库url连接配置
    -->
    <parameter>
      <name>url</name>
      <value>jdbc:mysql://host.domain.com:3306/juddi?autoReconnect=true</value>
    </parameter>
    <parameter>
           <name>validationQuery</name>
           <value>select count(*) from PUBLISHER</value>
    </parameter>
  </ResourceParams>
</Context>

1.4 本地安装检查

2 测试实例

2.1 使用uddi4j测试

2.1.1 加载配置文件时访问不到samples.prop

    Properties config = new Properties();
    try {
        config.load(new java.io.FileInputStream("./conf/samples.prop"));
    }
    catch (Exception e) {
        System.out.println("Error loading samples property file\\n" + e);
    }

2.1.2 TransportClassName配置错误

# -----------------------------------------------------------------------

# Transport classname. Typically defined on commandline as

# -Dorg.uddi4j.TransportClassName=xxx.

# -----------------------------------------------------------------------

#TransportClassName=org.uddi4j.transport.ApacheSOAPTransport

 TransportClassName=org.uddi4j.transport.ApacheAxisTransport

# TransportClassName=org.uddi4j.transport.HPSOAPTransport

2.1.3 TestFindBusiness案例不通过

2.1.4 PublisherManager的代码错误

RegistryProxy proxy = new RegistryProxy();

  /**

   * changed by xio

   * @param publisher String

   * @param password String

   * @param testprops Properties:增加的参数，传入基本配置

   * @return String

   */

public static String getExpiredAuthToken(String publisher, String password,

                                           Properties testprops) {

    Properties props = new Properties();

    props.setProperty(RegistryProxy.ADMIN_ENDPOINT_PROPERTY_NAME,

                      testprops.getProperty("adminURL"));

    props.setProperty(RegistryProxy.INQUIRY_ENDPOINT_PROPERTY_NAME,

                      testprops.getProperty("inquiryURL"));

    props.setProperty(RegistryProxy.PUBLISH_ENDPOINT_PROPERTY_NAME,

                      testprops.getProperty("publishURL"));



    RegistryProxy proxy = new RegistryProxy(props);

    AuthToken token = null;

    AuthInfo authInfo = null;

    String ret = null;

    try {

      token = proxy.getAuthToken(publisher, password);

      authInfo = token.getAuthInfo();

      ret = authInfo.getValue();

      System.out.println("getExpiredAuthToken:" + authInfo);

      proxy.discardAuthToken(authInfo);

    }

    catch (Exception ex) {

      ex.printStackTrace();

    }

    return ret;

  }

2.2 使用jUDDI测试

原作者：xio@qq.com
来 源：http://xio.mblogger.cn



原文地址：http://it.13520.org/ArticleView/2005-9-7/Article_View_121697.Htm

Web 服务承诺为因特网分布式计算提供基于标准的平台，集中在简易性和灵活性。一种关键的 Web 服务技术是 WSDL，即“Web 服务描述语言”。使用 WSDL，开发者可以以抽象的形式描述 Web 服务，与用在其它分布式计算框架（比如 CORBA）的现有“接口描述语言”（Interface Description Language（IDL））类似。WSDL 也使 Web 服务开发者能够给服务指定具体的绑定。并且这些绑定描述怎样将抽象服务描述映射到特定访问协议。WSDL 的这部分是可扩展的，这就是说任何人都可以提出他们自己的绑定，使之可能通过某个定制的协议访问服务。

因此，从某种程度来说，使用 Web 服务是一种挑战。对于同样的服务可以有多个绑定。这些绑定中的一些可能适合于一些情形，其它可能适合于另外的情形。绑定本身可以代表抽象服务描述到用来访问服务的任意一种协议的映射。虽然有多种选择使用服务和允许绑定扩展是很有用的，但这给客户机以统一方式查看服务造成了困难。

我以当前客户机端 API 及其性能的讨论开始这篇文章。我将通过讨论来激发人们对 WSIF，即“Web 服务调用框架”的需要，然后继续进行 WSIF 的概述。

当前的调用风格及其缺点
用于 Web 服务的 SOAP 绑定是 WSDL 规范的一部分。在大多数编程语言中，该协议有可用的实现和工具，在许多情况下是免费的。这样，它使得开发者能以微乎其微的成本进行用于 Web 服务的独立于平台的开发。

因此，下述情况是不足为奇的：大多数开发者当想到使用 Web 服务时，在他们头脑中出现的是使用某个 SOAP 客户机 API 来装配一个 SOAP 消息并将它经由网络发送到服务端点。例如，使用 Apache SOAP，客户机将创建和植入一个 Call 对象。它封装了服务端点、要调用的 SOAP 操作的标识、必须发送的参数等等。而这是对 SOAP 而言，它仅限于将其用作调用 Web 服务的一般模型，这是因为下面的原因：

• Web 服务不仅仅是 SOAP 服务
  将 Web 服务视为 SOAP 上提供的服务的同义词。这是对 Web 服务狭隘的见解。带有功能方面和访问协议 WSDL 描述的任何一段代码均可以被认为是 Web 服务。WSDL 规范为 Web 服务定义了 SOAP 绑定，但是原则上可能要添加绑定扩展，这样，例如，使用 RMI/IIOP 作为访问协议，EJB 就可以作为 Web 服务来提供。或者您甚至可以想象任意一个 Java 类可以被当作 Web 服务，以本机 Java 调用作为访问协议。就这个更广阔的 Web 服务定义来说，您需要用于服务调用的独立于绑定的机制。
• 将客户机代码绑到一个特殊的协议实现要受到限制
  将客户机代码紧密地绑定到特殊的协议实现的客户机库造成了难以维护的代码。让我们假设您在客户机端有一个用 Apache SOAP v2.1 调用 Web 服务的应用程序。如果您想利用 v2.2 中出现的新的功能和错误修正，您将不得不更新所有的客户机代码，这是一项耗时的任务，将涉及到常见的令人头痛的迁移问题。类似的，如果您想从 Apache SOAP 移到一个不同的 SOAP 实现，这个过程并非无关紧要。所需要的是用于服务调用的独立于协议实现的机制。
• 将新的绑定融入到客户机代码是很困难的。
  WSDL 允许有定义新的绑定的可扩展性元素。这使开发者能够定义绑定，这种绑定允许使用某种定制协议的代码作为 Web 服务。但是，事实上实现起来是很困难的。将不得不设计使用该协议的客户机 API 。应用程序本身可能正是使用 Web 服务的抽象接口，因此将必须编写一些工具来生成启用抽象层的存根。这些又一次是并非无关紧要的而且耗时的任务。所需要的是使绑定能够被更新或新的绑定能够容易地插入的服务调用机制。
• 可以以灵活的方式使用多绑定
  例如，设想您已经成功地部署了一个应用程序，该应用程序使用提供多绑定的 Web 服务。为了使这个示例更具体，假设您有用于服务的 SOAP 绑定和允许您将本地服务实现（一个 Java 类）作为 Web 服务的本地 Java 绑定。显而易见，如果客户机部署在与服务本身相同的环境中，只能使用面向服务的本地 Java 绑定，并且如果情况确实如此，通过直接进行 Java 调用而不是使用 SOAP 绑定与服务进行通信将高效得多。Java 绑定作为一种快捷访问机制。接下来，想要利用多绑定可用性的客户机将必须具有一种能力 — 根据运行时信息对要用的实际绑定进行切换的能力。因此为了利用提供多绑定的 Web 服务，您需要一种服务调用机制，允许您在运行时在可用的服务绑定之间进行切换，而不需要生成或重编译存根。

介绍 WSIF
“Web 服务调用框架”（WSIF）是为调用 Web 服务提供简单 API 的工具箱，而不管服务怎样提供或由哪里提供。它具有上面讨论中我确定的所有功能：

• 有给任何 Web 服务提供独立于绑定访问的 API。
• 提供端口类型编译器来生成允许使用抽象服务接口的调用的存根。
• 允许无存根（完全动态）的 Web 服务调用。
• 可以在运行时将更新的绑定实现插入到 WSIF。
• 可以在运行时插入的新的绑定。
• 允许将绑定选择延后到运行时。

分析 WSIF 的客户机 API
为了进行讨论，我将使用很常见的股票报价程序 — Web 服务的“Hello World”示例。请考虑下面清单 1 所示的使用 WSDL 的抽象服务描述。

清单 1：股票报价 Web 服务的 WSDL 描述

<?xml version="1.0" ?> 
<definitions targetNamespace="http://www.ibm.com/namespace/wsif/samples/stockquote-interface" 
             xmlns:tns="http://www.ibm.com/namespace/wsif/samples/stockquote-interface" 
             xmlns:xsd="http://www.w3.org/1999/XMLSchema" 
             xmlns="http://schemas.xmlsoap.org/wsdl/"> 
  <message name="GetQuoteInput"> 
    <part name="symbol" type="xsd:string"/> 
  </message> 
  <message name="GetQuoteOutput"> 
    <part name="quote" type="xsd:float"/> 
  </message> 
  <portType name="StockquotePT"> 
    <operation name="getQuote"> 
      <input message="tns:GetQuoteInput"/> 
      <output message="tns:GetQuoteOutput"/> 
    </operation> 
  </portType> 
</definitions>

足够简单：它描述了只带有由一个端口类型提供一个操作的服务。该操作等待一个字符串，被解释为股票的报价机符号，然后返回当前该股票报价，一个浮点值。为了实际使用该服务，您需要某个定义访问机制的绑定以及该绑定的服务端点。清单 2 展示了该服务的 SOAP 绑定：

清单 2：股票报价 Web 服务的 SOAP 绑定

<?xml version="1.0" ?> 
<definitions targetNamespace="http://www.ibm.com/namespace/wsif/samples/stockquote" 
             xmlns:tns="http://www.ibm.com/namespace/wsif/samples/stockquote" 
             xmlns:tns-int="http://www.ibm.com/namespace/wsif/samples/stockquote-interface" 
             xmlns:xsd="http://www.w3.org/1999/XMLSchema" 
             xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" 
             xmlns:java="http://schemas.xmlsoap.org/wsdl/java/" 
             xmlns="http://schemas.xmlsoap.org/wsdl/"> 
  <import namespace="http://www.ibm.com/namespace/wsif/samples/stockquote-interface" 
          location="stockquote-interface.wsdl"/> 
  <binding name="SOAPBinding" type="tns-int:StockquotePT"> 
    <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> 
    <operation name="getQuote"> 
      <soap:operation soapAction="http://example.com/GetTradePrice"/> 
      <input> 
        <soap:body use="encoded" 
                   namespace="urn:xmltoday-delayed-quotes" 
                   encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> 
      </input> 
      <output> 
        <soap:body use="encoded" 
                   namespace="urn:xmltoday-delayed-quotes" 
                   encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> 
      </output> 
    </operation> 
  </binding> 
  <service name="StockquoteService"> 
    <documentation>Stock quote service</documentation> 
    <port name="SOAPPort" binding="tns:SOAPBinding"> 
      <soap:address location="http://localhost:8080/soap/servlet/rpcrouter"/> 
    </port> 
  </service> 
</definitions>

这是一个标准的 SOAP 绑定，使用 RPC 风格和作为传输协议的 HTTP 与服务进行通信。在文档的 port 部分中，我定义了使用 SOAP 绑定可以访问服务的 URI。在清单 3 中，我将就通过 Apache SOAP 2.2 客户机端 API 和 WSIF 的客户机 API 使用该服务进行对比。

清单 3：用于服务访问的 Apache SOAP API 与 WSIF API 对比

// Step 1: identify the service 
 Call call = new Call(); 
 call.setTargetObjectURI("urn:xmltoday-delayed-quotes"); 
 // Step 2: identify the operation 
 call.setMethodName("getQuote"); 
 call.setEncodingStyleURI(encodingStyleURI); 
 // Step 3: identify the parameters 
 Vector params = new Vector(); 
 params.addElement(new Parameter("symbol", 
                          String.class, symbol, null));
 call.setParams(params); 
 // Step 4: execute the operation 
 Response resp = call.invoke(url, 
                   "http://example.com/GetTradePrice");
 // Step 5: extract the result or fault 
 if(resp.generatedFault()) 
 { 
   Fault fault = resp.getFault(); 
   System.out.println("Ouch, the call failed: "); 
   System.out.println("  Fault Code   = " +  
                      fault.getFaultCode()); 
   System.out.println("  Fault String = " +  
                      fault.getFaultString()); 
   throw new SOAPException("Execution failed " + fault); 
 } 
 else 
 { 
   Parameter result = resp.getReturnValue(); 
   return ((Float) result.getValue()).floatValue(); 
 }

// Step 1: identify the service 
 Definition def = WSIFUtils.readWSDL(null,wsdlLocation);
 // Step 2: identify the operation (choose an 
 // appropriate service port) 
 WSIFDynamicPortFactory portFactory = 
        new  WSIFDynamicPortFactory(def, null, null); 
 // Get default port 
 WSIFPort port = portFactory.getPort(); 
 // The user can also explicitly select a port  
 // to use. 
 // WSIFPort port =  
 //             portFactory.getPort("SOAPPort"); 
 // Step 3: identify the parameters 
 // Prepare the input message 
 WSIFMessage input = port.createInputMessage(); 
 input.setPart("symbol",  
               new WSIFJavaPart(String.class, symbol));
 // Prepare a placeholder for the output value 
 WSIFMessage output = port.createOutputMessage(); 
 // Step 4: execute the operation 
 port.executeRequestResponseOperation("getQuote", 
                             input, output, null);
 // Step 5: extract the result or fault 
 WSIFPart part = output.getPart("quote"); 
 return ((Float)part.getJavaValue()).floatValue();

正如您可以看到的，WSIF 的 API 由以 WSDL 编写的抽象服务描述驱动；它完全从实际使用的绑定中分离出来。该调用 API 是面向 WSDL 的，并且使用它更自然，因为它使用 WSDL 术语引用消息部件（message part）、操作等等。当您阅读一个 WSDL 描述，出于直觉会想到选用支持所需端口类型的端口，然后通过提供必需抽象输入消息（由必要部件组成）调用操作（不用担心怎样将消息映射到特定的绑定协议）；WSIF API 就是这样设计的。

常用的 API，比如上面所示的 Apache SOAP API 采用了以特殊协议为中心的概念，比如在使用 SOAP 的情况下，目标 URI 和编码风格。这是不可避免的，因为 API 不是普遍适用于 WSDL，而是为特殊的协议设计。