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: <wsdl:definitions targetNamespace="http://pkg.my/v1"; xmlns:tns="http://pkg.my/v1"; ...> ... <!-- Defined in 'somens' --> <xs:complexType name="MyType"> ... <!-- wrapper elem for operation 'm1' --> <xs:element name="m1"> <xs:complexType> <xs:sequence> <xs:element name="param" type="somens:MyType"/> </xs:sequence> </xs:complexType> </xs:element> .... <wsdl:portType name="MyIntf"> <wsdl:operation name="m1"> ... I'm planning to use this MyIntf portType on an <interface.wsdl> 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: <interface.wsdl interface="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 <interface.java> 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]
