tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Marino <jmar...@myromatours.com>
Subject Re: Registry proposal, was: Delivery Status Notification (Failure)
Date Mon, 04 Sep 2006 03:06:24 GMT
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:

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)?


Again, thanks for all your effort.


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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

View raw message