I've been thinking about a Phoenix Block for some time. That is
to say a Block that encapsulates the phoenix kernel and runs
within a Phoenix application. This would enable the creation
of block hierarchies. For example, imagine have a block which
provides the establishment of a context for a set of subsidiary
blocks - if I stop/suspended the parent block, all subsidiary
blocks would be stopped as well. Removing a parent block would
imply removal of child blocks. This approach enables a separation
of functional units - dependencies at the level of an application
can be encapsulated and separated from external operational
dependencies and public services.
Example:
Main Application
|
|--TimeService Block
|
|--NamingService Block
|
|--PKI Application Block
| |
| |-- Certificate Repository Block
| |-- CertificationAuthority Block
| |-- RegistrationAuthority Block
|
|--Collaboration Application Block
| |
| |-- User Block
| |-- Task Block
| |-- Message Block
| |-- Processor Block
| |-- Workspace Block
| |-- Commumnity Block
| |-- Encounter Block
|
|--Customer Solution Block
|
|-- BusinessProcess-1 Block
|-- BusinessProcess-2 Block
|-- BusinessProcess-3 Block
This raises a few questions:
1. Does anyone know if there is any similar or related development?
2. What is good starting point in-terms of the
existing Phoenix platform classes/interfaces.
- initial throughts are that thgis would look something like
a varient of the PhoenixServlet/SingleAppDeployer
3. Are there any major problems that are likely to be encountered?
4. Is a nested environment.xml necessary/desirable?
5. What elements/features of a application-block should reside
at the root phoenix level (e.g. extensions directory, logging,
etc.)
Cheers, Steve.
Stephen J. McConnell, OSM sarl
digital products for global business
http://www.osm.net
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
