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 <[email protected]>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 <[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 >> >> > > > -- > Sanjiva Weerawarana, Ph.D. > Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/ > email: [email protected]; 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: [email protected], blog: ruchirawageesha.blogspot.com, mobile: +94 77 5493444*
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
