view release on metacpan or  search on metacpan

README  view on Meta::CPAN

for example you, you can install required modules by downloading
them and building them by hand. Another possibility is to 
configure CPAN to run as a normal user, the file CPAN_help gives
pointers on how to do this.

If you run into problems with Module::Build, which is used by
DateTime see 
http://kato.mvc.mcc.ac.uk/rss-wiki/SoftwareInstallation/ModuleBuild

You should update your CPAN shell issuing a  "install Bundle::CPAN" 
before doing anything else. People have reported error (unresolved 
version conflicts) while installing required packages 
(DateTime::Format::Epoch) with prior versions of CPAN (1.7x)



Changes from v0.3
=================

v0.3 uses the latest version of the WS-Addressing 
specification, the major change is that ResourceProperties
have been dropped from WS-Addressing. WSRF::Lite used
ResourceProperties to route messages to particular 
backend WS-Resources. The old WS-Addressing Endpoint
References (EPRs) for WSRF::Lite looked like:

<wsa:EndpointReference>
  <wsa:Address>http://vermont.mvc.mcc.ac.uk/WSRF/Counter</wsa:Address>
  <wsa:ResourceProperties>
    <mmk:ResourceID xmlns:mmk="http://www.sve.man.ac.uk/wsrf/">346435645764576456</mmk:ResourceID> 
  </wsa:ResourceProperties>
</wsa:EndpointReference>

The new version of WS-Addressing EPRs is:

<wsa:EndpointReference>
 <wsa:Address>http://vermont.mvc.mcc.ac.uk/WSRF/3464645764576456</wsa:Address> 
</wsa:EndpointReference>

So each WS-Resource will have a different value for the Address element.
This change may cause some older WSRF::Lite clients/services to break.  
Also WS-Addressing may yet still change - it has not completed the 
standardisation process. (If you have already developed services using
a previous version of WSRF::Lite it may be wise to wait for the version
of WSRF::Lite that implements the specifications when they become 
standards)

This version of WSRF::Lite also provides better support for WS-Addressing
on the client side, the client will now automatically create the proper
SOAP headers if you pass them a WS_Address object:

$ans=  WSRF::Lite
       -> uri($uri)                                              #set the namespace
       -> wsaddress(WSRF::WS_Address->new()->Address($target))   #location of service
       -> $func(@ARGV);                                    #function + args to invoke

Note the use of WSRF::Lite instead of SOAP::Lite. Instead of using
->proxy($target) we now use ->wsaddress passing it a WS_Address
object created using the endpoint of the service. This client will
automatically create the correct WS-Addressing SOAP Headers, there
is no longer any need to create a SOAP::Header object with the
WS-Addressing information. 

The WS_Address funtion 'from_envelope' takes either an WS-Addressing 
EPR encoded as XML or as a SOM object and returns a WS_Address object:

eg.

 $som = WSRF::Lite
        ->uri("http://localhost:50000/CounterFactory")
        ->wsaddress(WSRF::WS_Address->new()
                                    ->Address('http://localhost:50000/CounterFactory/'))
        ->createCounterResource();

 $wsa = WSRF::WS_Address->from_envelope($som);

 $ans = WSRF::Lite
         ->uri("http://localhost:50000/Counter")
         ->wsaddress($wsa)
         ->add('1');


This version of WSRF::Lite provides experimental support for signing
SOAP messages using x509 digital certificates according to the WS-Security
standard and WS-I Basic Security Profile. You should find two sample
client scripts ./client-scripts/sample_WS-Security_client.pl and 
./test/signature_checker.pl. The WS-Security signing has been tested
against a .NET service and a service implemented with the Sun Java Web 
Service Developer Pack (JWSDP) however more testing needs to be done (see 
TODO).

There has been some changes to the Container scripts to support command
line arguments to set the port and hostname to use.

The WSRF::Container module has been re-written to make it eashier to
add HTTP handlers - it should be easy to add a handler to support
uploading files for example.

WS-Resources hosted in the Container now support HTTP GET, if you
use GET (from the LWP Perl package) on a WS-Resource endpoint you 
get a copy of the WS-Resource's ResourceProperty document in a 
SOAP message. You can also use a HTTP DELETE to destroy a WS-Resource
eg.

  GET -m DELETE http://localhost:50000/WSRF/Counter/Counter/354634563456

(curl can also be used, there are problems with wget, see TODO)

WSRF::Lite v0.4 implements the latest version of the WSRF specifications,
these add the following operations: GetResourcePropertyDocument (gets
the ResoureProperty document, effectively all the Resource Properties,
of the WS-Resource, UpdateResourceProperty (updates a WS-Resource),
InsertResourceProperty (insert a property into the WS-Resource) and 
DeleteResourceProeprty (delete a property from a WS-Resource). The last
three operations are effectively a breaking down of the functionality of
the SetResourceProperty operation - which is of course still available.

The WS specifications versions implemented are:
WS-Addressing - 
http://www.w3.org/TR/2005/WD-ws-addr-core-20050331/