Hi Yang,
Thanks for your effort on this (the documentation is really
impressive too). I have some more comments based on an initial look:
- There appears to be a number of places static references on
interfaces are used, e.g. SymbolSpace.Registry. Doing this is really
problematic in a managed environment as we have found with SDO and
earlier versions of SCA which used .INSTANCE. As a Java developer I
also find this approach not really intuitive. Is there a technical
reason for doing this?
- It also seems a lot of inner interfaces are used. I think things
could be simplified by not using inner interfaces at all, possibly
segregating classes using subpackages if necessary.
- I don't think we should hardcode component names into interfaces
nor do we need to use locateService() to find a component. Rather, we
should just rely on the container to inject the correct regsitry
instance through autowire into a component as in:
@Autowire
public void setRegistry(Registry myRegistry){
//
}
Stepping back a bit, I would also like to understand the requirements
of the registry a little better and this is where my ignorance of
WSDL issues will probably show through...Do we need the ability to
cache using multidimensional keys? For example, if we didn't share
symbols across applications, I don't see that as a major performance
issue given the number of WSDLs and applications a typical runtime
instance is going to manage (limited) versus everything else that is
going on including creation of the assembly model and runtime
artifacts (many). Instead, couldn't we just cache by deployed unit?
To help me understand things a bit better, why would a registry
interface like the one below not work for our purposes (let's assume
for the time being the container can provide the client code with the
correct manager instance scoped to a deployment unit/classloader)?
http://celtix.objectweb.org/docs/api/org/objectweb/celtix/wsdl/
WSDLManager.html
Again, thanks for all your effort.
Jim
On Sep 2, 2006, at 12:28 PM, Yang ZHONG wrote:
I've updated the registry proposal basing on feedbacks (thank everyone
especially Jeremy and Jim) and some time to refine diagrams and
examples/samples,
and proposed a WSDL Registry (thank Jeremy for strong-interface
suggestion).
Please see the new attachment at
http://issues.apache.org/jira/secure/attachment/12340097/registry.zip
for JIRA
http://issues.apache.org/jira/browse/TUSCANY-677
It seemed easy to overlook ReadMe.txt and miss some info already
provided,
so please spend a little time on diagrams and examples/samples if
possible.
The major change is the API Programming Model from
SymbolSpace.Registry.INSTANCE
to
CurrentCompositeContext.getContext().locateService(
SymbolSpaceRegistry.class, SymbolSpaceRegistry.SERVICE)
Thank Ant for detailed info.
I've tried not to involve Scoping in the WSDL Registry, so the API
doesn't
mention Scoping at all.
However, a "scope" notation is still used in WSDLRegistry to make
the API
practically useful.
But I've left the signature to be "Object" to be flexible/open enough.
Although the WSDL Registry proposal doesn't cover Scoping, it's not
really
necessarily too early to discuss Scoping,
so that we might have a little bit more thorough thinking/
discussion about
Scoping before the eventual approach adopting.
I see at least 3 kinds of scenario (examples assume WSDLRegistries
WSDL =
CurrentCompositeContext.getContext().locateService
( WSDLRegistries.class,
WSDLRegistries.SERVICE)):
3-1. Designated WSDL location.
Users may need Message/PortType/Binding/Service/Definition lookup
to be
scoped by the designated location,
and recursively delegated to all included locations. e.g. (location
dimension/Scoping)
WSDL.getInterfaceRegistry(
FTP://hosting.org/WSDL/vertical.wsdl<ftp://hosting.org/WSDL/
vertical.wsdl>
)
3-2. Absent WSDL location with designated CompositeComponent (thank
Raymond
for explaining me Composite).
Users may need Message/PortType/Binding/Service/Definition lookup
to be
scoped by the designated CompositeComponent,
and recursively delegated to all included CompositeComponents. e.g.
(CompositeComponent Scoping)
WSDL.getBindingRegistry( compositeComponent)
3-3. Nothing designated.
Users may need Message/PortType/Binding/Service/Definition lookup
to be
scoped by context.
I don't know SCA confident enough yet to propose anything, however
I hope
you don't mind me sharing that I feel CompositeComponent is a natural
context Scoping for SCA.
If that's the approach adopted, the lookup may need to be scoped by
the
context CompositeComponent and recursively delegated to all included
CompositeComponents. e.g. (no matter what context Scoping ends up
being
adopted)
WSDL.getServiceRegistry( null)
For either 3-2 or 3-3, we may need something like:
static Scoping COMPOSITE_SCOPING = new Scoping<CompositeComponent>()
{
public Iterable<CompositeComponent> includes (CompositeComponent
composite)
{
return composite.getIncludes().values();
}
public Iterable<CompositeComponent> imports (CompositeComponent
composite)
{
return composite.getImports().values();
}
};
--
Yang ZHONG
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
