Saturday, January 10, 2004

J2EE: Websphere Security

The Websphere Redbook example I am experimenting with uses filter servlets to add programatic security. The filter servlets are mapped to various urls in the web.xml. The filter servlet checks for the existance of a user object in the session and redirects you to the login.jsp if it can't find one. If you are logged in, then the filter servlet will find the user object (this is added to the session when you login) and pass you straight through to the resource you were after.

This is fab for sites with a few areas that require security but am not convinced that it is a good approach for larger sites with hundereds of pages. Maybe I'm wrong but what i'd rather have (in a domino stylee) is a declarative security approach much like our good old fashioned ACLs.

This is all available in Websphere of course but seems oriented towards LDAP and operating system user registeries. Hmmm. What I was after was using the built in websphere security features but pointing them at my custom user registery, so I was kind of pleased to find "Testing J2EE Security Applications Using a Custom Registry in WebSphere Studio V5"

Anybody else found any decent Websphere security/authentication resources? If you have please stick a comment on.

As Otis Redding said:

"I want security, yeah
I'm telling you, once say again, oh now
And I want it in the end, oh"

Thursday, January 08, 2004

LOTUSFEAR: Monkey Programmer Boy Merchandise

With Lotusfear only a few weeks away the team here at "Can I get down now dad?" have decided to produce their own Monkey Programmer Boy merchandise. It's quality stuff, incorporating badly sized jpegs and the cheapest fonts available.

Tuesday, January 06, 2004

This was posted via my mobile phone using the blogger api oooo

This post was made with a trial version of BlogPlanet, a photo blog client for mobile phones. For more information visit

Monday, January 05, 2004

RPS: Important Sporting News

If the endless grind gets you down as you spiral towards death and oblivion; there is always "Rocks, Paper Scissors" to pass the time. Here's the official site: The Official Rock Paper Scissors Strategy Guide.

J2EE: Differences with Domino Development.

Since my glorious exam result I have been busy going through the Redbook: "WebSphere Application Server - Express: A Development Example for New Developers" which contains a real world non-ejb websphere application. I have downloaded the source code and imported into WSAD and gone over the design to find out how things were done. The example application is a good place to start as it uses STRUTS, log4J, DB2 backend and some typical design patterns (Data Access Object & Business Facade).

I have used the Redbook design as a template for re-building one of my Domino applications into a J2EE app. This has proven a very useful exercise and I would reccomend it. The key benefit is that the app is real-world enough to be useful, unlike the typical "Don't runwith scissors" kind of examples you find in many books.

One of the main things I have noticed is how simple life is in the Domino world. This is often a frustrating limitation but you don't half realise how much you take forms, views and the object store for granted when you are in the bowels of a J2EE app.

For instance, take a user registration form. In domino you would:

1. Create a form with name and address on it. Bit of validation in the fields maybe.
2. Create a view with username on it and sort by username.

Thats it. You've got the form and this saves the record into the object store and off you go.

In J2EE (following the Redbook example) you would do the following:

1. Create a form with name and address on it.
2. Create an associated formbean with name and address fields, getter and setter functions.
3. Add a mappiong to the STRUTS config.
4. Add a validate() function to the form bean. This will have stuff about the name and addrress in it too.
5. Create user data transfer object (with name and address fields) so you can send user information around layers.
6. Create a usermanager class to act as a business facade for the data access layer.
7. Create user data access object with name and address fields, getter and setter functions. This accesses the backend database.
8. Finally the relational database itself which has a table called user which has name and address fields too.
9. Oh and then you have to do the stuff to display a list of users like the view ...

Phew. Bit more involved eh, and were not using EJBs.

Now imagine adding a new field, country for instance. In domino you just add the field to the form. If the new field doesn't need any validation or appear in the view then you are done.

In the J2EE example you have a lot of work to do. Adding the field to the various objects and then altering the relational database structure.

Don't get me wrong. In some respects working in the J2EE environment is a total breath of fresh air. You can create large layered applications which have a coherent design and go FAST. Once Domino hits its glass ceiling these type of apps become a spider's web of $$viewtemplate for dontRunWithScissors forms and hacks.

That said, for simple applications Domino is a breeze, which is food for thought for those suggesting Websphere is a contender in the SMB market place. My example is based on a Websphere express example by the way.

This page is powered by Blogger. Isn't yours?