Comments inline.
Simon Laws wrote:
On 9/26/07, ant elder <[EMAIL PROTECTED] > wrote:
On 9/26/07, Simon Laws <[EMAIL PROTECTED]> wrote:
We have two SCADomain interfaces (I'm leaving aside EmbeddedSCADomain
for
now)
1) o.a.t.s.host.embedded.SCADomain (supports a domian with a single
node)
public static SCADomain newInstance()
public static SCADomain newInstance(String composite)
*A* public static SCADomain newInstance(String domainURI, String
contributionLocation, String... composites)
*A* public static void removeInstance(SCADomain domainInstance)
*A* public static SCADomain connect(String domainURI)
public void close()
public abstract String getURI()
public abstract <B, R extends CallableReference<B>> R cast(B target)
public abstract <B> B getService(Class<B> businessInterface, String
serviceName)
public abstract <B> ServiceReference<B> getServiceReference(Class<B>
businessInterface, String referenceName)
private static String getServiceName(ClassLoader classLoader, String
name)
static SCADomain createNewInstance(String domainURI, String
contributionLocation, String... composites)
*B* public ComponentManager getComponentManager()
2) o.a.t.s.domain.SCADomain (supports a domain with one or more nodes)
public static SCADomain newInstance()
public static SCADomain newInstance(String composite)
*A* public static SCADomain newInstance(String domainURI, String
nodeURI, String contributionLocation, String... composites)
public abstract void close()
public abstract String getURI()
public abstract <B, R extends CallableReference<B>> R cast(B target)
public abstract <B> B getService(Class<B> businessInterface, String
serviceName)
public abstract <B> ServiceReference<B> getServiceReference(Class<B>
businessInterface, String referenceName);
private static String getServiceName(ClassLoader classLoader, String
name)
static SCADomain createNewInstance(String domainURI, String nodeURI,
String contributionLocation, String... composites)
I propose we move to having one. I've marked the parts that differ with
*?*.
There are two main points.
*A* The mechanism by which this local domain representation (the node)
is
associated with a wider logical domain
*B* The mechanism by which the domain is managed (the components in the
domains single node in the case of 1 above)
Before we start re-positioning interfaces though we need to agree what
we
mean by the words we use here as there has been some confusion. We've
discussed these issues before [1][2][3] etc. The result was a separation
of
node and domain so that you could operate on a node and on a
domain. This
approach/API is currently hidden behind SCADomain as there was no
consensus
that this was the right approach. e.g. I've heard people saying things
like
"a node shouldn't provide an interface for adding contributions as you
add
contributions to a domain".
I want to push on the issue of how we expect users to deal with a domain
and
the nodes in that domain before going back to look at the API. My
starter
for 10 is...
- There are different types of users we must consider. Here are two
examples,
1/ the developer who uses the Tuscany APIs to build a node
implementation
and makes contributions and manages components programmatically (see our
samples for an example of this approach)
2/ the user who manages one or more nodes as a domain, making
contributions and managing components through a GUI.
- Programmatically, to developer 1/, a node API provides sca runtime
support and has to implement all of the management interfaces for
accepting
contributions, managing components etc, so that developer 1/ can wire
tuscany into whatever mechanism they have in their implementation and so
that, once the node is added to a domain, the domain can configure and
manage the node. The implication here is that the node is configured and
managed through contribution/component management interfaces that is a
superset of that of a domain (a superset as I would expect use of other
detailed Tuscany APIs to get the node to work)
- Programmatically, to developer 1/, there should also be a domain
representation so that they can include their node in a domain and
perform
domain level operations like locating a service (or even adding
contributions, management components at a domain level). Developer 1/
would
associate their node implementation with a domain (within a single VM
this
would be as easy as passing the node object into the domain interface).
- To the user of type 2/ all of these operations may be performed
through
a
GUI using some slick drag and drop management interface. However, they
are
the same operations. We don't have a slick GUI interface currently so
contributions find their way directly to nodes because they are made
programmatically in the node in question. The implication though is that
if
we do things at the domain level under the covers the real processing is
delegated to the nodes in the domain.
So opinions please on how you see domains and nodes working.
Regards
Simon
[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg23008.html
[2] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg18920.html
[3] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg22589.html
+1 to moving to one SCADomain.
I've always found the SCADomain impls a bit confusing so i guess now is
the
chance to ask questions -
Why all the static and abstract methods? Is there a reason SCADomain
couldn't just be an interface with a separate SCADomainFactory for
creating
instances?
I don't know. A factory works for me.
+1 for making SCADomain an interface
+1 for having a factory
So instead of:
SCADomain domain = SCADomain.newInstance(...)
We'll have:
SCADomainFactory domainFactory;
SCADomain domain = domainFactory.createSCADomain(domainURI)
Now how do people would like to the get factory? a pretty common pattern is:
SCADomainFactory domainFactory = SCADomainFactory.newInstance(...)
Is there a better pattern?
Does that answer the question about "why the static and abstract
methods"? :)
I think there is a lack of clarity
about creating an SCA Domain vs creating an object in a JVM that represent
an SCA Domain. IMHO A factory/new instance method doesn't create a new
domain just creates a new object that is able to talk to a domain. Others
may have different opinions.
I think we need to distinguish:
- creating a domain... createDomain(domainURI)
- getting a handle to an existing domain... getDomain(domainURI)
I've also found the contributionLocation and composites parameters of the
newInstance methods confusing as well. Why do we need the composites
parameter, contributions should use the meta-inf/sca-contribution.xml to
define the deployable composites shouldn't they? And I'm not sure what
is
really valid for contributionLocation as whatever you specify it seems to
go
off and discover all the composites in the path itself anyway. Could the
composites parameter be dropped and the contributionLocation point at any
one of these:
- a single .composite file in which case that will be the only composite
used and it will get deployed
- a single contribution jar with a meta-inf/sca-contribution.xml to say
what
composites get deployed
- a folder containing multiple contribution jars and/or subfolders
containing "un-jar'ed" contributions
Me too. Has always confused me. I did some investigation to work out exactly
what's going on here (see http://issues.apache.org/jira/browse/TUSCANY-1779).
But I'm still suspicious of combining two notions (the location where
contributions can be found and the contributions that will be loaded from
there) into one method . This would be OK except that passing either a
relative or null contribution location still works as the code invents a
contribution location. I'd rather have a specific interface for this.
So that would be something like:
SCADomainFactory
SCADomain createSCADomain(contributionLocation)
SCADomain createSCADomain(domainName, contributionLocation)
SCADomain createSCADomain(domainName, nodeName, contributionLocation)
It's not the first time we bump into this. Having a method take a
contribution location makes a lot of sense. The problem is figuring that
location...
a) in Eclipse or another IDE
b) with a JAR produced by Maven
c) with classes under test/classes
With the API you're proposing you're going to have to write the following:
URL contributionLocation = <magic code>;
Whatever whateverFactory = createWhatever(contributionLocation);
Any good idea on how to write the <magic code> that works with [a], [b]
and [c]?
I'm picking up on three things going on here in various combinations
1/ Creating an object that gives you an interface to a domain
2/ Associating a node with this domain
3/ Adding contributions to the domain
I think we could simplify by reducing to 2 things
1/ Creating an object that gives you an interface to a domain
2/ Adding contributions to the domain
SCADomain createSCADomain()
I want to create a local domain object but the domain is not
distributed outside this JVM so I'm not bothering with a domain name.
I'll add some contributions later
SCADomain createSCADomain(domainUri, nodeUri)
I want to create a local domain object to represent the named
domain and add this named node in the domain
I'll add some contributions later
SCADomain createSCADomain(contributionLocation)
just start me a domain object which only knows about a single
local node and a single contribution, i.e. the pattern we use in most of our
tests
SCADomain createSCADomain(domainUri, nodeUri, contributionLocation)
I want to create a local domain object to represent the named
domain and add the named node in the domain
I want to load the contribution from the provided location
The resulting SCADomain object represents both the local node and the
interface to the domain.
It still feels a bit strange to me that it's called SCADomain. I still have
this feeling that we should have a domain thing that knows about the domain
and a node thing that knows how to run contributions.
+1 to separate the two:
- Domain - you go to a domain to declare contributions and domain
composites
- Node - you go to a node to run components (to simplify let's say that
a node runs a composite containing components)
I.e. you create a
domain object and talk to the domain (locate a service etc.) and if you want
to provide some runtime resources you create a node and add it to the
domain.
+1 and I'd like to start with the following simplifying assumptions:
- A node belongs to a domain, you specify the domain when you create the
node, the node does not migrate from one domain to another
- A node does not have complicated lifecycle operations, a node is
created, configured with a composite and the contributions needed by the
composite, runs off of that, then dies or gets recycled. In other words
a node is immutable.
This of course is currently hidden by the SCADomain interface. This
separate domain/node view is inconvenient and looks heavyweight if you want
to write a quick sample so maybe having this convenience of single method
construction is good but under the covers that is my mental model of what is
going on.
Well, I think we have two use cases:
- I want to deal with the node myself, I create a node, configure it
with a composite and contributions, start it etc.
- I don't care about nodes, I go to the domain, contribute
contributions, declare composites, then just ask the domain do start my
composite, however it wants, wherever it wants. To do that the domain
will have to create one or more nodes under the covers, configure them
with the composite and contributions, start it etc. But as a user of the
domain, I'm not exposed to nodes at all.
We also need management interfaces for adding contributions, controlling
components etc. We did this before by providing operations that returned
management objects, as the current SCADomain interface does, but there were
objections to this approach.
We will need management interfaces, but I think we should know where
we're going with the basic concepts and experiment with simpler APIs -
just two interfaces Domain and Node - before adding more APIs.
...ant
Simon
To help with the discussion, I put my thoughts around domain and node in
code there:
Samples showing node and domain use cases:
http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/sebastien/java/sca/domain-and-node/samples/
Strawman node and domain interfaces:
http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/sebastien/java/sca/domain-and-node/org/apache/tuscany/sca/node/
http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/sebastien/java/sca/domain-and-node/org/apache/tuscany/sca/domain/
Thoughts?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
