On Thu, May 28, 2009 at 5:26 PM, Raymond Feng <[email protected]> wrote: > In addition to the domain centric vs node centric view, there are > potentially two different level of functions that are provided by the SCA > domain. > > 1) Deployment: Manage SCA contributions, composites and node configurations. > > This is the deployment manager that helps SCA assemblers/deployers to > partition the domain composite into smaller composite applications that can > be deployed a specific runtime unit. For example, the administrator can > starts with a deployable composite. The domain manager can then find the > required contributions based on the import/export. The composite application > can then be allocated a node. It ends up with a configuration for a node.
Sounds good. I think this is what the domain manager does today. > > A node can have a fixed configuration to a given composite application. Or > the domain can assign a composite application to the node dynamically based > on the capability of the node (such as implementation/binding/policy types). Agreed. We haven't done this dynamic assignment to date. Probably not the top of the list this time as we should probably think about the wiring dynamicity first as per you RFC119 type scenarios. Interesting point though > > In a node-centric view, node configurations can be manually crafted > (programmatically or via node.xml) or locally discovered (from the > classpath). I would be pretty handy also if the node could tell the domain what it's configuration is without manual file editing, e.g. what it's name is, what ports is provides for what protocols etc. > In a domain-centric view, node configurations are received from the domain > (by connecting to the domain deployment manager or taking a pre-built xml > document). > > 2) Runtime: Share service descriptions so that we can perform SCA > domain-level wiring. This can be done in "online" mode or "offline" mode. > > Online mode: There is a live service registry (centralized or distributed) > that keeps up-to-date information of the domain-level service descriptions. Yes, that's what we don't have today. > Offline mode: The domain-level service descriptions are pre-built (or even > pre-resolved) and a SNAPSHOT of that is used. For example, some XML > documents (such as a deployment composite with all the SCA endpoints) > resolved are used to store the domain metadata. And in this case the configuration is static?
