Hi,
I finally got the first sample (String<-->DOM) up and running with the
databinding framework integrated with the core with some workarounds/hacks.
The following is a list of issues and assumptions during the process. I
would like to get your opinions so that we can finalize the integration
story as soon as possible.
1) Define compatiblity of two service contracts that can be wired together
and applicability of databinding transformations.
* For local operations that require pass-by-reference semantics, databinding
transformation cannot be applied because the source data and transformed
result can run out of sync. If the two operations require different
databindings, they are treated as incompatble.
* For remoteable operations, should we consider the following operation peer
compatible assuming we can map SDOCustomer to JAXBCustomer and JAXBAddress
to SDOAddress?
Source Operation: SDOAddress getAddress(SDOCustomer customer);
Target Operation: JAXBAddress getAddress(JAXBCustomer customer);
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.
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}.
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.
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.
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)
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.
A related question: I'm seeing the TargetInvoker is set to a Reference's
inbound wire. Should it be set on the outbound wire instead?
Sorry for the long text.
Thanks,
Raymond
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
