More comments inline.
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <[email protected]>
Sent: Thursday, July 09, 2009 12:43 AM
To: <[email protected]>
Subject: Re: svn commit: r792032 -
/tuscany/java/sca/modules/node-api/src/main/java/org/apache/tuscany/sca/node/NodeFactory.java
On Wed, Jul 8, 2009 at 6:32 PM, Raymond Feng<[email protected]> wrote:
Hi,
I have a few questions on these changes:
1) Is the domain name an SCA concept? Isn't the domain URI good enough?
The domain URI is a URI so it can include all sorts of domain
configuration including things like the multicast and static routes to
other domain nodes which you probably don't want pronting out in all
the log messages.
Interestingly, the SCA assembly spec doesn't seem to have a statement about
the domain URI even though it is referenced in the SCAClientFactory. IMO,
the domain URI is just a unique id of the domain and it is not necessarily
same as the physical URL to connect to a domain manager. And the URI can be
as short as one segment such as "MyDomain". So it is the "name" of the
domain. I'm not keen on introducing extra concepts.
(this is something i've started to implement and will post more about
soon - so we can configure the dynamic domain including the multicast
options, static routes etc via the domain URI and then talk to that
domain with an SCAClient using a compatible domain URI)
Again, the domain URI is not the same as the physical URL that represents
the protocol to communicate the domain metadata.
2) The NodeFactory before can create Nodes that are under different SCA
domains (A node configuration has the domainURI property). Why do we need
to
have different node factories indexed by the domain URIs? That will lead
to
multiple instances of the same extension point or extension in the same
JVM.
As an aside from my comment below what is the issue with having
multiple extension instances when using multiple factories (which is
what we used to do and it worked on)?
It's a performance penalty and potentially causing conflicts. IIRC, there is
a case when two nodes in the same JVM try to use the same HTTP port to
publish binding.ws over host-jetty.
The NodeFactory owns the ExtensionPointRegistry that is shared by the
nodes
it creates. The extension points and extensions in the registry are
mostly
independent of the applications.
For those have state about the domain/node/app, we create a new instance
of
CompositeActivator for each node. If the problem is the EndpointRegistry,
we
can add a EndpointRegsitryFactory that can create/get EndpointRegistry by
domain URIs.
All those in (2) are something I've been wondering if we should
revisit now that 2.x has progressed on a bit and we've had an
opportunity to try it for a while, i think there's some refactoring
and tidying up we could do to simplify things now. One issue is the
problem of "...mostly independent..." which as it is now to fix
properly we'd really need to come up with a new extension type so we
can tell which are independent and which aren't.
In 2.x, we have made it working with the extension point registry shared by
multiple nodes. As I have mentioned, we only have one "CompositeActivator"
extension
in the UtilityExtensionPoint that owns the state of the application. The
other potential one is the EndpointRegistry if one instance only supports on
SCA domain. For example, the Tribes based registry filter the messages using
domain URI.
...ant
