After receiving the request, the BPEL process sends the response message to the WCF service specified within the ReplyTo header. The request and response messages are correlated using the RelatesTo header. On the client side, the WCF service operation includes the following code in order to receive the WS-Addressing v1.0 headers:

UniqueId relatesTo = OperationContext.Current.IncomingMessageHeaders.RelatesTo;

Using these steps, messaging solutions can interoperate even with different versions of WS-Addressing.

BPEL and WS-Security Interoperability Challenges
In the second part of this article, we focus on WS-Security interoperability, because it is another key specification in any WS-* implementation. The main goal behind WS-Security is to enhance SOAP messaging by providing message integrity, confidentiality, and authentication. WS-Security also serves as the base standard to other WS-* protocols, such as WS-SecureConversation, WS-Trust, and WS-Federation. The key function of WS-Security is to provide a general purpose mechanism to associate security tokens with SOAP messages. In this scenario, security-related information is carried in the message itself, instead of in external artifacts. This is known as message-based security and can be used in conjunction with a transport layer security such as SSL.

Message Security vs. Transport Security
SSL has proven its effectiveness in securing resources through the internet. When dealing with Web services, however, SSL is a very coarse-grained tool and has several specific limitations:

• SSL is strictly tied to TCP-based transports such as HTTP. For Web services that use non-TCP transports such as MSMQ or SMTP SSL, it is not a viable option.
• SSL was designed for point-to-point communications. This makes it difficult to implement a routing scenario between Web services. In a routing scenario, the final receiver must be able to validate the original credentials. Extensibility using SSL becomes difficult to provide when those credentials are not stored in the message.
• SSL protects the messages on the wire (between the endpoints) but does not provide protection for the message at the endpoints. This allows access to the whole message upon gaining access to one of the endpoints.

WS-Security Interoperability Example
WCF provides an up-to-date implementation of the WS-* security stack including WS-Security, WS-SecureConversation, WS-Trust, and WS-Federation, allowing developers to implement transport and message security scenarios. Specifically for WS-Security, WCF supports a number of token types, including UserName and Password.

The WS-Security UserNameToken profile provides a standards-based way to send user credentials, which enables applications and platforms to unify their approach. A message-based security approach moves credentials outside the actual operation and into SOAP headers, which makes it possible to alter authentication without touching the operation.

The example used in this article consists of a WCF service that is being invoked from a BPEL process. Before the first call is made, the BPEL process must authenticate to the WCF service using WS-Security and UserName and Password.

The code in Listing 4 shows the target WCF service.

The bindings and behaviors shown in Listing 5 enforce the use of UserName and Password for the authentication. Consider the sample code below, which shows a custom class that provides the UserName and Password validation:

public class MyUserNameValidator :UserNamePasswordValidator
{
    public override void Validate(string userName, string password)
    {
      if (null == userName || null == password)
      {
        throw new ArgumentNullException();
      }
      if (!(userName == "user1" && password == "password1"))
      {
        throw new SecurityTokenException ("Unknown Username or Incorrect Password");
      }
    }
}

Next we implement the BPEL process that invokes the WCF service. The first step is to create a BPEL partnerLink that represents the WCF service. Here is the partnerLink declaration.

<plnk:partnerLinkType name="ServiceSoap_PL">
    <plnk:role name="ServiceSoap_Role">
       <plnk:portType name="tns:MathService_ASPNetSoap"/>
    </plnk:role>
</plnk:partnerLinkType>

In the next step, we provide the required WS-Security headers as part of the <invoke> activity. Using bpelx:inputHeaderVariable (an extension to WS-BPEL standard) we can pass SOAP headers as part of the outgoing message. This is the primary way to send the SOAP-specific headers. The bpelx:inputHeaderVariable extension is specific to Oracle BPEL Process Manager, which also provides deployment descriptor properties (wsseHeaders, wsseUsername, wssePassword) to handle WS-Security headers implicitly.

Listing 6 highlights the code fragments dealing with WS-Security headers. Note especially the inputHeaderVariable that is passed along the invoke activity, as well as wsse:Security.

Running the BPEL process produces the SOAP message shown in Listing 7 when the WCF service is invoked. Pay close attention to the marked section.

This technique allows the creation of BPEL processes that can truly interoperate with WCF services by using WS-Security. The flexibility introduced by manipulating header variables in BPEL allows developers to create interoperability explicitly, when implicit means are not sufficient.

Conclusion
In this article we demonstrated how interoperability between Microsoft .NET WCF and WS-BPEL can be achieved by using explicit means.

SOA applications that require long-running business processes with security and messaging can be built quickly and easily with Web services as the underlying specifications. Web services promise heterogeneous interoperability, and while we anticipate implicit interoperability approaches to be sufficient in the near future, explicit capabilities are still needed in the short term. Such interoperability is real today, as shown by the examples in this article that use Microsoft WCF and Oracle BPEL Process Manager.