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

Reply via email to