Thanks for your comments, and mine are inline below.
On 9/4/06, Jim Marino <[EMAIL PROTECTED]> wrote:
Hi Yang, comments inline.
On Sep 4, 2006, at 12:14 PM, Yang ZHONG wrote:
>
> 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'd prefer before we check something in and use it throughout the
code base we sort these issues (SPI, API, WSDL) out as they will
impact a number of bindings.
Fine with me, it's not a bad idea since we have to do it anyway and it saves
some (refactoring) time overall.
Sorry for folks waiting to wait a little longer.
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.
Where do we intend to house the code? If it is in the Java SCA
project, I'd prefer we only have the capabilities we need and not
build something that is a generic symbol cache. If the code will be
maintained elsewhere, then I would tend to treat it as an external
dependency.
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
> - 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.
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.
Cool. Thanks.
>
> 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.
>
O.K., I think it is really simple:
Registry registry;
@Reference
public void setRegistry(Registry registry){
-or-
@Autowire
public void setRegistry(Registry registry){
Thanks a lot. I'll put them into JavaDoc.
> 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.
>
We don't keep the model around during runtime operation so I don't
think this is a problem for us.
> I don't know if current SCA ever computs equals, isSuperType and
> instanceof
> between message/portType/binding/service models.
Even if we did do this, would it ever be done across remote
boundaries (a deployment unit)? At that point we have by-val
semantics (and likely serialization) anyway.
> 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)
Perhaps we can optimize as needed? If we cache per application, I
don't see this as a huge performance hit. Also, I'd probably want
things loaded separately in different deployment units as it
simplifies re-deployment and application upgrades. So, I think
caching per application and not multi-dimensionally should be the
starting place.
Agree, let's "optimize as needed".
> 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
Perhaps we can make this the job of the runtime? In other words, just
as SCA does not require applications to track instances and has a
concept of Scope, we could do the same for the registry. This would
mean client code requests a registry from the runtime and the runtime
resolves the correct one:
@Autowire
public void setRegistry(Registry registry){
The runtime would "magically" return the correct instance. The client
would never have to pass a Scope key to the registry. There are a
number of ways this could be done. Jeremy has suggested one in the
past using property factories (Jeremy, care to elaborate)? I've also
toyed with the idea of "application scoped" system components.
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.
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.
Jim
--
Yang ZHONG
