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]
