Jim, I don't think it should be checked into SDO for the same reasons you mentioned below. SDO needs a Type and (global) Property registry. It would be nice if we could have a simple generic design that could be used for that and also for SCA/WSDL, but maybe that's not possible.
Frank. Jim Marino <[EMAIL PROTECTED]> wrote on 09/20/2006 01:08:56 PM: > Comments inline. Frank, in case you miss it below, could you comment > on if perhaps Yang's generic registry is something that is more > appropriate for checking into SDO? > > Jim > > On Sep 20, 2006, at 2:30 AM, Yang ZHONG wrote: > > >> > >> Looking at the implementation, I think there may be a rather large > >> disconnect in our views of what needs to be accomplished. So, I will > >> start by describing what I thought we are and are not trying to do... > >> > >> I thought we were trying to provide a registry which would resolve > >> *WSDL* artifacts to be used by binding (or other) extensions during > >> the build phase as an assembly is processed. These artifacts would be > >> used by the extensions to create appropriate runtime artifacts. The > >> goals of this WSDL registry would be primarily to provide a mechanism > >> where WSDL artifacts could be resolved and processed using a variety > >> of extensible strategies and, secondarily, as a way to cache them > >> (although whether caching produces significant performance gains > >> given typical runtime uses cases is debatable). From an > >> implementation perspective, the registry would rely on the runtime to > >> provide the proper visibility constraints which would alleviate the > >> former from having to provide scoping behavior such as keying on > >> classloader. Tuscany has a DeploymentContext that could be used to > >> hold the registry and maintain proper isolation between composites. > > > > > > Thanks a lot for so concrete requirement. > > > > What I thought we were *not* trying to accomplish is to provide a > >> "generic" registry that caches a variety of artifacts and provides > >> built-in scoping for a number of host environments (e.g. Tuscany, > > > > > > Scoping are not really built-in; > > a SPI (org.apache.tuscany.registry.spi.Scoping) is required > > implemented. > > The Reference Implementation provides the ClassLoader one *just* > > for Java > > users' convenience. > > > > some tool, etc.). Based on the implementation and things like the > >> package structure (e.g. org.apache.tuscany.registry), I suspect you > >> may disagree with this. From a project perspective, one of my > >> concerns here is that we should not be expanding the charter of > >> Tuscany to include an additional technology category at this point (a > >> generic registry). From a technology perspective, I have the > >> following concerns: > >> > >> - The majority of the implementation appears to offer features not > >> required by the runtime (e.g util, scoping, all of the stuff related > >> to multiple keys in SPI and API) > > > > > > Yes, the Reference Implementation (RI) does provide much more > > functions than > > you expected. > > > > However, it's better than nothing. At least folks can start to use > > WSDL > > Registry > > whose API is *not* bound to the RI at all. > > The RI does *not* prevent us from implementing the WSDL Registry > > API from > > scratch as you suggested. > > While folks are able to use the WSDL Registry, we can go for other > > implementation(s) in parallel. > > > I don't believe we should check this code in for the reasons I > previously mentioned. IMO we should work on an implementation that > fulfills the requirements that I mentioned above, namely something > that resolves WSDL artifacts. > > On the other hand, Frank and I talked about the registry the other day > > and we both think it might be something useful for SDO Type > > registry (and > > Global Property registry). > > And Fuhwei's team needs a registry too. > > SCA and SDO as one Tuscany team don't have to duplicate similar > > effort. > > > If SDO requires a generic registry, perhaps it is best that Frank, > Kelvin or one of the other committers working in that area review > your patch and decide if it fits their requirements and check it into > the SDO subproject? I don't think this should be checked in as a > sibling project to SDO, DAS, or SCA as that expands the Tuscany > charter. I am also not comfortable with the Java SCA runtime sharing > source code between subprojects as we (I should say Jeremy) just > spent a lot of time decoupling them. > > Frank, do you feel this is something that could be checked into SDO? > > > If it ends up used by no one, and we have a new implementation for > > the WSDL > > Registry API already, > > we can easily throw the RI away and I don't see it hurt anything > > (it will *not* hurt my feeling since I volunteered and it's my > > interest to > > help with my experience anyway) > > > I'd prefer we work on a solution that addresses the specific runtime > requirements we have without introducing unneeded complexity, keeping > in mind YAGNI. > > - It is difficult to follow and does not appear to be similar to how > >> other extensions are architected (e.g. loaders, builders, > >> databinding). I still don't understand what the extension points are > >> or how I would use the SPI. > > > > > > Builders and DataBinding are SCA architects which I'm not confident > > enough > > to discuss about. > > I'd like to learn even if I don't see them related to the registry > > so far, > > maybe the education can teach me more requirements of a registry. > > > Registry may be a misnomer: maybe resolver is a better term? > > > > > You had pointed me to Celtix's WSDLManager > > and I changed the WSDL Registry API proposal. > > No comment since then and I thought you were fine with the new > > proposal. > > Sorry if I misunderstood, what's your new suggestions please? > > > Sorry I was out due to personal reasons. I think I kind of laid out > how I would approach this in prior emails: > > - Define an API similar to what Celtix has. We've partially done this. > - Implement the WSDL registry similar to how builders and loaders are > done. These use simple collections to cache configuration artifacts > that are disposed of after the build process. The registries don't > need to handle visibility constraints themselves, instead relying on > the runtime to do that. This would mean we don't need any of the > pluggable scoping, etc. > - Have pluggable resolvers as mentioned by Jervis. We may/will have > some work to do in the runtime to get it to support this but can > address that once we have a basic implementation. > > Jim > > --------------------------------------------------------------------- > 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]
