Thank you all for the repsonses.
Please see my comments/questions inline.
Raymond
----- Original Message -----
From: "Jeremy Boynes" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Thursday, September 07, 2006 6:52 AM
Subject: Re: Update on the databinding integration and open issues for
discussion
Thanks Raymond - comments inline, quite a bit snipped though.
On Sep 6, 2006, at 11:27 PM, 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.
Here is the algorithm I have so far:
For each parameter, if it's an instance of the source databinding (by
introspection of the parameter value/class, if the databinding metadata
is not supplied at the parameter level), transform it to the target
databinding, otherwise leave it as is.
For example, with the operation signature:
Address getBillingAddress(Customer customer, String str);
Source databinding: SDO (assuming Address and Customer are generated SDO
classes)
Target databinding: AXIOM
The incoming payload is Object[] {Customer, String} and the transformed
request will be a new Object[] {OMElement, String}.
As above, the transformed input might also be a single OMElement with {
customer, str } as children.
A related question: For the the parameters/return value/faults, should
we capture the QNames if the service contract is from a WSDL portType?
Doing that we help me produce a meanlingful OMElement.
For a service contract defined by WSDL then I would have expected the
logical type to be the XML QName for the param/return/fault - would that
suffice?
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.
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)
4) Apply databinding interceptors to different wiring scenarios
There are 4 legal wires between SCA artifacts:
component.reference --> component.service
component.reference --> composite.reference
composite.service --> component.service
composite.service --> composite.reference
a) component reference: outbound wire only (to component.service or
composite.reference)
b) component service: inbound wire only (from component.reference or
composite.service)
c) composite reference: inbound (from component.reference or
composite.service) & outbound (to binding)
d) composite service: inbound (from binding) & outbound (to
component.service or composite.reference)
Not sure what you mean here - all wires can have callbacks and so may
have both inbound and outbound chains.
Can we make callbacks to composite.service? Or only component.reference?
For case c) and d), I assume that the binding builder will tell the
runtime its preferred databinding (for example, AXIOM for references and
services with Axis2 binding).
For other cases, the source/target databindings are provided by the
service contracts.
I think the builder (binding or component) should declare to the runtime
what it's preferred databinding is and what other ones it can handle. In
the connect phase we would add in the necessary transformations to match
up the representations from the source and target. This is part of
determining if the source and target interfaces are compatible (i.e.
operations must match and the data must be convertable between them).
Where should these information go, Service and Reference?
--
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]