Wednesday, January 23, 2008

Where to set your options?.. in WSClient or in WSMessage?

If you are familiar with WSF/PHP web service API, you may find that you can set your options in different level. For an example in order to set the endpoint you can either use the WSClient constructor like this,

new WSClient("to" => "endpoint",
"other_options" => .. );

or you can use the WSMesasge constructor

new WSMessage("to" => "endpoint",
"other_options" => .. );

It may seems quite unnecessary to have duplicate methods to set something like "endpoint". But there are cases this is really helpful in your application.

If you ever tried calling two web service operations from one WSClient object, you may have already found the importance of having this way.

In such a case you can set the common options in the WSClient and operation specific options in the WSMessage.

Most probably you will use the same WSClient to invoke different operation in a service. There your service endpoint is the same for all the operation. So you can set the service endpoint and additionally some other common configurations like the soap version in the WSClient constructor.

new WSClient("to" => "common_endpoint",
"useSOAP" => 1.1 );

After that you can concentrate on message specific options. One would be "action" which is different from message to message. In addition to that common case, say you have some set of operations which need authentication and others don't need. For that you have to use user-name tokens for that particular set of operations. What you can do is setting that security policy and the security token only to that request messages.

$client->request(new WSMessage( $payload,
array("action" => "",
"securityToken" => $securityToken,
"policy" => $policy)));

So I think it is clear the flexibility provided by the duplicate methods of doing the same thing. It make your code more organized and most importantly more efficient.

No comments: