Yeah I know. I've been on the road for company related stuff.

So I've shown how to add security annotations to a pretty vanilla EJB. When you develop EJBs remember to keep them limited in scope. For example, if you have an EJB that handles Inbound orders (placeOrder, reviewOrder, cancelOrder, addToOrder, removeFromOrder, etc...) do not feature creep by having that same EJB handle Outbound orders or worst yet schedule orders in a calendar app.

I cannot tell you the number of times that I've run across an EJB where 30% of the code really belongs in its own EJB unit. For example the calendar app should view Inbound orders as a Collection not as a derived member called SchdOrd (PS use freaking descriptive names! The next guy will not understand that OrdTckChcExc is short for Order Ticket Cache Exchange; nor will that name mean anything to them.) A calendar *HAS A* Collection of Inbound orders makes more sense than A Scheduled Order *IS AN* Inbound Order.

The reason it makes more sense? Just because something is a something else does not mean that the logic for the unit is clarified by the statement. The statement only implies a date an doesn't do a very good job of telling anyone what that date means to anybody. A calendar (thus we get the date concept) has a (okay that tells us something about storage) collection (alrighty this tells us that we are going to be looking at a lot of similar things at once) of Inbound orders.

As you can see the HAS A statement tell more about the underlying logic than the IS A statement. So, more than likely by Justin's 23rd rule of programming, the logic will be easier to implement.

I'm getting off on a tangent here, sorry.

Next post I'll cover using a JAAS callback to implement acustom login dialog and how to handle a failed login, yes you do have to handle those Glassfish will not do it for you.

Cheers!