未定义partnerLinkType问题的解决方案

文章仅供大家参考，所有评论, 错误报告, 其他信息以及批评, 请邮寄到 Jeffery.Lee AT gmail.com 或者访问我的个人blog同我交流( http://ibuddie.spaces.live.com/ )。本文遵从GNU 的自由文档许可证(Free Document License)的条款，欢迎转载，如若修改、散布，请注明文章原始出处和来源。

---

在做Web服务组合的时候，如果调用第三方服务，很有可能第三方服务的WSDL文件中，并没有提供相应的partnerLinkType的定义，这时候可以按照如下思路处理：
1、本地创建一个新的WSDL文件，通过import元素导入第三方的WSDL（包装的思想），然后补充partnerLinkType的定义 ；
2、在BPEL服务的WSDL中添加partnerLinkType的定义（具体可行与否，还有待测试）

---

主要参考以下文档:

From BPEL Specification

A <partnerLinkType> characterizes the conversational relationship between two services by defining the roles played by each of the services in the conversation and specifying the portType provided by each service to receive messages within the context of the conversation. Each <role> specifies exactly one WSDL portType. The following example illustrates the basic syntax of a <partnerLinkType> declaration:

<plnk:partnerLinkType name="BuyerSellerLink">

<plnk:role name="Buyer" portType="buy:BuyerPortType" />

<plnk:role name="Seller" portType="sell:SellerPortType" />

</plnk:partnerLinkType>

The extensibility mechanism of WSDL 1.1 is used to define <partnerLinkType> as a new definition type to be placed as an immediate child element of a <wsdl:definitions> element. This allows reuse of the WSDL target namespace specification and its import mechanism to import portType definitions. The <partnerLinkType> definition can be a separate artifact independent of either service's WSDL document. Alternatively, the <partnerLinkType> definition can be placed within the WSDL document defining the portTypes from which the different roles are defined.

The syntax for defining a <partnerLinkType> is:

<wsdl:definitions name="NCName" targetNamespace="anyURI" ...>

...

<plnk:partnerLinkType name="NCName">

<plnk:role name="NCName" portType="QName" />

<plnk:role name="NCName" portType="QName" />?

</plnk:partnerLinkType>

...

</wsdl:definitions>

This defines a <partnerLinkType> in the namespace indicated by the value of the targetNamespace attribute of the WSDL document element. The portTypes identified within <role>s are referenced by using QNames according to the rules in WSDL specifications.

Note that in some cases it can be meaningful to define a <partnerLinkType> containing exactly one <role> instead of two. That defines a partner linking scenario where one partner expresses a capability to link with any other partner, without placing any requirements on the other partner.

Examples of <partnerLinkType> declarations are found in various business process examples in this specification.

From Sun Developer Network(SDN)

(http://developers.sun.com/jsenterprise/nb_enterprise_pack/reference/techart/bpel2.html)

Incorporation in WSDL

You define partnerLinkType as a WSDL extension in the WSDL file—not in the BPEL process definition—because partnerLinkType specifies the relationship between two services.

If the partner's WSDL file does not contain a definition for partnerLinkType, we suggest that you create a wrapper WSDL file to import the original WSDL file and then add the definition in the wrapper. Afterwards, you can refer to the wrapper from your BPEL process.

From the book of “Business Process Execution Language for Web Services”

Partner link types represent the interaction between a BPEL process and the involved parties, which includes the web services the BPEL process invokes and the client that invokes the BPEL process.

In our example, there are three different partners: the client, the employee travel status service, and the airline service. Ideally, each web service should define the corresponding partner link types (in the WSDL). In real-world scenarios, this may not be the case. Then we can wrap the partner web service with a WSDL that imports the WSDL of the web service and defines the partner link types. Alternatively, we can define all partner links in the WSDL of the BPEL process. However, this is not recommended as it violates the principle of encapsulation.