I agree with Venkat - SPI should only pertain to the core. How about
making a base extension that other extensions use? This could be done
either with the include mechanism or through a contained composite.
Jim
On Aug 7, 2006, at 11:19 PM, Venkata Krishnan wrote:
Hi,
Though this is very tempting, I am not comfortable about moving this
'specific' (yet generic to webservices) stuff to the spi. My
understanding
is that what one would find in spi is the base common functionality
that
'all' other extensions would take off from. Adding a layer of
'webservices'
to that makes it contain something specific to some extensions. Or
is there
a perpective that I am actually missing out here :-)?
- Venkat
On 8/8/06, Liu, Jervis <[EMAIL PROTECTED]> wrote:
Hi, how about move WebServiceBinding.java to
java\sca\spi\src\main\java\org\apache\tuscany\spi\model\webservice
directory, and WebServiceBindingLoader.java to
java\sca\spi\src\main\java\org\apache\tuscany\spi\extension
\webservice
diretory ?
Cheers,
Jervis
-----Original Message-----
From: Raymond Feng [mailto:[EMAIL PROTECTED]
Sent: 8/8/2006 (星期二) 6:38 上午
To: [email protected]
Cc:
Subject: Re: Web services infrastructure
Hi,
I think it makes a lot of senses to extract the common layer.
Axis2/Celtix/JAX-WS can be treated as three dialects to the WS
binding.
Thanks,
Raymond
----- Original Message -----
From: "Ken Tam" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, August 07, 2006 3:25 PM
Subject: Web services infrastructure
> Hey folks,
>
> So it looks like there are a bunch of us looking at various issues
> involved with WS infrastructure (Ant wrt interface.wsdl & the
> WSDLDefinitionRegistry, and Rick with getting the Axis2 binding
> working with the new core, and myself looking at how to
integrate the
> JAX-WS RI).
>
> What do you guys think about pulling up the basic support for
> binding.ws (ie, WebServiceBinding.java and
> WebServiceBindingLoader.java) into someplace common to the specific
> implementations (Axis2, Celtix, etc)? From what I've seen, it
seems
> like there shouldn't be any implementation-specific information
> necessary in that functionality.
>
>
---------------------------------------------------------------------
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
