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…
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
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? :)
Tutorial how to set up JBoss, Struts and AOP together
It’ll be about JBoss Application Server and Aspect Oriented Programming and web applications.
As everyone who knows me know I develop simple, yet powerful web application. At least I try. There was time at the beginning of this adventure I’ve used Tomcat web container among with Struts Model-View-Controller framework.
After some time, Aspect Oriented Programming (thanks to Andrew) came into my developer’s life. It is JBoss AOP that I ‘play’ with.
I still need to develop web application. How to include AOP into web application? First of all I decided not to play with Tomcat any more. Main reason is I knew JBoss Application Server also has Tomcat embedded inside it. Also JBoss AS, as the JBoss company is the mother of JBoss AOP, has AOP included inside their product.
Note: as of May, 2005 I reverted to Tomcat as it is possible to run a web application with AOP (JBossAOP) enabled on plain Tomcat. No need for JBoss which took 1 minute to start. Tomcat starts in about 20 secs.One just needs to precompile AOP’ed sources with JBossAOP compiler (using Ant’s tasks) and pack application (WAR) in a standard way.
I don’t utilize JSP AOP precompilation, as I don’t need aspects there and there is no Java code on my presentation layer webpages.
So I took the freshest JBoss 4.0.1 release of JBoss AS and unpacked it.
I use Ant for my application, so examples will use it. This “tutorial” is also valid for Java 1.4 version. I don’t know if there are any problems with 1.5.
I assume you know basics of JBoss AOP and how to deploy [Struts] web application on Tomcat.
Steps to successfully deploy AOP enabled web application on JBoss AS with Struts:
download JBoss AS 4.0.1. Unpack. I use /usr/local/java/jboss/ directory.
prepare your web applicationI mean get your *.war file that was running on Tomcat with Struts. I had to change nothing to the files.
next step is to write your aspects and put them along with your plain Java source files
next, write JBoss AOP configuration file. It is usually called jboss-aop.xml
We should be able to write as many aspects’ configuration files as we like. When one deploys *.aop archive on JBoss Application Server, then it is possible to put any number of META-INF/*-aop.xml config files.
But when using Tomcat it isn’t possible. One option was to use a system property: jboss.aop.path=some_dir/. But this makes an application dependant on the property (user has to set it), and second – worse – doesn’t permit one to have several different contexts with different AOP configurations.Here’s solution: name each config file as: jboss-aop.xml and put it into custom, _empty_ JAR file. Call JAR archive whatever you want. Put those configuration archives into classpath and your’e done.
This way I’m able to write aspect libraries using JBossAOP and plain Tomcat web server. :-)
now when we have all source files, configuration files, we need do compile sources
AOP sources compilation process consists of four parts:
Get the libraries:Libraries needed to compile aspects are in these directories:
Compile your sources:compile all sources, including aspects with plain Java compiler (I use <javac>)
Compile JBoss AOP annotations (if you use them):
Compile all sources using AOP compiler:
Ok. The next step is packaging all of it. So, basically, all we need is to pack all files related to web application into application.war file, and all files related to AOP into application.aop file. After doing this, put those two files into one file application.sar with one configuration file.So here is how the structure of my deploy/directory looks like:
[optional step] edit AOP configuration file of default/ configuration of JBoss AS to enable weaving process:We have to choices here: if we precompile sources with <aopc>, <annotationc> (as it is in my situation) then we do nothing and go to the next stepOtherwise we may not precompile sources using those two tasks! Aspects may be hot deployed. But for this, one must adapt configuration:
Change JBOSS_HOME/server/default/deploy/jboss-aop.deployer/META-INF/jboss-service.xml and set variable EnableTransformer to true
deploy your application by putting it under JBOSS_HOME/server/default/deploy/ directory. I just expand the file contents into JBOSS_HOME/server/default/deploy/application.sar/ directory
run JBoss AS: JBOSS_HOME/bin/run.sh -c default.For my needs I also update -Xmx value in run.conf file