Agree that a common web services extension would be good for things
like parsing the web services binding but I think sca/idl should not
be changed (since other idls may be used instead of wsdl). Also,
sca.wsdl should only have things related to WSDL contracts, with web
services in a separate extension.
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]
