cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject [RT] Componentizing Cocoon Applications
Date Sun, 03 Feb 2002 15:34:43 GMT
Cocoon is currently a publishing framework, meaning that is somewhat
more powerful for stateless resources than for stateful ones.

I strongly believe that Ovidiu's work on Schecoon will (sooner or later)
bring balance to this picture, allowing Cocoon to be as powerful with
stateful resources than it is today with stateless ones.

This considered, the concept of 'cocoon application' is to be extended
to include all possible sums of stateful and stateless resource serving.

These RT are based on the assumption that the above is true and try to
address the future needs for cocoon application design, programming,
debugging, refactoring, maintenance, installation and deployment.

                              - o -

Cocoon has been described as a 'framework', a 'pipeline engine' and even
as a 'web operating system'. While one can disagree with these
metaphors, one thing is common between these descriptions: cocoon runs
your applications.

Well, to be honest, today Cocoon runs 'one' application, or, in some
circumstances, a disorganic collection of independent applications
sharing the same URI space.

This reminds me of the trend that appeared on software system: the first
systems were monolithic monotasking environments, then started to appear
multitasking environments, preemptive multitasking (IoC anyone?) and
more recently, component based environments and distributed component
based environments.

In order to grow architecturally, I strongly believe that cocoon must
allow (not force, allow!) the componentization of the applications it is
capable of running.

Why this? in order to allow easier reuse of modules, both in different
applications running at the same time, both in different applications
developped in different times.

I also believe that Cocoon should wait to enter the 'distributed' realm
until this componentization effort is finished. Doing it *before* might
be extremely dangerous (this is the same pattern we followed for Avalon:
get strong locally first, then think of growning distributed)

                              - o - 

Cocoon is an avalon application and avalon applications are
componentized and avalon forced you to design your applications thinking
about the components that make it up.

I would like to do the same with Cocoon applications, just at another
level: Avalon concentrate on modularizing the programming logic, Cocoon
must induce cocoon application designers (I can't talk of programmers
since it should not be a programmer to design a cocoon application but
an entire team sharing different concerns) to modularize their stuff.

But how is a component model for cocoon applications useful?

1) components can be defined behaviorally: in Avalon, if you need a
Store, a Logger, a ThreadManager, a Clock, etc... you just ask for a
component that performs that 'role'. Avalon takes care of everything
else, just hands you the component that you need to do your job. In
short, it reduce concern overlapping between the composer (who uses the
component) and the component. 

I would like the same to happen in Cocoon: a webmail written as a cocoon
application will require user authentication and authorization, mail
transport facilities (both to IMAP and to SMTP), skins, a persistent
repository for user preferences, a persistent repository for addresses
or a connection to the addressbook storage (LDAP, for example), a
connection facility with the server side filter engine (Sieve, for
example), etc...

Being a programmer (like it or not), the 'axis' I use to componentize a
web application is normally the functionality (the logic concern realm).
My personal experience tells me that this is almost never the case for
other types of individuals: graphic designers will divide components
depending on graphical attributes, wording editors will divide
components depending on verbosity and other word attributes
(informative, activity, indications), usability engineers will divide
components depending of the complexity of their flow.

The question is: since these diffenent componentizations *always*
cross-cut, can Cocoon make it possible to have all these coexhist?

I believe so.

The only price to pay is an increased number of contracts between the
different realms and a consequent higher frequency of redesign and
refactor (which might also turn out to be healthy)

Let's make an example: suppose you have three concern realms A,B,C each
with a different 'component' view of the problem and some overlap.

 A           [                    |    |           |    ]
 B           [  |               |            |          ]
 C           [        |           |       |  |          ]

the idea is to have a higher granularity of componentization

             [  |     |         | |    |  |  |     |    ]

and then somewhat glue togheter the components in the same realm

 A           [  *     *         * |    |  *  *     |    ]
 B           [  |     *         | *    *  *  |     *    ]
 C           [  *     |         * |    *  |  |     *    ]

An example of such a 'glue' is content aggregation: things that were
componentized at the 'logic' level are glued back together at 'content'
level.

The drawback is that we have a higher number of 'marks' in the picture
(both '*' and '|') and each one of them is a contract, so eventually
requiring changes and possibly impacting more than one concern island.

                                  - o - 

Now that we have identified the theory, let's try to dive into the
practice.

Suppose we have a simple web site and we want to make it skinnable.

We decide to have a higher order modularization separating 'content'
from 'style' and using the markup schema and the location of the
sytlesheets as a contract between the two components.

The flow of composition is that 'content' requires a 'skin' in order to
be functional.

So, we have component 'MysiteContent' that implements 'Content' and
requires an instance of the component 'Skin'.

We deploy 'MysiteContent' on top of Cocoon, indicating where we want to
mount it (let's say '/' which is the root of the addressing space
handled by Cocoon). 

The deployment descriptor of 'MysiteContent' will indicate that it
requires an instance of 'Skin' in order to operate. Cocoon will prompt
for a list of components that implement the 'skin' role and allow you to
choose between them.

if none is present, you will be asked to provide one.

Of course, this is just an example of functionality: it could be
entirely possible to deploy an entire application with all the required
components inside, but this is just implementation details.

But what does it mean, in practice, that the 'CoolSkin' component
implements the 'Skin' role?

Let me make a sitemap example to see what I envision:

 <match pattern="*.html>
  <generate src="docs/{1}.docbook"/>
  <transform src="[skin]://docbook/docbook2html.xslt"/>
  <serialize/>
 </match>

where the absence of 'protocol' information indicates that the component
should look into its internal addressing space, while the [***]: virtual
protocol indicates that you should connect to the implementation of the
'skin' role that you have choose at deployment time.

So, what is the contract here? the location of the stylesheet in the
internal addressing space of the 'skin'-implementing component.

The above gives us:

 1) complete separation: components are totally independent as long as
their contracts are not touched
 2) polymorphism: I can have multiple implementations of the same role
and decide (even at runtime!) what to choose.
 3) total reuse across different apps: I could use the same module for
different installations and webapps (think of
authentication/authorization module

Last but not least, these components must have the ability to install
new java components into cocoon without having to modify the cocoon
installation.

if a webapp requires a special hand-written transformer, this should be
installed along with the deployment descriptor and might even be little
as having one cocoon app component as one cocoon component.

Ok, enough for now.

Awaiting for your comments!

Ciao

-- 
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