Consider the use case where I start with a .componentType file, e.g.: <componentType xmlns="http://www.osoa.org/xmlns/sca/1.0";> <service name="HelloWorld"> <interface.wsdl interface=" http://helloworld#wsdl.interface(HelloWorld)" /> </service> </componentType>
And I proceed to write a Java impl with @Service pointing to a Java interface. -------------------------- Well, this is going to cause problems today. I'm not precisely sure where in the code... I know it has something to do with how we build the wire source/target InterfaceContracts in CompositeActivatorImpl... but somehow the net seems to be that we assume that if an interface is specified in the .componentType file then this .componentType interface will describe something physical on the wire. Now, one could argue that it is correct that the use case I started with is not supported. I think the words in the OSOA Assembly spec do more to suggest the current interpretation than the one I'm suggesting. But regardless, I'm arguing that the componentType should be treated as more of a logical description in this case than a physical description. So in the code I'd say we should be basing the wire source/target interface contract's on something which is more of a "client/impl InterfaceContract" than the componentType InterfaceContract we're using today. In particular this allows more of an ability to express top-down, WSDL-centered, interface design via the componentType file. Scott
