Thanks Jeremy.
Mario, I think Jeremy has covered most of your points. If you need any more
clarifications or have further queries, please feel free to ask. As Jeremy
said, any help in these areas, ongoing and/or especially in the next two
days :) will be highly appreciated.
Ta
Meeraj
From: Jeremy Boynes <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: [email protected]
Subject: Re: Understanding Service Discovery
Date: Fri, 16 Mar 2007 18:53:14 -0700
On Mar 16, 2007, at 2:03 PM, Antollini, Mario wrote:
Hello Meeraj,
I have read several emails and I got to know that you are working on the
Discovery service. I am very interested in this topic and I will like to
get a better understanding about it.
Great to have you involved.
I have seen that you have also mentioned the Federated Deployer,
Federated Assembly and Marshaling Framework throughout your posts. I
think all these components are somewhat connected to the Service
Discovery mechanism, aren't they? I will really appreciate if you can
give me some details on how they all interact, if they do so at all.
And, I will also like to understand the big picture here; i.e. what is
the main goal you are trying to achieve with all that. In addition to
that I will like to understand the role JXTA plays here and how it also
interacts with these components.
Their interaction is only indirect - they are more just using it as a
transport.
The discovery layer is responsible for determining which runtime processes
are participating in the federation at any time. We're using JXTA for that
as it is a standard peer-to-peer protocol and is available in many
different languages, specifically both Java and C++ which are the two
runtime implementations we have in Tuscany. We also want other protocols
to work as well (for example, Bonjour or JINI) but want to get one working
first.
As well as tracking the available processes it also provides a mechanism
for allowing those processes to exchange messages and we are using that to
send management operations across the system fabric.
Some of those management operations are associated with federated
deployment. SCA's deployment model is based on the concept of changes to
the domain assembly (e.g. include composite). Our implementation of that
routes those changes to the controller nodes (at first one, next
replicated, finally distributed) which take those logical changes and
convert them to the physical ones that need to be made on participating
runtimes. With the JXTA-based fabric, those are XML encoded JXTA messages;
the marshalling framework is all about converting between those messages
and the internal data structures (physical model) used by the Java runtime
(C++ does not support this yet).
The federated deployer is a runtime node service that receives
demarshalled change set messages from the fabric and applies the changes
they contain to the local runtime - basically creating, removing
resources, components and wires.
At the moment there's no interaction between JXTA and user components but
if that was useful then we would just need to create a transport component
implementation and wire attacher on the physical side and the binding
support on the controller side.
Finally, I would like to know which is its is (i.e.; what it is already
able to do, what parts are missing, if you are willing to receive any
help, you are planning to get it ready for M3, etc).
We are in heavy development right now planning to show it working next
week at TSSS - any help would be appreciated, both now and ongoing. All of
this is happening in trunk for the 2.0-alpha2 release.
As you saw I am asking way too many things, however I will be really
glad if you can answer at least some of these questions.
Hope I covered the key points.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
MSN Hotmail is evolving - check out the new Windows Live Mail.
http://ideas.live.co.uk/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
