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
