On Sep 7, 2006, at 2:01 AM, ant elder wrote:
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)?
We should not have pass-by-value as the default for wires between
local services since local services are the default type within a
composite mandated by the SCA spec. The notion of local services as
the default service type was put into the SCA spec to avoid the
mistake made with technologies such as early EJB where everything was
remote. Data transformations should only occur when the target
service contract is remotable. If a target service is remotable,
allows pass-by-ref, and a data transform is required, the resulting
wire will be by-val.
* 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
