More comments inline :)
Raymond Feng wrote:
I'm a bit confused by that your statement in :
6. Mark http://store#store as deployed. Store has a reference to a
CurrencyConverter service (from composite http://cloud#cloud which is
not in my domain yet) so it shows a red-x and appears disabled.
In this case, the target service is not in my domain yet, but it
shouldn't prevent http://store#store from being assigned to a node to
start the composite.
My view is that this case should prevent assigning http://store#store to
a machine, in the next few months at least.
Having a reference is the expression of a requirement (i.e. I need the
function behind the reference to be available to perform my job).
Assigning a component with a dangling reference to a processor and
starting it is just violating that requirement, like trying to run a
Java class with compile errors.
I'm not saying that we'll never have to look into that kind of dream
dynamic scenario, but I'd like to start with reality before attacking
that dream.
The relationship between the reference and service
is loosely-coupled, right?
Can you help me understand your definition of loosely coupled?
It could be a warning though.
I assume when we select a deployable composite from a contribution, we
just have to create a collection of contributions required to deploy the
composite. Let's say let have two deployable composites
http//store#store and http://cloud#cloud. It could end up with two
downloadable zips: store.jar & assets.jar for store composite and
cloud.jar & asset.jar for cloud composite. One zip can be downloaded to
machine 1 and the other goes to machine 2.
Yes. We could also put some of the pieces of runtime required to run the
composite in that zip.
There is no need to check if
a reference in store composite can be fulfilled by a service in cloud
composite.
If somebody has declared a reference, that was for a reason: express the
requirement to have a service wired to that reference so I'd prefer to
check for now.
Also until the reference is satisfied you may not know which binding to
use, thereby preventing you to select the correct machine equipped with
the necessary software to support that binding.
Or the GUI could select the required
contributions/composites as we mark one deployable composite.
We could do that, except that the required composites might not be
available in the domain yet.
I should say required contrbutions.
Yes, when you select a composite, the UI could highlight the
contributions required by the contribution containing that composite.
[snip]
9. Select http://cloud#cloud and associate it with machine2.
Cloud.jar and assets.jar are downloaded to machine2 and machine2 is
configured with http://cloud#cloud.
Who initiates the download? Is it a pull or push model?
I was thinking about push: the domain triggers the download.
To avoid over-engineering this too quickly, how about starting simple
and just generating a zip of the artifacts and let the administrator
FTP and unzip it on the target machine?
In other words I think we need to be comfortable with executing the
install / resolve / deploy / configure / distribute steps manually
before trying to automate them.
It's import to keep all these steps separate and manually operatable.
Exactly.
For example, we could expose management services over JMX, and the
control be invoked from any JMX-enabled consolse/command line.
Not sure about JMX yet, I'd like to understand what the individual steps
are before picking a specific technology to implement them.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
