On Thu, Jul 9, 2009 at 5:14 PM, Raymond Feng<[email protected]> wrote:
> 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.
>
Could this be resolved by simply changing the name of the parameter in
the NodeFactory.getInstance call? Right now its named "domainURI"
perhaps it could be "uri" or "configURI" instead, would that help?
>>
>>>
>>> 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.
>
I think it might still be a bit early in 2.x to be trying to optimize
things for performance. We've got quite a lot of function to add and
code clean up and refactoring that needs to be done so it would easier
for now to keep thing as simple as possible and only nearer the end
then look at performance and what could be optimized. Having the port
conflict when two nodes in different domains try to use the same http
port actually seems ok to me - wouldn't it be simpler if we just say
you can't do that with our standalone runtime across domains?
>>
>>> 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.
>
But thats a bit of a fudge isn't it, the architecture is designed to
be all flexible and plugible so anyone is able to write their own
extensions and drop them in, but that isn't going to work properly if
we have to hardcode how some special case extensions get used. Anyway
thats a bit of a digression, I do think sharing extensions across
nodes like the NodeFactory is doing is useful, but it seems better to
share them only within a domain not across domains (and thats how the
current code works (doesn't it?) which seems good to me).
So i think based on what we've been saying is to have something like
the following (not sure if this is additions to, or replacement of, or
as well as the current Node/NodeFactory):
There is something like "NodeFactory" that represents the domain
locally (or perhaps instead of NodeFactory it could be called
SCADomain or DomainNode or ...?), it is tied to a single domain and
has specific configuration for things like the distributed domain
communications, base uri's if required, etc. If you had domains named
"default" and another named "accounts" then there would be two
instances of the "NodeFactory" and they wouldn't share things.
You'd be able to create things like "Nodes" from the "NodeFactory" and
they would share the config from the "NodeFactory". So with the http
port issue mentioned above when running the standalone runtime the
nodes could share the http port only if they are from the same
NodeFactory instance as its the NodeFactory that has the http host and
you can't start two http hosts on the same port (just like you can't
run multiple appservers using the same ports). Or perhaps the user
doesn't even need to know about things like "Nodes" and we could hide
the Node from the user by instead of createNode having methods like
add/removeContribution.
So you could do code something like (using SCADomain instead of
NodeFactory to make it clearer):
SCADomain scaDomain =
SCADomain.newInstance("tribes:myAccountsDomain?multicastPort=1048,staticRoutes="http://9.167.239.57:4321,http://9.167.10.123:4567";);
domain.addContribution("/accounts/foo.jar")
and then in other JVMs you can create other SCADomain instances or
SCAClients using that are part of that domain by using a similar uri.
What are the issues with that? How about we try implementing this
based on using code using the existing Node/NodeFactory andd see how
that works or what could get merged back to the Node/NodeFactory?
...ant
