SOAP in/out variables bring memories of C-style buffers
 |
By Scott Balmos [posted by Jack Vaughan] About a month ago I happened to be playing around with some parts of SOAP I hadn’t really gotten into much. At the time, I tried out in/out variables. Support for in/out variables, at the time I looked, was still somewhat iffy. And it occurred to me that the idea of in/out variables seemed to go against traditional object->method() type OO programming that most SOAP implementations seem to embody. In a way, it reminded me a lot of the original type of OO in pure C, where buffer references were passed around in parameters. |
Personally, I can’t think of a situation right now where I would actively use in/out variables. I’d be more inclined to stick with the SOAP ideology of a “message document transfer”, and simply create a slightly more complex response message (which, in turn, would translate to a response data type class that has one or two more fields to it).
This would seem to be easier on the brain than documenting that various return types could possibly have data changed in them upon return. Look at JAX-WS as it is, for instance. Instead of calling a SOAP endpoint with data types, you’d potentially have to use the Holder class, access that Holder’s properties to get to the data, etc etc etc. Is that really so much simpler than simply creating another field in the response complexElement? Okay, again, maybe so for those people writing in pure C, who are more than used to this form of object passing. But as it currently stands, Java and .Net are the two main drivers for SOAP usage.
And their programming paradigms are of the Smalltalk message-passing OO style, not the hybrid style where parameter values are different after a method call than they were beforehand.
One possibility is if some enterprising DB vendor decided to meld XML data return from the DB engine along with stored procedures that use in/out-type parameters along with a simple SOAP stack in the DB engine.
Then SOAP could be used to initiate those stored procedures, bypassing SQL altogether (for better or worse).
I’d be interested to hear back how you’ve used in/out SOAP variables in your projects so far, if you’ve used them at all. “Remember, I’m pullin’ for ya… We’re all in this together.”
January 16th, 2007 at 6:50 pm
When I deal with SOAP/XML and WS stuff i always use Axis or Castor. So I don’t have to deal with the SOAP stuff, after setting it up. And it usually works great.
January 22nd, 2007 at 11:15 am
I have implemented a SOAP service long time ago in Delphi using msxml and http. And what i did use is to use some technique to pass result of one action as parameters to other following action in the same request. So I could create 2 objects and link them in the same request. That was very powerfull but I m not sure you are talking about this.
January 22nd, 2007 at 11:17 am
Per,
Haven’t you tried Axis2(http://ws.apache.org/axis2) or WSO2 WSAS(http://www.wso2.org)? They are much better compared to Axis, and contain better functionality.
–Jeff
January 22nd, 2007 at 12:18 pm
I have been writing in python and I miss the possibility to return tuples in Java (as you can do in pyhton).
That is “(x,y) = f()”
Of course you can define your own “return of f class” but the smoothness of simply define which variables the return value should be mapped to is a lot easier.
Perhaps the Java team can be convinced to add this “syntactic suger” into Java. Any one else that would like that?
January 22nd, 2007 at 12:47 pm
I’m not sure what you mean about Java not using in/out type parameters. Its pretty common for a calling method to pass in an object whose state is used and modified by a called method. Perhaps what you mean is that JAX-WS has not addressed in/out parameters to make them viable?
January 22nd, 2007 at 12:57 pm
I have done SOAP, home grown XML-RPC and WS etc. for a while now and I totally agree that there is probably no need to use the in/out param types with newer languages.
However, I see a reason why they are in there, The whole approach in WFC is that you have this interface contract which has to work irrespective of the transport/protocol used for the RPC which suggests that for completeness they may have had to add the support for in/out params as it is a valid method definition construct and one that is extensively used in COM. Up until now SOAP or rather all XML based RPC dictated how you could define the methods or rather classes without a proper interface definition, albeit, this changed in WFC which allows interfaces. One of my peeve pain points is not being able to use the data currency types already defined within a business layer model that go in as params to the WebService. Workarounds available include replacing the using/or imports of the relevant namespaces for the data type of params but these require additional work. Ideally I’d rather see support for reuse of existing classes or option to do so as needed. I have found SOAP-WS more useful for inter-application RPC mechanism in a distruibuted application development rather than an application developed using a 3rd party WS through UDDI for which generated data types seem appropriate.