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]
