The spec is quite careful to separate the concepts of service
contract and binding and I think we should maintain that separation.
The IDL module group was added as an umbrella for service contract
definition mechanisms which include Java interface, WSDL, CORBA IDL, C
++ headers and so on. The Java version is bundled with core because
the runtime is written in Java, the others should all be separate
extensions.
There was talk on another thread of providing a WSDL registry to
support caching of definitions and that makes a lot of sense.
However, the role of such a service should be restricted to caching
definitions rather than mixing in other functions as well.
For the binding side, I agree that there is a good case for a web-
services framework which can contain the generic bits that are not
related to a particular implementation - for example, the parsing
code for <binding.ws> XML. Whether we should do that though depends
on the amount of coupling it introduces between the different
implementations. If there are just a few useful classes in the
framework then it might be better just to duplicate the code in the
different implementations (axis, celtix, ...) rather than introduce a
dependency.
Regarding WS*MetaData, I'm not convinced they are a good idea as they
bleed a lot of model information down to the runtime. Most of what
they contain can be converted to implementation-specific definitions
in the builder - for example, PortMetaData can be converted to an
AxisService.
If we do end up with a framework it may be worth providing SCDL
snippets for inclusion but if so they should be included by the
extension's SCDL file - they should never end up in a system scdl.
--
Jeremy
On Aug 26, 2006, at 3:16 AM, ant elder wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
