Re: Need spec defined Databindings? Was: (TUSCANY-824) DataBinding: Is it a concern of Programming Model vs. Assembly?
Hi, Mike. Thank you for looking into it. Please see my comments inline. Raymond - Original Message - From: "Mike Edwards" <[EMAIL PROTECTED]> To: Sent: Friday, July 06, 2007 6:34 AM Subject: Need spec defined Databindings? Was: (TUSCANY-824) DataBinding: Is it a concern of Programming Model vs. Assembly? Folks, OK, finally, I bite ;-) The question for me is whether we need the SCA (Java) spec to define some standard metadata (typically annotations) for databindings of services & references. I make the assumption that for much of the time, it is possible to work out the required databinding simply by inspection of the types of the parameters involved. If you find an SDO object, if you find a JAXB object, etc. We have been trying hard to inspect the data types in order to avoid tuscany-specific annotations. The inspections are based on different things, for example, the DataObject interface for dynamic SDO, code pattern for generated SDO (or we have to register generated SDO types first and do a lookup using the java class as the key) and annotations for JAXB. The inspection can figure out what data type is used in most cases, for example, a SDO data object, a JAXB bean or a DOM node. Sometimes we need additional metadata for the purpose of data transformation, for example, the element QName for a DOM or AXIOM element. Generally speaking, I prefer to define the standard metadata if necessary. Then the medadata can be collected in many ways, from XML, from annotation or from inspection. So is the real issue the case where mixed types of data objects turn up? Or are there ambiguous cases where you can't tell what the kind of object is? I agree that it's rare for an operation to use mixed types of data. There are ambiguous cases though. One simple senario will be using java.lang.String to represent data. In the following three operations, [1] expects an XML string, [2] expects an plain string, and [3] expects an JSON string. Inspection cannot tell the differences without annotations. [1] String m1(String xmlString); [2] String m2(String plainString); [3] String m3(String jsonString); I suppose that we can take two views of cases like these: a) Don't go there, it's not valid. b) OK, annotate your code enough to tell us exactly what you expect to happen. If we want to go down the second path, then I'm happy to carry back requirements to the SCA Java WG, but I'd really like an appreciation of just how common this case is likely to be. Views please Yours, Mike. - 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: Need spec defined Databindings? Was: (TUSCANY-824) DataBinding: Is it a concern of Programming Model vs. Assembly?
Hi, Mike.
I like your proposal to define the interface compatibility. The current 1.0
spec is vague in this area.
One thing to clarify: are you proposing to use WSDL as the canonical IDL?
WSDL 1.1 or 2.0?
Thanks,
Raymond
- Original Message -
From: "Mike Edwards" <[EMAIL PROTECTED]>
To:
Sent: Monday, July 09, 2007 2:52 AM
Subject: Re: Need spec defined Databindings? Was: (TUSCANY-824) DataBinding:
Is it a concern of Programming Model vs. Assembly?
Scott,
I think you ask a fair question here, which is definitely a question for
the Assembly spec working group to consider and answer.
Making it as succinct as I can, I think the issue is this:
For the interfaces at each end of a wire, when they are specified using
the same interface definition language, do they have to be identical, or
is it sufficient that they both map to the same WSDL?
It is clear in the case where the interface definition languages are
different, that the rule is to map to WSDL and then compare the WSDLs.
This is not stated for the case where the two ends of the wire use the
same interface definition language.
I can also see two cases to consider:
a) Where the interface is local
b) Where the interface is remotable
I believe that for local interfaces, only by using the same interface
definition language is it possible to have a local interface. In this
case, the rules are going to REQUIRE that the interfaces are identical.
Local in principle implies handing over of "native" data objects between
client and provider - ie Java objects in the case of Java interface
definitions. This can't be done if the object types don't match exactly.
For remotable interfaces, they MUST be mappable to WSDL. So in the case
of wires connecting remotable interfaces, the rule is to map both ends to
WSDL and then do the comparison. Hence I think that in this case, the
Java form of the two interfaces does not have to match at all - as long as
the databinding takes care of mapping the Java interfaces to the same
WSDL, then we are good to go.
This is my interpretation - let's see what the other spec team people
think about it
Yours, Mike.
Scott Kurz wrote:
Mike,
I'd been steering the discussion towards how to avoid annotations since I
haven't been interested in the mixed cases (since I'm not sure who would
want to do that) and the last points we've been discussing relate to how
to
do the Tuscany-specific introspection and DB setup properly.
So I personally don't see a need to input to the spec.
--
I'd like to use this opportunity to ask about a different point (but
related
to the subject heading of the JIRA).
(This is long because I fleshed out some examples)
I would be interested to hear your and others' opinions on the question:
how does the choice of intf at Assembly impact the PM?
(I think this question was touched on in the original exchange btw.
Raymond
and Jim Marino but I'm not sure how it was resolved.)
To illustrate, suppose I have a WSDL which defines operation 'm1'
In MyIntf.wsdl:
http://pkg.my/v1";
xmlns:tns="http://pkg.my/v1"; ...>
...
...
...
I'm planning to use this MyIntf portType on an to type
an
SCA service intf
But first, say I have a Java impl of this service intf:
MyImpl.java
@Service(some.pkg.MyIntf.class)
class MyImpl implements some.pkg.MyIntf {
void m1(my.pkg1.MyType) {
// .. impl ..
}
}
Suppose some.pkg.MyIntf is generated from WSDL per-JAXWS. Suppose that
the
Java type
my.pkg1.MyType is mappable to the somens:MyType schema type.
Having set this up, I don't think there's any question that the the
some.pkg.MyIntf is wire-compatible
with WSDL interface: tns:MyIntf
Now, the question of whether this will work in Tuscany or not will depend
on
more info introspected
from the impl. For example if the impl uses a generated SDO of type
my.pkg1.MyType or a JAXB type
annotated to match somens:MyType, then this will be able to make it
through
the Tuscany DB framework.
If my.pkg1.MyType matches a POJO or some other type, then whether it will
work depends on whether we
can construct the appropriate transformer chain or not.
If the component-service is configured in SCDL with:
http://pkg.my/v1#wsdl.interface(MyIntf)"/>
then there's no question the Java impl's Java service intf is compatible
with this WSDL intf. (My Java
interface's package doesn't matter since the SCA assembly spec clearly
says
that mappability can be satisfied
in the interfaces have the same operations with the same types.
Now.. one way to phrase the core of the question I've been building up to
would be: are interfaces compatible merely by having "mappable" types
or do they have
Re: Need spec defined Databindings? Was: (TUSCANY-824) DataBinding: Is it a concern of Programming Model vs. Assembly?
Scott,
I think you ask a fair question here, which is definitely a question for
the Assembly spec working group to consider and answer.
Making it as succinct as I can, I think the issue is this:
For the interfaces at each end of a wire, when they are specified using
the same interface definition language, do they have to be identical, or
is it sufficient that they both map to the same WSDL?
It is clear in the case where the interface definition languages are
different, that the rule is to map to WSDL and then compare the WSDLs.
This is not stated for the case where the two ends of the wire use the
same interface definition language.
I can also see two cases to consider:
a) Where the interface is local
b) Where the interface is remotable
I believe that for local interfaces, only by using the same interface
definition language is it possible to have a local interface. In this
case, the rules are going to REQUIRE that the interfaces are identical.
Local in principle implies handing over of "native" data objects
between client and provider - ie Java objects in the case of Java
interface definitions. This can't be done if the object types don't
match exactly.
For remotable interfaces, they MUST be mappable to WSDL. So in the case
of wires connecting remotable interfaces, the rule is to map both ends
to WSDL and then do the comparison. Hence I think that in this case,
the Java form of the two interfaces does not have to match at all - as
long as the databinding takes care of mapping the Java interfaces to the
same WSDL, then we are good to go.
This is my interpretation - let's see what the other spec team people
think about it
Yours, Mike.
Scott Kurz wrote:
Mike,
I'd been steering the discussion towards how to avoid annotations since I
haven't been interested in the mixed cases (since I'm not sure who would
want to do that) and the last points we've been discussing relate to how to
do the Tuscany-specific introspection and DB setup properly.
So I personally don't see a need to input to the spec.
--
I'd like to use this opportunity to ask about a different point (but
related
to the subject heading of the JIRA).
(This is long because I fleshed out some examples)
I would be interested to hear your and others' opinions on the question:
how does the choice of intf at Assembly impact the PM?
(I think this question was touched on in the original exchange btw. Raymond
and Jim Marino but I'm not sure how it was resolved.)
To illustrate, suppose I have a WSDL which defines operation 'm1'
In MyIntf.wsdl:
http://pkg.my/v1";
xmlns:tns="http://pkg.my/v1"; ...>
...
...
...
I'm planning to use this MyIntf portType on an to type an
SCA service intf
But first, say I have a Java impl of this service intf:
MyImpl.java
@Service(some.pkg.MyIntf.class)
class MyImpl implements some.pkg.MyIntf {
void m1(my.pkg1.MyType) {
// .. impl ..
}
}
Suppose some.pkg.MyIntf is generated from WSDL per-JAXWS. Suppose that the
Java type
my.pkg1.MyType is mappable to the somens:MyType schema type.
Having set this up, I don't think there's any question that the the
some.pkg.MyIntf is wire-compatible
with WSDL interface: tns:MyIntf
Now, the question of whether this will work in Tuscany or not will
depend on
more info introspected
from the impl. For example if the impl uses a generated SDO of type
my.pkg1.MyType or a JAXB type
annotated to match somens:MyType, then this will be able to make it through
the Tuscany DB framework.
If my.pkg1.MyType matches a POJO or some other type, then whether it will
work depends on whether we
can construct the appropriate transformer chain or not.
If the component-service is configured in SCDL with:
http://pkg.my/v1#wsdl.interface(MyIntf)"/>
then there's no question the Java impl's Java service intf is compatible
with this WSDL intf. (My Java
interface's package doesn't matter since the SCA assembly spec clearly says
that mappability can be satisfied
in the interfaces have the same operations with the same types.
Now.. one way to phrase the core of the question I've been building up to
would be: are interfaces compatible merely by having "mappable" types
or do they have to be "the same"?
Sec. 1.6.4 of the Assembly spec seems to say both in a short span.
So, some examples:
With the same MyImpl.java annotated above with service intf:
@Service(some.pkg.MyIntf.class)
would the following Java interfaces be considered mappable if they were
placed on the component-level service in SCDL
via the corresponding element?
MyIntfSDO.java
void m1(DataObject)
MyIntf.java
void m1(my.pkg2.MyType) // MyType is identical but in a different
package
MyIntf.java
void m1(my.pkg2.MyTypeImpl) // where MyTypeImpl is a generated SDO
implementing MyType
Hopefully it's clear how these examples relate to my question: how d
Re: Need spec defined Databindings? Was: (TUSCANY-824) DataBinding: Is it a concern of Programming Model vs. Assembly?
+1. :-) - Original Message - From: "Mike Edwards" <[EMAIL PROTECTED]> To: Sent: Friday, July 06, 2007 9:34 PM Subject: Need spec defined Databindings? Was: (TUSCANY-824) DataBinding: Is it a concern of Programming Model vs. Assembly? > Folks, > > OK, finally, I bite ;-) > > The question for me is whether we need the SCA (Java) spec to define > some standard metadata (typically annotations) for databindings of > services & references. > > I make the assumption that for much of the time, it is possible to work > out the required databinding simply by inspection of the types of the > parameters involved. If you find an SDO object, if you find a JAXB > object, etc. > > So is the real issue the case where mixed types of data objects turn up? > Or are there ambiguous cases where you can't tell what the kind of > object is? > > I suppose that we can take two views of cases like these: > > a) Don't go there, it's not valid. > > b) OK, annotate your code enough to tell us exactly what you expect to > happen. > > If we want to go down the second path, then I'm happy to carry back > requirements to the SCA Java WG, but I'd really like an appreciation of > just how common this case is likely to be. > > Views please > > > Yours, Mike. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
Re: Need spec defined Databindings? Was: (TUSCANY-824) DataBinding: Is it a concern of Programming Model vs. Assembly?
Mike,
I'd been steering the discussion towards how to avoid annotations since I
haven't been interested in the mixed cases (since I'm not sure who would
want to do that) and the last points we've been discussing relate to how to
do the Tuscany-specific introspection and DB setup properly.
So I personally don't see a need to input to the spec.
--
I'd like to use this opportunity to ask about a different point (but related
to the subject heading of the JIRA).
(This is long because I fleshed out some examples)
I would be interested to hear your and others' opinions on the question:
how does the choice of intf at Assembly impact the PM?
(I think this question was touched on in the original exchange btw. Raymond
and Jim Marino but I'm not sure how it was resolved.)
To illustrate, suppose I have a WSDL which defines operation 'm1'
In MyIntf.wsdl:
http://pkg.my/v1";
xmlns:tns="http://pkg.my/v1"; ...>
...
...
...
I'm planning to use this MyIntf portType on an to type an
SCA service intf
But first, say I have a Java impl of this service intf:
MyImpl.java
@Service(some.pkg.MyIntf.class)
class MyImpl implements some.pkg.MyIntf {
void m1(my.pkg1.MyType) {
// .. impl ..
}
}
Suppose some.pkg.MyIntf is generated from WSDL per-JAXWS. Suppose that the
Java type
my.pkg1.MyType is mappable to the somens:MyType schema type.
Having set this up, I don't think there's any question that the the
some.pkg.MyIntf is wire-compatible
with WSDL interface: tns:MyIntf
Now, the question of whether this will work in Tuscany or not will depend on
more info introspected
from the impl. For example if the impl uses a generated SDO of type
my.pkg1.MyType or a JAXB type
annotated to match somens:MyType, then this will be able to make it through
the Tuscany DB framework.
If my.pkg1.MyType matches a POJO or some other type, then whether it will
work depends on whether we
can construct the appropriate transformer chain or not.
If the component-service is configured in SCDL with:
http://pkg.my/v1#wsdl.interface(MyIntf)"/>
then there's no question the Java impl's Java service intf is compatible
with this WSDL intf. (My Java
interface's package doesn't matter since the SCA assembly spec clearly says
that mappability can be satisfied
in the interfaces have the same operations with the same types.
Now.. one way to phrase the core of the question I've been building up to
would be: are interfaces compatible merely by having "mappable" types
or do they have to be "the same"?
Sec. 1.6.4 of the Assembly spec seems to say both in a short span.
So, some examples:
With the same MyImpl.java annotated above with service intf:
@Service(some.pkg.MyIntf.class)
would the following Java interfaces be considered mappable if they were
placed on the component-level service in SCDL
via the corresponding element?
MyIntfSDO.java
void m1(DataObject)
MyIntf.java
void m1(my.pkg2.MyType) // MyType is identical but in a different
package
MyIntf.java
void m1(my.pkg2.MyTypeImpl) // where MyTypeImpl is a generated SDO
implementing MyType
Hopefully it's clear how these examples relate to my question: how does the
choice of intf at assembly impact the PM?
Thanks,
Scott
On 7/6/07, Mike Edwards <[EMAIL PROTECTED]> wrote:
Folks,
OK, finally, I bite ;-)
The question for me is whether we need the SCA (Java) spec to define
some standard metadata (typically annotations) for databindings of
services & references.
I make the assumption that for much of the time, it is possible to work
out the required databinding simply by inspection of the types of the
parameters involved. If you find an SDO object, if you find a JAXB
object, etc.
So is the real issue the case where mixed types of data objects turn up?
Or are there ambiguous cases where you can't tell what the kind of
object is?
I suppose that we can take two views of cases like these:
a) Don't go there, it's not valid.
b) OK, annotate your code enough to tell us exactly what you expect to
happen.
If we want to go down the second path, then I'm happy to carry back
requirements to the SCA Java WG, but I'd really like an appreciation of
just how common this case is likely to be.
Views please
Yours, Mike.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
