I'm not sure the 1.x domain manger does what we need in 2.x now that the domain is really distributed and dynamic so I'm going to continue looking at adding support for distributed imports/exports using the existing 2.x distributed registry.
...ant On Sat, Feb 13, 2010 at 8:15 AM, Raymond Feng <[email protected]> wrote: > I would suggest that we port SCA Domain Manager from 1.x into 2.x and evolve > it into a SCA Domain Provisioning Service which can provide metadata for > Nodes within the SCA domain to meet the SOA Governance requirements. > Ideally, such service can give us a RESTful view of the SCA domain metadata, > including the following resources: > > * Domain composite > * Policy definitions > * Installed contributions > * Deployable composites > * Node configurations > * ... > > Similar with the EndpointRegistry for runtime endpoint descriptions, the > Provisioning Service can be built on top of the same infrastructure to > support different schemes of communication (such as multicast, wka, central > server, etc). We can extend EndpointRegistry to be a DomainRegistry so that > other entries than Endpoints can be shared. Personally speaking, I'm leaning > to centralized management of the SCA domain over the P2P based approach on > the Provisioning/Governance perspectives. > > Thanks, > Raymond > -------------------------------------------------- > From: "ant elder" <[email protected]> > Sent: Friday, February 12, 2010 11:02 AM > To: <[email protected]> > Subject: Re: Imports and exports in the distributed domain > >> On Thu, Feb 11, 2010 at 6:43 PM, Raymond Feng <[email protected]> wrote: >>> >>> Conceptually, the contributions are known to the SCA domain. But they >>> don't >>> have to be physically stored with the nodes or a central place. We adopt >>> the >>> URL idea to represent physical locations of contributions. A node just >>> needs >>> to know a list of URLs for the contributions that can be loaded locally >>> or >>> remotely. The list of contributions can be built following the >>> import/export >>> statements of the installed contributions within an SCA domain. >>> >>> Now it's a matter how a Node gets its contribution URLs. Such information >>> is >>> part of the node configuration, which can be provided by one of the >>> following ways: >>> >>> 1) A local node.xml file to list the contribution locations >>> 2) Programmatically configured using the NodeConfiguration model >>> 3) Locally discovered from the classpath >>> 4) Provisioned from the SCA domain dynamically >>> >>> We already support 1, 2, and 3. Once we port SCA Domain Manager into 2.x >>> and >>> (potentially) reuse the DomainRegistry to share the metadata in addition >>> to >>> the runtime endpoint descriptions, we can support 4). >>> >> >> From that list (4) is most interesting to me. I think we should >> discourage (3) as it circumvents SCA by having the contributions on >> the classpath (and only works for jar contributions), and (1) and (2) >> are less useful in a dynamic domain environment and will be less >> needed if we have (4). So, to get (4) working are there any >> alternative proposals for how to get it working or modifications for >> what I suggested earlier in this thread? >> >> ...ant > >
