June 2006 - Posts

Wednesday, June 21, 2006 11:27 PM

Rick is blogging

Another TwoConnector joined the blogsphere. Rick Pelletier is the AdapterWorx Community Program Manager, one of our Solution Architects and all around a great guy. If you have question about the AdapterWorx community Rick is your man

Posted by gsusx | with no comments
Monday, June 19, 2006 11:23 PM

Commerce Server 2007

Commerce Server 2007 RTMs are now available. I’ve been working with this version since the first Beta ; really great stuff. Congrats to the team!!

Posted by gsusx | 2 comment(s)
Monday, June 19, 2006 11:02 PM

Xml news

The XML Core Working Group has released four Proposed Edited Recommendations for core XML specifications: the fourth edition of Extensible Markup Language (XML) 1.0 and second editions of Extensible Markup Language (XML) 1.1, Namespaces in XML 1.0 and Namespaces in XML 1.1. Proposed for the convenience of readers, the publications correct all errors reported to date and are not new versions. The test suites have been updated.

Posted by gsusx | with no comments
Thursday, June 15, 2006 11:23 AM

WSE 3.0 adapter Chat Talk today.

If you want to know about the WSE 3.0 adapter for BizTalk Server 2006 I’m doing a chat talk this afternoon (5:30 pm) with Mark Fussell (Security Lead Program Manager of the Connected Systems Division) at the Connected Systems Theater. We have some cool demos about WSE 3.0, WCF interoperability and multi-transport Web Services. WE also promise to finish the talk before the party. Hope to see you there.

Posted by gsusx | with no comments
Monday, June 12, 2006 10:41 PM

Teched 2006: day 1

Today was the first day of Teched 2006. I spent most of the day attending to sessions and having interesting conversations on the Connected Systems area. I particularly enjoyed the session “Putting the user back in SOA” delivered by Simon Guest.

Simon explained key concepts (visualization, foundation and context) in order to build really productive user interfaces. He also covered important topics like how to correctly include the user interface in the development lifecycle as well as methods for testing user interfaces. If you want to get more familiar with those concepts you can listen to this Arcast episode with  Simon Guest and Ron Jacobs.

 

Posted by gsusx | with no comments
Friday, June 09, 2006 10:27 AM

Teched 2006

This Sunday (hopefully) I’m flying to Boston to speak on a couple of sessions at Teched 2006. This Teched is special for me because I’m speaking about some of the technology products that we (TwoConnect) have created during last year. My two sessions for this year:

  • Day/Time: Wednesday, June 14 10:15 AM - 11:30 AM  Room: 102 AB

      Speaker(s): Javier Mariscal, Jesus Rodriguez

 Service Broker Enhancements (SBE) is an award winning toolkit (BizTalk Server Product winner & Community Winner in the Microsoft Connected Systems Developer Competition -2005) that greatly enhances the capabilities of SQL Server 2005's Service Broker feature. In this session, see how Service Broker can easily integrate with BizTalk Server 2006, SQL Server Integration Services, UDDI, MSMQ and even non-Microsoft technologies such as Websphere MQ, Oracle Advanced Queing, and TIBCO Rendezvous among others. As a special new announcement, learn how to configure the new SSB Enhancements' Monolog feature which adds publish/subscribe capabilities to Service Broker.

Track(s): Database Development and Administration

       Session Type(s): Breakout Session

       Session Level(s): 400

  • CONTLC20  WSE 3.0 Adapter for BizTalk Server 2006

            Speaker(s): Javier Mariscal, Jesus Rodriguez, Mark Fussell (WSE 3.0 Lead Program Manager)

            Track(s): Connected Systems

            Session Type(s): TLC Theater

            Session Level(s): 300

Other than that I think that I’ll be attending the sessions and hanging by the Connected Systems TLC area so that if you want to talk about WinFX or BizTalk pass by and say hello.

Posted by gsusx | 2 comment(s)
Friday, June 02, 2006 7:07 PM

In Memoriam: Alan Kotok

Alan Kotok, W3C Associate Chair, MIT site manager and head of the W3C Systems Team, passed away last week in Cambridge, Massachusetts, USA. He was 64. Before his many contributions to W3C, Alan held senior engineering positions at DEC in storage, telecommunications and software. A member of the MIT Tech Model Railroad Club, he helped to build the legendary computer game Spacewar, and the gaming joystick. He appears in the Origins of computer chess and in Hackers: Heroes of the Computer Revolution.

Posted by gsusx | with no comments
Thursday, June 01, 2006 9:18 PM

WS-Addressing interoperability between Oracle BPEL Process Manager and Microsoft Windows Communication Foundation

By Jesus Rodriguez

Web Service Addressing (WS-Addressing) and BPEL

WS-Addressing is one of the most important WS-* protocols released until now. The main purpose of WS-Addressing is to incorporate message addressing information into Web Services messages. SOAP is an envelope encoding specification that represents Web Services messages in a transport neutral format. However SOAP itself does not provide any feature to identify endpoints. Normal endpoints like message destination, fault destination, and message intermediary were delegated up to the transport layer.  Combining WS-Addressing with SOAP makes it a real message oriented specification. WS-Addressing defines a set of constructs to specify addressing information in an independent manner embedding that information into the message itself. WS-Addressing is complemented with two other specifications: WS-Addressing SOAP Binding, and WS-Addressing WSDL Binding that indicates how to represent the WS-Addressing properties into SOAP and WSDL respectively.

 

At a very high level WS-Addressing defines an EndpointReference construct to represent a Web Service endpoint. It also defines a set of headers ReplyTo, FaultTo, RelatesTo, MessageID used to dynamically define the message flow between different endpoints. 

In regards to business process integration, Standard BPEL relies on WS-Addressing to endpoint representation and asynchronous Web Services invocations. With the increasing number of Web Services technologies that implements WS-Addressing, interoperability becomes a challenge. From the BPEL standpoint, is almost mandatory for the BPEL integration servers to support WS-Addressing interoperability scenarios with different Web Services suites.

WCF & WS-Addressing

Windows Communication Foundation (WCF) represents the next generation of distributed programming and Service Orientation technologies built on top of the Microsoft.NET platform. WCF unifies the existing set of distributed programming technologies like ASP .NET Web Services, .NET Remoting, COM+, etc under a common, simple and service-oriented programming model. As part of the current build, WCF implements a vast set of WS-* protocols including WS-Addressing.

Oracle BPEL & WS-Addressing

Oracle BPEL Process Manager (PM) is one of the most creative BPEL-based integration servers in the industry today. Oracle BPEL PM executes business processes that orchestrate interaction between Web Services. Oracle BPEL PM implements WS-Addressing to represent dynamic endpoints and to invoke Web Service on an asynchronous messaging pattern.

Interoperability Challenge

As previously explained, both Oracle BPEL PM and WCF implements the WS-Addressing protocol. However while WCF implements version 1.0 and the August 2004 draft of WS-Addressing; Oracle BPEL PM in its current version implements the March 2003 draft of WS-Addressing. The difference of the data models between those WS-Addressing versions represents a challenge when developing dynamic messaging scenarios between WCF and Oracle BPEL PM. Fortunately Oracle BPEL PM provides a set of flexible features for SOAP header manipulation. This flexibility makes it possible to apply some techniques to address the interoperability needs.

 

Suppose that we have the following scenario:

  1. An Oracle BPEL Process explicitly exposes WS-Addressing headers on the process WSDL
  2. A WCF client invokes the Oracle BPEL Process passing the ReplyTo WS-Addressing v1.0 header representing the URL of a WCF Service that is expecting the operation response message. The client also sends a MessageID WS-Addressing v1.0 header to uniquely identify the request.
  3. The Oracle BPEL Process receives the messages, performs some operation and uses the ReplyTo address to define a dynamic endpoint using WS-Addressing 03/2003.
  4. The Oracle BPEL Process sends a reply message to the WCF service specified on the ReplyTo address, passing the RelatesTo WS-Addressing v1.0 header as a way to correlate the original request with the response.
  5. The WCF service receives the response message.

This scenario clearly shows a two-way WS-Addressing interoperability between WCF and Oracle BPEL PM. In this example WCF will use WS-Addressing v1.0; however, Oracle BPEL PM is using WS-Addressing 03/2003. Let’s explore how to implement the previous steps.

 

  1. As part of the process, WSDL imports the WS-Addressing v1.0 xsd and declares the ReplyTo and MessageID headers as part of the binding section.  It also declares messages of type ReplyTo, MessageID and RelatesTo to be used as variable types in the BPEL Process.

<definitions xmlns:tns1="http://xmlns.oracle.com/WCFAddr" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:ns1="http://tempuri.org/" xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/" xmlns:ns2="http://www.w3.org/2005/08/addressing" xmlns:client="http://xmlns.oracle.com/WCFAddr" xmlns:wsa10="http://www.w3.org/2005/08/addressing" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" targetNamespace="http://xmlns.oracle.com/WCFAddr" name="WCFAddr">

            <types>

                        ...

                        <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

                        <xsd:import namespace="http://www.w3.org/2005/08/addressing" schemaLocation="http://www.w3.org/2006/03/addressing/ws-addr.xsd"/>

                        </xsd:schema>

                        ...

            </types>

            ...

              <wsdl:message name="wsaRelatesTo">

                 <wsdl:part name="parameters" element="wsa10:RelatesTo"/>

             </wsdl:message>

 

             <wsdl:message name="wsaReplyTo">

                <wsdl:part name="parameters" element="wsa10:ReplyTo"/>

             </wsdl:message>

 

              <wsdl:message name="wsaMessageId">

                 <wsdl:part name="parameters" element="wsa10:MessageID"/>

              </wsdl:message>

 

            <binding name="WCFAddrBinding" type="tns1:WCFAddr">

                        <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>

                        <operation name="initiate">

                                    <soap:operation soapAction="initiate" style="document"/>

                                    <input>

                                                <soap:header message="tns1:wsaReplyTo" part="parameters" use="literal"/>

                                                <soap:header message="tns1:wsaMessageId" part="parameters" use="literal"/>

                                                <soap:body use="literal"/>

                                    </input>

                                    <output>

                                                <soap:body use="literal"/>

                                    </output>

                        </operation>

            </binding>

            ...

</definitions>

Using this technique, we’re explicitly declaring that the BPEL Process expects the WS-Addressing ReplyTo and MessageID headers as part of the incoming message.

  

  1. In the BPEL process declares variables of type ReplyTo, MessageID and RelatesTo of the messages type declared on the previous section. 

  1. In the BPEL process declares variables of type ReplyTo, MessageID and RelatesTo of the messages type declared on the previous section. 

<variable name="wcfServiceAddr" messageType="ns1:wsaReplyTo"/>

<variable name="wcfRequestId" messageType="ns1:wsaMessageId"/>

<variable name="wcfResponseId" messageType="ns1:wsaRelatesTo"/>

  1. Populate the variables declared on the previous step to the WS-Addressing v1.0 headers of the incoming message.

<receive name="receiveInput" partnerLink="client" portType="client:WCFAddr" operation="initiate" variable="inputVariable" createInstance="yes" bpelx:headerVariable="wcfServiceAddr wcfRequestId"/>

  1. Declare a variable of type EndpointReference( WS-Addressing 03/2003 )     

<variable name="wcfEndpoint" element="ns3:EndpointReference"/>

 The ns3 prefix is associated with the WS-Addressing 03/2003

                    xmlns:ns3="http://schemas.xmlsoap.org/ws/2003/03/addressing"

 

  1. Populate the wcfEndpoint variable using the ReplyTo header stored in the wcfServiceAddr variable. We can implement that as a series of copy rules in an Assign construct.

<assign name="endpointAssign">

<copy>

       <from>

         <EndpointReference xmlns="http://schemas.xmlsoap.org/ws/2003/03/addressing" xmlns:ns1="http://tempuri.org/">

           <Address />

           <ServiceName />

         </EndpointReference>

       </from>

       <to variable="wcfEndpoint"/>

     </copy>

     <copy>

       <from variable="wcfServiceAddr" part="parameters" query="/ns2:ReplyTo/ns2:Address"/>

       <to variable="wcfEndpoint" query="/ns3:EndpointReference/ns3:Address"/>

     </copy>

     <copy>

       <from expression="’ns1:wcfService’"/>

       <to variable="wcfEndpoint" query="/ns3:EndpointReference/ns3:ServiceName"/>

     </copy>

   </assign>

  1. Assign the wcfEndpoint variable to the wcfService Partner Link       

   <assign name="PLAssign">

     <copy>

       <from variable="wcfEndpoint"/>

       <to partnerLink="wcfService"/>

     </copy>

   </assign>

  1. In order to correlate request and response messages, copy the value of the wcfRequestId (MessageID) to wcfResponseId (RelatesTo).

<copy>

       <from variable="wcfRequestId" part="parameters" query="/ns2:MessageID"/>

       <to variable="wcfResponseId" part="parameters" query="/ns2:RelatesTo"/>

  </copy>

  1. Invoke the WCF Service passing the RelatesTo (WS-Addressing v1.0) header. We can achieve that using the bpelx:InputHeaderVariable attribute of the invoke construct.

<invoke name="Invoke_1" partnerLink="wcfService" portType="ns1:IOperationCallback" operation="SendResult" inputVariable="wcfRequest" bpelx:inputHeaderVariable="wcfResponseId"/>

  1. Now its time to create a WCF client to invoke the Oracle BPEL PM process. On the client code create a WCF Binding Element that allows the use of WS-Addressing v1.0 then wraps the call to the Oracle BPEL process in an OperationContextScope in order to populate the WS-Addressing headers

The following code template shows these steps:

HttpTransportBindingElement addrBindingElement = new HttpTransportBindingElement();

addrBindingElement.ManualAddressing = true;

TextMessageEncodingBindingElement encElement = new TextMessageEncodingBindingElement();

encElement.AddressingVersion = AddressingVersion.WSAddressing10;

encElement.MessageVersion = MessageVersion.Soap11WSAddressing10;

CustomBinding opbinding = new CustomBinding(encElement, addrBindingElement);

EndpointAddress opendpoint = new EndpointAddress(WCF Service Address…);           

ChannelFactory<IOperationCallback> factory = new ChannelFactory<IOperationCallback>(opbinding, opendpoint);

IOperationCallback op = factory.CreateChannel();

using (new OperationContextScope((IContextChannel)op))

{

  MessageVersion CurrentVersion=        OperationContext.Current.OutgoingMessageHeaders.MessageVersion;

  OperationContext.Current.OutgoingMessageHeaders.ReplyTo = new   EndpointAddress(opendpoint);

  OperationContext.Current.OutgoingMessageHeaders.To = new Uri(Oracle BPEL Process Address…);

  OperationContext.Current.OutgoingMessageHeaders.MessageId = new UniqueId();

   Execute operation…

 }

This code is going to produce a SOAP message like the following: 

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" xmlns:a="http://www.w3.org/2005/08/addressing">

            <s:Header>

                        <a:Action s:mustUnderstand="1">http://tempuri.org/IOperationCallback/SendResult</a:Action>

                        <a:ReplyTo>

                                    <a:Address>WCF Service Address…</a:Address>

                        </a:ReplyTo>

                        <a:To s:mustUnderstand="1">Oracle BPEL Process Address…</a:To>

                        <a:MessageID>urn:uuid:847b546e-16e5-4ea9-8267-b6fe559f0c1f</a:MessageID>

            </s:Header>

            <s:Body>

            Body...

            </s:Body>

</s:Envelope>

  1. After receiving the request, the Oracle BPEL Process will send the response message to the WCF Service specified on the ReplyTo header. The request and response messages are correlated using the RelatesTo WS-Addressing v1.0 header. 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 those steps we can build messaging solutions that interoperate the current WS-Addressing implementation of WCF and Oracle BPEL PM. Conceptually this process is mapping the incoming WS-Addressing ReplyTo header to the WS-Addressing 03/2003 ReplyTo header supported for Oracle BPEL PM dynamic endpoints. Lastly, the correlation between the request and response message is completed, mapping the MessageID and RelatesTo headers.

Where are we?

We have discussed in detail how to achieve WS-Addressing interoperability between Oracle BPEL Process Manager and Windows Communication Foundation.  Both technologies implement different versions of the WS-Addressing Standard, but the header manipulation feature of Oracle BPEL PM makes it possible to achieve the interoperability between the two. These same techniques can be applied to achieve interoperability with the WS-Addressing August 2004 specification.

Posted by gsusx | 18 comment(s)
Filed under: , ,
More Posts