You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Raymond Feng <en...@gmail.com> on 2006/09/07 08:27:54 UTC
Update on the databinding integration and open issues for discussion
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Update on the databinding integration and open issues for discussion
Posted by Jim Marino <jm...@myromatours.com>.
On Sep 7, 2006, at 9:35 AM, Raymond Feng wrote:
> I guess for now I'll focus on the remotable interfaces first to
> apply databinding transformations. Are any of you going to take the
> local interface discussion to the spec group?
>
That seems to make the most sense in terms getting things working. It
would be nice if someone other than Jeremy or myself wrote up a
proposal and presented to the spec group since it would raise the
visibility of Tuscany contributions as both of us are kind of viewed
as "spec people" instead of Tuscany people from that side of the house.
Any takers?
Jim
> Thanks,
> Raymond
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Update on the databinding integration and open issues for discussion
Posted by Raymond Feng <en...@gmail.com>.
I guess for now I'll focus on the remotable interfaces first to apply
databinding transformations. Are any of you going to take the local
interface discussion to the spec group?
Thanks,
Raymond
----- Original Message -----
From: "Jim Marino" <jm...@myromatours.com>
To: <tu...@ws.apache.org>
Sent: Thursday, September 07, 2006 7:20 AM
Subject: Re: Update on the databinding integration and open issues for
discussion
>
>>>>
>>>> I don't think i'm saying pass-by-value be the default for local
>>>> services,
>>>> what i'm asking is if operations are possible between local components
>>>> using
>>>> different data bindings, and if so then it seems more user friendly
>>>> that the
>>>> default be that it just works without having to define anything extra
>>>> to
>>>> make it work.
>>> Sure if you can do the data transformation by-value which would be
>>> really difficult to achieve with most databinding frameworks. Otherwise
>>> the wire must be by-ref and the only way to do that is when the target
>>> service contract explicitly declares its remotability. This is
>>> extremely important to be declared in the contract, as opposed to being
>>> the default, since the semantics of the data are affected and the
>>> client cannot treat it as by-ref.
>>
>> I think there are use cases where local pass-by-value makes sense. For
>> example, if the data is immutable then the framework can make a copy to
>> a different format and not break the semantic contract. Taking this
>> further, if the data is mutable but the target does not modify it then
>> we can again make a copy and still preserve the semantic.
>>
>> One way to do this would be to support something like an @ReadOnly
>> annotation that the target can declare on a parameter. In the local
>> (by-ref) case this would allow the runtime to make copies to support
>> incompatible data types; in the remote (by-value) case this would allow
>> the runtime to avoid making a copy if it didn't need to. This could also
>> be done at the type level with an @Immutable annotation on the class.
>>
> Yea this like a good solution as since it forces that decision to be
> explicit. The notion of read-only should probably be proposed to the spec
> for local services. For the remotable case, we have the "allows by-ref"
> marker. That means local service contracts must explicitly declare this,
> and it is not the default. For remotable contracts, the default would
> imply copying of params and nothing needs to be proposed I believe.
>
>> Jim makes a good point about not repeating the mistakes from earlier
>> frameworks. I think the biggest mistake that they made was to focus on
>> the "how" (as in by-ref, by-val) semantics rather than the "what"
>> (read-only, immuatable) characteristics of the interaction. I think if
>> we do that we can provide the function Ant would like.
>>
> That's why it is "allows" instead of "is" by reference ;-) Good point,
> though.
>> --
>> Jeremy
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Update on the databinding integration and open issues for discussion
Posted by Jim Marino <jm...@myromatours.com>.
>>>
>>> I don't think i'm saying pass-by-value be the default for local
>>> services,
>>> what i'm asking is if operations are possible between local
>>> components using
>>> different data bindings, and if so then it seems more user
>>> friendly that the
>>> default be that it just works without having to define anything
>>> extra to
>>> make it work.
>> Sure if you can do the data transformation by-value which would be
>> really difficult to achieve with most databinding frameworks.
>> Otherwise the wire must be by-ref and the only way to do that is
>> when the target service contract explicitly declares its
>> remotability. This is extremely important to be declared in the
>> contract, as opposed to being the default, since the semantics of
>> the data are affected and the client cannot treat it as by-ref.
>
> I think there are use cases where local pass-by-value makes sense.
> For example, if the data is immutable then the framework can make a
> copy to a different format and not break the semantic contract.
> Taking this further, if the data is mutable but the target does not
> modify it then we can again make a copy and still preserve the
> semantic.
>
> One way to do this would be to support something like an @ReadOnly
> annotation that the target can declare on a parameter. In the local
> (by-ref) case this would allow the runtime to make copies to
> support incompatible data types; in the remote (by-value) case this
> would allow the runtime to avoid making a copy if it didn't need
> to. This could also be done at the type level with an @Immutable
> annotation on the class.
>
Yea this like a good solution as since it forces that decision to be
explicit. The notion of read-only should probably be proposed to the
spec for local services. For the remotable case, we have the "allows
by-ref" marker. That means local service contracts must explicitly
declare this, and it is not the default. For remotable contracts, the
default would imply copying of params and nothing needs to be
proposed I believe.
> Jim makes a good point about not repeating the mistakes from
> earlier frameworks. I think the biggest mistake that they made was
> to focus on the "how" (as in by-ref, by-val) semantics rather than
> the "what" (read-only, immuatable) characteristics of the
> interaction. I think if we do that we can provide the function Ant
> would like.
>
That's why it is "allows" instead of "is" by reference ;-) Good
point, though.
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Update on the databinding integration and open issues for discussion
Posted by Jeremy Boynes <jb...@apache.org>.
On Sep 7, 2006, at 6:46 AM, Jim Marino wrote:
> On Sep 7, 2006, at 6:35 AM, ant elder wrote:
>> On 9/7/06, Jim Marino <jm...@myromatours.com> wrote:
>>> On Sep 7, 2006, at 2:01 AM, ant elder wrote:
>>> > On 9/7/06, Raymond Feng <en...@gmail.com> wrote:
>>> >> 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.
>>
>>
>> I don't think i'm saying pass-by-value be the default for local
>> services,
>> what i'm asking is if operations are possible between local
>> components using
>> different data bindings, and if so then it seems more user
>> friendly that the
>> default be that it just works without having to define anything
>> extra to
>> make it work.
> Sure if you can do the data transformation by-value which would be
> really difficult to achieve with most databinding frameworks.
> Otherwise the wire must be by-ref and the only way to do that is
> when the target service contract explicitly declares its
> remotability. This is extremely important to be declared in the
> contract, as opposed to being the default, since the semantics of
> the data are affected and the client cannot treat it as by-ref.
I think there are use cases where local pass-by-value makes sense.
For example, if the data is immutable then the framework can make a
copy to a different format and not break the semantic contract.
Taking this further, if the data is mutable but the target does not
modify it then we can again make a copy and still preserve the semantic.
One way to do this would be to support something like an @ReadOnly
annotation that the target can declare on a parameter. In the local
(by-ref) case this would allow the runtime to make copies to support
incompatible data types; in the remote (by-value) case this would
allow the runtime to avoid making a copy if it didn't need to. This
could also be done at the type level with an @Immutable annotation on
the class.
Jim makes a good point about not repeating the mistakes from earlier
frameworks. I think the biggest mistake that they made was to focus
on the "how" (as in by-ref, by-val) semantics rather than the
"what" (read-only, immuatable) characteristics of the interaction. I
think if we do that we can provide the function Ant would like.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Update on the databinding integration and open issues for discussion
Posted by Jim Marino <jm...@myromatours.com>.
On Sep 7, 2006, at 6:35 AM, ant elder wrote:
> On 9/7/06, Jim Marino <jm...@myromatours.com> wrote:
>>
>>
>> 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 <en...@gmail.com> 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.
>
>
> I don't think i'm saying pass-by-value be the default for local
> services,
> what i'm asking is if operations are possible between local
> components using
> different data bindings, and if so then it seems more user friendly
> that the
> default be that it just works without having to define anything
> extra to
> make it work.
Sure if you can do the data transformation by-value which would be
really difficult to achieve with most databinding frameworks.
Otherwise the wire must be by-ref and the only way to do that is when
the target service contract explicitly declares its remotability.
This is extremely important to be declared in the contract, as
opposed to being the default, since the semantics of the data are
affected and the client cannot treat it as by-ref.
Jim
>
> ...ant
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Update on the databinding integration and open issues for discussion
Posted by ant elder <an...@gmail.com>.
On 9/7/06, Jim Marino <jm...@myromatours.com> wrote:
>
>
> 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 <en...@gmail.com> 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.
I don't think i'm saying pass-by-value be the default for local services,
what i'm asking is if operations are possible between local components using
different data bindings, and if so then it seems more user friendly that the
default be that it just works without having to define anything extra to
make it work.
...ant
Re: Update on the databinding integration and open issues for discussion
Posted by Jim Marino <jm...@myromatours.com>.
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 <en...@gmail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Update on the databinding integration and open issues for discussion
Posted by ant elder <an...@gmail.com>.
Great stuff Raymond, some questions and comments inline...
...ant
On 9/7/06, Raymond Feng <en...@gmail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Update on the databinding integration and open issues for discussion
Posted by Raymond Feng <en...@gmail.com>.
Hi,
More updates on this topic.
1) I changed the Operation model to take an inputType, an outputType and a
list of faultTypes. The inputType is a special DataType with its logical
type representing the parameters. For a java method, the inputType looks
like:
databinding: "java:parameters" (for the Object[] --> Object[] conversion)
physical: "java.lang.Object[]"
logical: List<DataType<T>> (A list of DataTypes, each element in the list
representing a parameter type. The list is empty for no-arg.
2) Add speical databindings/transformers to represent the inputTypes from
different IDLs so that we can perform payload transformations. For example,
Object[] --> Object[] and Object[] --> OMElement.
3) Add "isWireable(ServiceContract source, ServiceContract target)" to the
WireService and provide an implementation in JDKWireService. Right now, I
relax the the checking on remotable operations so that only name is matched.
3) A databinding sample based on the dummy EchoBinding with the on-demand
transformation across the following two interfaces.
@DataType(name="java.lang.String")
@Remotable
public interface Interface1 {
Object call(Object msg);
Object call1(Object msg);
}
@DataType(name="org.w3c.dom.Node") // interface-level
@Remotable
public interface Interface2 {
Node call(Node msg);
@DataType(name="javax.xml.stream.XMLStreamReader") // operation-level
XMLStreamReader call1(XMLStreamReader msg);
}
And here's the result:
ComponentA --> Received message: <foo>123</foo> [java.lang.String]
ComponentB --> Received message: [#document: null]
[org.apache.xerces.dom.DeferredDocumentImpl]
ComponentB --> Returned message: [#document: null]
[org.apache.xerces.dom.DeferredDocumentImpl]
ComponentA --> Returned message: <?xml version="1.0"
encoding="UTF-16"?><foo>123</foo> [java.lang.String]
ComponentA --> Received message: <foo>123</foo> [java.lang.String]
ComponentB --> Received message:
org.apache.axiom.om.impl.llom.OMStAXWrapper@1520152
[org.apache.axiom.om.impl.llom.OMStAXWrapper]
ComponentB --> Returned message:
org.apache.axiom.om.impl.llom.OMStAXWrapper@1520152
[org.apache.axiom.om.impl.llom.OMStAXWrapper]
ComponentA --> Returned message: <foo>123</foo> [java.lang.String]
Accidentally, I verified the two-hop transformations from XMLString -->
AXIOM --> XMLStreamReader and the reverse because I forgot to register the
direct transformers. :-)
4) Several issues that are worked around
1. I have to add "addInterceptor(int index, Interceptor interceptor)" method
to the InvocationChain so that I can add the DataBinding interceptor before
the TargetInvokerInterceptor.
2. There's no component init dependency accross composites. In my case, some
transformers from databinding-axiom have dependencies on
databinding-framework which is still an extension at this moment. I have to
add the "databinding.scdl" to the "test" to make it part of the "core".
I think I'm ready to check in the changes so that other folks can help if
there's no objections.
Thanks,
Raymond
----- Original Message -----
From: "Jeremy Boynes" <jb...@apache.org>
To: <tu...@ws.apache.org>
Sent: Thursday, September 07, 2006 11:47 AM
Subject: Re: Update on the databinding integration and open issues for
discussion
> On Sep 7, 2006, at 11:26 AM, Raymond Feng wrote:
>> I propose that we change the Operation model as follows:
>>
>> Operation
>> --- name (Name of the operation)
>> --- inputType (For java, it's a DataType representing the Object [].
>> For WSDL, it could be a DataType representing the top-level request
>> element using Axiom or other databindings)
>> --- outputType (For java, it's a DataType representing the
>> returnType. For WSDL, it could be a DataType representing the top- level
>> response element using Axiom or other databindings)
>> --- faultTypes (A list of DataTypes representing the faults/
>> exceptions)
>
> OK
>
>> DataType
>> --- databinding
>> --- phsicalType
>> --- logicalType
>> --- properties (A list of DataProperty(s) for the DataType to
>> represent the visible children)
>
> Why properties? For example, a Java argument list does not have named
> parameters (in the source yes but not in the public contract).
> Can we just use:
> physicaltype: Object[].class
> logicalType: Class[]{Customer.class, String.class}
> and
> physicalType: OMElement.class
> logicalType: QName{http://example.com, order}
>
>>
>> DataProperty
>> --- name (QName of the property)
>> --- type (DataType for the property)
>
> QName only makes sense for XML - what would that be in the Java case?
>
>> For the DataType/DataProperty recursion, we don't have to go too deep.
>> For example, we may only require a list of properties for the DataType
>> for the inputType.
>
> There's something fishy here if the properties only apply in certain use
> cases.
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Update on the databinding integration and open issues for discussion
Posted by Jeremy Boynes <jb...@apache.org>.
On Sep 7, 2006, at 12:10 PM, Raymond Feng wrote:
>> and
>> physicalType: OMElement.class
>> logicalType: QName{http://example.com, order}
>>
>
> When we try to populate the OMElement for "order" with Customer and
> String, we have to create child OMElements under "order" and the
> child elements requires QNames. Where can we get the corresponding
> child element QNames? Axiom doesn't provide access to the XSD model
> and we cannot look them up by the order QName.
This seems like a problem with Axiom :-) Well not really, just the
issue that you need access to the XML schema and it's not providing it.
I'm thinking here that the logicalType is actually an element QName
as it is an instance not a type. We are trying to generate the XML
<order>
<customer>
<string>
and need to know the "order" element name as well as its sub-elements.
IOW the Axiom databinding needs to know the schema involved. That is
an issue with Axiom (and DOM and other things without a built-in type
system) rather than XML itself. For example, for SDO we could have
physicalType: DataObject.class
logicalType: Type{Order.class} or Type{QName{http://example.com,
order}}
> And for WSDL, do we only support single-part messages? If not, the
> inputType for WSDL could be Object[] as well.
I'm not sure how WSDL applies here. I can see that for a multi-part
message (but all XML and not multi-part mime (attachments) :-) ) you
could have:
physicalType: OMElement[].class
logicalType: QName[]{ QName{example:order}, QName{xs:string} }
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Update on the databinding integration and open issues for discussion
Posted by Raymond Feng <en...@gmail.com>.
----- Original Message -----
From: "Jeremy Boynes" <jb...@apache.org>
To: <tu...@ws.apache.org>
Sent: Thursday, September 07, 2006 11:47 AM
Subject: Re: Update on the databinding integration and open issues for
discussion
> On Sep 7, 2006, at 11:26 AM, Raymond Feng wrote:
>> I propose that we change the Operation model as follows:
>>
>> Operation
>> --- name (Name of the operation)
>> --- inputType (For java, it's a DataType representing the Object [].
>> For WSDL, it could be a DataType representing the top-level request
>> element using Axiom or other databindings)
>> --- outputType (For java, it's a DataType representing the
>> returnType. For WSDL, it could be a DataType representing the top- level
>> response element using Axiom or other databindings)
>> --- faultTypes (A list of DataTypes representing the faults/
>> exceptions)
>
> OK
>
>> DataType
>> --- databinding
>> --- phsicalType
>> --- logicalType
>> --- properties (A list of DataProperty(s) for the DataType to
>> represent the visible children)
>
> Why properties? For example, a Java argument list does not have named
> parameters (in the source yes but not in the public contract).
> Can we just use:
> physicaltype: Object[].class
> logicalType: Class[]{Customer.class, String.class}
It works for java.
> and
> physicalType: OMElement.class
> logicalType: QName{http://example.com, order}
>
When we try to populate the OMElement for "order" with Customer and String,
we have to create child OMElements under "order" and the child elements
requires QNames. Where can we get the corresponding child element QNames?
Axiom doesn't provide access to the XSD model and we cannot look them up by
the order QName.
And for WSDL, do we only support single-part messages? If not, the inputType
for WSDL could be Object[] as well.
>>
>> DataProperty
>> --- name (QName of the property)
>> --- type (DataType for the property)
>
> QName only makes sense for XML - what would that be in the Java case?
I was thinking of either dummy names such as {java:interfaceName#methodName,
argX} or null.
>
>> For the DataType/DataProperty recursion, we don't have to go too deep.
>> For example, we may only require a list of properties for the DataType
>> for the inputType.
>
> There's something fishy here if the properties only apply in certain use
> cases.
I agree it's not ideal but it seems to be the gap among IDLs.
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Update on the databinding integration and open issues for discussion
Posted by Jeremy Boynes <jb...@apache.org>.
On Sep 7, 2006, at 11:26 AM, Raymond Feng wrote:
> I propose that we change the Operation model as follows:
>
> Operation
> --- name (Name of the operation)
> --- inputType (For java, it's a DataType representing the Object
> []. For WSDL, it could be a DataType representing the top-level
> request element using Axiom or other databindings)
> --- outputType (For java, it's a DataType representing the
> returnType. For WSDL, it could be a DataType representing the top-
> level response element using Axiom or other databindings)
> --- faultTypes (A list of DataTypes representing the faults/
> exceptions)
OK
> DataType
> --- databinding
> --- phsicalType
> --- logicalType
> --- properties (A list of DataProperty(s) for the DataType to
> represent the visible children)
Why properties? For example, a Java argument list does not have named
parameters (in the source yes but not in the public contract).
Can we just use:
physicaltype: Object[].class
logicalType: Class[]{Customer.class, String.class}
and
physicalType: OMElement.class
logicalType: QName{http://example.com, order}
>
> DataProperty
> --- name (QName of the property)
> --- type (DataType for the property)
QName only makes sense for XML - what would that be in the Java case?
> For the DataType/DataProperty recursion, we don't have to go too
> deep. For example, we may only require a list of properties for the
> DataType for the inputType.
There's something fishy here if the properties only apply in certain
use cases.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Update on the databinding integration and open issues for discussion
Posted by Raymond Feng <en...@gmail.com>.
More comments inline.
Thanks,
Raymond
----- Original Message -----
From: "Jeremy Boynes" <jb...@apache.org>
To: <tu...@ws.apache.org>
Sent: Thursday, September 07, 2006 10:13 AM
Subject: Re: Update on the databinding integration and open issues for
discussion
> On Sep 7, 2006, at 9:32 AM, 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.
>
> I think so - this will be part of the datatype definition (physically its
> a Object[], logically it is an array of Classes.
I propose that we change the Operation model as follows:
Operation
--- name (Name of the operation)
--- inputType (For java, it's a DataType representing the Object[]. For
WSDL, it could be a DataType representing the top-level request element
using Axiom or other databindings)
--- outputType (For java, it's a DataType representing the returnType.
For WSDL, it could be a DataType representing the top-level response element
using Axiom or other databindings)
--- faultTypes (A list of DataTypes representing the faults/exceptions)
DataType
--- databinding
--- phsicalType
--- logicalType
--- properties (A list of DataProperty(s) for the DataType to represent
the visible children)
DataProperty
--- name (QName of the property)
--- type (DataType for the property)
For the DataType/DataProperty recursion, we don't have to go too deep. For
example, we may only require a list of properties for the DataType for the
inputType.
>
>>
>> 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.
>
> AIUI this is converting between a single object (the wrapper element) and
> a collection of objects (the parameters) and vice versa. I think
> previously we did this purely based on child ordering - can we do the
> same now?
>
>>>>
>>>> 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)
>
> Yes although I would not expect them to be treated differently in the
> pipeline.
With my proposal, we should be able to unify the two, i.e., transform the
payload as DataTypes for the inputType/outputType.
> --
> Jeremy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Update on the databinding integration and open issues for discussion
Posted by Jeremy Boynes <jb...@apache.org>.
On Sep 7, 2006, at 9:32 AM, 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.
I think so - this will be part of the datatype definition (physically
its a Object[], logically it is an array of Classes.
>
> 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.
AIUI this is converting between a single object (the wrapper element)
and a collection of objects (the parameters) and vice versa. I think
previously we did this purely based on child ordering - can we do the
same now?
>>>
>>> 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)
Yes although I would not expect them to be treated differently in the
pipeline.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Update on the databinding integration and open issues for discussion
Posted by Raymond Feng <en...@gmail.com>.
Thank you all for the repsonses.
Please see my comments/questions inline.
Raymond
----- Original Message -----
From: "Jeremy Boynes" <jb...@apache.org>
To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Update on the databinding integration and open issues for discussion
Posted by Jeremy Boynes <jb...@apache.org>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org