More comments:
--------------------------------------------------
From: "ant elder" <[email protected]>
Sent: Wednesday, January 13, 2010 9:03 AM
To: <[email protected]>
Subject: Re: SCAClientFactory domainURI format
Heh, so thats not what i'd like for either of those, so we need to
find a way to work this out.
I'd like to avoid _requiring_ some other external config for
connecting to the domain which is why encoding it in the URI is good.
It could be fine to have the option of some external config if a user
really wants to do that, but it doesn't seem particularly user
friendly or convenient to requiring yet another non-spec defined
mapping file when it works just fine using the mapped value directly
in the SCAClientFactory call.
Adding the physical address to the domainURI doesn't seem to be consistent
with the spec. We probably need a bit clarification from the spec folks.
We can possibly have to a default scheme for the client and it can be
configured as an attribute in the META-INF/services/... . If the user wants
to customize it, then other ways such as System properties or external files
can be used.
Then with the URI scheme, I'd like to avoid using the explicit
underlying technology like tribes or hazelcast as thats runtime
specific and variable so using a generic one seems better and the
runtime and registry impl can map that to what the particular impl can
use.
Some of the underlying stacks have their own set of properties to configure.
We can try to generalize them if possible. But I still prefer
to have schemes such as "multicast" or "wka" (well-known-addresses) which
are known protocols.
...ant
On Wed, Jan 13, 2010 at 4:50 PM, Raymond Feng <[email protected]> wrote:
My understanding of the SCA spec is that the domainURI is a unique id for
an
SCA domain. What you have in the sample seems to be the physical URI that
can be used to connect to the domain registry. I think they are two
different things and it's probably not a good idea to hard code the
physical
address in the client code.
Here is what I have in mind:
1) When a client wants to connect to an SCA domain whose URI is
"urn:com.example/sca/domain1", the code would be:
SomeService s =
SCAClientFactory.newInstance("urn:com.example/sca/domain1").getService(SomeService.class,
"SomeComponent");
2) The client environment would have some of sort configuration to map
the
domain URI to the domain registry URI, such as:
urn:com.example/sca/domain1 = tuscany:domain1?remote=9.120.1.1:14820
urn:com.example/sca/domain2 = tribes://228.0.0.100:50000
urn:com.example/sca/domain2 = zookeeper:9.120.1.1:14820,9.120.1.2:14820
BTW, I prefer to name the scheme to be the protocol such as http,
multicast,
tcp or stack name such as hazalcast, tribes, or zookeeper.
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <[email protected]>
Sent: Wednesday, January 13, 2010 4:09 AM
To: <[email protected]>
Subject: SCAClientFactory domainURI format
The OASIS SCAClientFactory uses a domainURI to define the which domain
to access. In Tuscany today we've various ways thats used that but
there's never been much discussion about the format of the URI, do we
need to do that? As an example, here's how the API is used:
SomeService s =
SCAClientFactory.newInstance(domainURI).getService(SomeService.class,
"SomeComponent");
So the domainURI could be things like:
"myDomain" - assumes only the Tuscany SCAClientFactoryImpl on the
classpath, and that there is a domain in the local JVM called myDomain
"tuscany:myDomain" - use the Tuscany SCAClientFactoryImpl and there is
a domain in the local JVM called myDomain
"tuscany:myDomain?remote=9.120.1.1:14820" - a remote domain called
myDomain on a remote machine running Tuscany listening on IP address
9.120.1.1 port 14820
I'm not sure we should do the first of those as it would prevent an
other runtimes SCAClientFactoryImpl from being used. Are we happy with
the "tuscany" URI prefix, do we need to make that different or
pluggable?
Any comments, do we want that, or something more, or something
different?
...ant
