cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject Re: [RT] Flowmaps, propagation, and aspect-oriented data processing
Date Sat, 17 Mar 2001 20:18:41 GMT
Robin Green wrote:
> 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.
> ----------------
> 1.
> 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; 

Not quite correct. The only implementation of the Matcher interface so
long is one that matchers agains URI. But the abstraction is to match
agains anything you can think of (do you remember Stefano saying
matching against time of day, load of the machine etc. ?)

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

Exactly. this is the beauty of those very simple Actions that take the
single concern of "authorisation" out of all pages (as you mentioned
compared to C1). And you can use it for simple XML documents as well and
don't have to write an XSP page to be sure the resource is protected. In
C1 you have the need to protect XML documents by help from your web
server (.htaccess or alike) to achieve this. And you can move them in
and out of these protected areas in the sitemap to change its protection
status. Isn't this cool?

> 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.
> E.g.
> <map:match pattern="admin/**">
> <map:select type="check-authorized">
>   <map:when test="admin">
>    <map:match pattern="admin/adminscreen1">
>      ...
>    </map:match>
>    <map:match pattern="admin/adminscreen2">
>      ...
>    </map:match>
>   </map:when>
>   <map:otherwise>
>    <map:redirect-to uri="login?where=admin"/>
>   </map:otherwise>
> </map:select>
> <map:serialize/>
> </map:match>

This example is totally in accordance with the syntax and semantics of
the sitemap. Good example.

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

And using sub-sitemaps even scales those issues into separately
admisistrated units.

> 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
> constraint.
> 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
> visible.
> 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!

This goes IMHO into content aggregation as well. If you look at the
proposal for it so far. It means that we will be able to implement what
browsers call frame technology on the srver side but will a granularity
which is never reached by any browser/HTML standard. Can you imagine to
built up your navigation bar out of several aggregated items which
processed through the sitemap/flowmap will be totally dynamic and
generated by xsp or any generator you have at hand? And if we ever get a
cache system like the one proposed so far C2 will be nevertheless fast.


> ----------
> 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
> graphically.
> -------
> 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:

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

View raw message