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]
