Great stuff Raymond, some questions and comments inline...
...ant
On 9/7/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
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.
This is a bit sad. Couldn't there be some way to say pass-by-value is ok,
something like the opposite of the @AllowsPassByReference annotation (and
consider having this the default)?
* 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);
IMO yes.
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.
Isn't this the question that already came up about should different
databindings be mixed on the same interface? With the below example the
target is expecting AXIOM so most of the time would likely expect the String
parameter to also be AXIOM
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.
I'd say yes as an OMElement using QNames that don't match the WSDL schema
doesn't seem so useful :)
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.
From the POV of a binding writer it would be much easier if the data binding
framework handled wrapping/unwrapping. What are the reasons the databinding
framework can't do this?
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.
For these other cases does this still work when using
interface.wsdleverywhere? I know there was that thread about SCDL
extensions for the data
binding, did that reach a conclusion, could you show an example of what the
SCDL would look like?
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]
