Hi On Fri, Jun 1, 2012 at 5:25 PM, Samisa Abeysinghe <[email protected]> wrote:
> Are we shipping this for C4 release? > No. We were discussing about the subject as an intern project. But we do not see a perfect solution. We believe the current state of the JSStub is much more convenient for all cases. however it is not as easy as the old stub for simple cases like in MS. We would like to know if there are any possible/better ways to improve this. Regards, /Nuwan > > On Fri, Jun 1, 2012 at 3:40 PM, Ruchira Wageesha <[email protected]> wrote: > >> Hi All, >> >> We are in the process of refactoring the SOAP web service JavaScript >> stub. Before going through that, I need to highlight few stuff and come up >> with a proper decision/architecture about the JS stub. >> >> Old Stub of MS >> ============= >> Old stub was mainly writted thinking about services in MS and it >> generated methods for each operation in a service. This was absolutely >> simple to consume services in Mashup Server as MS didn't allow to write a >> service with complex schemas. i.e. In MS, we have only strings, numbers, >> dates etc. and anytype elements only. >> >> Following is a set of JS service method signatures that we can write in >> MS and relavent JS stub method signatures of them. >> >> *scenario1* - every parameter is a string >> >> Operation signature : function saveUser(username, birthday, >> addressLine1, addressLine2, city, country) >> Stub method signature : function saveUser(username, birthday, >> addressLine1, addressLine2, city, country) >> >> *scenario2* - address parameter is anytype and rest are strings >> >> Operation signature : function saveUser(username, birthday, address) >> Stub method signature : function saveUser(username, birthday, address) >> >> Here address is an anytype and we don't have any schema over that in the >> WSDL. i.e. We had to document about the address schema. >> <address> >> <addressLine1/> >> <addressLine2/> >> <city/> >> <country/> >> </address> >> >> *scenario3* - userInfo is an anytype >> >> Operation signature : function saveUser(userInfo) >> Stub method signature : function saveUser(userInfo) >> >> Here userInfo is an anytype and WSDL contain nothing about it. i.e. We >> had to document about userInfo schema. >> <userInfo> >> <username/> >> <birthday/> >> <address> >> <addressLine1/> >> <addressLine2/> >> <city/> >> <country/> >> </address> >> </userInfo> >> >> But when it comes to non-MS services, *scenario3* would be the common >> case and with the old stub, it won't do much as we have to manually >> contruct the userInfo payload string and pass it to the method. >> >> >> The current stub >> ============= >> >> op = operations["saveUser"]; >> op(userInfo); >> >> A Modified version of the old stub, which allows you to pass either the >> payload XML(as in the case of old stub) or payload JSON in Badgerfish >> notation. This doesn't matter how complex the payload is. >> >> Only practical use of this stub is in it's Badgerfish mode. i.e. There is >> a method to get a sample BF JSON of the payload. Then, user only need to >> replace the relevant values of the BF JSON. After that, BF JSON will be >> converted back to an XML string using a util function and send to the >> endpoint. >> >> Further, instead of generating top level JS methods as in the old stub, >> those functions are accessed using operation name from the operations >> object. The reason behind that is, we can't have exact same WS operation >> name as the JS method name. i.e. "-" are valid in WS operation names, but >> invalid for JS variable names. >> >> >> When the we consider a Java stub, it makes easier to consume the WS. But, >> in JS case, we need to carefuly design the JS stub. i.e. As JavaScript is a >> dynamically typed langague, we don't have much choices. >> >> In Java stub, it might generate a UserInfo bean, Address bean etc. But in >> JS case, we won't need to have seperate objects as we can pass whole >> UserInfo element as a JSON. Again mapping a JSON to a highly styped schema >> is very difficult and we will have to find a way to preserve original >> details of the XML payload such as namespaces, sequences etc. >> >> So without addressing those issues, JS stubs will be useless. I am not >> sure whether there will be a perfect solution. But sometimes, we might have >> the old stub for simple services such as MS, and none for services with >> complex schemas. >> >> Anyway, we need to come up with a proper design/decision. >> >> _______________________________________________ >> Dev mailing list >> [email protected] >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> >> Thanks, > Samisa... > > Samisa Abeysinghe > VP Engineering > WSO2 Inc. > http://wso2.com > http://wso2.org > > > > _______________________________________________ > Dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- *Thanks & Regards, Nuwan Bandara Associate Technical Lead & Member, MC, Development Technologies WSO2 Inc. - lean . enterprise . middleware | http://wso2.com blog : http://nuwanbando.com; email: [email protected]; phone: +94 11 763 9629 * <http://www.nuwanbando.com/>
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
