Really appreciate your compliment and thanks a lot for your comments.
My comments are below.
On 9/3/06, Jim Marino <[EMAIL PROTECTED]> wrote:
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?
Maybe the old attachment is confusing, I tried to remove it however I didn't
find a way to do that.
In the new attachment, I've already removed INSTANCE from API, and there's
no INSTANCE in WSDL API.
If you meant SPI, I didn't feel urgent to change right now from two
perspective:
2-1. SPI is not any part of user Programming Model at all, since it's
internal, we can change it any way later.
I intend to focus on API, WSDL API and reference implementations so
that Ant and other folks can use as soon as possible.
Then we can do fine tuning inside the implementations. So I
prioritize SPI changes lower/later than providing something working first.
2-2. There's a granularity to apply SCA. I'm pretty sure about two extremes:
SCA is perfect for service invocation and SCA is not a replacement
for basic programming such as "new ArrayList()".
For granularities between those two extremes, different people may
have different opinions.
So I prioritize SPI changes lower/later than providing API, WSDL API
and something working first.
My current reference implementation has no dependency on SCA at all, it
enables easy development, easy debuging and problems isolation.
Once the implementation is stabilized, we can always have more time and
resources to refine what granularity to apply SCA.
- 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.
Some people find inner interface helpful and better readable,
I think the Java spec wouldn't include it if it's a absolute evil :-)
An example of inner interface usage is EMF
interface EPackage
{
interface Registry
}
therefore EPackage.Registry is a Registry of EPackages.
I don't really normally argue about interface styles, I've already changes
SymbolSpace.Registry to SymbolSpaceRegistry in the *new* attachment as you
suggested before.
If you're talking about NameSpace.xxx, I sure will change them too in next
update.
- 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){
//
}
Right, I only documented non-SCA client Programming Model to use the
registry,
I hesitated to include SCA client one because of the requirement
(setRegistry) and the assumption of SCA clients know what to do.
Since you mention it (thank you), I'll also document the SCA client PM to
use the registry in next update.
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?
If I understand correctly, you concern "why multiple dimensions".
A typical scenario is MyApplication.Ear = MyWeb.War + share.jar(
MyService.wsdl) + MyEJB.jar
and the share.jar is shared by both MyWeb and MyEJB.
Some frameworks has an option to check receiving data against interface,
incuding Java and I know SCA used to have that option.
Checking instance against model may have problems if the model is loaded as
more than one copies,
Xxx.class and SDO/EMF types all have such problems.
I don't know if current SCA ever computs equals, isSuperType and instanceof
between message/portType/binding/service models.
If never, I admit multi-dimension as a generic isuue doesn't have to be
applied to SCA except for performance concerns
(I've seen real customers sometimes have huge WSDL/XSD files and loading and
caching them more than once is unecessary pain for customers)
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
I see at least 3 areas WSDLManager can improve (besides the multi-dimension
issue):
3-1. It's nice the WSDLManager supports location(String/URL) Scoping.
however it doesn't seem supporting other Scoping such as
CompositeComponent
Particularly, it's a problem when wsdlLocation/scdlLocation is absent
3-2. Scope delegation is not mentioned at all. e.g. a location query should
be able to be delegated to all included location,
and a CompositeComponent query should be able to be delegated to all
included CompositeComponent
3-3. message/portType/binding/service may not necessarily reside in current
Definition, they may be available from included/delegated Definitions.
Without direct API to query message/portType/binding/service, users
have to query current Definition first,
then manually and recursively query all included/delegated
Definitions,
which is quite error-prone..
Again, thanks for all your effort.
Jim
Thank *you* for supporting the effort along the way.
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]
--
Yang ZHONG
