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
Re: SCDL extensions to define data types for parameters and return value
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, Hi Jervis, I thought Celtix supported multiple databindings through NodeReader/ NodeWriter? Is that wrong? Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCDL extensions to define data types for parameters and return value
Hi Raymond, How about defining databidings separately instead of embedded them as extensions to the interface.wsdl. Right now I take the case of a WSDL to express what I mean to say. In a WSDL... - the message are defined - then we have wsdl:porttype element and its children defined around these messages - we then have wsdl:binding that defines bindings around this portype - then the service definitions around the bindings - why not have something like wsdl:data that defines the databiding. If this defn. is there then it is taken up and used otherwise the defaults apply. Is there something similar that we can do for what we define in SCDLs. ? This way the interfaces definitions and the databidings are kept apart. If there is a databiding defn. it will have info about which interface (by name) it should be applied to. Makes sense? Thanks - Venkat On 8/29/06, Jim Marino [EMAIL PROTECTED] wrote: 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, Hi Jervis, I thought Celtix supported multiple databindings through NodeReader/ NodeWriter? Is that wrong? Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: SCDL extensions to define data types for parameters and return value
Yes, multiple databindings can be supported by different reader and writer. What I said is that the Celtix 1.0 release only includes the support for JAXB. More is being added. Jervis -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: 2006?8?29? 15:03 To: tuscany-dev@ws.apache.org Subject: Re: SCDL extensions to define data types for parameters and return value 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, Hi Jervis, I thought Celtix supported multiple databindings through NodeReader/ NodeWriter? Is that wrong? Jim - 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]
Re: SCDL extensions to define data types for parameters and return value
Ah o.k that clarifies things. Jim On Aug 29, 2006, at 9:17 AM, Liu, Jervis wrote: Yes, multiple databindings can be supported by different reader and writer. What I said is that the Celtix 1.0 release only includes the support for JAXB. More is being added. Jervis -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: 2006?8?29? 15:03 To: tuscany-dev@ws.apache.org Subject: Re: SCDL extensions to define data types for parameters and return value 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, Hi Jervis, I thought Celtix supported multiple databindings through NodeReader/ NodeWriter? Is that wrong? Jim - 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]
Re: SCDL extensions to define data types for parameters and return value
Hi, Sometimes it would be difficult to annotate the WSDL to add databinding extensions because the WSDL could be from external web services. I think your idea is similar to java annotations. Usually, the metadata in SCDL should override those from java/wsdl annotations. Thanks, Raymond - Original Message - From: Venkata Krishnan [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, August 29, 2006 1:53 AM Subject: Re: SCDL extensions to define data types for parameters and return value Hi Raymond, How about defining databidings separately instead of embedded them as extensions to the interface.wsdl. Right now I take the case of a WSDL to express what I mean to say. In a WSDL... - the message are defined - then we have wsdl:porttype element and its children defined around these messages - we then have wsdl:binding that defines bindings around this portype - then the service definitions around the bindings - why not have something like wsdl:data that defines the databiding. If this defn. is there then it is taken up and used otherwise the defaults apply. Is there something similar that we can do for what we define in SCDLs. ? This way the interfaces definitions and the databidings are kept apart. If there is a databiding defn. it will have info about which interface (by name) it should be applied to. Makes sense? Thanks - Venkat On 8/29/06, Jim Marino [EMAIL PROTECTED] wrote: 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, Hi Jervis, I thought Celtix supported multiple databindings through NodeReader/ NodeWriter? Is that wrong? Jim - 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]
Re: SCDL extensions to define data types for parameters and return value
On Aug 29, 2006, at 1:55 PM, Raymond Feng wrote: 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. Can you explain these use cases further? Thanks, Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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.../
referenceHelloWorldComponent/reference
/service
component name=HelloWorldComponent
js:implementation.js script=HelloWorld.js/
references
reference
name=helloWorldServiceHelloWorldService/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/
Re: SCDL extensions to define data types for parameters and return value
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.../
referenceHelloWorldComponent/reference
/service
component name=HelloWorldComponent
js:implementation.js script=HelloWorld.js/
references
reference name=helloWorldServiceHelloWorldService/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/
referenceCreditReportComponent/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
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.../
referenceHelloWorldComponent/reference
/service
component name=HelloWorldComponent
js:implementation.js script=HelloWorld.js/
references
reference
name=helloWorldServiceHelloWorldService/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/
referenceCreditReportComponent/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
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.../
referenceHelloWorldComponent/reference
/service
component name=HelloWorldComponent
js:implementation.js script=HelloWorld.js/
references
reference name=helloWorldServiceHelloWorldService/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/
referenceCreditReportComponent/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]
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
