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.
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.
- 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>
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){
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.
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.
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?
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
