On Sep 5, 2006, at 11:22 AM, Yang ZHONG wrote:
I've proposed hosting the registry dircetly under tuscany/java:
distribution
*registry*
sdo
spec
sca
The rational is we are dealing with generic issues beyond just sca
and sdo
anyway,
especially I know some SDO implementations are using registry for
types (and
elements).
There's one thing I don't even have preference myself at all: where
to host
the tailoring for sca.
It can either be
tuscany/java/registry/sca
or
tuscany/java/sca/registry
Can we first try and solve the specific issue of WSDL loading and
then see if we can make something generic? It feels as if a "one-size-
fits-all" approach is going to introduce complexity we don't need in
the SCA runtime. Also, doing this potentially introduces dependencies
between the projects which was what we just eliminated and which I
would not want to reintroduce.
> - 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 :-)
<rant>I think statics on interfaces like .INSTANCE are evil.
Thankfully, they are not widely used in Java technologies I am aware
of (outside SDO and EMF) as they cause so many problems in managed
environments where classloader isolation is important. ;-) I honestly
don't understand how this pattern is easier to use as there are
simple alternatives Java developers are familiar with such as IoC and
factories. </rant>
The above paragraph was talking about inner interface, *not*
singleton.
I understand singleton causes management difficulties although it
makes
simplest/easiest Programming Model.
There's no singleton in API and WSDL API already.
I don't see you say inner interfaces are evil, however I can guess
they're
not your preference and I sure will replace them in API and SPI.
Sorry to be so adamant but static references to implementation
classes on interfaces have caused me a lot of grief in the past. On
the "inner" interface issue I think it is more common to use Java
packages, so thanks for accommodating this.
Brilliant idea! Using the WSDL API as example, we can offer
definition/message/portType/binding/service Registry
directly to SCA contained component exactly the way you mentioned,
and offer scope aware WSDLRegistries to non SCA-contained or low/
system
level programming.
I think we can simplify this even further: we just offer a WSDL
registry that is held in the DeploymentContext and thrown away after
the deployment process. We don't need the registry to manage any
scoping as that is done by the runtime. Jeremy suggested this a while
back, I believe. In this case, we would have a loader that would
process <import.wsdl> and create the registry if needed, putting it
in the DeploymentContext. Subsequent requests would key off that. At
the end of the deployment process, the DeploymentContext is thrown
away so we don't have to worry about the cache managing references to
classloaders or having to implement complex scoping algorithms.
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..
Could we provide a utility method or just modify the api to do this?
Jervis or Dan, how does Celtix handle this?
>
As a way to move forward, do you think we could assume for the time
being the runtime can handle resolving the correct registry instance
and we take the Celtix API and merge it with the API you are
proposing?
Are you fine/satisfied with the Celtix (WSDL) API? If so, I can put
a hold
on my efforts since I guess the Celtix (WSDL) API has an
implementation
already.
I remember someone mentioned a SCDL registry before. If you think
SCDL could
use a registry too, I can keep on the registry efforts.
Please let me know.
I don't think we need a SCDL registry but I definitely think you
should keep working on the WSDL registry since we do need one. I took
Celtix as an example since it seemed intuitive. Perhaps a good way
forward is to look at their API and make some of the modifications
you suggested? Then, once we are satisfied with the API, we look at
how to best implement it. I would start with the assumption that we
just need a WSDL registry since I can't think of other model
artifacts that need to be cached right now (there may be in the
future but then we will have more use cases to work from). I'd also
start with the assumption that scoping will be handled by the
runtime, in this case the deployment context, and that model
artifacts are thrown away after deployment and not used during
invocation processing.
Does this work?
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
