Resurrecting this old thread...I'd still like for something to happen here, could we do something like the "web services foundation" extension archiveKen suggested. I know it doesn't solve all the problems brought up in this thread but its a better than duplicating wsdl code across different projects as is happening now.
How about renaming sca/idl to sca/wsdl and then within sca/wsdl have: org.apache.tuscany.wsdl.binding - WebServiceBinding - WebServiceBindingLoader org.apache.tuscany.wsdl.idl - InterfaceWSDLLoader - WSDLServiceContract org.apache.tuscany.wsdl.registry - WSDLDefinitionRegistry - WSDLDefinitionRegistryImpl (or whatever classes Yang comes up with for the wsdl registry) org.apache.tuscany.wsdl.utils - WebServiceOperationMetaData - WebServicePortMetaData (or maybe do some refactoring of these two into a WSDLUtils class) And provide separate scdl files for interface.wsdl, binding.ws, and the wsdl registry so they can be separately included or not in a system scdl file. ...ant On 8/8/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
On Aug 8, 2006, at 9:34 AM, Ken Tam wrote: > It seems like <binding.ws> belongs as one extension, of which there > are multiple implementations (which would be packaged and deployed > separately). I'm not sure nesting (either via inclusion or > containment) is the right approach though -- since you could have > multiple implementations of the binding present, wouldn't nesting > imply that binding.ws was loaded multiple times? This is something that's been concerning my from the spec side. binding.ws is defining a binding to a generic technology without specifying a particular implementation of that technology. This is OK when users don't care which implementation they use but doesn't work when they do want a specific implementation, or worse want multiple implementations concurrently. Perhaps we can separate the generic parts from the implementation parts. For example, the loader bits for <binding.ws> could be shared by all implementations, with each providing overrides as well e.g. <binding.axis2>. The builder bits work on a first-registered basis so if there was no implementation-specific bit then a generic binding would be handled by the first implementation loaded; if you need a specific binding, then use its overrides rather than the generic ones. > OTOH, just having an extension pkg for binding.ws seems like a bit too > fine a level of granularity -- we could aim towards eventually > packaging it in a "web services foundation" extension archive, with > other related extensions like perhaps WSDL related components (the > WSDL registry), support for <interface.wsdl> ? Then if you wanted to > deploy a particular technology-specific WS extension, you'd likely > also have to deploy the foundation extensions. > Is there a way to express dependencies like this between extensions? Not specifically no. There was some discussion of this a while ago when we were talking about start-order support. What we don't have in the model (or spec) is the concept of loose dependencies between components that are not expressed as wires. The best we can do right now is tell the user to deploy both extensions and use the initLevel attribute to ensure they start in the right order (if that matters). We also need to be careful about what the dependencies really are. For example, although web service interfaces will often be expressed as WSDL there is no requirement that they are and SCA makes is possible to bind components to web services without using <interface.wsdl> at all. We may decide that is is convenient to include <interface.wsdl> in the kitchen-sink but we should not force an OEM to do so if they don't need to. We should probably propose some additions here to the spec. -- Jeremy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
