On Dec 12, 2007 11:51 AM, Mike Edwards <[EMAIL PROTECTED]> wrote: > Folks, > > Jean-Sebastien Delfino wrote: > <snip> > > > > That was the intention :) a node would be: > > > > <component name="myNode"> > > <implementation.node composite="my:composite"/> > > </component> > > > > You could also extend the idea to do: > > > > <component name="myNode"> > > <service name="xyz"> > > <binding.abc...> > > </service> > > <implementation.node composite="my:composite"/> > > </component> > > > > where the <service> could represent: > > - technical services offered to manage the node > > - or a description of the business services offered by the composite > > loaded into the node (reflected from the composite) > > I think that it would be best to have implementation.node offer a set of > services which relate to its activities as a node (ie node management) > and NOT the business services offered by the artifacts deployed onto the > node. > +1. The composites we have currently that describe the node and domain independently have only "management" type interfaces (I have management in quotes here as they are internal interfaces and not WSDM or JMX etx type interfaces which would normally be associated with the word management). This seems to work Ok. Looking at what Sebastien committed I have started down the track of assuming that the composite description that the domain reads describes how the domain is constructed from nodes and doesn't describe how the applications that the domain runs are constructed.
> > > > > > (I'm not sure which way to go, would be good to explore both, but that > > was the general idea) > > > > and where my:composite could <include> other composites > > > > (if you decided to load multiple composites into the node). > > > > I'm not convinced that the domain needs to track which contribution has > > been loaded into each node, as it can be deducted from the composites. > > I think that it is valuable to consider a node having a service which > returns a list of the artifacts running on that node. +1 - Although the domain could do this on behalf of the node as it knows what is deployed to the node > > > There is a need also to bridge between the Domain configuration and the > artifacts on the node. Currently the only thing that the domain doesn't know is the service endpoint information that the domain relies on the node provide. We haven't investigated any scenarios where the node has artifacts that are not also available to the domain in some way. Do you have specific examples of artifacts that you are thinking of here? > > > The discussion above leads me to think that only "whole composites" are > deployed to a node. In general, this should not be the case. Consider > a composite containing both a Java implementation and a C++ > implementation (ie 2 components). I'd not expect these to get deployed > on the same node, but rather be deployed to 2 separate nodes. Yes. We are associating composites with a node at the moment. This may not necessarily be the case in the future. I accept that you may want to describe a composite application where any one node is not able to run all of the components. You would have to achieve this today by putting the components into separate composites and wiring at the domain level. We are just starting to talk about these kind of issues now so we should work up a concrete scenario that we can use to target development activities. We have started down this road by looking at EJBs in the store sample but a simple Java/C++ assembly would be a good test also. > > > Describing this kind of deployment is going to be tricky, simply as any > one node will only have a partial description of what is running. > Perhaps this would be done by the node reporting that it is running a > component with composite X, where all "non local" components are > declared specially, with the actual location of these components is > described ( <implementation.remote node="nodeURL" /> perhaps) >From a runtime point of view we currently have to cope with a similar situation because when we have several composite running on different nodes in the domain then each node is only directly aware of the composite it is responsible for. The domain is responsible for ensuring that component references are set appropriately to target remote endpoints. But you are right I don't know how to describe the deployment of individual components within a composite to separate nodes. As we discussed previously we only currently support the association of composites with a node. A few thoughts. We could allow the association of components with nodes. We could also do some requirement matching, for example, we could ask each node what extensions it has available and only have it run components that will run there. In this way we could still work at the composite level but have the nodes work out for them selves what can be run. I think the first of these is simpler. Can you say a bit more about what you mean by the implementation.remotethought? > > > > Yours, Mike. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
