avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen McConnell" <mcconn...@osm.net>
Subject Phoenix Block
Date Wed, 28 Nov 2001 15:08:35 GMT

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:mcconnell@osm.net 



--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message