Hi Raymond,
I doubt there is a need to mix different data bindings for a same interface.
Can someone name a valid use case, for example, different operations are using
different data bindings? If we can safely assume one interface is always
implemented by one specific data binding, things can be simplified greatly. For
example, we wont end of with a very complex scdl as you mentioned before:
<interface.wsdl ...>
...
<tuscany:databinding
xmlns:tuscany="http://tuscany.apache.org/xmlns/1.0-SNAPSHOT"; dataType="sdo">
<!-- default to sdo for the portType -->
<operation name="getCreditReport" dataType="sdo"> <!-- default to
sdo for the operation -->
<!-- more fine control -->
<input>
<part index="0">
<dataType name="sdo"
xmlType="{http://customer}Customer"/>
</part>
</input>
.....
A simple configuration e.g. a property to specify which data binding
(jaxb/sdo/xmlbeans etc) is used should be enough.
Also to answer Jeremy's question raise before: "I believe Celtix uses WSDL
extensions for this i.e. annotations added
to the WSDL or possibly the underlying XMLSchema to indicate the data binding
to use. ". This is not true. Celtix1.0 only supports jaxb, CeltixFire( the
apache project that is a merge between Celtix and XFire) will support multiple
data bindings, but I don't think there will be any thing related to data
bindings being added into wsdl or xmlschema. It is configured by a
configuration somewhere. This follows the same principle used by SCA: as long
as the two interface types are equivalent, they can talk to each other without
knowing what the underlying data binding is, which means the interface
definition should not be polluted by data bindings.
Cheers,
Jervis
> -----Original Message-----
> From: Raymond Feng [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 29, 2006 12:25 AM
> To: [email protected]
> Subject: Re: SCDL extensions to define data types for parameters and
> return value
>
>
> Hi,
>
> When we use WSDL as an IDL in a java runtime, we probably
> have assumed some
> data mapping rules because WSDL usually uses XML schema to
> define the data
> types. To provide/consume data in java for a WSDL operation,
> we have to use
> an XML info model such as DOM, AXIOM, SDO, and JAXB.
>
> The SCA spec defines some rules for the java<-->WSDL mapping
> as quoted
> below:
>
> "1.3.4.4 Mapping of Java Interfaces to & from WSDL Interfaces
>
> A Wire can connect between interfaces defined by different
> languages ie.
> Java interfaces and
> WSDL portTypes/WSDL interfaces in either direction, as long as the
> operations defined by the
> two interface types are equivalent. They are equivalent if
> the operation(s),
> parameter(s), return
> value(s) and faults/exceptions map to each other.
>
> SCA maps Java interfaces to and from WSDL interfaces using
> the mapping
> defined by the JAXWS
> specification [4], with the following differences:
> . Complex parameters and return values in WSDL operations
> may be mapped
> as SDOs, using the mapping defined in the SDO 2.0 specification [2]
> . Holder classes are not supported"
>
> Based on this, I think we should at least support JAXB and
> SDO databindings
> for the WSDL. It's not very clear in the spec which
> databinding is the
> default. Maybe we can introspect the value to figure out
> which one is in
> use.
>
> For the granularity, it seems to me that we use the same
> databinding for
> the whole interface in most cases. But we can support operation and
> parameter levels if required. I guess we need to modify the
> ServiceContract/Operation model to capture the default
> databinding at its
> own level.
>
> Thanks,
> Raymond
>
> ----- Original Message -----
> From: "ant elder" <[EMAIL PROTECTED]>
> To: <[email protected]>
> Sent: Friday, August 25, 2006 2:44 AM
> Subject: Re: SCDL extensions to define data types for
> parameters and return
> value
>
>
> > What I'm trying to see is the minimum needed to get
> assemblies going with
> > different data bindings. One difference with using WSDL
> portTypes is that
> > you can't use introspection or annotations so all the
> config needs to be
> > done in the SCDL. I'm also wondering about the config for
> the source and
> > target ends of the wires which is why the example i asked
> about earlier
> > had
> > a service wired to a component wired to a reference. Could
> you use that
> > example and show what is the minimum necessary to get it
> working with the
> > new data binding framework?
> >
> > ...ant
> >
> > On 8/25/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
> >>
> >> Hi,
> >>
> >> I don't see much difference to define DataTypes for WSDL
> portTypes than
> >> java
> >> interfaces.
> >>
> >> If we look at the WSDL structure, we can define default
> DataType for a
> >> portType, an operation or a part.
> >>
> >> portType
> >> operation
> >> input: message
> >> part
> >> output: message
> >> part
> >> fault: message
> >> part
> >>
> >> Usually, the part is typed by XSD. So it makes sense to
> have the DataType
> >> such as SDO, JAXB, and XmlBeans.
> >>
> >> An example may look like (for illustration only):
> >>
> >> <interface.wsdl ...>
> >> ...
> >> <tuscany:databinding
> >> xmlns:tuscany="http://tuscany.apache.org/xmlns/1.0-SNAPSHOT";
> >> dataType="sdo">
> >> <!-- default to sdo for the portType -->
> >> <operation name="getCreditReport" dataType="sdo">
> <!-- default to
> >> sdo for the operation -->
> >> <!-- more fine control -->
> >> <input>
> >> <part index="0">
> >> <dataType name="sdo"
> >> xmlType="{http://customer}Customer"/>
> >> </part>
> >> </input>
> >> <output>
> >> <part index="0">
> >> <dataType name="sdo"
> >> xmlType="{http://credit}CreditReport"; javaClass="...'/>
> >> </part>
> >> </output>
> >> </operation>
> >> </tuscany:databinding>
> >> </interface.wsdl>
> >>
> >>
> >> Thanks,
> >> Raymond
> >>
> >> ----- Original Message -----
> >> From: "ant elder" <[EMAIL PROTECTED]>
> >> To: <[email protected]>
> >> Sent: Thursday, August 24, 2006 1:39 AM
> >> Subject: Re: SCDL extensions to define data types for
> parameters and
> >> return
> >> value
> >>
> >>
> >> > What about when you're using interface.wsdl and things
> like JavaScript?
> >> > Take
> >> > the following composite example, could you show what the
> additional
> >> > SCDL
> >> > extension would be needed to get that to work with SDO and E4X?
> >> >
> >> > <composite ...>
> >> >
> >> > <service name="MyHelloWorldWebService" ...>
> >> > <interface.wsdl.../>
> >> > <binding.ws.../>
> >> > <reference>HelloWorldComponent</reference>
> >> > </service>
> >> >
> >> > <component name="HelloWorldComponent">
> >> > <js:implementation.js script="HelloWorld.js"/>
> >> > <references>
> >> > <reference
> >> name="helloWorldService">HelloWorldService</reference>
> >> > </references>
> >> > </component>
> >> >
> >> > <reference name="HelloWorldService">
> >> > <interface.wsdl..."/>
> >> > <binding.ws.../>
> >> > </reference>
> >> >
> >> > </composite>
> >> >
> >> > Thanks,
> >> >
> >> > ...ant
> >> >
> >> > On 8/23/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> I think we have several use cases here:
> >> >>
> >> >> Case 1: Invoking a web service using a SCA reference with Axis2
> >> >> binding
> >> >>
> >> >> <composite ...>
> >> >> <reference name="creditReport">
> >> >> <interface.java interface="sample.CreditReportService"/>
> >> >> </reference>
> >> >> ...
> >> >> </composite>
> >> >>
> >> >> Source DataType is controlled by the application (it
> can be either
> >> >> decorated
> >> >> by SCDL extensions or introspected from the value. For
> example, the
> >> >> Customer
> >> >> can be a SDO or JAXB object). I see the requirement
> that the DataType
> >> be
> >> >> specified at parameter/return value level for a given
> operation. I'm
> >> not
> >> >> sure at which level where the default databinding should be set,
> >> >> interface,
> >> >> or composite?
> >> >>
> >> >> Target DataType is controlled by the binding. Axis2
> WebService binding
> >> >> uses
> >> >> AXIOM. We need a way for the binding builder to tell
> Tuscany runtime
> >> the
> >> >> DataTypes it can support for references and services.
> >> >>
> >> >> Case 2: SCA service with web service binding delegates
> the invocation
> >> to
> >> >> a
> >> >> POJO component
> >> >>
> >> >> <composite ...>
> >> >> <service name="creditReportService">
> >> >> <interface.java interface="sample.CreditReportService"/>
> >> >> <reference>CreditReportComponent</reference>
> >> >> </service>
> >> >> <component name="CreditReportComponent">
> >> >> <implementation.java
> class="sample.CreditReportServiceImpl"/>
> >> >> ...
> >> >> </composite>
> >> >>
> >> >> In this case, the Axis2 binding gets AXIOM data and
> it's now ready to
> >> >> invoke
> >> >> the target POJO component.
> >> >>
> >> >> Source DataType will be AXIOM.
> >> >>
> >> >> Target DataType will be controlled by the POJO component
> >> >> implementation
> >> >> which can choose to use SDO, JAXB, or OMElement to receive the
> >> >> parameters.
> >> >> The metadata can be extracted from SCDL, java annotations or
> >> >> introspection.
> >> >>
> >> >> Case 3: One component invokes another component in the
> same composite
> >> >>
> >> >> Both source DataType and target DataType are controlled by the
> >> >> application.
> >> >> With the databinding, do we want to extend the concept
> of compatible
> >> >> interfaces? For example, the "component1.reference1" is wired to
> >> >> "component2.service1". "component1.reference1" is typed
> by interface
> >> >> CreditReportService1 while component2.service1 by
> >> >> CreditReportService2.
> >> >> We
> >> >> assume that CustomerSDO can be transformed to
> CustomerJAXB, same for
> >> >> CreditReportJAXB to CreditReportSDO.
> >> >>
> >> >> public interface CreditReportService1 {
> >> >> public CreditReportSDO getCreditReport(CustomerSDO
> customer);
> >> >> }
> >> >>
> >> >> public interface CreditReportService2 {
> >> >> public CreditReportJAXB
> getCreditReport(CustomerJAXB customer);
> >> >> }
> >> >>
> >> >> Thanks,
> >> >> Raymond
> >> >>
> >> >>
> >> >> ----- Original Message -----
> >> >> From: "ant elder" <[EMAIL PROTECTED]>
> >> >> To: <[email protected]>
> >> >> Sent: Tuesday, August 22, 2006 7:12 AM
> >> >> Subject: Re: SCDL extensions to define data types for
> parameters and
> >> >> return
> >> >> value
> >> >>
> >> >>
> >> >> > Could you give a bit more detail and a few more
> complete examples,
> >> I'm
> >> >> not
> >> >> > sure I understand all this? It seems a lot of XML,
> you're not likely
> >> to
> >> >> > use
> >> >> > different databinding technologies on the same
> interface are you,
> >> >> > and
> >> >> > would
> >> >> > a lot of this have defaults so you don't have to
> specify all this
> >> >> > for
> >> >> > every
> >> >> > operation?
> >> >> >
> >> >> > ...ant
> >> >> >
> >> >> > On 8/21/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
> >> >> >>
> >> >> >> Hi,
> >> >> >>
> >> >> >> I'm trying to define the XML schema for the tuscany
> databinding
> >> >> extension
> >> >> >> to describe the data types for input and output.
> Here's an example.
> >> >> >> Please
> >> >> >> note "databinding" will be an extension to the
> interface type.
> >> >> >>
> >> >> >> <interface.java interface="sample.CreditReportService">
> >> >> >> <tuscany:databinding xmlns:tuscany="
> >> >> >> http://tuscany.apache.org/xmlns/1.0-SNAPSHOT>
> >> >> >> <operation name="getCreditReport">
> >> >> >> <input>
> >> >> >> <part index="0">
> >> >> >> <dataType name="sdo" xmlType="{
> >> >> >> http://customer}Customer"/>
> >> >> >> </part>
> >> >> >> </input>
> >> >> >> <output>
> >> >> >> <part index="0">
> >> >> >> <dataType name="sdo"
> xmlType="{
> >> >> >> http://credit}CreditReport"; javaClass="...'/>
> >> >> >> </part>
> >> >> >> </output>
> >> >> >> </operation>
> >> >> >> </tuscany:databinding>
> >> >> >> </interface.java>
> >> >> >>
> >> >> >> Any opinions?
> >> >> >>
> >> >> >> 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]
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> 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]
