Dimuthu’s Blog

WSO2 WSF/PHP comes with a comprehensive set of test cases. It covers the most of the basic/concrete scenarios supported by WSF/PHP. You can find these test cases inside the “src/tests” directory of WSF/PHP source package. Or you can find the latest test-suite from the SVN location.

Here are some aspects covered in the test-suit.

(Note that Here ‘*’ is used as a wild card represent 0 or many characters)

Steps to Run Tests

• First you need to install WSF/PHP correctly. Please read the WSF/PHP installation manual for that.
• You have to have the ‘pear’ utility tool comes with PHP. And add this to the PATH environment variable.
• Copy the samples and src/tests/samples/services directory (paths are relative to the root directory of the wsf/php package) to the web root directory.
• Then go to the src/tests directory and execute the following command.

  pear run-tests -r

  This will execute all the test cases under the ‘tests’ directory and finally give a summery of the test results.

• You can run individual test cases separately by providing the relative path to the test case from the ‘test’ directory. E.g. To run the echo_client.phpt test case, you may type

  pear run-tests samples/echo_client.phpt

If you like to add test cases for the WSF/PHP scenarios, follow this comprehensive guideline titled Writing Simple phpt Test Scripts For PHP Web Services.

WSDL Caching is first introduced with the WSF/PHP 2.0.0 release to optimize the response time of PHP web services. In WSDL Caching WSF/PHP keeps an intermediate XML model which is generated from the WSDL in memory. This intermediate model which we call as ‘SIG’ or ‘Signature’ model is generated at the first request to the service. This SIG can be generated using an XSLT template from any WSDL 2.0. So if you provide a WSDL version 1.1, WSF/PHP first convert it to a WSDL 2.0 using another XSLT template and then generate the SIG model. So in generally when WSDL caching is used it avoids two XSLT parses and hence optimize the response time significantly.

In this blog, I will show you a result of some performance tests I did to measure the response time of a service with and without WSDL Caching.

The complete source codes used for the test can be found from here.

Here is a part of the service script I used. It is a simple echo service that echo a string.

	// create service in WSDL mode
	$service = new WSService(array ("wsdl" =>"echo.wsdl",
			"cacheWSDL" => false, // By default cache WSDL is true
			"actions" => $actions,
			"operations" => $operations));

	// getting the start_time
	$start_time = microtime(true);

	// process client requests and reply 
	$service->reply();

	// getting the end time
	$end_time = microtime(true);

	// getting the time difference
	$time_diff = $end_time - $start_time;

	logme($time_diff);

You can see in there I have set the “cacheWSDL” to false and log the time taken by the $service->reply() function. Later I have set the “cacheWSDL” to true and measure the time again for the comparison with earlier values.

I have written a client to invoke the service 10 times. And I’m going to measure the time taken do the client request in there.

	    for($i = 1; $i <= 10; $i ++) {
		// create client in WSDL mode
		$client = new WSClient(array ("wsdl" =>"echo.wsdl"));

		// get proxy object reference form client 
		$proxy = $client->getProxy();

		// create input object and set values
		//TODO: fill $input with (data type: string) data to match your business logic
		$input = "Hello World";

		// getting the start_time
		$start_time = microtime(true);

		// call the operation
		$response = $proxy->myEcho($input);
		//TODO: Implement business logic to consume $response, which is of type string

		// getting the end time
		$end_time = microtime(true);

		// getting the time difference
		$time_diff = $end_time - $start_time;

		logme($time_diff);

		echo $response."</br>";

	    }

Then I have measured the time taken to first 10 request for both WSDL caching on and off scenarios just after starting the Apache server.

If you obvious these values you will figure out when you don’t use WSDL caching it takes same amount of time to server each request. But when you turn on WSDL caching it takes a little more time at the very first request, but the subsequent requests take very low values.

Here is the chart for the above Data, See the Green and White lines corresponding to the WSDL caching turn on, have taken low values. In average we can observe a 50% reduction in server response time with the WSDL caching.

Response Time With and Without WSDL Caching

This result is for a very simple WSDL which only had an echo operation. When the WSDL get more complex and contain lot of wsdl/schema includes and imports, we can expect more optimization due to the WSDL caching. We will check how the complexity of the WSDL affect the performance in a later blog post.:)

In XML Schema we declare an array or a multiple occurrence of a schema element by setting its maxOccurs attribute to a value greater than 1 or to the value “unbounded” in a case of no maximum boundary.

<xs:element maxOccurs="unbounded"
            minOccurs="0"
            name="params"
            nillable="true"
            type="xs:int"/>

If you generate PHP code to such a schema using wsdl2php tool, you will get a code for the class variable named “params” similar to this.

    /**
     * @var array[0, unbounded] of int
     */
    public $params;

So if you have a variable (say $object) for the object of this class you can fill the “params” field like this,

$object->params = array(1, 5, 8);

This will create the xml with the expected array of elements.

<wrapper>
    <params>1</params>
    <params>5</params>
    <params>8</params>
</wrapper>

Not only for simple types, you can have arrays of complex types too.

<xs:element maxOccurs="unbounded"
            minOccurs="0"
            name="params"
            nillable="true"
            type="tns:MyComplexType"/>

Instead of giving simple integers like earlier case, this time you will feed the “params” variable with an array of PHP objects of ‘MyComplexType’ class.

$obj1 = new MyComplexType();
/* feeding data to obj1 variables */

$obj2 = new MyComplexType();
/* feeding data to obj2 variables */

$obj3 = new MyComplexType();
/* feeding data to obj3 variables */

$object->params = array($obj1, $obj2, $obj3);

This will create a xml containing array of params similar to this,

<wrapper>
    <params>
        <elementx/> <!-- elements in the MyComplexType type -->
        <elementy/>
    </params>
    <params>
        ... <!-- elements in the MyComplexType type -->
    </params>
    <params>
        ... <!-- elements in the MyComplexType type -->
    </params>
</wrapper>

WSF/PHP Demo Site contains number of applications that demonstrate the different features of WSO2 WSF/PHP in practice. Calendar Service is one of such application. It demonstrate the use of WSDL Mode for a service with different policies for different operations + the use of Username tokens.

You can view the source code of the Calendar Service from here.

The username token is provided as an arguments to the WSService constructor at the end of the service script.

// our security token
$security_token = new WSSecurityToken(array("passwordCallback" => "get_password",
                                      "passwordType" => "plain"));
// create service in WSDL mode
$service = new WSService(array ("wsdl" =>"Calendar.wsdl",
        "actions" => $actions,
        "classmap" => $class_map,
        "securityToken" => $security_token,
        "operations" => $operations));

// process client requests and reply 
$service->reply();

We use a callback function (“get_password”) to validate the user and give that function name to the securityToken object constructor. Inside that callback function, we retrieve the password for the user from a database call. Here is the code inside the callback function that is again extracted out from the calendar service.

/**
 * call back function.
 * verify the validity of user enterd password with
 * the actual password which is kept in the database.
 */
$current_username = "";
function get_password($username)
{

    $dbhost = DB_HOST;
    $dbname = DB_NAME;
    $dbuname = DB_USERNAME;
    $dbpass = DB_PASSWORD;
    $link=mysql_connect($dbhost,  $dbuname,  $dbpass);
    mysql_select_db($dbname, $link);

    $sql="SELECT password FROM `customer_details` WHERE `user_name` = '".$username."'";
    $result=mysql_query($sql,$link);
    $password=mysql_fetch_array($result, MYSQL_NUM);

    global $current_username;
    if($password) {
         $current_username = $username;
         return $password[0];
    }
    else {
         $current_username = "";
         return NULL;
    }
}

So for all the operations which require authentication like login, getEvents, deleteEvents and addEvent, the WSF/PHP engine validate the user before invoking the operation. If the authentication fails, the engine will send a SOAP fault with the fault details. But in this service there is a operation which doesn’t require authentication. That is the ‘register’ operation. Because until the registration complete you can’t have a username password, so we should not authenticate that ‘register’ operation. So we need to provide a different policy for the ‘register’ operation.

The policies for each of the operation is declared in the Calender.wsdl itself.  If you look at the WSDL you can see each of the policies required by the operations are declared inside the policy elements as mentioned in WS-Policy Specification. And each of the operation refers the corresponding policy element from the binding section of the WSDL.

You can see how it is done for login (which requires authentication) and the register (which doesn’t requires authentication) from the code below.

        <wsdl:operation name="login">
            <soap12:operation soapAction="urn:login" style="document"/>
            <wsdl:input>
                <wsp:PolicyReference URI="#username_token_policy"/>
                <soap12:body use="literal"/>
            </wsdl:input>
            <wsdl:output>
                <soap12:body use="literal"/>
            </wsdl:output>
        </wsdl:operation>
        <wsdl:operation name="register">
            <soap12:operation soapAction="urn:register" style="document"/>
            <wsdl:input>
                <soap12:body use="literal"/>
            </wsdl:input>
            <wsdl:output>
                <soap12:body use="literal"/>
            </wsdl:output>
        </wsdl:operation>

In WSF/PHP WDL Mode we have two APIs, first one is the class based API which we give a class object as the input parameter for the operation and expect to retrieve a class object as the response as well. The other API is the array based API. which we give an array (in fact an associated map) containing all the necessary information and returns an array filled with response information.

If you are using WSDL2PHP script you are always using the class based API. But there are situations where you can easily use array based API instead of the class based API. Here is an example.

Take the simple add operation of the following WSDL, http://labs.wso2.org/wsf/php/example.xml.

If you generated the code using wsdlphp tool (Here is the complete generated code for the above wsdl using online wsdlphp tool) You can see two classes are generated for the above operation, one for the input object and the other for the output object.

class simpleAdd {

    /**
     * @var int
     */
    public $param0;

    /**
     * @var int
     */
    public $param1;

}

class simpleAddResponse {

    /**
     * @var int
     */
    public $return;

}

So in order to invoke the service you need to create an object of the simpleAdd and set your input parameters and return the value from the simpleAddResponse object.

  $input = new simpleAdd();

  $input->param0 = 3;
  $input->parma1 = 4;

  // call the operation
  $response = $proxy->simpleAdd($input);

  // extract the return value
  echo $response->return;

But if you are using array mode for the same operation it will be something like this.

  // input as an array
  $input = array("param0" => 3, "param1" => 4);

  // call the operation
  $response = $proxy->simpleAdd($input);

  // extract out the return value from the array
  echo $response["return"];

In this approach you don’t need to declare classes at the start. So you can write the code without the support of WSDL2PHP tool. Anyway for complex scenarios it is not easy to find the keys needed to be in the input array, so it is better depend on the generated code. But you can use array based approach more productively for simple scenarios like this.

WSO2 WSF/Ruby is back in a release, after more than 6 months. We released the WSF/Ruby 1.0.0 in this January (with the start of the year work) with a number of features that someone may expect in a WS-* stack. For Ruby space there were no such thing support that many number of WS-* specs, specially implementation for WS-Security, WS-SecurityPoilcy, MTOM were really new for ruby developers.

For this release (1.1.0), we mainly worked for improving the usability aspects of the WSF/Ruby. The result is the WSDL mode for both client and the server, and more importantly with this you can specify WS-Addressing and WS-SecurityPolicy assertions through a WSDL.

Here is the complete release note. Hope you ruby people try this out, enjoy and more importantly give us some valuable feedback..

WSO2 Web Services Framework For Ruby (WSF/Ruby) – 1.1.0 Released
=============================================

WSO2 WSF/Ruby team is pleased to announce the release of WSO2 WSF/Ruby 1.1.0.

WSF/Ruby is the Ruby language extension to WSO2 WSF/C. This enables you to consume/provide Web Services both with REST and with the power of WS-* stack including WS-Reliable Messaging, WS-Security, WS-Addressing and MTOM Attachments.

For more information, please visit our project home page, http://wso2.org/projects/wsf/ruby

You can download this release from: http://wso2.org/downloads/wsf/ruby

Key Features
============
1. Client API to consume Web services

* WSMessage class to handle message level options
* WSClient class with both one way and two way service invocation support

2. Service API to provide Web services

* WSMessage class to handle message level options
* WSService class with support for both one way and two way operations

3. Attachments with MTOM

* Binary optimized
* Non-optimized (Base64 encoded)

4. WS-Addressing

* Version 1.0
* Submission

5. WS-Security
* UsernameToken and Timestamp
* Encryption
* Signing
* WS-SecurityPolicy based configuration

6. WS-Reliable Messaging
* Single channel two way reliable messaging

7. WSDL mode support for both client and server side
* WS-Addressing and WS-SecurityPolicy is supported in WSDL mode

8. REST Support
* Expose a single service script both as SOAP and REST service

Major Changes Since Last Release
================================
o WSDL mode support for both client and server side
* WS-Addressing and WS-SecurityPolicy is supported in WSDL mode

Dependencies
============
1. The provider implementation uses Rails framework as the deployment model. Therefore in order to use provider implementation, you should have Rails installed on your machine. Please visit http://www.rubyonrails.org/ to find out more about RoR(Ruby on Rails).

Reporting Problems
==================
Issues can be reported using the public JIRA available at: https://wso2.org/jira/browse/WSFRUBY

Contact Us
==========
Please subscribe to our user or developer mailing lists. For details on how to subscribe please visit: http://wso2.org/mail#wsfruby

Thank you for your interest in WSO2 WSF/Ruby.

- WSO2 WSF/Ruby Team