In a previous post, I blogged about my works in a CMS system using AOP,
and the problem of implementing security in a 100% AOP system, and then
I realized I hadn't yet said anything about it in my blogs. Sorry
fellas, here it goes. :)
One of the really weird things about having a 100% AOP system is that
you end up using composition, with introductions, to create your
objects. I started doing this in order to put some stress on Jonas'
transparent persistence for aspects, and then I realized it actually
gives me a very good level of flexibility and abstraction. In a Content
Management System, you'd expect to see either a very flexible or very
complicated Content class. Without any further ado, here's mine:
public class Content { }
That's it: one line of code. You're probably thinking now: "Yeah,
Carlos, so what? Are you just trying to create unreadable code or are
you actually doing something useful?". I'm sorry I can't answer that
question, but bear with me, I'm doing quite of an exercise here. Time
will tell if it's any good or if it's readable or not.
All the fun going on with that Content class goes into AspectWerkz and
its definition file, where I compose the Content object with the
properties, or, as I'd like to call, atoms, I like to see in those
objects:
This has two interesting effects: I can now create a second class,
HtmlContent, and have it composed with the hasName atom, but using a
different atom for the actual content:
This way, I'm reusing the hasName atom throughout different objects in
the system. Then, I'm handling a cross-cutting concern, that is to have
a property that defines the name of a given object, using an
introduction. The code for this particular introduction is not really
interesting, and you probably figured it out yourself at this time, but
anyway, here it goes:
public class HasNameImpl implements HasName { private String name = ""; public void setName(String name) { this.name = name; } public String getName() { return name; } }
As you can see from these code and XML snippets, my "business
objects" aren't really any interesting until I run them through
AspectWerkz, and then things start to make sense. Persistence, for
example, is handled transparently by AspectWerkz in this case, using
Prevayler. Awesome! :)
Now, the problem is: how do I keep those objects safe from unwanted
users? By implementing two simple atoms, hasOwner and hasPermissions, I
can now manage my object's ownership and permissions. But who's going
to enforce them? I hear you scream "advices!" already. Cool, advices
fit perfectly in this description, but there's a big problem here: how
can I let an advice know who is trying to fiddle with a given object?
The advice would need to actually ask the Servlet Container for an
object in the HttpSession that holds the currently logged-on User
reference (User is also a composed object, like Content, above). Given
that I'm manipulating those objects using WebWork 1.x actions, what are
my choices?
More thougts on this later, as the clouds in my head disappear. :)
Previous Topic
