Feeds:
Posts
Comments

Archive for August, 2009

Building Apache ODE

It seems building ODE is not the easiest thing to do. I found this the hard way when I really messed up all sorts of things when trying to build ODE in my office machine. (Funny thing is that it went to the extent of reinstalling the OS). The process is quite strange if you are new to the Ruby world like me, because ODE uses a Ruby build system called buildr. Before installing buildr following packages has to be installed if Ruby is not installed in your system.

Ruby – packages related to the language
RubyGems – the Ruby package manager

buildr internally uses the Ruby build program Rake which is a simple ruby build program with capabilities similar to make.

So the second time I was prepared. I metaculously went through the instructions in the ODE and buildr sites. Since the information is scattered a bit across sites, here is the exact the steps I went through for a succesful ODE build. Note that ODE branch and ODE trunk uses different versions of buildr. So both versions of buildr has to be installed first.

Important: I am using an Ubuntu box. So these steps are for an Ubuntu system.

Installing buildr

Step 1 – Installing Ruby

$ sudo apt-get install ruby-full ruby1.8-dev libopenssl-ruby build-essential

Step 2 – Installing RubyGems

$ wget http://rubyforge.org/frs/download.php/38646/rubygems-1.2.0.tgz
$ tar xzf rubygems-1.2.0.tgz
$ cd rubygems-1.2.0
$ sudo ruby setup.rb
$ sudo ln -s /usr/bin/gem1.8 /usr/bin/gem

Step 3 – Installing buildr

$ sudo env JAVA_HOME=$JAVA_HOME gem install buildr -v 1.2.10
//this version is used to build ODE branch

$ sudo env JAVA_HOME=$JAVA_HOME gem install buildr -v 1.3.2
//this version is used to build ODE trunk

Step 4 – Source checkout

Now installing buildr has been done ODE can be built from its source. To checkout ODE.

Branch

$> svn checkout http://svn.apache.org/repos/asf/ode/branches/APACHE_ODE_1.X ode-1.X

Trunk

$> svn checkout http://svn.apache.org/repos/asf/ode/trunk ode-trunk

Step 5 – Build ODE

Go to the checkout directory. In this case ode-1.x in case of branch and ode-trunk in case of trunk.

Building branch

$> buildr _1.2.10_ clean install TEST=no

Building trunk

$> buildr _1.3.2_ clean install TEST=no

Generating Eclipse project files

$> buildr eclipse

Generating IDEA project files

$> buildr idea

Note: It also work even if you don’t mention the buildr version in trunk build. But in the branch build version number has to be used. Otherwise you may see an error similar to this.

rake aborted!
can’t activate buildr (~> 1.2.4, runtime), already activated buildr-1.3.2
~/ode-1.x/Rakefile:17

Advertisements

Read Full Post »

A WSDL describes a web service. A WSDL binding describes how the service is bound to a messaging protocol. SOAP is a prominent binding used in WSDLs. WSDL 1.1 distinguishes between two message styles: document and RPC.

* Document: contains one or more child elements called parts. There are no SOAP formatting rules for what the contains; the content is to be interpreted by endpoints as they have agreed prior to the communication.
* RPC: RPC implies that contains an element with the name of the method or remote procedure being invoked. This element in turn contains an element for each parameter of that procedure.

There are two serialisation formats of the SOAP message as well.

* Encoded: If the format is encoded the SOAP message is encoded with SOAP encoding. This was predominantly used with RPC style since it uses the names of the method and its parameters to generate structures that represent a method’s call stack. These structures can then be serialized into the SOAP message according to a set of encoding rules defined by the SOAP encoding.
* Literal: Message payload is plain XML data adhering to WSDL/XML Schema rules, requiring no additional encoding/decoding.

The combination of these styles and serialisation formats (uses) give rise to four style/use scenarios.

1. RPC/encoded
2. RPC/literal
3. Document/encoded
4. Document/literal

Additionally there is a defacto model in uasge named document/literal wrapped as well. There is potential for confusion over the wordings here. The definition of styles may be suggestive of the fact that, RPC style is used in RPC programming models and document style should be used for document or messaging programming models. This may not be the case at all. You can use RPC style with document model vice versa. Latter sections of this post describe how this can be done. The style merely says how the WSDL messages should be bound to the SOAP message.

RPC/encoded

WSDL Message


<message name="details">
<part name="name" type="xsd:string">
<part name="id" type="xsd:int">
</message>

<message name="balance">
<part name="balance" type="xsd:int">
</message>
<portType name="myPT">
   <operation name="getBalance">
      <input message="details">
      <output message="balance">
   </operation>
</portType>

SOAP Message

<soap:envelope>
   <soap:body>
      <getBalance>
         <name xsi:type="xsd:string">hill</x>
         <id xsi:type="xsd:float">1284</y>
      </getBalance>
   </soap:body>
</soap:envelope>

Important Notes

* WSDL message consist of one or more type declarations. They can be simple or complex types.

* SOAP body’s root element is the operation name. This is helpful for dispatcher mechanisms.

* Type information are present in the as they are present in SOAP encoding specification. This information most of the times an overhead but can become useful when the types have to be determined polymorphically.

* Not WS-I complaint. So not much used now.

RPC/literal

WSDL Message

Same as RPC/encoded style.

SOAP Message

<soap:envelope>
   <soap:body>
      <getBalance>
         <name>hill</x>
         <id>1284</y>
      </getBalance>
   </soap:body>
</soap:envelope>

Important Notes
* Type encoding is not present in the SOAP body.

* RPC/literal is WS-I complaint.

* As RPC/encoded this style also has the disadvantage that the SOAP body cannot be validated entirely on a schema since the root element (operation name) assumes a knowledge about the WSDL although elements under the root are derived from a schema.

Document/encoded

WSDL Message

<types>
   <schema>
      <element name="nameELement" type="xsd:string"/>
      <element name="idElement" type="xsd:int"/>
      <element name="balanceElement" type="xsd:int">
   </schema>
</types>

<message name="details">
<part name="name" element="nameElement">
<part name="id" element="idElement">
</message>

<message name="balance">
<part name="balance" element="balanceElement">
</message>
<portType name="myPT">
   <operation name="getBalance">
      <input message="details">
      <output message="balance">
   </operation>
</portType>

SOAP Message

<soap:envelope>
   <soap:body>
      <nameElement xsi:type="xsd:string">hill</nameElement>
      <idElement xsi:type="xsd:int">1284</idElement>
   </soap:body>
</soap:envelope>

Important Notes

* Not WS-I complaint. Not used at all.

Document/literal

WSDL Message

Same as Document/encoded.

SOAP Message

<soap:envelope>
   <soap:body>
      <nameElement>hill</nameElement>
      <idElement>1284</idElement>
   </soap:body>
</soap:envelope>

Important Notes

* No type coding information present.

* XML validation of SOAP body can be done.

* Operation name is lost making it harder for dispatchers.

* This specific WSDL is not WS-I compliant since SOAP body can only contain one child as per WS-I. This specific SOAP message contains two children. Had the message contained one part this would become WS-I complaint.

Document/literal wrapped

WSDL Message

<types>
   <schema>
        <element name="getBalance">
          <complexType>
              <sequence>
                     <element name="nameElement" type="xsd:string"/>
                     <element name="idElement" type="xsd:int"/>
             </sequence>
         </complexType>
       </element>

       <element name="balanceElement" type="xsd:int">
   </schema>
</types>

<message name="details">
<part name="name" element="getBalance">
</message>

<message name="balance">
<part name="balance" element="balanceElement">
</message>
<portType name="myPT">
   <operation name="getBalance">
      <input message="details">
      <output message="balance">
   </operation>
</portType>

SOAP Message

<soap:envelope>
   <soap:body>
      <getBalance>
         <nameElement>hill</nameElement>
         <idElement>1284</idElement>
      </getBalance>
   </soap:body>
</soap:envelope>

Important Notes

* The SOAP body looks more less the same as the RPC/literal SOAP body format. The idea here is to insert the operation name lost in other Document styles using a single message part name similarly to the operation name. While this make the SOAP conformant with WS-I basic profile rule that a message can only contain one element part, it also solves the issue of missing operation data making it easier to dispatch for SOAP nodes. This is not a standard rule per se, but more or less a norm to get the best of both RPC and Document styles.

* This usage also reflects the fact that the style employed does not necessarily convey the type of programming model used. Here the Document style is used in a similar setup like RPC since at the end of the day SOAP body conveys exactly the same information that RPC style does. (operation parameters wrapped inside the operation name element) In this setup it is up to the nodes to identify the fact that root element name is similar to that of the operation name and use this information appropriately when SOAP generation and dispatching whereas in RPC style this is implicitly implied. But however looking at the SOAP body it is not possible to conclude the style employed since nodes communicating with Document style messages can agree upon to format SOAP messages that of similar to RPC style which is the case with Document/literal wrapped style.
BPEL Data Manipulation

How does this knowledge about WSDL binding styles has any bearing on data manipulation within a BPEL process? In a BPEL process every piece of data is represented using XML. XPath is typically used in traversing XML data. Since BPEL process itself is exposed as a web service it’s WSDL binding style determines how the XML data coming in to and from the process is to be formatted. This make it necessary to have a knowledge about the binding styles since required XPath queries change according to the binding styles. Since WS-I basic profile only allows RPC/literal and Document/literal styles only data manipulation scenarios with respect to those two styles will be discussed.

One of the key constructs used in BPEL data manipulation is assign.A copy element within the assign activity specifies the source and target of the assignment (what to copy from and to), which must be of compatible types. The formal syntax as shown in the Business Process Execution Language for Web Services Specification is as follows:

standard-elements
+
from-spec
to-spec

Both from-spec and to-spec can contain variable, part and query attributes corresponding to variable name, wsdl part and query within the part as follows.

The discussion below will focus how the corresponding queries should be built according to the given WSDL styles.

RPC style

WSDL Message

<types>
   <schema>
      <complexType name="DetailType">
        <sequence>
           <element name="name" type="xsd:string"/>
           <element name="id" type="xsd:int"/>
       </sequence>
     </complexType>
   </schema>
</types>

<message name="details">
<part name="detail" type="DetailType">
</message>

RPC style BPEL File

<variable name="input"
          messageType="tns:details"/>
...
<assign>
   <copy>
      <from>hill</from>
      <to variable="input" part="detail" query="/detail/name"/>
   </copy>
</assign>

Document Style

WSDL Message

<types>
   <schema>
      <element name="DetailElement">
         <complexType>
           <sequence>
              <element name="name" type="xsd:string"/>
              <element name="id" type="xsd:int"/>
           </sequence>
         </complexType>
     </element>
  </schema>
</types>

<message name="details">
<part name="detail" element="DetailElement">
</message>

Document Style BPEL file

<variable name="input"
          messageType="tns:details"/>
...
<assign>
   <copy>
      <from>hill</from>
      <to variable="input" part="detail" query="/DetailElement/name"/>
   </copy>
</assign>

* For an RPC-style message, the top-level element (and therefore the first node in an XPath query string) is the part name (deail in this example). In document-style, the top-level node is the element name (for example, DetailElement)

Read Full Post »