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
