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，而是为特殊的协议设计。

两种使用 WSIF 的调用模型
WSIF 允许 Web 服务以两种方式调用。一种是无存根的动态调用，它要求直接使用 WSIF API；另一种是通过生成允许应用程序使用 Java 接口（直接对应于 WSDL 端口类型）和隐藏了 WSIF API 的存根的调用。

无存根（动态的）调用
访问 Web 服务所需的所有信息 — 抽象接口、绑定和服务端点可以通过 WSDL 得到。如果您仔细查看上面的客户机 API 示例，您将会注意到唯一由用户提供的信息是用于服务的 WSDL 文件位置和所需要的股票报价符号。很明显接下来是用 WSFL API 在运行时装入这个服务和进行该调用。

WSIF 分发包包含了演示怎样执行 WSDL 的任意一个操作的 DynamicInvoker。它以 WSDL 文件的 URI 和所需的操作参数作为命令行参数（在最初的实现中只接受简单的类型，如字符串），并且直接使用 WSIF API 完成工作。其用来调用股票报价服务的示例如清单 4 所示；您可以在包含 WSIF 分发包的文档中查找详细信息。

因为这类调用不会导致生成存根类，并且不需要单独的编译周期，所以它很方便。

清单 4：使用 DynamicInvoker 访问股票报价服务

java clients.DynamicInvoker http://services.xmethods.net/soap/urn:
    xmethods-delayed-quotes.wsdl getQuote IBM
Reading WSDL document from 'http://services.xmethods.net/soap/urn:
    xmethods-delayed-quotes.wsdl'
Preparing WSIF dynamic invocation
Executing operation getQuote
Result:
Result=108.8
Done!

使用存根的调用
在应用程序需要更抽象的服务视图和不希望处理 WSIF 客户机 API 的情况下，无存根调用不适用。WSIF 提供一个端口编译器，如果给定一个 WSDL，与所用到的复杂类型的 Java 等价物（以 JavaBean 的形式）一起，端口编译器将为每一个端口类型生成一个客户机存根。使用生成存根的应用程序可以利用抽象服务接口，并且这样与协议和 WSIF 客户机 API 分离。对于实际服务调用，这些存根使用缺省端口。通过由 WSIF 的端口类型编译器生成的存根使用股票报价服务的示例如清单 5 所示。

清单 5：使用生成存根的 WSIF 访问股票报价服务。

StockquotePT service = new StockquotePTStub(WSIFUtils.readWSDL(null, wsdlLocation), 
    null, null);
float quote = service.getQuote("IBM");
System.err.println (">> Received quote: "+quote);

值得注意的是存根驻留在某些受管环境（如应用程序服务器）的情况，它们能够被定制；例如，可以改变负责返回恰当端口的工厂来定制端口选择算法，或者可以改变用于调用自身的实际端口。

在这篇文章中，我略述了对 WSIF 的需要，分析其通过高级 API 进行独立于绑定的服务访问的主要特征以及生成可定制的存根（通过其抽象接口使用服务）的端口类型编译器的可用性。直接通过 SOAP 客户机 API 和使用 WSIF API 进行服务访问之间的对比展示了 WSIF（由服务的 WSDL 描述驱动）怎样将 Web 服务调用的全部问题从以绑定为中心的观点转移到更抽象的级别。这是 WSIF 的设计原则之一，使服务绑定能被看作是根据特殊协议进行调用所需的代码片断，可以在任何时候插入它们。

在接下来的文章，我将分析 WSIF 的体系结构，看一看它怎样允许新的或更新的绑定实现被插入，它怎样使定制的类型系统用于 Web 服务以及怎样使运行时环境使用定制的探索性方法在多端口之间进行选择。

参考资料

• 请参加关于这篇文章的讨论论坛。
• 请下载 alphaworks 上的 WSIF 分发包，并且试验比较简单的样本。它将给您一个由 WSIF 支持的不同调用风格的第一手示例以及它优于特定协议客户机 API 的优势。
• 重温 WSDL 规范，看一看允许哪一种扩展；如果用来为访问 Web 服务定义 SOAP 绑定，您也可以学习 WSDL 的扩展机制。
• 重温 SOAP 规范本身。
• 如果以前您没有对 Web 服务编过程，Web Services Toolkit 是很好的起点。
• 请查看 WSDL4J，一个可扩展的 WSDL 分析框架，WSIF 在此基础上进行构建。

关于作者
Nirmal K. Mukhi 是 IBM 的 T J Watson Research Lab 的副研究员，自 2000 年 11 月，他一直在从事各种 Web 服务技术的研究。他还对 AI、创造性写作以及过时的计算机游戏感兴趣。您可以通过 nmukhi@us.ibm.com 与 Nirmal 联系。

1． 方法一
如果三元组中a是老大，即有个资源的地位是支配性的，如:小明的身高是170cm.
表示方法为 把老大提出来，再把三元关系分解为3个二元关系：
  R1(a, a’) ， R2（a’,b）,  R3（a’,c）  // R1(a, a’) 用RDF三元组表示为 （a , R1 , a’）
例如：小明的例子可以表示为
length(小明，length_obj_1);  //小明是老大, length_obj_1 是一个身高对象 
value(length_obj_1，170);     //值
unit(length_obj_1，cm);      //单位
2． 方法二
如果三元组中没有明显的老大，如: 小红借给小明语文书.
表示方法为提出一个对象，每个元素都和这个对象有关系：
R1(g, a) ， R2（g,b）,  R3（g, c）
例如：小红借书的例子可以表示为
rdf:type (borrow_obj_1,  BorrowRelation); // BorrowRelation 是一个表示借书关系的类
borrow_owner((borrow_obj_1,小红)； 
borrow_agent((borrow_obj_1,小明)； //借书的人
borrow_book((borrow_obj_1, 语文书)；

3． 结论
1) n-元关系有2exp(n-2) 种表示方法： 二元关系一种表示法，三元关系有如上二种表示法，由数学归纳法得证。
2) 如果用RDF对复杂系统建模，有必要引入一个中间的抽象层，用以表示N元关系，还有named graph, context 等。如引入rdfe:relation(a,b,c,d,….)表示n元关系 
3) n-关系的表示对RDF数据的查询和存储优化很有价值，因为n-关系往往对应了数据库中的表。

注：大部分摘译自： 
http://www.w3.org/2001/sw/BestPractices/OEP/n-aryRelations-20040623/

更为详细的信息也参考它。

原文地址：http://bbs.w3china.org/dispbbs.asp?boardID=2&ID=8416

众所周知，Web Service是靠SOAP协议进行数据传输的。而SOAP是基于XML技术之上的。SOAP协议是连接客户和服务器的桥梁。而SOAP协议本身没有异步功能，需要在客户端实现异步调用。我们以一个简单的Web Service的例子来说明这一点。

一、MathService.asmx

<%@ WebService Language="C#" Class="MathService" %>

using System;

using System.Web.Services;

[WebService]

public class MathService : WebService {

[WebMethod]

public float Add(float a, float b)

{

return a + b;

}

[WebMethod]

public double Subtract(double a, double b)

{

return a - b;

}

[WebMethod]

public float Multiply(float a, float b)

{

return a * b;

}

[WebMethod]

public float Divide(float a, float b)

{

if (b==0) return -1;

return a / b;

}

}

这是个实现了加，减，乘，除的Web Service，任何客户端程序都可以调用它。下面我们用wsdl（微软公司提供）工具产生一个MathService.asmx 的客户代理程序：wsdl /n:MyMath　http://localhost/mathservice.asmx (假设MathService.asmx放在IIS服务器的根目录) ，产生一个MathService.cs代理程序，默认是SOAP协议。

二、MathService.cs:

namespace MyMath{

using System.Diagnostics;

using System.Xml.Serialization;

using System;

using System.Web.Services.Protocols;

using System.ComponentModel;

using System.Web.Services;

[System.Diagnostics.DebuggerStepThroughAttribute()]

[System.ComponentModel.DesignerCategoryAttribute("code")]

[System.Web.Services.WebServiceBindingAttribute(Name="MathServiceSoap", Namespace="http://tempuri.org/")]

public class MathService : System.Web.Services.Protocols.SoapHttpClientProtocol {

public MathService() {

this.Url = "http://localhost/mathservice.asmx";

}

[System.Web.Services.Protocols.SoapDocumentMethodAttribute("http://tempuri.org/Add", RequestNamespace="http://tempuri.org/", ResponseNamespace="http://tempuri.org/", Use=System.Web.Services.Description.SoapBindingUse.Literal, ParameterStyle=System.Web.Services.Protocols.SoapParameterStyle.Wrapped)]

public System.Single Add(System.Single a, System.Single b) {

object[] results = this.Invoke("Add", new object[] {

a,

b});

return ((System.Single)(results[0]));

}

public System.IAsyncResult BeginAdd(System.Single a, System.Single b, System.AsyncCallback callback, object asyncState) {

return this.BeginInvoke("Add", new object[] {

a,

b}, callback, asyncState);

}

/// <remarks/>

public System.Single EndAdd(System.IAsyncResult asyncResult) {

object[] results = this.EndInvoke(asyncResult);

return ((System.Single)(results[0]));

}

/// <remarks/>

[System.Web.Services.Protocols.SoapDocumentMethodAttribute("http://tempuri.org/Subtract", RequestNamespace="http://tempuri.org/", ResponseNamespace="http://tempuri.org/", Use=System.Web.Services.Description.SoapBindingUse.Literal, ParameterStyle=System.Web.Services.Protocols.SoapParameterStyle.Wrapped)]

public System.Double Subtract(System.Double a, System.Double b) {

object[] results = this.Invoke("Subtract", new object[] {

a,

b});

return ((System.Double)(results[0]));

}

/// <remarks/>

public System.IAsyncResult BeginSubtract(System.Double a, System.Double b, System.AsyncCallback callback, object asyncState) {

return this.BeginInvoke("Subtract", new object[] {

a,

b}, callback, asyncState);

}

/// <remarks/>

public System.Double EndSubtract(System.IAsyncResult asyncResult) {

object[] results = this.EndInvoke(asyncResult);

return ((System.Double)(results[0]));

}

/// <remarks/>

[System.Web.Services.Protocols.SoapDocumentMethodAttribute("http://tempuri.org/Multiply", RequestNamespace="http://tempuri.org/", ResponseNamespace="http://tempuri.org/", Use=System.Web.Services.Description.SoapBindingUse.Literal, ParameterStyle=System.Web.Services.Protocols.SoapParameterStyle.Wrapped)]

public System.Single Multiply(System.Single a, System.Single b) {

object[] results = this.Invoke("Multiply", new object[] {

a,

b});

return ((System.Single)(results[0]));

}

/// <remarks/>

public System.IAsyncResult BeginMultiply(System.Single a, System.Single b, System.AsyncCallback callback, object asyncState) {

return this.BeginInvoke("Multiply", new object[] {

a,

b}, callback, asyncState);

}

/// <remarks/>

public System.Single EndMultiply(System.IAsyncResult asyncResult) {

object[] results = this.EndInvoke(asyncResult);

return ((System.Single)(results[0]));

}

/// <remarks/>

[System.Web.Services.Protocols.SoapDocumentMethodAttribute("http://tempuri.org/Divide", RequestNamespace="http://tempuri.org/", ResponseNamespace="http://tempuri.org/", Use=System.Web.Services.Description.SoapBindingUse.Literal, ParameterStyle=System.Web.Services.Protocols.SoapParameterStyle.Wrapped)]

public System.Single Divide(System.Single a, System.Single b) {

object[] results = this.Invoke("Divide", new object[] {

a,

b});

return ((System.Single)(results[0]));

}

/// <remarks/>

public System.IAsyncResult BeginDivide(System.Single a, System.Single b, System.AsyncCallback callback, object asyncState) {

return this.BeginInvoke("Divide", new object[] {

a,

b}, callback, asyncState);

}

/// <remarks/>

public System.Single EndDivide(System.IAsyncResult asyncResult) {

object[] results = this.EndInvoke(asyncResult);

return ((System.Single)(results[0]));

}

}

}

之后我们用csc /t:library MathService.cs编译并产生一个MathService.dll.

现在我们可以写任何的客户程序去调用服务器上的MathService.asmx。

如：WinForm, C#,ASPX等。

下面我们写一个test.cs去测试异步调用：

三、test.cs:

using System;

public class test{

public static void Main(){

MyMath.MathService math = new MyMath.MathService();

IAsyncResult result1 = math.BeginAdd(10,20,null,null);

Object result=math.EndAdd(result1);

Console.WriteLine("result =========="+result);

}

}

我们看到它是先调用代理MathService.cs中的BeginAdd方法，然后状态信息保存在IasyncResult中，直到调用了EndAdd方法才返回调用的确切值。本例是远端调用MathService.asmx中的Add方法。

那Microsoft到底怎样实现客户端的异步呢？设计模式又是怎样的呢？

异步模式所提供的革新之一就是调用方确定特定调用是否应是异步的。　　对于被调用的对象，没有必要执行附加的编程来用于支持其客户端的异步行为；在该模式中异步委托提供此功能。公共语言运行库处理调用方和被调用的对象视图之间的差异。被调用的对象可以选择显式支持异步行为，这或者是因为它可以比一般结构更为有效地实现异步行为，或者是因为它想只支持其调用方的异步行为。但是，建议这种被调用的对象遵循公开异步操作的异步设计模式。

类型安全是异步模式的另一项革新。尤其对于异步委托，针对 .NET 框架和公共语言运行库的语言编译器可令映射到规则 Invoke 方法的开始和结束操作（例如，BeginInvoke 和 EndInvoke）的方法签名是类型安全的。这是十分重要的，因为编译器为异步委托将同步调用拆分成开始和结束操作，使其能够只传递有效参数。

在此模式中所蕴含的基本想法如下所示：

1．调用方确定特定调用是否应是异步的。

2. 对于被调用的对象，没有必要由其客户端执行附加的编程来用于支持异步行为。公共语言运行库结构应该能够处理调用方和被调用的对象视图之间的差异。

3. 被调用的对象可以选择显式支持异步行为，这或者是因为它可以比一般结构更为有效地实现异步行为，或者是因为它想只支持其调用方的异步行为。但是，建议这种被调用的对象遵循公开异步操作的异步设计模式。

4. 编译器为 BeginInvoke 和 EndInvoke 以及异步委托生成类型安全方法签名。

5. .NET 框架提供支持异步编程模型所需的服务。此类服务的部分列表示例是：

(1)同步基元，例如监视器和阅读器编写器锁定。

(2)线程和线程池。

(3)同步构造，例如支持等候对象的容器。

(4)向基础结构片（例如 IMessage 对象和线程池）公开。

该模式将一个同步调用拆分成各构成部分：开始操作、结束操作和结果对象。考虑以下示例，在其中可能要用大量时间来完成 Factorize 方法。

public class PrimeFactorizer

{

public bool Factorize(int factorizableNum, ref int primefactor1, ref int primefactor2)

{

// Determine whether factorizableNum is prime.

// If is prime, return true. Otherwise, return false.

// If is prime, place factors in primefactor1 and primefactor2.

}

}

如果遵循异步模式，则类库编写器添加 BeginFactorize 和 EndFactorize方法，这两个方法将同步操作拆分成两个异步操作：

public class PrimeFactorizer

{

public bool Factorize(

　　　　int factorizableNum,

　　　　ref int primefactor1,

　　　　ref int primefactor2)

{

// Determine whether factorizableNum is prime.

// if is prime, return true; otherwise return false.

// if is prime palce factors in primefactor1 and primefactor2

}

public IAsyncResult BeginFactorize(

　　　int factorizableNum,

　　　ref int primefactor1,

　　　ref int primefactor2,

　　　AsyncCallback callback,

　　　Object state)

{

　// Begin the factorizing asynchronously, and return a result object,

}

public bool EndFactorize(

　　　ref int primefactor1,

　　　ref int primefactor2,

　　　IAsyncResult asyncResult

　)

{

// End (or complete) the factorizing, and

// return the results,

// and obtain the prime factors.

}

}

服务器将异步操作拆分成两个逻辑部分：采用来自客户端的输入并调用异步操作的部分，向客户端提供异步操作结果的部分。

除了异步操作所需的输入外，第一部分还采用在完成异步操作时后要被调用的 AsyncCallback 委托。第一部分返回一个可等待的对象，该对象实现客户端使用的 IAsyncResult 接口来确定异步操作的状态。

服务器还利用它返回到客户端的可等待的对象来维护与异步操作关联的任何状态。通过提供可等待的对象，客户端使用第二部分获取异步操作的结果。

可用于客户端来启动异步操作的选项有：

在开始异步调用时提供回调委托。

　public class Driver1

　　　{

　　　　 public PrimeFactorizer primeFactorizer;

　　　　 public void Results(IAsyncResult asyncResult)

　　　 {

　　　　　int primefactor1=0;

　　　　　 int primefactor2=0;

　　　　　 bool prime = primeFactorizer.EndFactorize(

　　　　　　　　　ref primefactor1,

　　　　　　　　　ref primefactor2,

　　　　　　　　　asyncResult);

　　　　}

　　　　 public void Work()

　　　　 {

　　　　　 int factorizableNum=1000589023,

　　　　　 int primefactor1=0;

　　　　　 int primefactor2=0;

　　　　　 Object state = new Object();

　　　　　 primeFactorizer = new PrimeFactorizer();

　　　　　 AsyncCallback callback = new Callback(this.Results);

　　　　　 IAsyncResult asyncResult = 　　　　　　　　　　　　　　　　　　　　　primeFactorizer.BeginFactorize(

　　　　　　　factorizableNum,

　　　　　　　ref primefactor1,

　　　　　　　ref primefactor2,

　　　　　　　callback,

　　　　　　　state);

　　　　}　

｝

在开始异步调用时不提供回调委托。

public class Driver2

{

public static void Work()

{

int factorizableNum=1000589023,

int primefactor1=0;

int primefactor2=0;

Object state = new Object();

PrimeFactorizer primeFactorizer = new PrimeFactorizer();

AsyncCallback callback = new Callback(this.Results);

IAsyncResult asyncResult = primeFactorizer.BeginFactorize(

factorizableNum,

ref primefactor1,

ref primefactor2,

callback,

state);

bool prime = primeFactorizer.EndFactorize(

ref primefactor1,

ref primefactor2,

asyncResult);

}

}

我们以.Net的一个例子来说明这一点：

AsyncDelegate2.cs

using System;

using System.Threading;

using System.Runtime.Remoting;

using System.Runtime.Remoting.Messaging;

public class Wak

{

public int Pat(int i)

{

Console.WriteLine("Hash: {0} Wak Pat", Thread.CurrentThread.GetHashCode());

return i*2;

}

};

public delegate int WakPatDelegate(int i);// 异步调用的委派.

public class Simple

{

public static void SomeMethod(IAsyncResult ar)

{

// Obtain value from AsyncState object

int value = Convert.ToInt32(ar.AsyncState);

// Obtain results via EndInvoke

int result = ((WakPatDelegate)((AsyncResult)ar).AsyncDelegate ).EndInvoke(ar);

Console.WriteLine("Simple.SomeMethod (AsyncCallback): Result of {0} in Wak.Pak is {1} ",value, result);

}

public static void Main(String[] args)

{

Console.WriteLine("Thread Simple Context Sample");

Console.WriteLine("");

Console.WriteLine("Make an instance of a context-bound type Wak");

Wak oWak = new Wak();

int value=0;

int result=0;

Console.WriteLine("Make a sync call on the object");

value = 10;

result = oWak.Pat(value);

Console.WriteLine("Result of {0} in Wak.Pak is {1} ",value, result);

Console.WriteLine("Make single Async call on Context-bound object");

WakPatDelegate wpD1 = new WakPatDelegate(oWak.Pat);

value = 20;

IAsyncResult ar1 = wpD1.BeginInvoke(value,null,null);

ar1.AsyncWaitHandle.WaitOne();

result = wpD1.EndInvoke(ar1);

Console.WriteLine("Result of {0} in Wak.Pak is {1} ",value, result);

Console.WriteLine("Make single Async call on Context-bound object - use AsyncCallback and StateObject");

WakPatDelegate wpD2 = new WakPatDelegate(oWak.Pat);

value = 30;

IAsyncResult ar2 = wpD2.BeginInvoke(

value,

new AsyncCallback(Simple.SomeMethod),

value

);

Console.WriteLine("Make multiple Async calls on Context-bound object");

int asyncCalls = 5;

IAsyncResult[] ars = new IAsyncResult[asyncCalls];

WaitHandle[] whs = new WaitHandle[asyncCalls];

int[] values = new int[asyncCalls];

WakPatDelegate wpD3 = new WakPatDelegate(oWak.Pat);

for (int i=0; i < asyncCalls; i++)

{

values[i] = i;

ars[i] = wpD3.BeginInvoke(values[i],null,null);

whs[i] = ars[i].AsyncWaitHandle;

}

WaitHandle.WaitAll(whs,1000, false);

for (int i=0; i < asyncCalls; i++)

{

result = wpD3.EndInvoke(ars[i]);

Console.WriteLine("Result of {0} in Wak.Pak is {1} ",values[i], result);

}

Console.WriteLine("");

Console.WriteLine("Done");

}

}

如果异步调用成功，将显示：

Thread Simple Context Sample

Make an instance of a context-bound type Wak

Make a sync call on the object

Hash: 3 Wak Pat

Result of 10 in Wak.Pak is 20

Make single Async call on Context-bound object

Hash: 16 Wak Pat

Result of 20 in Wak.Pak is 40

Make single Async call on Context-bound object - use AsyncCallback and StateObje

ct

Hash: 16 Wak Pat

Make multiple Async calls on Context-bound object

Simple.SomeMethod (AsyncCallback): Result of 30 in Wak.Pak is 60

Hash: 16 Wak Pat

Hash: 16 Wak Pat

Hash: 16 Wak Pat

Hash: 16 Wak Pat

Hash: 16 Wak Pat

Result of 0 in Wak.Pak is 0　

Result of 1 in Wak.Pak is 2

Result of 2 in Wak.Pak is 4

Result of 3 in Wak.Pak is 6

Result of 4 in Wak.Pak is 8

Done

原文地址：http://www.ccw.com.cn/htm/center/prog/02_8_23_6.asp

术语

　　在开始讨论支持回调的客户端之前，阐明相关术语是很重要的。下图就显示了客户端使用带有回调操作的 Web service 时所涉及到的主要实体。

图 1. 调用 Web service 的客户端

　　上图描述了客户端对 Web service 的调用。 Web service 能够在一段时间后通过对客户端的回调做出响应 。因此，包含回调操作的 Web service 客户端的特别之处在于，客户端本身必须提供一个端点。我们调用这一回调端点 ，并将这个端点定义为由 URI 确定的唯一地址， SOAP 请求消息将发送到这个 URI 。

　　将 SOAP 消息发送到Web service 端点 之后，客户端本身开始与 Web service 进行交互。由客户端发送给 Web service 的相关请求消息及其相关响应消息构成了客户端初始化操作 。如前所述，客户能够处理 Web service 发送到回调端点的请求消息。相关的请求和响应消息一起被称为一个回调 操作。

　　理解这些术语之后，让我们走近一步考察 Web service 回调的概念，以及它与会话式 Web services 和异步 Web service 调用之间的关系。

异步、回调和会话

　　异步 Web service 调用的概念有时容易与 Web services 回调和会话式 Web services 相混淆。虽然这三个概念很相关，但却不同。

　　异步 Web services 调用 是指在不阻塞接收服务器发来的相应响应消息的情况下，客户端能够发送 SOAP 消息请求 。 BEA WebLogic Platform 8.1 web services 上进行异步 Web service 调用的过程已经详细地 记录在软件文档中了 ，因此在本文中不作进一步的讨论。

　　Web services 回调 是指 Web services 提供者向客户端发回 SOAP 消息的情况。 Web Services Description Language (WSDL) specifications 将这种操作定义为一种“请求 / 响应”。支持回调操作的 Web services 客户端本身必须有一个 Web services 端点，这样 Web service 就可以利用这个 Web services 端点在任意时间发送回调请求，也就是说，可以是异步的。注意，这跟我们上面讨论的异步调用 没有关联。

　　如果一系列可在两个端点之间来回传送的消息可以被唯一会话 ID 追踪，而这个 ID 又由特定的操作来标识消息流的始末，这种 Web services 就是 会话式 的。提供回调的 Web services 也定义为会话式的。这是因为正常情况下如果 Web services 能够对客户端进行回调访问，它就必须有它自己的回调端点信息。这种情况只有客户端做出了初始调用以后才会发生。因此，至少由客户启动的初始化操作和由 Web services 做出的回调操作是相互关联的，并且由唯一的会话 ID 跟踪。如果不是这样，客户端就无法分辨与不同初始调用相关联的回调操作。

　　我们现在将考虑这些问题并创建支持回调的客户端，就像我们刚才所看到的，这些客户端构成了请求 - 响应和会话式 Web services 的基础。

创建支持回调的客户端

　　正如前面讨论的，支持回调的 Web services 客户端需要提供一个能够异步接收和处理回调操作消息的回调端点。为避免必须提供回调端点这类复杂的事情，一种叫做 polling （轮询）的技术可以作为替代技术。然而这种技术要求客户端周期性地调用服务端以校验回调事件。如果这种事件很少发生，那么调用的开销就太大了。如果客户端提供一个回调端点并直接处理回调操作，这种开销就可以避免。

　　我们还应该注意到，尽管可以通过用 JMS 上的 Web services （如果提供了这种连接）创建支持回调的客户端，但这种方法有一些限制，其中一个重要的限制就是客户端要被迫采用与 Web services 提供者相同的 JMS 实现。因此我们将集中于经过 HTTP 传输来完成我们的任务。有两个领域需要创建这样的客户端：创建适当的客户端启动 SOAP 消息，以及处理回调操作。

　　当客户端启动有回调的 Web service 操作时，它需要以某种方式包含回调端点的 URI ，使其在请求消息中监听。 Web Services Addressing 和 SOAP Conversation Protocol 规范都定义了 SOAP 头部元素，允许您实现这一目标。从理论上说，用于规定回调端点的规范并不重要。但是大多数 Web services 容器（包括 BEA WebLogic Server 8.1 ）都还没有包含 Web services Addressing 规范的实现形式。当前， BEA WebLogic Workshop 8.1 的 Web services 支持 SOAP Conversation Protocol 规范，我们将在例子客户端中使用。

　　根据 SOAP Conversation Protocol ， SOAP 头部在会话的不同阶段是不同的。对于会话中的第一个客户端启动（开始）操作，我们需要通过 callbackLocation 头部元素 提供有回调端点的 Web service 。所有操作（包括第一个操作）也将需要唯一的 ID ，这个 ID 在整个会话过程中都用在我们的 SOAP 消息里。这可通过 conversationID 元素 来完成。下面是一个启动支持回调会话的 SOAP 请求消息的例子：

<soapenv:Envelope soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" 
    xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
    xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" 
    xmlns:env="http://schemas.xmlsoap.org/soap/envelop/" 
    xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">
  <soapenv:Header>
    <con:StartHeader soapenv:actor="http://schemas.xmlsoap.org/soap/actor/next" 
     soapenv:mustUnderstand="0" 
     xmlns:con="http://www.openuri.org/2002/04/soap/conversation/">
      <con:conversationID>[123456]:192.168.1.100:8181</con:conversationID>
         <con:callbackLocation>
          http://192.168.1.100:8181/StockNotificationCallback
         </con:callbackLocation>
      </con:StartHeader>
 </soapenv:Header>
  <soapenv:Body>
    <n1:registerForThresholdNotif xmlns:n1="http://www.openuri.org/">
      <n1:stockTicker>CCC</n1:stockTicker>
      <n1:threshold>10</n1:threshold>
    </n1:registerForThresholdNotif>
  </soapenv:Body>
</soapenv:Envelope>

　　现有的大多数 Java Web service 工具包（例如 BEA WebLogic 的 clientgen 、 Apache Axis 和 JWSDP ）都允许您创建一个代理库，客户端程序可以容易地用它来调用 Web services 操作。但是，这些框架中没有一种支持回调操作，主要问题是它们的代理不生成所需的头部。在能提供这种支持以前，通过扩展它们对回调操作的支持来利用这些框架（例如复杂类 XML 映射），这种益处还是很需要的。一种用来达到这种效果的技术就是应用 SOAP 消息处理程序 。

　　上面提到的所有 Web services 工具包都能支持 SOAP 消息处理程序。消息处理程序是一种 Java 类，它实现了 javax.xml.rpc.handler.GenericHandler 界面，并且还包含一种称为先送出（或后接收） SOAP 消息的方法。这里介绍我们客户端中的消息处理程序，它能够找出一个特定会话的当前阶段，并据此扩展带有所需头部的请求消息。

　　注意到这一点是很重要的，客户端 SOAP 消息处理程序必须能确定消息属于会话的哪个阶段，以便创建合适的头部元素。生成会话 ID 也是客户端处理程序要完成的一个任务。

　　一旦 Web services 端点收到扩展的请求消息，它就会将请求消息发送到由开始消息的 callbackLocation 元素规定的回调端点。在大多数情况下，客户端过程自身就需要提供这个端点，并且恰当地处理回调消息。如果客户端在 Web services 的容器中运行，这项工作就可以通过把有回调操作的 Web services 部署在同一个容器内来完成。然而，如果客户端不是正在容器中运行，这项工作就要靠在一个嵌入在客户端过程本身的轻量级容器中执行回调端点来完成。这使我们能够调用客户端生成的操作，并且处理同一过程上下文中的传入回调操作。注意在回调端点背后（和在客户端中）的过程实体要求不仅能够分配对适当域的代码操作，而且还能处理 XML 映射。

　　当然，客户端也可以选择简单地设置恰当的 callbackLocation 头部元素来规定一个在容器中的回调端点，而这个容器与访问过程相分离。

　　正如我们已经看到的，为带回调操作的 Web services 创建客户端并不是毫无意义的，它包含了复杂元素，比如处理 SOAP 消息、管理会话（包括阶段和 ID ）、参数映射以及操作分配。当 Web service 通过 BEA WebLogic Workshop Service Control 访问时，这些复杂性就都不存在了，它会自动为用户执行所有操作。

使用服务控件创建支持回调的客户端

　　通过 WebLogic Workshop Service Control 访问 Web services 在 软件文档 中已经做了详细描述。如果客户端实体能够使用控件（也就是 Java Process Definition 业务流程或其他控件； Page Flows 不能使用控件回调），这个解决方案就是最简单的使用支持回调的 Web services 的方案了。采用这种方法，所有涉及访问支持回调的 Web service 的复杂性就都迎刃而解了。

股票通知服务例子

　　本文的例子包括一个股票通知（ Stock Notification ）的会话式 Web service 和一个能阐明概念的示例客户端。 Web service 提供的操作允许客户端注册股票接收机并设置一个相关的阈值价格。然后服务端就监视股票，只要股票价格超过了阈值价格就通过一个回调（ onThresholdPassed() ）通知客户端。

图 2. 本图说明了这个例子的配置

　　很显然，轮询技术不是创建客户端的最佳解决方案：股票价格有可能经常超过阈值价格也可能极少超过阈值价格。轮询间隔短就会造成很多不必要的访问，而另一方面，轮询间隔长又可能导致股票价格超过阈值价格很长时间后客户端才被告知。

　　客户端应用程序中回调端点的实现应该是一种更好的解决方案。让我们首先来看一下例子客户端是如何将操作传递给 StockNotification Web service 的。我们已经采用两种不同的技术实现了客户端。第一种技术使用 WebLogic Workshop 生成的代理库，并由 StockNotificationClient 类的 makeCallUsingBEAProxy() 方法来实现：

public void makeCallUsingBEAProxy() {
    try {
      // Get the proxy instance so that we can start calling the web service operations
      StockNotificationSoap sns = null;
      StockNotification_Impl snsi = new StockNotification_Impl();
      sns = snsi.getStockNotificationSoap();

      // Register our conversational handler so that it can properly set our
      // our conversation headers with a callback location
      QName portName = new QName("http://www.openuri.org/",
                                 "StockNotificationSoap");
      HandlerRegistry registry = snsi.getHandlerRegistry();
      List handlerList = new ArrayList();
      handlerList.add(new HandlerInfo(ClientConversationHandler.class, null, null));
      registry.setHandlerChain(portName, handlerList);

      // Register, call some methods, then sleep a bit so that our callback
      // location can receive some notifications and finally finish the conversation.
      sns.registerForThresholdNotif("AAAAA", "100");
      sns.addToRegistration("BBBBB", "5");
      StockList stocks = sns.getAllRegisteredStocks();

      ...

      sns.endAllNotifications();
    }
    catch (Exception e) {
      throw new RuntimeException(e);
    }
}

　　正如从上述代码段中看到的，我们可以使用 clientgen 生成的类。与没有回调的 Web service 调用相比，这段代码唯一强调的就是，在方法一开始就实例化和注册了客户端 SOAP 消息处理程序。这个处理程序截取了发出的 SOAP 消息，并加上必要的会话头部。每当客户端过程发出 SOAP 请求消息时，消息处理程序的 handleRequest() 方法就被调用，它利用了一个包含了输出 SOAP 请求信息的 MessageContext 对象。下面是例子客户端消息处理程序的代码段：

package weblogic.webservice.core.handler;

...

public class ClientConversationHandler
    extends GenericHandler {

public boolean handleRequest(MessageContext ctx) {  
  ...
  if (phase.equals("START")) {
    headerElement
              = (SOAPHeaderElement) header
              .addChildElement("StartHeader",
                               "con",
                               "http://www.openuri.org/2002/04/soap/conversation/");

    headerElement.addChildElement("con:callbackLocation")
              .addTextNode(CALLBACK_URI);
  }
  else if (phase.equals("CONTINUE") || phase.equals("FINISH")) {
    headerElement
              = (SOAPHeaderElement) header
              .addChildElement("ContinueHeader",
                               "con",
                               "http://www.openuri.org/2002/04/soap/conversation/");
  }

  headerElement.addChildElement("con:conversationID").addTextNode(convID);
  ...
}
}

　　BEA clientgen 工具生成的代理库已经用了一个缺省的客户端 SOAP 消息处理程序，可创建会话式 StartHeader 头部元素。不幸的是，目前的 clientgen 输出不支持回调操作，因此缺省的处理程序不会创建所需的 callbackLocation 次级元素。所以我们必须保证自己的消息处理程序重写缺省的会话式处理程序，以便管理创建 callbackLocation 头部的额外任务。我们通过确保处理程序在一个与缺省处理程序相同的程序包中创建来做到这一点，这个程序包就是 weblogic.webservice.core.handler ，并且它还有具体的相同类名称 ClientConversationHandler 。注意，这种技术涉及到重写现有会话消息处理程序，但它并不能保证是向前兼容的。这个例子展示了消息处理程序如何用于创建回调头部，以及这种概念如何应用于任何其他支持 SOAP 消息处理程序的 Web services 框架中。

　　有一种使用 SOAP 消息处理程序和代理类的可选技术，它使用 JAXM API 直接创建 SOAP 请求消息，并把它们送往 Web service 。这是我们例子客户端采用的第二种技术，它在 StockNotificationClient 类的 makeCallsUsingJAXM() 和 callMethodFromFile() 方法中实现：

public void makeCallsUsingJAXM() {
      callMethodFromFile("C:\\registerForNotifSOAP.xml");
      ...
      callMethodFromFile("C:\\endAllNotifSOAP.xml");
}

private void callMethodFromFile(String fileName) {

    try {
      // Create a SOAP connection object
      SOAPConnectionFactory scf = SOAPConnectionFactory.newInstance();
      SOAPConnection conn = scf.createConnection();

      // Create the SOAP request message from the specified file
      MessageFactory mf = MessageFactory.newInstance();
      SOAPMessage msg = mf.createMessage();
      SOAPPart sp = msg.getSOAPPart();

      // Read the file content into a string and replace the conversation ID with
      // the current one.
      String fileContent = readFileIntoString(fileName);
      fileContent = fileContent.replaceFirst(CONV_ID_HOLDER,
                                             ConvIDGenerator.getInstance().
                                             getConversationID());

      StreamSource prepMsg = new StreamSource(new StringBufferInputStream(
          fileContent));
      sp.setContent(prepMsg);
      msg.saveChanges();

      // Make the actual call
      conn.call(msg, TARGET_SERVICE_URI);
      conn.close();
    }
    catch (Exception ex) {
      throw new RuntimeException(ex);
    }
}   

　　callMethodFromFile() 方法从指定的文件读取 SOAP 消息，用客户端的当前会话 ID 取代消息会话 ID ，最后生成实际调用。当使用 JAXM 方法时， Java 到 XML 的映射操作参数和返回值必须由客户端来完成。通过使用从文件中预先生成的 SOAP 消息（它已经包含了所需的参数值），我们已经避免了这一任务。尽管从概念上来说这种方法很好，但对于比较复杂的客户端端来说，这不是一种可行的解决方案。这些客户端必须从头开始通过编程方式使用 JAXM 来创建消息。

　　既然我们已经回顾了客户端在生成 Web services 操作中的作用，下面让我们转向客户端的回调端点的实现方式和对来自 Web services 回调消息的处理。因为回调端点需要能够处理输入的 HTTP 请求， servlet 就是一种合适的选择。进一步说，我们非常需要一个 servlet ，它能够从输入的 HTTP 请求中提取 SOAP 消息，并以一种容易使用的方式提供给我们。 javax.xml.messaging 程序包里的 ReqRespListener 接口和 JAXMServlet 类提供给我们这个功能。只要安排合理，应用了这种接口和类的 servlet 将把所有的目标 HTTP post 请求自动转换成 SOAPMessage 实例，并通过 onMessage() 方法传递给我们。下面的代码显示了 onMessage() 方法如何帮助例子客户端实现这些功能。

public class CallBackHandlerServlet
    extends JAXMServlet
    implements ReqRespListener {


  public SOAPMessage onMessage(SOAPMessage message) {
    try {
      // We have just received a SOAP message at the callback
      // endpoint. In this example we will just assume that
      // the message received is in fact the onThresholdPassed
      // callback request. However, a servlet handling
      // multiple callbacks cannot make this assumption and
      // should process the SOAP message to see what callback
      // it relates to and do as appropriate for each.
      String stockTicker = extractOnThresholdPassedArgument(message);

	System.out.println("[DEV2DEV CALLBACK EXAMPLE]: Received treshold notification 
	                                for: " + stockTicker);

      // Now we have to create a proper response to the callback
      // request. Returning this response as part of the onMessage()
      // method will ensure that the SOAP response gets back to the server.
      SOAPMessage response = createThresholdPassedResponse();

      return response;
    }
    catch (Exception e) {
      throw new RuntimeException(e);
    }
  }
  ...
}

　　一旦回调请求消息被 onMessage() 方法所接收，客户端就从股票接收机中提取参数，将它输出到标准设备上，并生成一条相应的响应消息，它还会通过 servlet 返回到 Web service 。使用带有多个回调操作的 Web services 客户端也需要把传入的请求分发给客户端代码的合适部分，这个过程是基于相应的回调操作的。

　　尽管 servlet 包含了合适代码来处理来自 Web services 的传入 onThresholdPassed() 回调消息，但它需要在监听回调 URI 的 servlet 容器中部署完成，这样才能完成回调端点的实现。 Jetty 开源项目有一个轻量级 servlet 容器，它可以嵌入在我们的客户端中。将 CallBackHandlerServlet servlet 部署在一个嵌入式 Jetty 容器中，允许我们将回调端点驻留在客户端 Java 进程中。 StockNotificationCallbackProcessor 类是一种客户端使用的公共类，它用于启动 Jetty 服务器和部署CallBackHandlerServlet servlet ：

public class StockNotificationCallbackProcessor {

  public static final String CALLBACK_SERVER_PORT = ":8181";
  public static final String CALLBACK_SERVLET_CLASS = 
       "asynchwsconsumer.CallBackHandlerServlet";
  public static final String CALLBACK_SERVLET_NAME = "CallBackHandlerServlet";

  private HttpServer server;

  public StockNotificationCallbackProcessor() {}

  public void startListening() {

    try {
      // Configure the server so that we listen on the callback URI
      server = new Server();
      server.addListener(CALLBACK_SERVER_PORT);
      ServletHttpContext context = (ServletHttpContext) server.getContext("/");
      context.addServlet(CALLBACK_SERVLET_NAME, "/*",
                         CALLBACK_SERVLET_CLASS);

      // Start the http server
      server.start();
    }
    catch (Exception e) {
      throw new RuntimeException(e);
    }
  }

  public void stopListening() {
    try {
      server.stop();
    }
    catch (Exception e) {
      throw new RuntimeException(e);
    }
  }
}

　　startListening() 方法把 CallBackHandlerServlet 部署在端口 8181 上并配置嵌入式 servlet 容器，这样所有 HTTP 请求都将指向这个端口。这种方法还启动了嵌入式 servlet 容器。

　　现在我们已经考察了 Web service 操作的创建和回调操作的处理，下面我们来看看例子客户端的 main() 方法是如何使用这些元素的：

public static void main(String[] args) {

    StockNotificationClient snClient = new StockNotificationClient();

    snClient.snCallbackProcessor.startListening();

    snClient.makeCallUsingBEAProxy();

    ConvIDGenerator.getInstance().resetConversationID();

    snClient.makeCallsUsingJAXM();

    snClient.snCallbackProcessor.stopListening();
}

　　正如您所看到的，这种方法开始于建立一个回调端点（正如前面所看到的，它包括启动嵌入式 servlet 容器和部署回调过程）。该方法接着使用 BEA clientgen 代理来调用股票通知的 Web service 。这样，这种与 Web services 的交互就通过调用 endAllNotifications() 端操作来完成会话，客户端需要改变会话 ID 以启动新会话。客户端使用 ConvIDGenerator 单一类来管理会话 ID ，而 ConvIDGenerator 类又使用 java.rmi.dgc.VMID 类来创建合适的格式化唯一会话 ID 。

　　一旦会话 ID 发生了变化，客户端就会用 JAXM 再一次调用股票通知 Web services 。最后，客户端终止嵌入式 servlet 容器，这个过程就结束了。

　　我们现在已经完成了对例子客户端的分析，该例子客户端可作为本文的一部分下载。当您运行客户端和股票通知 Web services 的时候，客户端和 Web service 都将把消息显示在标准输出设备上，用以描述会话的不同阶段，包括对回调操作的处理。

结束语

　　本文展示了为包含回调操作的 Web services 创建独立客户端过程的步骤。这种客户端需要管理 Web services 调用的会话方面，并提供一个端点用于 Web service 进行回调操作。

下载

CallbackExample.zip (1.7Mb) ——这个文件包括了本文讲述的完整实例应用程序。

参考资料

• Invoking Web Services from Client Applications and WebLogic Server
• Using Polling as an Alternative to Callbacks
• Web Services Description Language Specification
• Jetty Java HTTP Servlet Server
• Workshop Web Service Control
• Creating SOAP Message Handlers to Intercept the SOAP Message
• SOAP Conversation Protocol
• Web Services Addressing

原文出处

http://dev2dev.bea.com/pub/a/ 2005/03/c allback_clients.html

OMElement payload = .... 
Call call = new Call();
call.setTo(
        new EndpointReference(AddressingConstants.WSA_TO,
                "HTTP://...));
call.setTransportInfo(Constants.TRANSPORT_HTTP, 
       Constants.TRANSPORT_HTTP, false);
OMElement result =
        (OMElement) call.invokeBlocking(
        operationName.getLocalPart(), payload);

//this is the payload goes on the body of SOAP message 
OMElement payload = .... 
Call call = new Call();
call.setTo(
        new EndpointReference(AddressingConstants.WSA_TO,
                "HTTP://...));
call.setTransportInfo(Constants.TRANSPORT_HTTP,
              Constants.TRANSPORT_HTTP, false);

Callback callback = new Callback() {
    public void onComplete(AsyncResult result) {
        //what user can do to result
    }
    public void reportError(Exception e) {
       //on error
    }
};
call.invokeNonBlocking(operationName.getLocalPart(),
       payload, callback);

OMElement payload = .... 
Call call = new Call();
call.setTo(
        new EndpointReference(AddressingConstants.WSA_TO,
                "HTTP://...));
call.setTransportInfo(Constants.TRANSPORT_HTTP,
    Constants.TRANSPORT_HTTP, true);
Callback callback = new Callback() {
        public void onComplete(AsyncResult result) {
        ....
        }

        public void reportError(Exception e) {
        ...
        }
};
call.engageModule(new Qname("addressing"));
call.invokeNonBlocking(operationName.getLocalPart(), method, callback);

OMElement payload = .... 
Call call = new Call();
call.setTo(
new EndpointReference(AddressingConstants.WSA_TO,
        "HTTP://...));
call.setTransportInfo(Constants.TRANSPORT_HTTP,
    Constants.TRANSPORT_HTTP, true);
OMElement result =
        (OMElement) call.invokeBlocking(
           operationName.getLocalPart(), payload);

　　在SOA的上下文中设计WebServices必须处理好一系列问题，包括可重用性和灵活性等。然而，一旦最初的设计是让独立的服务一起以集成的方式出现就会导致另一些需求的出现，其中大多数可以被业务过程执行语言(Business Process Execution Language ，BPEL)来处理。

　　BPEL是由IBM、Microsoft和BEA在2003年共同发明的。但从诞生尹始，BPEL就得到了Web services标准的引导。现在，在OASIS的资助下已经升到了2.0版本，有超过35家公司正在参与规划未来标准的方向，它将成为处理Web services编排的标准。

　　但如何通过BPEL来进行Web services编排呢?一些其它公司把它称为Web services工作流，意思是已经使用基础的Web services协议栈SOAP/WSDL/UDDI。让我们来谈这个问题之前先假设你被派去迁移一个信用卡应用系统并使用到Web services。

　　由于自身的特性，我们的信用卡应用程序必须与第三方系统交互，并且在同样的过程中有成百的调用。她们基于同样的Web services，这样可以满足不同系统用户的要求。

　　BPEL就是用来构建这些Web services决策链或工作流的。但是，在更深入探讨它的具体使用之前，你应该认识到一个重要事情或者说必备条件，即BPEL背后的价值:可重用性。

　　为了尽可能多的构建基于Web services的业务过程并用BPEL把它们粘合到一起，必须使每个独立的服务都达到精确的平衡。使用粗粒度的Web services比使用BPEL创建不同决策链的整体目标更重要，因为它们可能是完整的业务过程。同样的，细粒度的服务不利于重用和构建BPEL工作流。

　　这个过程本质上与面向对象的设计很类似，即一个对象需要完成足够的工作来证明它的存在才能不被认为是上层调用对象。你应该用同样的方式考虑Web service。Web service 的可重用性是SOA的一个主要原则，这自不必说，而在使用BPEL的时候这一点体现的更加明显。

　　作为核心，BPEL用XML语法来表达Web service交互，而像声明变量、流控、事务和错误处理等其它事情你可以让另一种语言来负责编排协作。

　　因为这样也隐含着Web servcies基本的SOAP/WSDL/UDDI方法，因此BPEL要求其自身环境能够执行这些命令，我们称之为BPEL引擎。

　　现在，BPEL引擎存在着不同的成熟度和复杂性。当SOA领域的一些厂商用其它核心产品例如ESB来紧密集成他们的BPEL引擎时，其他人则在同样的领域创建单独的产品。

　　为了牢固掌握BPEL，我们通过最中立和不侵权的方法，即一个叫做ActiveBPEL的开源Java BPEL引擎来看看下面的BPEL示例。

　　ActiveBPEL是一个单独的BPEL引擎，可以在任何Java/J2EE应用服务器下以Web应用(WAR文件)的形式运转。由于ActiveBPEL属于开源产品，所以它与事实上的Java/J2EE开源Tomcat、Apache's Web services框架Axis以及流行的构建工具Ant紧密的结合在一起。

　　这些特点使ActiveBPEL成为开发BPEL功能的优秀产品，因为它基于已经被熟知并已获得应用的技术。如果你的机器上还没有这些包，可以下载它们并按照基本安装命令进行安装。我们不会谈论配置问题，因为本文的目的是让你能更快的使用BPEL。

　　让我们从高层审视ActiveBPEL编排的过程。你的银行系统需要执行一个信用卡应用过程，并根据一系列详细的决策链返回一个简单的"yes" or a "no"。这些决策链需要拿到贷款数额、某个律师的信用历史或支出地点，所有这一切都是通过调用单独的Web services来完成的。

　　根据市场条件或银行政策，这个业务过程将很可能改变信用卡应用的验证方式。用上层Web services返回结果是相当不灵活的方法，因为它使得每次修改Web services之后都要继续修改业务逻辑。另一方面，让BPEL过程来编排应用逻辑会给我们带来两大好处。

　　BPEL的XML语法授予我们一种指令级别，通过它可以改变应用的工作流而不必在现场业务逻辑之后再修改。这为我们以后在更复杂的工作流情况下重用某套核心Web services提供了方便。

　　假设我们已经为我们的核心Web servcies完成了最后的设计。我们有两个Web services，它们组成了一个approver和一个assessor。初始分析显示这两个服务都能很容易地被其他信用演进过程重用。因此，现在来看BPEL的伪代码并看看为创建BPEL-XML语法我们需要做什么。

if (creditapplication < $10,000) {
        if (assessor returns "lowrisk")
                return "yes"
        else
                return approver response
}
else
        return approver response

　　首先是检查信用卡应用的数额。如果它的量超过$10,000，我们就把输入的数据转交给approver Web service以获得一个响应。反之，如果数量在$10,000以下，我们就先调用assessor Web service，让它返回一个回答，如果响应是"lowrisk"，那么应用程序立即被证实。否则我们就需要进一步调用approver Web service。

　　这是一个很直接的业务过程，很明显的展示了BPEL的强大，达到了为我们的核心Web services编排不同调用场景的目的。现在，让我们来看看实际的BPEL-XML语法。

<?xml version="1.0" encoding="UTF-8"?>
<process name="loanApprovalProcess" suppressJoinFailure="yes"
targetNamespace="http://acme.com/loanprocessing"
xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
xmlns:apns="http://tempuri.org/services/loanapprover"
xmlns:asns="http://tempuri.org/services/loanassessor"
xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
xmlns:lns="http://loans.org/wsdl/loan-approval" xmlns:loandef="http://tempuri.org/services/loandefinitions"
 xmlns:xsd="http://www.w3.org/2001/XMLSchema">
   <partnerLinks>
      <partnerLink myRole="approver" name="customer" partnerLinkType="lns:loanApprovalLinkType"/>
      <partnerLink name="approver" partnerLinkType="lns:loanApprovalLinkType" partnerRole="approver"/>
      <partnerLink name="assessor" partnerLinkType="lns:riskAssessmentLinkType" partnerRole="assessor"/>
   </partnerLinks>
   <variables>
      <variable messageType="loandef:creditInformationMessage" name="request"/>
      <variable messageType="asns:riskAssessmentMessage" name="riskAssessment"/>
      <variable messageType="apns:approvalMessage" name="approvalInfo"/>
      <variable messageType="loandef:loanRequestErrorMessage" name="error"/>
   </variables>
   <faultHandlers>
      <catch faultName="apns:loanProcessFault" faultVariable="error">
         <reply faultName="apns:loanProcessFault" operation="approve" partnerLink="customer"
       portType="apns:loanApprovalPT" variable="error"/>
      </catch>
   </faultHandlers>
   <flow>
      <links>
         <link name="receive-to-approval"/>
         <link name="receive-to-assess"/>
         <link name="approval-to-reply"/>
         <link name="assess-to-setMessage"/>
        <link name="assess-to-approval"/>
          <link name="setMessage-to-reply"/>
      </links>
      <receive createInstance="yes" name="receive1" operation="approve" partnerLink="customer"
      portType="apns:loanApprovalPT" variable="request">
         <source linkName="receive-to-approval" transitionCondition="bpws:getVariableData('request',
         'amount')>=10000"/>
         <source linkName="receive-to-assess" transitionCondition="bpws:getVariableData('request',
         'amount')<10000"/>
      </receive>
      <invoke inputVariable="request" name="invokeapprover" operation="approve"
      outputVariable="approvalInfo" partnerLink="approver"
     portType="apns:loanApprovalPT">
         <target linkName="receive-to-approval"/>
         <target linkName="assess-to-approval"/>
         <source linkName="approval-to-reply"/>
      </invoke>
      <invoke inputVariable="request" name="invokeAssessor" operation="check" outputVariable="riskAssessment"
     partnerLink="assessor"
     portType="asns:riskAssessmentPT">
         <target linkName="receive-to-assess"/>
         <source linkName="assess-to-setMessage" transitionCondition=
         "bpws:getVariableData('riskAssessment', 'risk')='low'"/>
         <source linkName="assess-to-approval" transitionCondition="bpws:getVariableData
        ('riskAssessment', 'risk')!='low'"/>
      </invoke>
      <reply name="reply" operation="approve" partnerLink="customer" portType="apns:loanApprovalPT"
      variable="approvalInfo">
         <target linkName="approval-to-reply"/>
         <target linkName="setMessage-to-reply"/>
      </reply>
      <assign name="assign">
         <target linkName="assess-to-setMessage"/>
         <source linkName="setMessage-to-reply"/>
         <copy>
            <from expression="'approved'"/>
            <to part="accept" variable="approvalInfo"/>
         </copy>
      </assign>
   </flow>
</process>

　　注意BPEL的元素有<partnerLink>, <variable>, <faultHandler>, <flow>, >target>等等。继续讲解BPEL语法的含义超出了本问的范围，但如果你跟进的话你就能发现在伪代码中有同样的模式。还要注意到，很多BPEL过程是使用特殊的编辑器创建的，这样可以避免手写XML时的错误。

　　在看过实际的BPEL过程后，你大概会问这跟实际的Web servcies的UPI或WSDL描述符有什么关系。在ActiveBPEL中，它需要你定义一个过程部署描述符(Process Deployment Descriptor)文件来告诉BPEL引擎你的过程。下面就是这个PDD文件。

<process location="bpel/loanapproval.bpel" name="bpelns:loanApprovalProcess"
xmlns="http://www.active-endpoints.com/schemas/deploy/pdd.xsd"
xmlns:bpelns="http://acme.com/loanprocessing"
xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing">
  <!-- Partner Link for inbound request from customer -->
  <partnerLinks>
    <partnerLink name="customer">
      <myRole allowedRoles="" binding="RPC" service="ApproveLoan"/>
    </partnerLink>
    <!-- Partner Link for outbound request to delegate approver -->
    <partnerLink name="approver">
      <partnerRole endpointReference="static">
 <wsa:EndpointReference xmlns:approver="http://tempuri.org/services/loanapprover">
   <wsa:Address>approver:anyURI</wsa:Address>
   <wsa:ServiceName PortName="SOAPPort">approver:LoanApprover</wsa:ServiceName>
 </wsa:EndpointReference>
      </partnerRole>
    </partnerLink>
    <!-- Partner Link for outbound request to risk assessment process -->
    <partnerLink name="assessor">
      <partnerRole endpointReference="static">
 <wsa:EndpointReference xmlns:assessor="http://tempuri.org/services/loanassessor">
   <wsa:Address>assessor:anyURI</wsa:Address>
   <wsa:ServiceName PortName="SOAPPort">assessor:LoanAssessor</wsa:ServiceName>
 </wsa:EndpointReference>
      </partnerRole>
    </partnerLink>
  </partnerLinks>
  <wsdlReferences>
    <wsdl location="project:/wsdl/loandefinitions.wsdl"
    namespace="http://tempuri.org/services/loandefinitions"/>
    <wsdl location="project:/wsdl/loanapproval.wsdl"
    namespace="http://loans.org/wsdl/loan-approval"/>
    <wsdl location="project:/wsdl/loanapprover.wsdl"
    namespace="http://tempuri.org/services/loanapprover"/>
    <wsdl location="project:/wsdl/loanassessor.wsdl"
   namespace="http://tempuri.org/services/loanassessor"/>
  </wsdlReferences>
</process>

　　注意这个描述符是如何与刚才的BPEL过程协作的。它声明了<process location="bpel/loanapproval.bpel">来为每个<partnerLink>定义物理地址，并声明了多个WSDL描述符。

　　重要的是，这个文件与我们的Web services一起绑定到BPEL过程。通过上面的讲解，你应该能意识到Web services WSDL文件组成了任何BPEL过程的主体。

　　前面的因为WSDL定义了一个Web service的方法、消息和特征。而一个BPEL过程则通过它的引擎使得丰富的使用信息被包含在这些标准Web services文件中，以此来编排需要的业务过程。

　　本文通过ActiveBPEL让大家了解BPEL。如果你已经看过Loan Approval Application for ActiveBPEL 并知道它的内部工作方式，那么现在就能体会到BPEL对给你的Web services和SOA开发所带来的价值。

Q: BPEL、WSBPEL和 BPEL4WS之间的区别是什么?
A: 除了历史参考文献不同外，没有什么其他的不同。这些名字都涉及到相同的未决标准。“BPEL4WS”是起初规范的名字，它由BEA、IBM和Microsoft编写和公布的。“WSBPEL”目前是规范和未决标准的名称。当这个规范提交到OASIS时,出于Web服务相关标准的努力，按照OASIS命名方案更换了这个名字。尽管如此，大部分团体仍然简单地称这个标准为“BPEL”。

Q: 什么是 BPELJ？
A: BPELJ 是BPEL和Java 语言的组合，它允许一起运用这两种编程语言来构建完整的业务流程应用程序。通过允许BPEL和Java一起工作， BPELJ使得每种语言可以做它最擅长的事。BPELJ优于BPEL，但没有它那么有竞争力。

Q:如何把BPELJ和 BPEL联系起来，它们之间区别在哪里？
A: BPEL基本上向编程发展，它支持业务处理流程的逻辑。这些业务处理流程是独立的应用程序，这些应用使用Web服务作为实现业务功能的活动。BPEL 不会成为一门通用的编程语言。然而，有人认为BPEL将和用来实现业务功能的其他语言（少部分的编程）结合起来。为了方便BPEL和Java 结合起来，BPELJ对BPEL做了一些小的改动并且做了一些扩展。

Q: BPEL不是针对业务分析员吗? 如果是，为什么把Java加进来?
A: 有这么一个普遍的误解，那就是BPEL想达到非程序设计人员或者所谓的“业务分析员”也能使用的程度。这个错误的概念部分根源于市场上许多针对于这组用户的业务流程管理工具这样的一个事实。无可置疑，工具供应商为构建BPEL和BPELJ流程提供了广泛的可视化接口，但是语言本身的目的是为了开发人员。

Q: BPELJ如何工作？
A: 通过允许在BPEL流程定义中包含Java代码段（称为Java片断），BPELJ使得Java 和BPEL能够相互协作。

Q: 难道不应该考虑允许使用任何语言（C#、JavaScript和Java等）来设计代码片断吗？
A: 这个片断背后想法是有代表性，我们希望它能用于许多不同的语言。然而，要集成BPEL和一门特定的语言包含的不仅仅是用XML包装目标语言。集成变量绑定、事务管理、调用路径等问题必须周全地定义，然而，每种语言是用不同的方法解决这些问题，对所有语言进行统一的绑定是不现实的。所以， BPELJ集中解决 BPEL 和 Java的这些集成问题。我们期待着解决其他的语言的集成问题 。

Q: 难道BPELJ 没违反“ BPEL中活动是Web服务，数据是XML,数据结构用XML架构描述”这一原则吗？
A: 并不是世界上所有的服务都是Web服务，它们也不应该是。用J2EE更适合紧密耦合的系统，在这种系统中，容器提供的功能如安全和事务是特别有价值的。那些把业务逻辑部署成J2EE组件的人员应该能够在业务流程中充分利用这些组件，BPEL是描述这个过程最好的一门语言。
一些人争论说在程序片断中用Java来完成少量计算和数据操作非常合适，但是应该通过XML/Web服务视图强制所有服务调用。这是一个特别站不住脚的观点。如果您有一个用Java代码片断写的流程，很明显，有一个Java开发人员参与创建这个流程。
这意味着您可能有下面的设想：有一个开发人员熟悉用Java调用组件，他想用Java操纵组件的输入和输出。迫使那个人把所有的调用看成好像是调用Web 服务一样，这会产生一层混乱，阻止考虑业务逻辑。


原文地址：http://dev2dev.bea.com.cn/techdoc/2004120205.html


尽管我知道了bpel的理论，但是仍然觉得写一个bpel挺麻烦的。尽管有一些图形化的编辑工具，但是仍然觉得并不好用，可能是我对bpel还是不熟悉的缘故吧

但是，我可以写一个jave类，在这个类中用各个方法描述出了各个web service的组合调用关系。现在我要做的，就是找一个bpel编辑器和一个bpel服务器来将这个java类的逻辑变成bpel，然后运行之

为什么没有人将这个步骤作成自动化的呢？？？是因为没有必要还是因为别的什么？？

1.要求：

ActiveBPEL引擎需要一个servlet容器。安装脚本使用了CATALINA_HOME环境变量。另外它可以在任何标准servlet容器下运行。

2.安装：
运行安装脚本文件：install.bat(Windows)或者是install.sh(Unix).它把需要的lib拷贝到CATALINA_HOME/shared/lib下，并且创建一个$CATALINA_HOME/bpr,这个目录是放置.bpr文件的地方。

修改引擎配置文件：
服务启动时候包含一下参数，他们放在aeEngineConfig.xml文件中，你可以在$CATALINA_HOME/bpr找到它。你可以通过http://localhost:8080/BpelAdmin/config.jsp 修改。

3.发布:

参看专门的文章：发布BPEL。
一旦引擎启动，在你发布你的BPEL后，引擎会知道读取对应的.bpr文件。

4.启动引擎：

C:\activebpel> %CATALINA_HOME%\bin\startup.bat

activebpel% $CATALINA_HOME/bin/startup.sh

要发布一个BPEL process,你必须创建，安装一个发布文件来包含你的BPEL文件。一般使用jar。

发布你的BPEL Process

发布一个BPEL process 调用创建一个发布文件。（一个jar但是使用.bpr为后缀）并且拷贝到你的servlet容器中。要创建这个文件，你必须把你的文件用特殊的目录结构组织起来，创建一个或者2个配置文件。

首先创建一个文件夹，这个例子中我们命名为mybpel.创建以下子文件夹：

C:\> cd mybpel
C:\mybpel> jar cf mybpel.bpr *.pdd META-INF bpel partners wsdl
C:\mybpel> copy mybpel.bpr $CATALINA_HOME/bpr

% cd mybpel
% jar cf mybpel.bpr *.pdd META-INF bpel partners wsdl
% cp mybpel.bpr $CATALINA_HOME/bpr

你的WSDL文件可以是远程的，但是要写到.pdd中。

如果现在引擎在运行，它马上会发现新的.bpr文件然后自动读取它。你的BPEL process就可以使用了。

原文地址：http://robertpi.blogchina.com/422342.html

原文链结：http://www.theserverside.com/articles/article.tss?l=BPELJava

BPEL and Java

BPEL的作用

    实现从面向过程到面向服务的转变需要一种语言以描述Web services是怎样被组织成业务流程。如果这种描述是可执行的，即允许我们定义抽象的流程，而且允许我们描述流程准确的执行规则，那将更好。而BPEL正是这样一种语言。事实上它是最先具备以下特性的语言：
    1 允许我们定义抽象和可执行的流程
    2 有大多数公司支持
    3 软件运行在bpel流程可以执行（BPEL服务器）和设计（BPEL设计器）的平台上
    在我们对BPEL做更深入的了解之前，先论述一下怎样组织web服务。这通常有两种方法：音乐演奏式和舞蹈式。音乐演奏式为一个中心进程控制相关的web services并协调在操作中被调用的web services中不同操作的执行。音乐演奏时的乐谱就是一次组织过程。被调用的web services并不知道他们被调用以组织成一个流程，也不知道他们是一个更高层业务流程的一部分（它们也不需要知道）。只有音乐演奏中的指挥者知道这些，所以音乐演奏方式是将清晰定义的操作和web services的调用顺序集中起来管理的方式。
    相比而言舞蹈方式不依赖一个中心的协调器。每一个在舞蹈方式中被调用的web service清楚的知道何时执行它的操作并且知道与谁合作。舞蹈方式是专注与信息交互的合作方式。所有的参与者需要关注业务流程，操作的执行，信息的交互以及信息交互的时机。
    通过对组合web services以执行业务流程的了解，音乐演奏方式比之舞蹈方式为更灵活的处理方法：
     我们准确的知道谁对整个业务流程的执行负责
     即使是那些不知道他们是一个业务流程一部分的web services，我们也可以组合
     当错误发生时我们也可以提供可选择的替代
    BPEL遵循音乐演奏的方式。舞台方式为其他标准采用，比如WSCI（Web Services Choreogaphy Interface）和WS-CDL（Web Service Choreography Description Language）。比之BPEL，舞蹈方式还没有获得业界的支持。
    2002年8月，BEA、IBM、Microsoft开发出BPEL的第一个版本。从那时候起，越来越多厂商的加入使得在2003年3月在第一个版本基础上做了一些调整和改进的1.1版本的诞生。在2003年3月，BPEL被提交至OASIS组织作为标准，后来WSBPELTC组织成立。
    BPEL可以在公司内部和公司之间使用。在公司内部，BPEL的作用是标准化企业应用集成和促进以前孤立系统之间的集成。在企业之间，BPEL使得业务伙伴之间的集成更容易更高效。以BPEL描述的业务流程的定义在不影响现有系统的情况下完成升级。在已经是函数环境或将要通过web services方式提供服务的环境当中BPEL是重要的技术。随着web service技术得到越来越多的使用，BPEL的重要性将日渐增强。
BPEL语言
      现在让我们看一下BPEL语言。BPEL作为一种语言具体设计用来定义业务流程。BPEL支持两种不同类型的业务流程：
     可执行流程允许我们指定严格的业务流程的细节，他们由音乐演奏引擎执行。在大多数情况下，BPEL被用作定义可执行的流程
    抽象的业务协议允许我们指定仅仅在各参与者之间公共的信息交换。他们不包含处理流程的内部细节并且不是可执行的。
    BPEL建立在XML和web services之上，它是一种基于XML的语言，支持包括SOAP,WSDL,UDDI,WS-Reliable消息,WS-Addressing,WS-Coordination和WS-Transaction的web services技术栈。BPEL汲取了两种早先的工作流语言：WSFL(Web Services Flow Language)和XLANG。WSFL由IBM设计，基于有向的内容。XLANG由微软设，是一种程序块结构语言。BPEL融合了这两种方法为业务流程的描述提供了丰富的语法。
    一个BPEL流程严格指定了参与的web services被调用的顺序。这可以顺序或并行地完成。使用BPEL我们可以表示有条件的行为，例如一个web service的执行可以依赖前一个调用的结果。我们也可以构建循环，申明变量，拷贝和赋值变量，定义错误处理程序等。通过组合这些结构，我们可以以一个算法方式定义复杂的业务流程。
    因此BPEL可以与像java这样的一般编程语言相比，不过没有java那样强大。但另一方面，它更简单并适合业务流程的定义。因此BPEL不是对java这样的高级语言的替代而是一个补充。让我们了解一下一个典型的BPEL流程。首先，这个BPEL业务流程收到一个请求。为了处理这个请求，流程开始调用相关的web services并将最后的结果返回给最初的请求发送者。因为BPEL流程需要与其他的web services通信，所以它非常依赖被合成web service所调用的web services的WSDL描述。
    一个BPEL流程由很多个步骤组成，每一步骤被称为一个活动。BPEL支持基本的和结构化的活动。基本的活动即为基础的结构，用作公共的任务，比如：
    使用调用其他的web services
    通过发送一个消息等待客户端调用业务流程使用(收到一个请求)
    使用对同步的操作产生响应
    使用处理数据变量
    使用指示错误和异常
    使用等待一段时间
    使用结束整个流程等等
    这样我们可以组合这些和其他基本的活动定义准确反映业务流程步骤的复杂算法。为了组合基本的活动BPEL支持一些结构化的活动。其中最重要的有：
    允许我们定义一系列按顺序调用的活动
    用来定义一系列并行调用的活动
    用来构建分支结构
    用来定义循环
    在许多的替代路径中选择一个的操作使用
    每一个BPEL流程也可以使用申明变量，使用定义合作链接。我们将在文章的下面部分对合作链接作更多的探讨。
    一个BPEL流程可能是同步也可能是异步的。一个同步的BPEL流程锁定客户端(使用这个流程的)直到这个流程完成并返回一个结果给客户端。一个异步的流程不锁定客户端，而是使用一个回调来返回结果(如果结果存在的话)。通常我们使用异步的流程实现长时间的流程，使用同步实现在一个相对短的时间里返回结果的流程。如果一个BPEL流程使用异步的web services，流程本身同时也是异步的(虽然这不是必须的)。
     对于客户端来说，一个BPEL流程看起来就和其他的web service差不多。当我们定义一个流程，实际上我们是在定义一个由已存在服务组合而成的新的web service。为了调用由BPEL描述的业务流程，我们需要调用合成出来的复合web service。下图为一个BPEL流程的示意图：
 
   合作链接
上面我们提到BPEL也申明合作链接，现在让我们解释一下什么是合作链接。我们已经提到BPEL和外部的web services的交互有两种方式：
   BPEL流程调用其他web services上的操作
   BPEL流程接收客户端的调用。在所有客户端中有一个是发起最初调用的BPEL流程的使用者。其他客户端是web services。举例来说，是那些已经为BPEL流程所调用，但是需要回调以返回结果。
   BPEL把这些所有和它交互部分的链接称之为合作链接(partner links)。合作者链接可以是被BPEL流程调用的web services，也可以是调用BPEL流程的客户端。每一个BPEL流程至少有一个客户端合作链接，因为必然有一个调用BPEL流程的客户端。
    通常一个BPEL流程也至少有一个调用的合作链接，因为它将调用至少一个web service(通常不止一个)。不管怎么样，被调用的合作链接可能成为客户端链接——这通常是在异步服务的情况下，流程调用一个操作的地方。然后这个服务(合作者)调用流程上的回调操作来返回被请求的数据。
    BPEL像合作链接一样对待客户端有两个原因。最显而易见的是支持异步交互，第二个原因是基于BPEL流程可以提供服务的事实。这些通过端口类型提供的服务可以为多于一个的客户端使用。流程可能希望区分不同客户端并仅仅提供给他们经授权的功能。举例来说，一个保险流程可能提供给汽车保险客户与房产保险客户不同的一系列操作。
    综上述，我们可以看到合作链接描述了指向合作者的链接，这样的合作者可能是：
    流程调用的服务
    调用流程的服务
    两者兼而有之的服务——它们既被流程调用也调用流程

BPEL的例子
    为了了解BPEL流程究竟是什么样子，下面我们给出一个选择最好保险服务的非常简单的BPEL流程。首先，我们申明指向一个BPEL流程客户端（称作client）和两个保险web服务(称作insuranceA 和 insuranceB)的合作链接。
 

 1<?xml version="1.0" encoding="utf-8"?>
 2<process name="insuranceSelectionProcess"          targetNamespace="http://packtpub.com/bpel/example/"         xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/"         xmlns:ins="http://packtpub.com/bpel/insurance/"         xmlns:com="http://packtpub.com/bpel/company/" >
 3<partnerLinks>
 4      <partnerLink name="client"
 5                 partnerLinkType="com:selectionLT"
 6                   myRole="insuranceSelectionService"/>
 7      <partnerLink name="insuranceA"                                   partnerLinkType="ins:insuranceLT" 
 8 myRole="insuranceRequester"
 9                   partnerRole="insuranceService"/>
10      <partnerLink name="insuranceB"                   partnerLinkType="ins:insuranceLT"
11                   myRole="insuranceRequester"                   partnerRole="insuranceService"/>
12   </partnerLinks>  
13
14

然后，我们为保险请求申明变量(InsuranceRequest)，保险A和B响应(InsuranceAResposne, InsuranceBResposne)，和最终的选择(InsuranceSelectionResponse)

   <variables>
      <!-- input for BPEL process -->
      <variable name="InsuranceRequest"
                messageType="ins:InsuranceRequestMessage"/>
      <!-- output from insurance A -->
      <variable name="InsuranceAResposne"                messageType="ins:InsuranceResponseMessage"/>
      <!-- output from insurance B -->
      <variable name="InsuranceBResposne"                messageType="ins:InsuranceResponseMessage"/>
      <!-- output from BPEL process -->
      <variable name="InsuranceSelectionResponse"                messageType="ins:InsuranceResponseMessage"/>
   </variables>

最后，我们具体化流程步骤。首先我们从客户端等待初始的请求信息()。然后我们使用并行调用()两个保险web服务。保险服务返回保额，然后我们选择低的保额(/ )并使用将结果返回给客户(BPEL流程的调用者)

   <sequence>
      <!-- Receive the initial request from client -->
      <receive partnerLink="client"
               portType="com:InsuranceSelectionPT"               operation="SelectInsurance"               variable="InsuranceRequest"
               createInstance="yes" />
     <!-- Make concurrent invocations to Insurance A and B -->
      <flow>
         <!-- Invoke Insurance A web service -->
         <invoke partnerLink="insuranceA"                 portType="ins:ComputeInsurancePremiumPT"                 operation="ComputeInsurancePremium"                 inputVariable="InsuranceRequest"
                 outputVariable="InsuranceAResposne" />
         <!-- Invoke Insurance B web service -->
         <invoke partnerLink="insuranceB"
                 portType="ins:ComputeInsurancePremiumPT"
                 operation="ComputeInsurancePremium"
                 inputVariable="InsuranceRequest"
                 outputVariable="InsuranceBResposne" />
      </flow>
      <!-- Select the best offer and construct the response -->
      <switch>
        <case condition="bpws:getVariableData('InsuranceAResposne',
                         'confirmationData','/confirmationData/Amount')
                      <= bpws:getVariableData('InsuranceBResposne',
                         'confirmationData','/confirmationData/Amount')">
           <!-- Select Insurance A -->
           <assign>
             <copy>
               <from variable="InsuranceAResposne" />
               <to variable="InsuranceSelectionResponse" />
             </copy>
           </assign>
        </case>
        <otherwise>
           <!-- Select Insurance B -->
           <assign>
             <copy>
               <from variable="InsuranceBResposne" />
               <to variable="InsuranceSelectionResponse" />
             </copy>
           </assign>
        </otherwise>
      </switch>
      <!-- Send a response to the client -->
      <reply partnerLink="client"
             portType="com:InsuranceSelectionPT"
             operation="SelectInsurance"
 variable="InsuranceSelectionResponse"/>
   </sequence>
</process>

因为每一个BPEL流程都是一个web service，每一个BPEL流程也需要一个WSDL文档。我们将不再对开发BPEL流程的更深入的细节作讨论。更多的资料可以参阅由Packt Publishing于2004年10月出版的《web服务的业务流程执行语言》(Business Process Execution Language for Web Services)
  BPEL和Java
  看到从上面BPEL流程的例子一些人也许会想这样一个组合用java也很容易实现。对于非常简单的流程来说这是正确的。但是对于更复杂的流程来说我们会看到BPEL比之Java的至少两个重要的优势。
  BPEL比之Java的第一个优势是BPEL流程是可移植的，甚至可以运行在Java平台之外。BPEL流程可以在基于Java平台的音乐演奏服务器上运行也可以在任何其他的软件平台上运行(如.Net平台)。这在使用不同平台的B-B交互中显得尤为重要。
  BPEL的第二个优势是它针对业务流程特性的支持。通常业务流程是长时间运行的，特别是他们在internet上实现与其他合作者交互的时候。有可能这样流程的执行需要几分钟，几小时，甚至是几天才能完成。有可能它们调用一个web service需要等待一个相对长的时间以获得回调的结果。如果我们不使用一个BPEL流程而是使用一个Java应用程序我们的大部分时间将会担心什么线程已经完成，什么仍然在运行。我们将不得不跟踪Java线程以确定那些我们能结束，又有哪些需要继续运行以获得回调结果。
  BPEL也用相对简单的方式支持补偿。对在业务流程中那些已经成功完成操作的补偿，或者撤销操作是业务流程中最重要的问题之一。补偿的目的是恢复这个被撤销的业务流程中已经执行完成的活动。
   补偿与大多数业务流程的特性相关，这种业务流程是长时间运行的并且使用异步的方式与松散耦合的web servcies通信。就成功完成来说业务流程是非常脆弱的，因为他们所使用的数据本身就是脆弱的。因为它们通常横跨多个合作伙伴(同时是多个企业)，所以需要关注业务流程可能是完整执行也可能部分结果是未完成的，即补偿。这和在企业信息系统中的ACID事务类似。BPEL使用定义的补偿操作的能力支持补偿的概念(某种范围上讲这是特殊处理)，这种特性称之为长时间事务(LRT)。
    业务流程也可能需要对中心事件做出反映。这样的事件可能是消息事件或者警告事件。通过在端口类型上的调用操作消息事件由引入消息触发。警告事件是时间相关的，并且在一段持续时间之后或者一个特殊的时间触发。BPEL对业务流程中的事务管理提供了很好的支持。
    这样就有并发活动。在BPEL中并发活动使用活动来模拟。在标签内聚集嵌套的活动非常直观，也对表示那些并不太复杂的并发场景非常有帮助。为了表达更复杂的场景，提供在活动之间表达同步依赖的能力。换句话说，我们可以具体指定哪个活动能够开始，什么时候开始(依赖其他的活动)并且可以定义复杂的依赖。举例来说，我们常常指定一个特定的活动或几个活动必须在其他一个或几个活动结束之后才能开始。
    与web services的无状态模式相比业务流程模式需要使用一个有状态的模式。当一个客户端开始一个业务流程，一个新的实例将会创建。这个实例在业务流程的生命周期中存在。发送给业务流程的消息(使用在端口类型和通信端口上的操作)需要被转送到正确的业务流程实例。BPEL提供使用特定业务数据来保存指向特定业务流程实例的机制。这种功能称为相关性(correlation)。
    我们可以继续讨论，不过很明显BPEL已设计用来满足定义业务流程的需要。很明显，BPEL作为一种编程语言或是一个平台来说都不能取代Java。事实上，Java平台是运行BPEL流程的一个选择。
    BPEL服务器和开发工具
    为了执行BPEL流程我们需要一个音乐演奏式的服务器。这样的服务器为可执行的BPEL业务流程提供一个运行的环境。BPEL与web services紧密相关，也和支持web service开发的现代软件平台紧密相关，特别是J2EE和.Net平台。
    BPEL服务器可以使用J2EE或者.Net应用服务器的环境，这样他们可以使用应用服务器提供的服务，比如安全，事务，可伸缩性，和数据库的集成，EJB组件服务，如JMS的消息服务等等。
    BPEL服务器在J2EE和.Net平台上都已存在。在J2EE平台下我们至少可以在以下中选择：
     Oracle BPEL Process Manager (http://www.oracle.com/technology/products/ias/bpel/index.html)
     IBM WebSphere Business Integration Server Foundation        (http://www.ibm.com/software/integration/wbisf)
    IBM alphaWorks BPWS4J (http://www.alphaworks.ibm.com/tech/bpws4j)
    OpenStorm Service Orchestrator (http://www.openstorm.com)
     Vergil VCAB Server (http://www.vergiltech.com/products_VCAB.php)
    Active Endpoints ActiveWebflow Server (http://www.active-endpoints.com/products/index.html)
    ActiveBPEL engine (http://www.activebpel.org/)
    Fivesight Process eXecution Engine (http://www.fivesight.com/pxe.shtml)
    基于.Net平台的BPEL服务器包括：
Microsoft BizTalk 2004 (http://www.microsoft.com/biztalk/)
OpenStorm Service Orchestrator (http://www.openstorm.com)
  OpenStorm提供包括J2EE和.NET平台上的解决方案。除了BPEL音乐演奏式服务器之外还有一些可用的BPEL设计工具。这些工具支持对BPEL流程的图形化开发并通常和服务器集成在一起：
   Oracle BPEL Designer
  IBM WebSphere Studio Application Developer, Integration Edition
  IBM BPWS4J Editor
  Vergil VCAB Composer
 Active Endpoints ActiveWebflow Designer
当Vergil VCAB Composer在.NET平台上建立时，Oracle, IBM和Active Endpoints的解决方案则是基于Java Eclipse框架。我们可以看到在Java平台上更多可用的BPEL服务器和设计器。
BPEL+jAVA
  我们已经看到BPEL是组合web services成为业务流程的合适语言。BPEL不是一般普适性语言(也不想成为)。因此BPEL和JAVA相互配合，Java负责web services的编程实现和web services与BPEL流程的执行平台。
   如在规格说明书中提到的，BPEL是可扩展的。特别是BPEL可以扩展至web services之外是非常有前景的。这意味着我们可以使用BPEL组合不同的资源而不仅仅是web services。在J2EE平台中，可能包括EJBs，JMS，RMI，JCA和其他资源。对于这个问题通常有两种解决方法：
    支持BPEL和Java代码的混合，这就是BPELJ的思想
    用WSDL描述所有的资源(Java classes,EJBs,JMS等等)，这是Web Services调用框架中的思想
  BPELJ提供在BPEL流程定义中包含java代码(称之为JAVA片断)的可能性。这一方面使我们能够从BPEL中直接调用Java资源(BPELJ支持Java合作者链接)，另一方面，它给了BPELJ增强的能力，因为使用java片断，我们可以执行诸如计算值，构建XML文档之类的任务，也可以不用创建web服务就执行其他代码。我们也可以使用BPEL变量表达JAVA代码片段。IBM和BEA支持BPELJ，并且已经发表了BPELJ的白皮书。
    将java代码整合进BPEL流程以支持调用JAVA资源是非常有用的。但是，在某些情况下这样的处理方式也会带来缺点。对一个Java资源的调用不同于对一个web service的调用。web服务调用框架(WSIF)遵循另外一种处理思路：在BPEL中使用相同的语法调用资源或服务并使用WSDL来描述，即使它是一个不通过SOAP协议通信的Java资源。WSIF也允许我们将这样的服务和实际的实现与协议相映射。
    换句话说，我们可以把对抽象服务的描述与基于SOAP协议的实现绑定，与Java类绑定，与EJB绑定或者其它支持的资源，这只需要修改WSDL绑定即可。在BPEL中没有代码的更改是必须的而支持BPEL扩展也是需要的。对这种绑定的支持在由WSIF提供的支持者那里是坚定不移的。
   WSIF是最初由IBM的WSTK (Web Services Toolkit)开发中alphaWorks部分发展而来的Apache技术。现在如Oracle BPEL Process Manager的一些BPEL服务器已经支持WSIF。
   这两种方法，BPELJ和WSIF都适合现实世界的场景并且使得BPEL在EAI和B2B中都非常有用。
结束语
    BPEL是面向过程转向面向服务的一种重要语言。因为BPEL具体设计用来定义业务流程，因此对业务流程的很多特殊性有很好的支持，如长时间事务，补偿，事件管理，相关性等等。BPEL非常适合和J2EE平台一起使用，很多BPEL服务器也是建立在J2EE之上的。结合BPEL和Java的BPELJ以及WSIF的思路使得BPEL的可用性越来越好。应该看到正在制定的JBI(Java Business Integration)规范将会在JAVA平台里给业务集成和BPEL一个更好的备有证明文件的位置。  
 


地址：http://cauzcy.bokee.com/4749126.html

If you get this error when starting resin
"Can't load JNI VFS library.  Resin will still run,"
Follow the instruction for unix, for window the easiest way is to copy resin.dll into the windows/system32 directory

好像我的某次尝试报的就是这个错误，我不知道如何解决就放弃了那个解决方法，似乎是采用这个方法的时候：http://blog.csdn.net/chinarefers/archive/2005/03/09/315590.aspx


接下来的任务是配置XFire，这个过程是复杂而曲折的。。。

好，等下篇再写，我干活先因为现在还没弄清spring框架，那个service还不能跑呢，呵呵