On Sun, 2006-06-25 at 12:04 +1200, Dennis Sosnoski wrote:
> Hi Anne,
>
> The discussion we've been having relates to how wrapping/unwrapping is
> handled in the code. What Sanjiva and Ajith appear to be saying is that
> each parameter element should be a separate class, while I want to use
> an approach that's closer to Axis(1) wrapped handling, where primitives
> and simple values are handled directly and only complex structures need
> class definitions.
Hmm. That's *exactly* what Anne, Ajith and I are saying too, I believe.
This is the idea: Suppose you have:
int foo (float a, Address b)
Then the doc/lit (or WSDL 2.0) description of this would have two GEDs
(using a syntax hack):
<fooRequest>
<a @type=xsd:float>
<b @type=x:Address>
</fooRequest>
<fooResponse>
<return @type=xsd:int>
</fooResponse>
Now switch sides to generating stubs and skeletons for an operation that
has these as their in's and out's respectively.
What we do now (*without unwrapping) is to generate exactly one class as
an argument:
fooReqest foo (fooResponse)
where they are beans with properties.
If we had unwrap turned on, what I'd expect to see as the signature of
the stub or the skeleton is:
int foo (float, Address)
The implementation of the stub must "wrap" these arguments into a single
OMElement and use ServiceClient underneath to send the message out. When
the response is received, it must "unwrap" the incoming element to pull
out the child of the <fooRequest> element and get the value of the child
element as an int and return that. The implementation of the message
receiver is the opposite.
To do this, all we have to do is to tell the data binding framework to
data bind all the elements one level below the top level GED
representing the "wrapped" message. Data binding *does not* have to
change. Each such child must be treated as a typed thing that must
become a certain name when serialized, not as an element itself. That's
the way to avoid XMLBeans like class proliferation.
Are you talking about the same idea or something different? If so where
do we differ in our understanding of the problem to be solved and/or the
approach?
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
