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.

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.

    Elliotte Harold
    VISA
    5125456787651230
    2005-12

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)

    ServiceRequester1
    1.0
    13:20:00

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.

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.

Indeed, WS-* appears to be yet another ivory tower going up in a place no sane native would want to live. The village of the web is already plenty strong to withstand the distraction. Complex lights, flickering buzzwords, and long roadmaps to nowhere notwithstanding.

That’s DHH himself on the issue of WS-* in Rails. More than a year ago. Upon the release of Rails 2.0 quoting InfoWorld article,

REST is favored over SOAP now because those in the agile development camp feel it has become too complex, with its many WS-* standards to follow, said Hansson. Spoken as “ws star,” Hansson instead denigrated the WS-* specifications by referring to them as “ws death star.”

But what if you need doublew ess death star for your application? What if you need WS-Addressing or WS-Security? Start writing your application in Java?? You don’t have to. WSF/Ruby is a Ruby language bindings for a C framework that provides doublew ess death star stuff. WSF/C which gives you the death star goodness in C language now has a Ruby binding which allows your Rails apps to take full advantage of this deadly situation. Look you don’t have to die coding in Java which gather a lot of bad karma, you can now do it with Ruby and die

On a bit more serious note, WSF/Ruby, aimed at Rails apps will allow you to do WS-Addressing, WS-Security, WS-SecurityPolicy, WS-ReliableMessaging with some other goodies. Read the whole feature set.

While the merits of having or not having WS-* in Rails can be argued for both sides, with the current situation you’re more likely to look for another framework/language if you need it. Now the initial efforts to make the situation better is out. There are some samples bundled with the release that show how you could get them going on your apps. Try out and feel free to raise your voice in the mailing list if you need help.

One more thing, if you need commercial support for it just ask the bizdev team!