On Feb 12, 2007, at 2:48 AM, Simon Laws wrote:
Thanks Jeremy for commenting. I am of course now looking back
through the
archive and seeing that discussions are underway. Doh, sorry about
that.
From the distributed assembly [1], federated deployment [2], physical
component definition [3] threads I think I'm starting to appreciate
the
proposed direction. There is a fair amount of detail to digest and I'm
struggling a little to separate out the generic bits from guts of
what's
changing in Java.
From a native point of view I guess we need to understand
1/ How we employ JXTA to join the SCA federation
Can't help there - there's allegedly a C++ implementation which is
why we picked it but I don't know much about it
2/ The format of the physical model
On the wire where interop matters, it is a set of XML objects. The
runtimes exchange simple XML messages over JXTA to communicate. We
use strict versioning of the elements to identify model elements, and
tie them to the actual implementation.
3/ How we advertise our capabilities (supported components etc.) in
order
that "scheduling" decisions can be made.
Still thinking about that :-) Meeraj had some ideas.
4/ The nature of command and control system, start, stop etc.
More messages, probably using JXTA multicast.
You'll note I'm not proffering an opinion here. I've much to learn
yet:-)Maybe
we can start getting a more generic description up on the Cwiki. I
looked
and couldn't see one. I may of course be looking in the wrong
place. If
there isn't one I'll start putting notes up there as I find out
things.
As you can tell, we are still in the early stages with a lot of
this. The discussion is on the mailing list and through code but
capturing stuff on the wiki/website would be good.
Am I right in saying that you consider deployment, i.e. actually
getting
component implementations onto distributed boxes, to be a separate
issue
from the federation of active runtimes already configured with
implementations.
I hate "deployment" as it means different things to different people.
My view is that federation is about running and managing components
in a distributed environment. It's the components we are interested
in from a domain perspective. Those components have dependencies on
code artifacts in order to run (e.g. their implementation code) and
so that needs to be present. How it gets there is the responsibility
of the federation - it may be pre-installed, or it may be installed
on demand.
The spec is taking a similar tack with the separation of
Contributions from Assembly.
I'm not immediately sceptical of the java stuff. I have to say I don't
understand the details. I think the value though is if we can have the
native runtime play too so I'll look there first. I note from the
mail trail
that Pete is also interested in this.
[1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/
msg12900.html
[2] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/
msg13607.html
[3] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/
msg13830.html
Yeah. No need to get Java cooties when there is a lot to do on the
native side too :-)
Agreeing on the macro-architecture for the federation is the key -
the runtimes themselves should be able to evolve separately based on
different physical issues.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
