Hi Yang,
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.
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,
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)
- 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.
- It contains large amounts of untested and undocumented code. I
would prefer smaller, iterative patches that contain testcases to
verify functionality.
- It still uses static singletons which are anathema to SCA (and
Tuscany) being based on IoC.
Given the vast amount of work ahead of us, could we start with
defining our objectives for WSDL loading and then define an interface
for retrieving WSDL artifacts, potentially using Celtix's WSDLManager
for ideas. From there, we can figure out how to best implement it?
Jim
As an implementation strategy
On Sep 18, 2006, at 11:26 AM, Yang ZHONG wrote:
Thank you all for the patience.
(I also used the waiting time to assure no huge change to the API
and SPI)
A Reference Implementation is now available at
http://issues.apache.org/jira/secure/attachment/12341070/
registry4.zip
for JIRA
http://issues.apache.org/jira/browse/TUSCANY-677
The implementation has a JavaDoc at
impl/SPI/doc
and please try the live demo at
impl/API/src/test/java/org/apache/tuscany/registry/test
demonstrating using SPI to register Locator and loader and using
API to get
symbol on demand.
A WSDL Reference Implementation will be provided next time.
--
Yang ZHONG
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
