You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@cocoon.apache.org by st...@outerthought.org on 2003/09/20 17:00:03 UTC
[WIKI-UPDATE] BlockImplementation Blocks Sat Sep 20 17:00:03 2003
Page: http://wiki.cocoondev.org/Wiki.jsp?page=BlockImplementation , version: 1 on Sat Sep 20 14:47:44 2003 by Stefanomazzocchi
New page created:
+ !Design Constraints
+
+ # impact on back compatibility should be minimal, optimally none. that is: everything that worked before the introduction of blocks should continue to work with no required changes (this will reduce migration issues)
+ # the implementation should be incremental and evolutionary. no radical changes in the cocoon architecture should be created (this will reduce the amount of code to write and also provide better regression)
+ # security of the architecture for block managing and deploying is a __TOP__ priority and should be introduced up front.
+ # deployment should be system administrator-friendly. That is: should *NOT* require GUIs or webapps (even if it should allow them to be possible).
+
+ !The overall architecture
+
+ Let's start with the first requirement: security.
+
+ Blocks are functional components at the webapp level. If a user is able to change the block wiring, the user is, potentially, able to execute his/her own code with the same security level of the entire cocoon application.
+
+ For this reason, the block wiring information should be located in a configuration file that is "read-only" by cocoon and "read/write" by the block deployer.
+
+ {{{ +--------+ +----------------+
+ | cocoon | <--- [File System] <---> | block deployer |
+ +--------+ +----------------+}}}
+
+ Note that the block deployer *could* be anything (a CLI, a webapp, an eclipse plugin). The above meets our second requirement: user friendlyness for all types of users.
+
+ Also note that it meets, potentially, the ability for the system administrators to perform actions such as 'staging' and 'cluster replication' by simply performing a file copy. Cocoon should be able to reload the block wiring information if this is changed.
+
+ In order to improve security and avoid DoS, there is *no way* for the block deployer to signal directly information to the cocoon instance (and no way for the cocoon instance to modify the wiring information or to communicate directly with the block deployer). Everything is performed thru the use of the file system.
+
+ !The block deployer
+
+ The block deployer architecture is the following
+
+ {{{ +--------------------+ +------------------+
+ | +-----------+ | | |
+ [FS] <---->| FS Driver | | <-> | User Interface |
+ | +-----------+ | | |
+ | | +------------------+
+ | block |
+ | services |
+ | |
+ | +---------+ |
+ | +---------+| |
+ | | Locator |+ |
+ | +---------+ |
+ +------^-------------+
+ |
+ V
+ block library}}}
+
+ which is composed by four main parts:
+
+ # the file system driver: the part responsible for reading/writing the block wiring information and block configurations, to extract the files from the blocks distrubution archives and physically deploy the extracted files on the file system. There is no need for polymorphism for this part since there needs to be a solid file system contract between this driver and the cocoon block manager (included inside cocoon) which will need to read the block wiring info and locate the files on the file system.
+
+ # the block locator: the part responsible for locating the metadata associated with a given block identifier and thus, provide enough data for the block services and the user interface to drive the installation process. This part needs polymorphism. Potential implemenation of this locator are:
+
+ ** "file system"-based locator: the block metadata and location information is stored in a file on disk.
+ ** "network service"-based locator: the block metadata is provided by a network service (for example, a web service).
+
+ The block deployer can use multiple locators at the same time, in a cascading way: it should be possible to configure the block deployer with the kind of location services and provide a priority for which one to use. This allows, for example, to provide an architecture for block discovery that could work like this:
+
+ {{{block deployer ---> company block library -> cocoon official library}}}
+
+ (a collection of blocks is called a "block library". the application that, given a block identifier, looks up its metadata is called "block librarian".)
+
+ #the block services: the part that is shared by all potential block deployers (no matter how the user inteface is implemented).
+ # the user interface: the part that is driving the block services but it's dependent on the user interface.
+
+ !The Block Manager
+
+ The block manager is the part that is responsible for handling the block wiring information. This is included inside cocoon and it can
+ read and interpret the block wiring information written by the block deployer.
+
+ The block manager is the only part of cocoon that knows how block are wired together and where their actual location on disk is.
+
+ The block manager will be queried by all the cocoon internal services that need to locate block-dependent stuff, that is:
+
+ # the sitemap interpreter: to find out where the blocks sitemaps are mounted in the main sitemap URL space
+ # the block: protocol: to locate the services provided by the blocks
+ # the component manager: to locate components provided by the blocks (either avalon components, sitemap components and virtual components)
+
+
Page: http://wiki.cocoondev.org/Wiki.jsp?page=Blocks , version: 21 on Sat Sep 20 14:35:28 2003 by Stefanomazzocchi
- ''This page is a place-holder. I'm currently collecting together notes on what Blocks actually __are__. I'll be putting relevant links here to begin with, then will create additional documentation as I summarise these additional resources. So consider this a work in progress -- [Leigh Dodds]''
+ Blocks are reusable functional modules at the cocoon web application level.
- See also [BlocksUseCases] -- [Bertrand Delacretaz]
+ Blocks were introduced in Cocoon to allow users to:
- See also [BlockDescriptions] to learn what the different Blocks provide. -- [TonyCollen]
+ * easily deploy their content on cocoon without requiring operation downtime
+ * package functionality and services in modules that can be reused as-is
+ * easily extend existing modules
+ * create complex web applications by high-level composing of these functional modules
+ * depend on module behaviors, allowing for polymorphic module composition
+
+ See [BlocksUseCases] for scenarios of use.
- !Blocks Implementation Workspace
+ !!Blocks Design
+ See [Block Design|BlockDescription] for a detailed look at the block design.
- * [BlocksWiring]
-
- * [BlocksCob]
- !Mailing lists threads about Blocks
+ !!Blocks Implementation Workspace
- * [cocoon-dev blocks discussion (Implementing Blocks RT, August 2003)|http://marc.theaimsgroup.com/?t=106134591200003&r=1&w=2]
+ * [Block Implementation Plan|BlockImplementation] - This document contains the plan for the implementation of the block design.
- * [cocoon-dev blocks discussion (March 2002)|http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101732982704553&w=2] [1]
+ * [Block File System Layout|BlocksFSLayout] - This is an example of the file system layout that will be used as a contract between cocoon and the block deployer.
- * [cocoon-dev blocks discussion (June 2002)|http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102528398016325&w=2]
+ * [Block Wiring|BlocksWiring] - This is an example of the markup used by the wiring document (wiring.xml), created by the block deployer and used by cocoon to load the block wiring at initialization time.
+ * [Block Descriptor|BlocksCob] - This is an example of the markup used in the block descriptor document (block.xml), contained inside the block, that contains the metadata that is used by the block deployer to deploy the block, know its dependendies, the eventual behaviors implemented, the eventual block extended, required parameters, provided components and sitemap.
- *[Quick summary of Blocks (Aug 2002)|http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102941595120561&w=2] -- RossGardler
-
- *[Restating Blocks 1.1|http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103619609805268&w=2], also copied as [a living document|Blocks Definition] into the Wiki -- StevenNoels
- !Related technologies and projects
- * [jjar|http://jakarta.apache.org/jjar/] -- '' JJAR is an acronym for Jakarta JAR Archive Repository, an attempt at making a CPAN-like service/infrastructure for the Java development community.''
+ !!Implementation Phases
- * [Deployment on JBoss|http://www.jboss.org/online-manual/HTML/ch13s72.html] -- interesting to compare with the requirements for Blocks.
+ __Phase 1__: definition of the contract between the block manager inside
+ cocoon and the standalone block deployer. These contracts include:
- * [Debian apt-get|http://www.debian.org/doc/manuals/apt-howto/index.en.html] -- ''In the beginning there was the .tar.gz. Users had to compile each program that they wanted to use on their GNU/Linux systems...'' \\Sounds familiar, doesn't it?
+ # description of the [file system layout|BlocksFSLayout] (__done__)
+ # description of the [block wiring|BlocksWiring] schema (__done__)
+ # description of the [block descriptor|BlocksCob] schema (''in progress'')
+
+ __Phase 2__: definition and implementation of the block data model, with
+ reading/writing capabilities
+
+ # implementation of the block wiring data model
+ # implementation of the xml -> data model parser
+ # implementation of the data model -> xml serializer
+
+ Note: since the xml formats are not meant to be human editable, roundtripping of comments or formatting included in those xml files should not be a priority.
+
+ At this point, implementation can work parallel:
+
+ __Phase 3 - cocoon side__: implementation of block support.
+
+ # implementation of the BlockManager
+ # implementation of the block: protocol handler
+ # implementation of the link transformer
+ # implementation of the reload watchdog
+
+ The link transformer has to be "block-aware" in order to identify where other blocks are mounted]
+
+ Note: during this phase, development can happen with an handwritten and extracted block wiring info and block descriptors.
+
+ __Phase 3 - deployer side__: definition of the interfaces between the components
+
+ # the Locator interface
+ # the Block services interfaces
+
+ __Phase 4 - deployer side__: implementation of a basic block deployer
+
+ # implementation of the block services
+ # implementation of a "file system"-based locator
+ # implementation of a command-line user interface
+
+ __Phase 5 - deployer side__: implementation of a webservice block librarian
+
+ # implementation of a REST-style web service locator
+ # implementation of a cocoon block that implements block librarian capabilities
+
-
- [#1] ''I think here's the [summary|http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101862084628687&w=2] of this March 2002 discussion''
- -- [Bertrand Delacretaz]
+ Blocks are not active nor passive. Just like electronic chips, they are useless by themselves, but provide functionality if properly connected with an external system. This is not the behavior of engines, for example, which are active by themselves. Calling them components would create conflicts. Blocks are not used anywhere. While this could create a problem at first, later it's a good thing because it would make the terminology very precise for what we mean blocks are.
+ -- [Stefano Mazzocchi|stefanomazzocchi]
+
+ ----
+
+ !Related technologies and projects
+
+ * [Debian apt-get|http://www.debian.org/doc/manuals/apt-howto/index.en.html] -- ''In the beginning there was the .tar.gz. Users had to compile each program that they wanted to use on their GNU/Linux systems...'' \\Sounds familiar, doesn't it?
+
+ * [Maven|http://maven.apache.org/] -- maven uses a centralized repository for functional modules (jars in this case).
+
+ * [jjar|http://jakarta.apache.org/jjar/] -- JJar an attempt at making a CPAN-like service/infrastructure for the Java development community.
+
+ * [Deployment on JBoss|http://jboss.sourceforge.net/doc-24/ch11s72.html] -- interesting to compare with the requirements for Blocks.
+