Good morning,
When working with webservices in Java, there's a tool called WSDL2Java which creates objects from complexType based on the definition found in the WSDL file.
Unless I missed something, if the same WSDL is parsed with $DLC/bin/bprowsdldoc, complexTypes are mapped to longchars (containing XML) and have to be parsed manually.
Given the addition of OOABL in v10, is there something provided with OpenEdge to automatically create a class structure from a WSDL ?
And if it's not included in OpenEdge, does anybody have code to share ?
And if this kind of thing doesn't exist yet, I assume I'd have to do it myself. In this case, would someone be interested in working on that (code, test, documentation, ...) ?
Gilles
Hi Gilles,
the best that can happen to you right now, would be a mapping to a ProDataset, not an OOABL class. The bprowsdldoc tools would actually have to generate the source code for that holder class (that's what's happening in the Visual Studio when importing a web services reference).
So you need to build that on your own. Maybe my OOABL serialization talk from Exchange 2007 (http://communities.progress.com/pcom/docs/DOC-15816) helps as a starting point.
Mike
Yes, mapping to a PDS is another option. I was thinking of objects because I'm in the middle of Java code...
Main question is if I have to work with the result, would I prefer working with PDS or with objects ?
As for myself, I'd prefer working with PDS, but that's mainly because my experience with OOABL is really limited.
Thanks for the link, I'll read that.
Recall that in the current state of the AppServer, proxies are limited to being procedures, not classes.
What I'm trying to achieve is consuming a webservice from Progress, and getting PDS or objects instead of XML streams.
Not to publish existing ABL PDS/objects as webservices.
That's where serialization may help consuming the LONGCHAR and populating an object instance and vice versa.
But it requires a lot of manual work since there is no reflection API that would allow to do this dynamically.
I checked out Axis repository from SVN, and tried to figure out how it was done.
Applied to ABL, this would mean creating static PDS or objects interface and implementation, and then a bunch of procedures/methods to fill TT/attributes.
No reflection involved in Java, as objects structure is known (based on WSDL definition). So there wouldn't be any need for reflection in ABL, and it could mean working with static PDS, so a lot more easier than working with dynamic PDS.
They're describing in the WSDL2Java class how to write a custom emitter, so I'll have at this when I'll have some spare time.
At Axis there's a process that generates holder classes - much like the Visual Studio does. That's why in my initial comment I mentioned, that the bprowsdldoc would have to generate those holder classes. You may do so manually as well (actually as long as bprowsdldoc does not do so, you have to).
The holder classes are just a more simple way of dealing with the objects defined in the interface in your actual business logic (or interface logic depending on how you layer it) than the original XML stream would be.
But never the less you need a process that imports the XML (LONGCHAR) into the holder classes (creating an new instance for input parameters) and serializes an output object back to XML. That process would either require reflection to have dynamic access to properties or you need to generate that code as well. If I remember AXIS right, this code has not been generated. So I assume some sort of a dynamic/generic XML serialization and that must be based on reflection.
For the ABL you'll end up with generating this code as well.
That's why we have to have this discussion :-)
But never the less you need a process that imports the XML (LONGCHAR) into the holder classes (creating an new instance for input parameters) and serializes an output object back to XML. That process would either require reflection to have dynamic access to properties or you need to generate that code as well. If I remember AXIS right, this code has not been generated. So I assume some sort of a dynamic/generic XML serialization and that must be based on reflection.For the ABL you'll end up with generating this code as well.
Axis generates classes as well as an interface containing every method export in the WSDL, and a class with static methods implementing this interface.
So, with Axis, calling a webservice is just instantiating this class, calling a static method, and get the return value either as a primitive type or a class (generated in the first step).
As the classes for complexTypes are known at runtime, it's "just" a matter of XPath to say that the value to be assigned to a field should be taken from a specific XPath attribute or node value. Putting just within quotes, as it's not so simple, given the 'verboseness' of SOAP and response types.
To my mind, no reflection, in the sense that XPath values and attributes to be filled are known during the WSDL parsing. But yes, a generic XML serialization should be made available in parent class.
Once we got overridable constructors, it was common for me to define a class with three constructors. One with no arguments for instantiating it empty, one with a whole series of arguments for instantiation from database fields, and one with a single longchar argument for instantiation from XML.