Ilybra: aspects battlefield

On aspects in Ilybra project…

Great people like Ron Bodkin talk about the pragmatic way of doing software. So why don’t me, when I have this experience and I’m just hot to tell the world to look at the other side of this matrix..

Ilybra is a battlefield when it comes to aspects. Ther first aspect was tracing of course, the rest you see below, and today I got an idea on another one to my collection. Some people will even call my aspects “enterprise”! As you wish :) I don’t know the meaning of that word. I just develop an application for my library ladies.. ;)

Like it was said in the Ilybra: introduction, Ilybra utilizes some custom made aspects. They are:

  • authorization and authentification
  • optimization of access to some sorted data collection
  • tracing execution of Struts actions
  • dirty problem with null parameters
  • reseting Struts’ forms
  • measure the action invocation time
  • …and will be more, when need arises
  • Oh my, and I’ve just forgotten about the most important one: persistence – see how invisible it is my way :)

Many! lines of code has just disappeared from my classes. This is the core value of aspects. My code is cleaner.I will demonstrate you my Struts’ action code with: tracing, authorization, persistence, returning empty String instead of null, resetting forms and measuring time of invocation of action – ufff, a lot :) :

My full, original code (without any cheating or removal lines of code for the sake of the presentation of the example) of user story: Prolong copy on reader’s account: enter new date, accept choice, view confirmation.
Note: of course, there exists one, additional, global ilybra-aop.xml AOP configuration file for defining pointcuts.

Interested in library.prolongCopy(..) or library.getCopyById(..)??

..Authorization and authentification are common in applications. And so it is with Ilybra. It is 2 years now, I started to work on the application, but only from the last week the system must authorize a reader to access his account.

What is important here I’ve managed to add this concern – orthogonal concern – after the application was finished. I’ve done it with one simple aspect listening on all Struts actions, which checks if there is a User object in a session. Implementation is trivial. And aspect oriented way turned out to work. (This implementation could also be done using “servlet’s filters”, as they also crosscut expected behaviour in this particular example).

Code of the aspect on the plate:

I hope those examplets will clear your mind for a moment :)


My aspect orientation

On my aspect oriented experience

Things like aspect orientation and separating of concerns are really trivial for me. I mean I develop software and I write an aspect when I see there is a need for that. I use it pragmatically, and the number of my custom aspects is increasing every few days last weeks.

But as we see not for all people that’s the case. I will try to tell how it looks from my position. And I must start from the beginning: the client of application.

To familiarize with a business domain is the first and most important thing.
It is your client who drives the application, so the first thing is to dive into the client’s business and to look what’s there. But, just don’t spend too much time there.
Practical way (agile?) says: it would be nice for you client to see the first version of application very soon. So I implement the domain – simple Java classes and methods and plain JUnit tests.
And in the first week of development I’m only worried about implementing first business task of my client. I don’t think about persistence (you use Prevayler for prototyping, don’t you?) or any other system “services” – it is not important right now. Client is important, and time is important.

And it happened, when I worked this way, I’ve started to see things differently. Some years ago I tried to design a whole system at once. It is impractical. Requirements will change, client will wait. It just doesn’t work.
So I try to think only about functionality of the core system and nothing more. The rest of the system are system’s services – non functional requirements like authorization or tracing support – they will come at a later stage, when need arises. Then I will take care of those services – by implementing an aspect of course.
Like Andrzej Krzywda assumes: one can practically add any orthogonal functionality to an application at any given moment of time. And that is true. It worked out for me with authorization and the rest of my aspects.

Persistence strategy as I believe was the strongest point in my developer’s history. When you choose simple persistence, then you don’t have problems others do. This is the right direction: to get rid of problems. And “simple” doesn’t mean primitive. It is the art to make complex things look simple. I found when code looks clean, many things become brighter. And it is persistence that makes your code look uglier at most of the time. But I don’t want to talk about this topic right now – have a look on PAT, and you’ll see my way..

Need the examples of the code I create? PAT provides a Forum demo ready to extends to you super-duper, enterprise solution…

Ilybra: introduction

Introduction to Ilybra application…

Finally I’ll start column on Ilybra application. A lending library system for lending books to readers, managing books and copies, printing reports, keeping history of reader’s lendings and of course searching capabilities by different search categories. All based on PAT framework.

Numbers of systems’ data for your information (as of 1997 – May, 2005, data has been imported from former system):

  • books number is 9,530
  • copies: 12,500
  • readers: 1,750
  • authors of books: 10,200
  • history of lendings from year 1997: 10,400 records
  • … and 4 librarians

..and all this fits in my PC’s RAM (the small 1G). Surprising, isn’t it? ;)
Note: system is ready for numbers 10 times bigger and was tested with that amount of data. And searching speed wihout optimisation rocks! You do heavy loading of your system before implementing, don’t you?This is “an enterprise-class system”.

Ilybra is entirely based on POJO model – and this is most important and unique. What’s unique that persistence is invisible. There are no mappings, no tables. The only requirement to the POJO model is to annotate transaction-methods and business objects (BO) – one line of code:

Ilybra uses Jakarta Struts for presentation layer, Log4J for logging, works on Tomcat or JBoss AS. Tests are made with plain JUnit. Regression tests and load testing are done by Jakarta JMeter. Ant helps with one-click distribution creation, iText generates PDF documents on the fly, CSS supports printing.

Custom aspects take care of:

  • authorization and authentification
  • optimization of access to some sorted data collection
  • tracing execution of Struts actions
  • dirty problem with null parameters
  • reseting Struts’ forms
  • measure the action invocation time
  • Oh my, and I’ve just forgotten about the most important one: persistence – see how invisible it is my way :)

And this is reality – Ilybra exists and has a good time working our Intranet in a testing and bug discovering phase (as of 30 May, 2005). As soon it will be available on-line, I’ll tell..Why aspect oriented way?
This is pragmatic way, more. I do nothing for show. I do it because simpler software means you have to look for concerns, separate them and merge together (refactor?). And you have to do it all the time – well I do it this way.
Aspects are the most suitable way for developing this kind of applications nowadays.

And application is a set of crosscutting concerns, right? :)