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]

Reply via email to