Yes but that's the limitation we need to fix! Its not too hard .. its recursive application of the same rules :).
On Mon, Jun 11, 2012 at 9:04 AM, Ruchira Wageesha <ruch...@wso2.com> wrote: > In the old model, it generates functions like [1] for operations. But when > it is a service with complex types, most probably function signature would > be [2]. In [2] userInfo is the whole soap body and we need to construct it > manually. No help from the stub for soap body creation. > > [1] function saveUser(username, birthday, addressLine1, addressLine2, > city, country) > [2] function saveUser(userInfo) > > On Sun, Jun 10, 2012 at 10:48 AM, Sanjiva Weerawarana <sanj...@wso2.com>wrote: > >> Why do we need to re-invent a solution .. can the JAX-WS style binding >> model not work? What we had was a similar model in the old mashup server. >> >> W.r.t. complex schemas- I don't understand why the old model doesn't >> support complex types. Note that I'm talking about the model not the XSLT >> based implementation. >> >> Sanjiva >> >> 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 >>> >>> >> >> >> -- >> Sanjiva Weerawarana, Ph.D. >> Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/ >> email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1 >> 650 265 8311 >> blog: http://sanjiva.weerawarana.org/ >> >> Lean . Enterprise . Middleware >> > > > > -- > *Ruchira Wageesha > Senior Software Engineer & Member, Management Committee, Development > Technologies* > *WSO2 Inc. - lean . enterprise . middleware | wso2.com* > * > email: ruch...@wso2.com, blog: ruchirawageesha.blogspot.com, mobile: +94 > 77 5493444* > > -- Sanjiva Weerawarana, Ph.D. Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/ email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1 650 265 8311 blog: http://sanjiva.weerawarana.org/ Lean . Enterprise . Middleware
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
