hi,

What I got to know when talking to jaggery team was, with WSStub also we
need to manually create the payload (xml string) or set the input
parameters by giving the parameter names and values to the JSON (as in the
example above) which does not differ much from what we do with WSRequest.

true.

Me too did not feel much difference using WSStub over WSRequest. So what we
need to know is whether the stub design will be changed in near future and
whether it is OK to go with WSRequest for the moment?
Current WSStub in jaggery is needed payload. It do not support parameters
so it is not 100% perfect. WSStub will be improved for this feature in near
future.
There wan't be API level change for WSStub. It will be a just improvement.
If you wish to follow WSStub you can follow it. WSRequest in jaggery works
perfect and it will remain as it. If you was following WSRequest so far you
can follow it with out any problem.


WSStub design will be changed in near future?
WSStub will need improvement for passing parameters so WSStub can be
changed in back end implementation. But those changes will not change
jaggery API.

Thank you.


On Tue, Jun 5, 2012 at 3:03 PM, Ashansa Perera <[email protected]> wrote:

> Hi,
> In appfactory we are using jaggery to call our webservices/bpels. We were
> using the WSRequest for this purpose before, but after jaggery introduces
> the WSStub we thought of moving to stub. The reason we wanted to move from
> WSRequest to stub was that we had to manually create the payload when using
> WSRequest. But what I saw was even when using WSStub we need to mannually
> add parameters etc.
> With WSRequest we used
>         var ws = require('ws');
>         var request = new ws.WSRequest();
>         var options = new Array();
>         options.useSOAP = 1.1;
>         options.action = "urn:process";
>                 var payload = '<p:CreateApplicationRequest xmlns:p="
> http://wso2.org";><applicationName 
> xmlns="http://wso2.org";>'+applicationName+'</applicationName><userName
> xmlns="http://wso2.org
> ">'+userName+'</userName></p:CreateApplicationRequest>';
>                 request.open(options, endPoint, false);
>         request.send(payload);
>
> As we got to know this is how we have to create the payload for WSStub
>         var ws = require('ws');
>         var stub = new ws.WSStub(endpoint);
>         var getVersion =
> stub.services['CreateApplication'].operations['process'];
>         var payload = getVersion.payloadJSON();
>         payload["p:CreateApplicationRequest"].applicationName .$ =
> "userInput";
>         payload["p:CreateApplicationRequest"].userName .$ = "userInput";
>         getVersion.request(payload);
>
> What I got to know when talking to jaggery team was, with WSStub also we
> need to manually create the payload (xml string) or set the input
> parameters by giving the parameter names and values to the JSON (as in the
> example above) which does not differ much from what we do with WSRequest.
> The suggestion of the jaggery team was to go with WSRequest for the moment
> coz the current stub is not giving much support over WSRequest and what
> they mentioned was that the stub will be improved to ease the job and so
> for the moment it is better to go with WSRequest without changing to stub.
> Me too did not feel much difference using WSStub over WSRequest. So what
> we need to know is whether the stub design will be changed in near future
> and whether it is OK to go with WSRequest for the moment?
>
> Please point me if there are any significant advantages of using the
> current stub over WSRequest and could someone please state whether the
> WSStub design will be changed in near future?
>
> --
> Thanks & Regards,
>
> Ashansa Perera
> Software Engineer
> WSO2, Inc
>
>
> _______________________________________________
> Dev mailing list
> [email protected]
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
*Madhuka* Udantha
http://madhukaudantha.blogspot.com/
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to