cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] Cocoon web applications
Date Sat, 06 Oct 2001 14:13:55 GMT
This thread is become really good.

Michael Hartle wrote:
> 
> Hi,
> 
> I guess that adding practical examples and consequences to the
> suggestions will help discussing the concepts at a broader scale. I just
> love examples that can be torn in half and rebuild.
> 
> Ok, asbestos underwear in position - here we go:

Sam, seems like people liked this expression very much :)
 
> 1.) We want easily deployable packages, just like .war or .ear files in
> other contexts. For Cocoon, this would be .cwa files; I guess it's just
> a zip file with some information relating to the package, like a
> MANIFEST in a .jar file. I would consider this extra information to be
> at least a sitemap.xmap that controls the sub-URI-space of the package.

I share your vision totally.
 
> 2.) We want these easily deployable .cwa packages to be self-contained.
> I consider modifying a package for setup issues impractical, so the
> setup for a package should happen outside of the package. Inversion of
> control, Avalon principle ;). At the same time this allows a single .cwa
> package file to be setup and deployed at multiple places at the same time.

Ditto.
 
> Some setup like mounting could happen in a sitemap.xmap, as currently
> this is the place controlling URI space; this even allows for an
> auto-mounting extension for the sitemap. Many packages will require
> setup beyond mounting, for example where to find the corporate identity
> stylesheets, which accounting database to use, or what's the business
> name to be put on the tax report thats being produced, so I need both
> the information about what I CAN configure and what I actually DO
> configure for this package.

Again, I was thinking about IoC: have the CWA ask Cocoon about things it
needs instead of having you to modify the things after setup.
 
> I think of the former as sort of a standardized setup-info.xml or the
> like regulary contained in .cwa packages that have something to be
> configured. The latter could be an configuration file positioned
> somewhere near the sitemap.xmap and cocoon.xconf files in the
> filesystem. One might even refer to the configuration file from the
> sitemap, so the way the configuration files are being organized is left
> as a choice to the system administrator.

I recently came to know MacOSX NetInfo package and found it *very*
elegant (much more elegant than the 30-years old /etc directory,
anyway): it's a short of directory server that contains configuration. A
sort of elegant and simple configuration registry (unlike windows') that
is used to "serve" configurations to who it requires them.

It provides a central point of configuration and an easy way to deploy
something without having to modify it.

The contract is the internal tree shape (sort of URI space for
configurations) and CWA might look for configurations in there. For
example in a sitemap

 <map:parameter name="database"
value="conf://datasource/relational/main"/>
 <map:parameter name="user"
value="conf://datasource/relational/main/user"/>
 <map:parameter name="password"
value="conf://datasource/relational/main/password"/>

something like that. 

It is also pretty easy to scan the CWA for conf:// protocols and
understand if the registry contains already the information or needs to
prompt the installer for it.

This way, security sensible information is stored by Cocoon in another
location, probably out of the addressing space, making it inherently
more secure (it might even attach directly to an LDAP server, for that
matter).

> 3.) As the .cwa package does not know in advance where it will be
> deployed, it cannot know about the URI space it will be accessable from
> via the web, yet most content needs to point to other content in this
> package, for example just simple links from HTML page A to HTML page B.

I'd assume that the URI structure of the CWA package can be considered a
contract. So, the only "soft" thing is the location where this "hard"
URI tree is mounted.

> If  resource names of pipelines were added to the sitemap which are
> local to the package/sitemap, the .cwa designer could just use resource
> names in his package and have them resolved later via taglibs in a page
> or other means in the sitemap like a cocoon-protocol extension like it
> was posted for role-based access.

Exactly, we still have to define "how" those "soft"+"hard" links are
actually translated to real URL addresses, but we agree on the mechanism
and this is a good thing.
 
> 4.) .cwa packages will rarely be on their own, not interconnecting. So
> resource naming would need to work between .cwa packages. Giving each
> deployed .cwa package a global name, the local resource name for a
> pipeline could be referenced from another position.

You touch another important point here: if on one hand, addressing by
role must not sacrifice the ability to have multiple instances for the
same role, on the other hand, must be precise enough to avoid name
collisions.

This is the same problem faced by by both java dynamic loading and xml
namespaces: both use URI's as unique identification.

Avalon, for example, uses the inverse dot notation (in short, the
interface name, i.e. org.apache.cocoon.component.Parser) to create
unique behaviors identified by the interface that represent them.

Same thing for namespaces, in fact the xmlns attribute is a way to
reduce verbosity but doesn't change the nature of the internal infoset
which assumes that all elements are prefixed with the URI that uniquely
reference them.

So, each CWA must indicate both:

 o its unique role
 o its instance identifier

For example, a webmail CWA could be identified by

 http://apache.org/cocoon/webapp/webmail
 My Fancy WebApp 2.3

Now, the problem is that we cannot impose the use of something like

 cocoon://[http://apache.org/cocoon/webapp]/some/resource

but one solution would be use (abuse?) the XML namespace mechanism

 <element xmlns:webmail="http://apache.org/cocoon/webapp"
          href="cocoon://webmail/some/resource"/>

where we extend the default namespace behavior to do namespace
resolution even inside the attribute content. In fact, even XSLT does so
when doing
 
 <xsl:template match="ns:element" xmlns:ns="...">

and ns: is matched not by the prefix, but by the expanded namespace URI.

As far as uniqueness is concerned, the above mechanism works, but if we
want to allow more than one instance of the same role, we could indicate
so like this:

 <element xmlns:webmail="http://apache.org/cocoon/webapp"
          href="cocoon://webmail:mywebapp/some/resource"/>

But this creates a composition problem: one CWA must know in advance the
instance-specific name of the other CWA. Since this is controlled by the
CWA deployer and cannot be hardcoded (unless we accept name collisions),
this is a weak contract and it's very likely to break everything very
soon. (with a very hard time figuring out what to do).

So, here is my solution (that closely follows the strategy we designed
for Avalon blocks):

  each CWA indicates
    o  its role as a URI  (http://apache.org/cocoon/webapp)
    o  its name as a human readable form  (My Fancy Webapp)
    o  its version as major.minor format (2.3)
    o  its dependancies on other CWA (role:version)
    o  its dependencies on external configurations

when the CWA is deployed, the following things happen:

 1) the CWA deployment descriptor is read

 2) a machine specific name is given to the deployed instance. (if
another CWA of the same role:version pair is already in place, the
instance name must be unique, for example, adding a counter at the end
such as "http://apache.org/cocoon/webapp:2.3:2"

 3) for each CWA dependancy do:
  3.a) check if a CWA with that role is already in place.
  3.b) if so 
    3.b.i) if only instance of that role, map the role to that instance.
    3.b.ii) otherwise, prompt the deployer and ask for which available
instance should be associated to that role.
  3.c) otherwise, use the role URI to download the required CWA [we can
define how this is done later] and deploy it.

 4) for each configuration dependancy do:
   4.a) check if the configuration key already exists in the conf
registry
    4.a.i) if so, prompt the user if the available value is ok
     4.a.i.1) if so, go on
     4.a.i.2) otherwise, change the value associated to that
configuration and relative to that instance only.
    4.a.ii) otherwise, prompt the deployer for the conf value

 5) the deployer is finally asked for a URI location to mount the CWA
instance.

NOTE:

 1) possible recursive dependancies might create a deadlock on the
deployment phase, expecially when the Cocoon container is initially
empty. This is unlikely to happen for well designed components, but we
can download and scan all required CWA for deadlocks before actually do
any real deployment so that problems can be stopped *before* entering
the system.

 2) if more than one instance of a single webapp is available, the conf
registry must be smart enough to lookup a configuration based not only
on the requested path but also on the webapp instance that has requested
it. This avoid collisions due to the fact that different instances of
the same role by definition share the same configuration needs.

> I guess there are plenty of opportunities to discuss what can be done
> better or easier differently, so let's hear them.

The only thing that is left to discuss is how (who does it and at what
level) the address translation between roled-based access and real URI
address is performed.

Everything else looks in pretty good design shape to me, but of course,
comments are more than welcome.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message