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.
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?
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.
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.
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).
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
