On Sep 7, 2006, at 9:32 AM, Raymond Feng wrote:
2) Identify parameters that are required to be transformed?
From the wiring fabrics, the databinding interceptor receives an
Object[] as the input and produce an Object as the output. We
need to figure out which parameter needs to be transformed.
The message payload is actually Object as input and Object as
output. In a invoke from Java the input Object starts out as an
Object[] but that may change as the message flows through the
wire; conversely a binding may start off with the input Object as
an Object (e.g. the OMElement at the root of the message) that
needs to be converted to a Object[] for invoking a Java component.
Who owns the knowledge about what data structure (Object[] or
something else) is for the payload? Should the ServiceContract
provide this metadata? I don't think databindings give us the clue.
I think so - this will be part of the datatype definition (physically
its a Object[], logically it is an array of Classes.
There are two issues here:
a) The logical type should be the XSD type QName which is not the
same as the element QName. Should we capture the element QName(s)
in the DataType metadata or define a new model such as Parameter?
b) For doc-lit wrapped WSDL operations, we only have the top-level
wrapper element name by introspecting the WSDL portType/operation.
Without loading the XML schema, we cannot figure out all the first-
level child elements which are mapped into java parameters.
AIUI this is converting between a single object (the wrapper element)
and a collection of objects (the parameters) and vice versa. I think
previously we did this purely based on child ordering - can we do the
same now?
3) Assemble the transformed Object[] into a protocol-specific
message
I assume it's the responsiblity of the binding builders to
assemble the Object[] into a protocol-specific message and vice
versa. For example, the Axis2 web service binding builder will
take the Object [] with complex types represented as OMElement(s)
and create the OM- based SOAPEnvelope. It will also has to take
care of wrapping/ unwrapping for dcument-literal wrapped WSDL
operations.
I think the conversion between Object[] (from Java) to single
OMElement (for doc-lit wsdl) would be handled by a transform
rather than the binding.
So are we looking for two types of transformations here?
a) ServiceContract-based payload structure transformation (for
example, Object[] --> OMElement)
b) Data type transformation (for example, SDOCustomer -->
JAXBCustomer)
Yes although I would not expect them to be treated differently in the
pipeline.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
