More comments inline.
Thanks,
Raymond
----- Original Message -----
From: "Jeremy Boynes" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Thursday, September 07, 2006 10:13 AM
Subject: Re: Update on the databinding integration and open issues for
discussion
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.
I propose that we change the Operation model as follows:
Operation
--- name (Name of the operation)
--- inputType (For java, it's a DataType representing the Object[]. For
WSDL, it could be a DataType representing the top-level request element
using Axiom or other databindings)
--- outputType (For java, it's a DataType representing the returnType.
For WSDL, it could be a DataType representing the top-level response element
using Axiom or other databindings)
--- faultTypes (A list of DataTypes representing the faults/exceptions)
DataType
--- databinding
--- phsicalType
--- logicalType
--- properties (A list of DataProperty(s) for the DataType to represent
the visible children)
DataProperty
--- name (QName of the property)
--- type (DataType for the property)
For the DataType/DataProperty recursion, we don't have to go too deep. For
example, we may only require a list of properties for the DataType for the
inputType.
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.
With my proposal, we should be able to unify the two, i.e., transform the
payload as DataTypes for the inputType/outputType.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
