Hi,
I agree with you that only one databinding will be used for the same
interface for most cases.
I have a case that we need at least operation-level databinding. For SCA
reference/service with JCA bindings, we need databindings to deal with the
native EIS data format (for example, CCI record) at "Interaction" level
which usually maps to an operation in the ServiceContract. For your
reference, there's EMD spec from IBM & BEA @
ftp://www6.software.ibm.com/software/developer/library/j-emd/EnterpriseMetadataDiscoverySpecification.pdf
nad it talks about DataBinding for SDO<-->EIS transformations.
Jeremy, do you have some use cases that we need to go to the
parameter/return value level?
Thanks,
Raymond
----- Original Message -----
From: "Liu, Jervis" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Monday, August 28, 2006 11:57 PM
Subject: RE: SCDL extensions to define data types for parameters and return
value
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: tuscany-dev@ws.apache.org
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: <tuscany-dev@ws.apache.org>
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: <tuscany-dev@ws.apache.org>
>> 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: <tuscany-dev@ws.apache.org>
>> >> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
