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]
