I scheduled a discussion for next week --Srinath On Fri, Jun 1, 2012 at 5:33 PM, Nuwan Bandara <nu...@wso2.com> wrote:
> Hi > > On Fri, Jun 1, 2012 at 5:25 PM, Samisa Abeysinghe <sam...@wso2.com> 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 <ruch...@wso2.com>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 >>> Dev@wso2.org >>> 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 >> Dev@wso2.org >> 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: nu...@wso2.com; phone: +94 11 763 > 9629 > * > <http://www.nuwanbando.com/> > > _______________________________________________ > Dev mailing list > Dev@wso2.org > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- ============================ Srinath Perera, Ph.D. http://www.cs.indiana.edu/~hperera/ http://srinathsview.blogspot.com/
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
