Engwar

Just uploaded WSF/Perl 1.1 to CPAN. Doesn’t show up there yet but will be available within a few hours. This has many things added since the last release (which was ages ago). You could now do WS-ReliableMessaging, WS-Security, WS-SecurityPolicy. The release became ridiculously late due to couple of bugs which took me REALLY LONG to debug and fix. Ouch. Download and give it a shot. It’ll take couple of seconds to compile. If you’re in a generous mood I recommend contributing to a good cause in those few seconds.

This release again has only support only on the client side, if you’re looking forward to write/host services with WSF/Perl you still have to wait a bit more. Dinesh and Danushka has done some excellent progress on that front and will be finishing it soon. If you wanna know how it’s taking shape, then by all means.

SOAP headers are used to convey additional control information that complements the information in the payload. For example WS-Security is one such thing that use SOAP headers to say how integrity and confidentiality should be achieved. Apart from the specs that define standard SOAP headers you could also define your own custom headers which could then be processed as you wish from your application. Let’s see how we can generate custom SOAP headers using WSF/Perl. You’ll need to get the SVN head revision of WSF/Perl in order to get this working (as of this writing).

First, let’s see an example from “Processing XML with Java” (Amazon page) also available online here. I’m using the SOAP header example to show you how to generate the exact thing.

<Payment xmlns="http://namespaces.cafeconleche.org/xmljava/ch2/">
    <Name>Elliotte Harold</Name>
    <Issuer>VISA</Issuer>
    <Number>5125456787651230</Number>
    <Expires>2005-12</Expires>
</Payment>

Here’s how you can generate the above headers using WSF/Perl,

my $name = new WSO2::WSF::WSHeader( 
    {'name' => 'Name', 'data' => 'Elliotte Harold' } );
 
my $issuer = new WSO2::WSF::WSHeader( 
    {'name' => 'Issuer', 'data' => 'VISA' } );
 
my $number = new WSO2::WSF::WSHeader( 
    {'name' => 'Number', 'data' => '5125456787651230' } );
 
my $expires = new WSO2::WSF::WSHeader( 
    {'name' => 'Expires', 'data' => '2005-12' } );
 
my $payment = new WSO2::WSF::WSHeader( 
    {'name' => 'Payment',
      'ns' => 'http://namespaces.cafeconleche.org/xmljava/ch2/',
      'data' => [$name, $issuer, $number, $expires] } );
 
my $client = new WSO2::WSF::WSClient( 
    {...,
     'inputHeaders' => [$payment] } );

In the next example it shows the header with the mustUnderstand attribute set, this is how you set it,

my $client = new WSO2::WSF::WSClient( 
    {...,
     'mustUnderstand' => 'true',
     'inputHeaders' => [$payment] } );

Next, I’ll take an example from a developerWorks article that shows you how to manipulate SOAP headers in WebSphere. Consider the following header contents (Listing 4 in the article)

<MyPrefix:CallingApplication xmlns:MyPrefix="http://SOAPHeaderDemonstration">
    <name>ServiceRequester1</name>
    <version>1.0</version>
    <timeRequestMade>13:20:00</timeRequestMade>
</MyPrefix:CallingApplication>

The main difference in this is that it contains a custom prefix for the element CallingApplication. Here’s the WSF/Perl code to generate this header,

my $name = new WSO2::WSF::WSHeader( 
    {'name' => 'name', 'data' => 'ServiceRequester1' } );
 
my $version = new WSO2::WSF::WSHeader( 
    {'name' => 'version', 'data' => '1.0' } );
 
my $timereq = new WSO2::WSF::WSHeader( 
    {'name' => 'timeRequestMade', 'data' => '13:20:00' } );
 
my $capp = new WSO2::WSF::WSHeader( 
    {'name' => 'CallingApplication', 'ns' => 'http://SOAPHeaderDemonstration',
     'nsprefix' => 'MyPrefix',
     'data' => [$name, $version, $timereq] } );
 
my $client = new WSO2::WSF::WSClient( 
    {...,
     'inputHeaders' => [$capp] } );

As you saw in the examples, WSHeader class facilitate creating custom SOAP headers with WSF/Perl.

Besides having the ability to provide a high level and a more developer friendly API, making a scripting language binding to an existing C library could make the testing of the library a less painful process. Initially I was under the impression that exposing low level C functions to the scripting language will make it flexible so that you could build a high level module in that scripting language encapsulating those low level functions. True. But the big downside when you have, say, 3 different language bindings for your C library all exposing low level functions is, a) you need to spend a lot of time writing the module in the respective scripting language b) too much overhead when it comes to debugging. If you find a subtle bug which you have overlooked in the Ruby binding, now you need to change the same thing on your Python and Perl bindings as well.

This was a real issue that we came across developing the Ruby and Perl bindings for the WSF/C framework. Also having the Python binding in sight. We use SWIG to generate language bindings. Having learned the price you have to pay exposing the lowest level functions, I’m gonna look into refactoring the existing code limiting the stuff that’s exposed to the scripting language to a minimum. So, code that goes into the module which need to be written in the respective scripting language is very small.

At the end of the day it’s about making you feel sooo comfortable when you program in your favourite scripting language, exposing your services with the doublew ess death star goodness with a few lines which will call the C library for maximum performance which will then give the result back to your favourite scripting language scripting language. It’s a deadly game out there Yes, you can breathe now.