cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robin Green" <>
Subject [RT] Flowmaps, propagation, and aspect-oriented data processing
Date Fri, 16 Mar 2001 03:09:00 GMT
Next week I'm giving my debut presentation to my (academic) department's 
Human Factors group on Cocoon2 and "Human Separation of Concerns", so that's 
given me an impetus to seriously spend some time thinking and contributing, 
particularly as regards flowmaps.

This is quite long so I've split it into 4 parts:

Message summary:

Part 1. Yes, Virginia, Cocoon 2 _is_ aspect-oriented
Part 2. Another advantage of flowmaps - autopropagation
Part 3. OK, propogation works for security - where else does it apply? Ideas 
needed here!
Part 4. What about the "principle of least surprise"?
Appendix. For those who need reminding what a flowmap is.

Having finally looked at the C2 docs/samples for the first time (yes, 
despite being a cocoon committer, I've previously focused entirely on C1!) I 
am immediately struck by the impression that Stefano and Allan are 
absolutely right to characterise C2 as already aspect-oriented. And it's not 
just a case of fixed, predefined aspects either (like content, logic, style 
and site admin), as I first thought.

<map:match> is somewhat analogous to AspectJ's advice. The former allows you 
to have a group of URIs, specified by a pattern, handled by the same 
pipeline; the latter allows the insertion of common behaviour (such as 
logging) at the start or end of methods or in exception handlers, for 
example. In other words, one obviates the repititious and redundant pipeline 
processing instructions of C1 days, and centralises them in a sitemap; the 
other obviates repititious and redundant code in general, and centralises it 
in an aspect. (Both do much more as well, of course - the reduction in 
repitition is hardly the only important advantage!)

Just as with database normalisation, this reduction in repitition (if done 
appropriately) reduces the likelihood of error in keeping all the copies 
present and correct, and may be conceptually simpler and/or result in a 
clearer overview of the entire system. This is in addition to the 
oft-repeated advantages of facilitating division of responsibilities.

Some might argue that <map:match> "doesn't count" or "is trivial" as an 
aspect-oriented tool, because it "only" crosscuts data, not code. 
Admittedly, the sitemap code probably is much simpler than the AspectJ 
weaver, because its task is only to match requests with pipelines - not to 
read and modify existing classes. However, I intend to argue in my 
presentation that data-centric, as opposed to code-centric, separation of 
concerns is a worthwhile research area (which has significant overlaps with 
its code-centric cousin) - especially given the substantial productivity 
gains systems like Cocoon can bring.

2. One advantage of flowmaps (see foot of email for a copy of Stefano's 
definition of flowmaps) that hasn't yet been mentioned is autopropagation to 
further reduce redundancy - although perhaps this is only useful for a few 
concerns, like authorisation.

To explain autopropagation, consider the following progression of 
abstraction of authorisation (please feel free to correct any errors!):

2.0. JSP and C1: Each page requiring authorisation requires at least a small 
stub (at minimum, a taglib invocation) to check authorisation and redirect 
if the user is not logged in or not authorised, so the "must be authorised" 
concern must be addressed in every (affected) page.

2.1. Simple sitemap: Authorisation can be checked on a per-pipeline basis 
rather than (or as well as) a per-resource basis, using e.g. an Action - 
more abstracted.

2.2. Grouped pipelines: I'm not sure of the syntax for this - since there 
doesn't seem to be an example in the provided sitemap.xmap. Excuse my 
ignorance/laziness. But the idea is to have a group of pipelines that have 
shared pipeline elements, using nested <map:match> elements. This reduces 
verbosity and redundancy, and groups pipelines of certain types together. 

<map:match pattern="admin/**">
<map:select type="check-authorized">
  <map:when test="admin">
   <map:match pattern="admin/adminscreen1">
   <map:match pattern="admin/adminscreen2">
   <map:redirect-to uri="login?where=admin"/>

If at a later time more resources are upgraded in security terms to 
administrator-only (perhaps not very likely, but you can easily consider 
other more plausible kinds of security upgrades), the sitemap maintainer has 
to ensure that these resources are all protected by the access control 
mechanism. If one is missed out by mistake, we have a security hole. This 
can't entirely be prevented - however, theoretically...

2.3. With a flowmap (as long as it always faithfully represents all possible 
links!), we can automatically propagate certain security constraints by 
"reachability": for example, here:

--(must-be-role: admin)--> AdminMenu +--> ServerStatus
                                     +--> DoA1 --> VerifyA --> ADone
                                     +--> QueryB +--> QBResults
                                                 +--> QueryC --> ...

(note: backwards links omitted for simplicity.)

As you can see, only one role constraint needs to be inserted, the rest are 
automatically protected by propagation. (You still should have authorization 
checks on every protected resource, because even though a resource might not 
be _reachable_ to a user through links, that's just psuedo-security through 
obscurity - it doesn't mean they're incapable of finding out the URI or 
knowing it, e.g. by watching an authorized user's screen, or because it 
_used_ to be authorized to them, or because they developed the site, etc.)

However, we need to prevent the fact that AdminMenu links back to / 
rendering the whole site admin-only due to propagation! The formal 
definition is pretty simple:

Definition 1: the propagated constraint of a state S (which I'm considering 
here to be equivalent to a resource - see below) is [the logical-OR of the 
propagated constraints on each of the directly backlinked states] 
logical-AND the explicitly specified constraint for S (the latter is taken 
to be just 'true' if no constraint is specified).

Definition 2: State A is directly backlinked from B iff B is reachable from 
A via a direct link.

Definition 3: The constraint on (start) is simply 'true', i.e. no 

So, for example, if S is only directly reachable from A and B, and A is only 
for suppliers and B is only for retailers, and S has a "preferential status" 
explicit constraint, then by propagation S is accessible by users who are 
either clients or retailers AND have preferential status.

Note that here explicit constraints are actually associated with states, not 
links as they apparently are in Stefano's proposal, because there is not 
much point in enforcing authorisation only through certain routes!! 
Stefano's proposal allows you to write:

/ --(admin)--> AdminMenu <-- SecretOrMistakenBackDoor <-- BoringPublicPage

Even if one is working for the NSA and simply _must_ implement back doors, 
there are better ways that don't allow just anyone in! ;)

                              -- o --

In a very cleanly separated, ideal scenario, we have for example a _single_ 
"admin main menu" resource (which may still be content-aggregated into other 
resources for convenience, but it's only actually one resource in the 
sitemap) whose generator gets all its links from the flowmap.

To change the site design to make a certain subnet of the flowmap 
"admin-only", we just move links to the "entry points" of that subnet to the 
admin main menu in the flowmap. Both the menu and the security checks are 
automatically regenerated. (Automagically maintaining the association 
between links and any corresponding menu images when a link is moved from 
one page to another is left as an exercise for the reader.) No URI 
rewriting, not a single line of sitemap editing - not even any content, 
logic or style editing to alter the menu!

Alternatively, the links might not actually move to the admin section, but 
stay where they are in the flowmap with the upgraded security constraints. 
Lesser users would still be able to see the links, but not use them! Again, 
it is only necessary to protect the "entry points" of the subnet that should 
be protected, and the rest will be protected by autopropagation.

A third alternative would be to prevent users from even seeing any links 
they are unauthorised to view, not by moving them to a separate menu at a 
different URI (which can be a bad idea from a UI point of view if you want 
to say "do this to the current record"), but by selectively suppressing 
links in e.g. a generator - once again, this can be accomplished with a 
single call to the flowmap class, which knows exactly which links should be 

The latter is hard to do cleanly without a flowmap - you either have to 
duplicate the authorisation concern that's already in the sitemap, in e.g. 
stylesheets, and risk getting that out of step with the sitemap - or you 
have to somehow parse the sitemap yourself to extract the authorisation 
concern - or specify the authorisation concern in a separate configuration 
file, which is then at least partway to being a flowmap anyway.

2.1 and 2.2 can be alternatively implemented in httpd.conf, before the 
request even gets to Cocoon (at least in some cases) - but I don't see how 
2.3 could be!

Unfortunately the example given here is a bit contrived and does not 
necessarily provide _much_ advantage over 2.2 (grouping) in terms of 
separating out security, for many typical sites. More thought needed here.

3. Are autopropagation, or flowmaps in general, useful for other concerns?

Possibly. This is already too long, so I'll just mention two half-baked 
ideas of mine:

3.1. Hierarchical (or even non-hierarchical) menu systems. You might want a 
sidebar always displaying a context-sensitive menubar, for example, but it's 
a bad idea to redundantly place a submenu in every file in a directory, 
obviously. You can use some form of including, but one file per menu means 
menu files scattered all over, and one big menu file is better, but if you 
already have a graphical flowmap editor it makes sense to use this to edit 
menus rather than reinventing the wheel. (Hmmm, weak justification!)

3.2. Drag and drop a subnet to a new part of the flowmap, and it 
automatically picks up the "look-and-feel" of its new parent by propagation, 
even if the subnet is implemented by a diverse set of pipelines! Of course, 
this is just a sketchy idea without an implementation, and embodies several 
big assumptions - that "branding" can be done with a cleanly separated 
stylesheet and/or transformer added on to the pipeline, for example. In some 
simple cases it could be, but not in others. You also need a different 
definition of propagation because "look-and-feels" are not boolean 
functions, unlike constraints!

Insert your ideas here please!

4. Principle of least surprise?

One might object that autopropagation breaks the principle of least 
surprise, in that the look or behaviour of a resource in one part of a 
flowmap can be altered by a propagatable property of a distant resource, 
simply through reachability.

But, even if this turns out to be significant, it is another example of the 
trade-off involved in many kinds of separation of concerns - OOP has fragile 
base classes, XSP potentially has logicsheet interference, and AspectJ has 
the very obvious drawback that, in a standard text editor or code listing 
printout, there is often no indication in a classes' source of if and where 
an advice is being woven in (this is termed "reverse inheritance"). However, 
OOP and post-OOP techniques have been found that try to reduce the problem 
of fragile base classes; logicsheets can be written to avoid generated 
identifier clashes; and AspectJ has special IDE support. A graphical flowmap 
editing tool could perhaps restore the principle of least surprise in this 
case too - and it would also have the advantage that a graphical diagram is 
a much clearer representation of a flowmap than a textual XML tree, which 
must necessarily use labels to make links rather than pointing to them 

Appendix: What is a flowmap? (with quibbles)

>Stefano <> wrote:
> > The solution I envision is the creation of a "flowmap" where the web-app
> > designer is not focused on intermediate locations (resources), but in
> > the flow of the application, much like you procedural languages let you
> > program by writing a flow, not filling memory slots declaratively with
> > instructions.

I think this description is slightly misleading, because in the only example 
given (Slashdot) states were effectively mapped 1-1 to resources (or, to be 
precise, matching requests) - so the designer is focused on resources. And 
why not?

However, multiple states could be handled by a single resource, so I sort of 
see Stefano's point.

> > So, what is a flowmap?
> >
> > Take a piece of paper, avoid thinking you are writing an application for
> > the web, so avoid taking into consideration technical constraints (like
> > the request/response paradigm, intrinsic statelessness, low bandwidth,
> > proxying, etc..) and draw a diagram of the latest application you wrote.

[Whilst this might be a nice theory, I personally find it hard to think 
about an actual webapp without thinking in terms of responses and requests! 
:) But that's just a quibble.]

> >
> > What you should outline, at this stage, is the 'skeleton' of the flow:
> > this should be drawn to give the other people in the team the overlall
> > picture of what the application is doing.
> >
> > So, let's see, let's take something like
> >
> >
> >          identification
> >                ^
> >                |
> >                v
> >  (enter) ---> home ---> (exit)
> >                ^
> >                |
> >                +--> read article <-()-> post comment
> >                |
> >                +-()-> set preferences
> >                |
> >                +-()-> add article
> >                |
> >                +-(editor)-> accept submission
> >
> > where:
> >
> >  (enter) indicates the entrance of the application
> >  (exit) guess what? :)
> >  ---> indicates a 'general flow' [no restriction on identity]
> >  <---> indicates a 'bidirectional flow'
> >  -(???)-> indicates a 'restricted flow'
> >  -()-> indicates a 'identificated flow'

Get Your Private, Free E-mail from MSN Hotmail at

To unsubscribe, e-mail:
For additional commands, email:

View raw message