The following article published in SOA Web Services Journal provides a good glimpse into interoperability issues between Microsoft .NET WCF and Oracle BPEL Process manager. It highlights a couple of interesting items:
1. WS-Addressing is required for endpoint representation especially for long running transactions where the server invokes a callback to the client for sending the response once the processing is complete. Oracle BPEL Process Manager supports a different version on WS-Addressing than Microsoft .NET WCF. So out-of-the-box, the WS-Addressing will not work. Luckily, Oracle BPEL Process Manager supports WS-BPEL extensions (bpelx:headerVariable) that provides the BPEL process access to header information sent by the client. With a handle on header information, the BPEL process manager can manipulate WS-Addressing information and ensure that the the Process executes and that the call-back is compliant with what the .NET WCF client is expecting.
2. When a server is WS-Security enabled and is expecting a User Name Token, an X.509 token, or a SAML assertion in the SOAP Header, the BPEL Process Manager can again use WS-BPEL extensions such as (bplex:inputHeaderVariable) to stuff SOAP Headers with tokens before invoking an endpoint that expects this information.
Really Cool Stuff!
Web Services and SOA
— People sometimes ask what a service-oriented architecture enables today that could not have been done with the older, proprietary integration stacks of the past 5 to 15 years, such as those from Tibco, IBM, or Vitria. One such ability is the greater degree of interoperability between heterogeneous technology stacks that is made possible by the standards SOA is built on, such as Web services and BPEL. Although interoperability is only one facet of the SOA value proposition, it is one that has become increasingly more important, due in large part to the evolving IT environment, merger and acquisition activity, and increased partner connectivity.