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?
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 -- I gather there has been some discussion about Jeremy's idea of using maven (or parts of the maven infrastructure), this dovetails nicely into that. On 8/7/06, Jim Marino <[EMAIL PROTECTED]> wrote:
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
