Thank Jim for such a detailed response. I'll brief update first, then address Jim's concerns inline.
A Reference Implementation of WSDL is now available at http://issues.apache.org/jira/secure/attachment/12341187/registry5.zip for JIRA http://issues.apache.org/jira/browse/TUSCANY-677 Please try the live demo at impl/SCA/WSDL/src/test/java/org/apache/tuscany/registry/sca/wsdl/test For your convenience, here's the live demo (helloworld.wsdl): WSDLManager MANAGER = ... (SCA Programming Model) WSDLRegistries WSDL = MANAGER.getWSDLRegistries(null); Definition myDefinition = WSDL.getDefinition(myNameSpace); Registry<Message> messages = WSDL.getMessageRegistry(); Message myMessage = messages.get(myNameSpace, "getGreetingsRequest"); Registry<PortType> interfaces = WSDL.getInterfaceRegistry(); PortType myInterface = interfaces.get(myNameSpace, "HelloWorldServiceImpl"); Registry<Binding> bindings = WSDL.getBindingRegistry(); Binding myBinding = bindings.get(myNameSpace, "helloworldSoapBinding"); Registry<Service> services = WSDL.getServiceRegistry(); Service myService = services.get(myNameSpace, "HelloWorldServiceImplService"); TODOs (impl/SCA/WSDL/src/main/java/org/apache/tuscany/registry/sca/wsdl): CompositeScoping.java, any volunteer to complete the skeleton please? NameSpaceLocator.java, any volunteer to complete the skeleton to locate file from CompositeComponent please? RegistryLoader.java, any volunteer to change to the WSDLReader being used by SCA please? WSDLRegistries.java, any volunteer to compute the context CompositeComponent please? Jim proposed direct providing Registry<Message||PortType||Binding||Service> so that users don't have to WSDL.getXxxRegistry(); any volunteer to support that from SCA please? And any volunteer to make component files for impl/API and impl/SCA/WSDL please? I'm addressing Jim's concerns inline: On 9/19/06, Jim Marino <[EMAIL PROTECTED]> wrote:
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.
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. 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 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) - 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. All SPI JavaDoc(package.HTML), impl/API/src/test/java/org/apache/tuscany/registry/test and the new impl/SCA/WSDL/src/test/java/org/apache/tuscany/registry/sca/wsdl/test have sample/examples to use the SPI(Locator and RegistryLoader). Hope they help and I do see the documentation is far from complete. I'll try to find time to document more. Also any volunteer (I really don't want to be a bottleneck)? - It contains large amounts of untested and undocumented code. I
would prefer smaller, iterative patches that contain testcases to verify functionality.
Yes, tests are even much more worse than documentation. This's the area volunteers really really really help. - It still uses static singletons which are anathema to SCA (and
Tuscany) being based on IoC.
I had removed the API singleton upon your request. If you meant the SPI one, I've also removed it in the latest update upon your comment. 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?
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? Once we lock down the WSDL Registry API, we sure can figure out how to best implement it. (I hope you don't mind a may-be-silly RI for people to start) Jim
As an implementation strategy
Once again, thank Jim very much. 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]
-- Yang ZHONG
