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
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
