Sunday, December 20, 2009

Was I defeating bean pooling in OpenEJB?

As I previously reported I had to use JNDI to obtain a reference to my stateless session bean from my Jersey Rest service.

In so doing I created a helper class that would, among other things, cache the JNDI and EJB references I needed.

That got me to wondering - since I was using the same EJB reference over and over was I somehow defeating the stateless session bean pooling that OpenEJB was surely providing me?

The only documentation I could find on this hinted that pooling worked via the bean method invocations and not the bean reference itself. But, I wanted to see it with my own eyes. I did notice that my JNDI lookup was returning a proxy object and not my bean implementaion, so this provided me some hope that I was not defeating pooling.

My first test was to invoke my EJB 10 times via the same reference and, from inside my EJB implementation identify the bean instance that was invoked. Well, the 10 invocations went to the same instance - no pooling so far.

But, my test was not very realistic so I modified it to invoke my EJB 10 times via the same reference but from 10 separate threads. This time the 10 invocations were handled by 10 different instances of my bean implementation. Whew - proof that I had not defeated pooling by caching and reusing the bean reference I was retrieving from JNDI.

Out of curiosity I increased my invocations to 100 and this time only 9 unique instances of my stateless session bean were used to handle these 100 requests.

Tomcat, OpenEJB and Jersey, oh my

I was recently investigating putting EJBs behind Restful web services.

I did get it working without too much trouble using Jersey and JBoss AS 5.1, but I had to deploy my web app in exploded directory form and not as a war. No matter what I tried I could not get Jersey to find the rest service classes when I deployed my app as a war. This was contrary to my experiences with JBoss 4 and is probably due to the new virtual file system architecture in JBoss 5.

This prompted me to take a look around and see what else is out there. I stumbled upon OpenEJB and thought I would give that a shot inside Tomcat 6.

It was pretty simple getting Tomcat going with Jersey and within a few minutes I had my web service running inside standalone tomcat (without the EJB usage, of course).

However, when I dropped the OpenEJB war file into Tomcat things fell apart and my app would no longer deploy due to an apparent class loader issue which seemed to be introduced by OpenEJB. I tried a lot of different things but couldn't get past the class loader problem. I even went as far as to download and debug into the OpenEJB source code but I quickly found myself in compiled 3rd party code.

Here is the error I kept getting: Could not fully load class: com.sun.jersey.spi.container.servlet.ServletContainer due to: javax/ws/rs/core/Application in classLoader: org.apache.openejb.core.TempClassLoader

I finally decided to simply place the Jersey jars (asm.jar, jersey-core.jar, jersey-server.jar, and jsr311-api.jar) into the Tomcat lib folder and that did the trick. I also set the Jersey dependency to 'provided' in the maven pom for my webapp.
Also, I was hoping the @EJB annotation in my rest service class would inject my stateless bean reference, but it did not - I had to use JNDI. By default, OpenEJB uses the following scheme (you can configure) for naming your beans in JNDI: implementation class name + either 'Local' or 'Remote'.

For example, say you have an EJB class named AccountBeanImpl and it implements interfaces AccountBeanLocal and AccountBeanRemote. The corresponding JNDI names for the account bean would be AccountBeanImplLocal and AccountBeanImplRemote.

Thursday, October 22, 2009

J2EE Integration and Messaging

work in progress

CharacteristicWeb ServicesJMSJCA
sync vs. asyncsyncasync
security/encryptionyes, WS-Securityyes
reliability (guaranteed delivery)yesyes
systems use same technologyjava-non javajava-javajava-legacy/EIS

GoF Design Patterns

work in progress

Creational Patterns (AbFacBuildFacProSingle)
Abstract Factoryinterface for creating family of related/dependent objects without specifying concrete classes
Builderseparates construction from representation; same construction process can create different objects
Factory Methodinterface for creating an object; lets subclasses decide which class to instantiate
Singletoncontrols access to finite number of instances
Structural Patterns (AdBriComDecFaFlyProx)
Adapterconvert one interface to one the client expects
Bridgefunctional abstraction -> internal implementation
Compositehierarchical tree structures with elements of varying complexity but a uniform interface
Decoratoradd or remove functionality without changing external appearance
Facadeunifying interface on top of a group of interfaces/components of a subsystem
Flyweightsharing/reusing objects
Proxysurrogate controls access to real object
Behavioral Patterns (ChainComIntItMedMemObStateStratTempVis or C2I2M2-OSS-TV)
Chain of Responsibilitymessage handled where it is first received or directed on to another object for handling
Iteratorsequentially access items in a collection that is separate from the underlying collection
Mediatorobject that manages message distribution among other objects
Mementorepresents snapshot of object's state
Observerbroadcast messages to interested listeners
Stateobject alters behavior when internal state changes
Strategygroup of classes that represent a set of possible behaviors
Template Method
Visitorthink of using the enhanced for to iterate over a list in java and perform some operation on that list
underlined patterns are ones I have personally used

J2EE Persistence Strategies

This is a summary of the J2EE persistence strategies that a Sun Certified Enterprise Architect should be familiar with (use scrollbars at bottom to view entire table):

StrategyEase of DevelopmentPerformanceScalabilityExtensibilitySecurityStrategy
CMPrelatively simple; preferred over BMPcontainer dependentEJB container dependent *avaries by implementationEJB providedCMP
BMPmore involvedvery efficient w/control over SQLEJB container dependent *avaries by implementationEJB providedBMP
JDOsimplepossibly some performance penaltydeveloper managedvaries by implementationdeveloper managedJDO
JPAthe simplestpossibly some performance penaltyEJB container dependent *avaries by implementationEJB providedJPA
ORM/DAOssimplepossibly some performance penaltydeveloper managedvaries by implementationdeveloper managedORM/DAOs
JDBCmost time-consuming and involvedtheoretical best performancedeveloper managedvaries by implementationdeveloper managedJDBC
iBatis/DAOsomewhere between ORM and JDBCexcellent performancedeveloper managedvaries by implementationdeveloper managediBatis/DAO
*a = stateless session beans more scalable than stateful

not covered by SCEA exam

Spring can help level the playing field outside EJB in some of the above developer managed areas by helping with transactioning, scalability and security.

Friday, September 18, 2009

assign IDs in ExtJS, or else...

I was recently working on the UI side of things and having difficulty getting my complex 2-column form layout to display correctly (creating components dynamically and adding them to the the parent window object and nested panel objects).  Elements were either missing or grossly misplaced.

In ExtJS, IDs are automatically generated for your UI elements if you don't specifically assign them yourself, so I didn't really give much thought to the fact that I wasn't assigning my own IDs.  I was taking stabs in the dark and then for some reason decided to assign my own IDs and when I did, viola, it started working like a charm.  Lesson learned.

Thursday, September 17, 2009

the phone call

Yesterday morning my 3-year-old son called me at work to talk about something we would do together later that day.  He knows that I get home around dinner time so, mid conversation, I hear him call out to my wife "mom, can you make dinner now?"  Simply heart warming.

reflections on opportunities past

There are a lot of things I miss about being in the service (military) and besides the people, one of the things I miss most was the knowledge that no matter how good or how bad your current assignment was you knew it was going to change.  

The military thrives on leadership and to cultivate this its members are regularly reassigned in order to broaden their experiences and afford them opportunities for increased responsibility.  And there were so many choices of places you could go and things you could do.

My first experience with this was what they call "service selection night" at the Naval Academy.  It's actually an entire day and they start very early in the morning as it takes a while to get through 1000 people.  They make announcements over the PA system and summon people in groups, according to their ranking in the graduating class, down to the selection office.  The purpose of this event is for first class midshipmen (seniors or "firsties" as we were affectionately called) to choose what they were going to do after they graduated.

So, you hear your number called and you head down to the selection office.  You walk in the room and on the walls are listings of all the possible assignments that a young ensign or 2nd lieutenant could have.  There was Naval Aviation (Navy Air), Marine Air, Navy SEALs, Marine Infantry, artillery, Navy surface, or subs (submarines) or nuclear power, or whatever.  You could even pick the exact ship you were going to be assigned to and thus your home port.  It was really very exciting.  

For me, I knew I wanted to be a Marine and flying sounded exciting too so I thought I would give it a shot and become a pilot.  So that's what I chose - Marine Air.

And that's kinda how it was during my time in the service - there were always new opportunities and always choices and there was always something new to look forward to while you were busy enjoying where you currently were and the people you were with.  

After flight school I got to choose what aircraft I would get to fly and where I would be stationed.  At the end of my first tour where I flew CH-46 helicopters out of Southern California things got a little more interesting.  As you move up you start talking to your 'monitor' (aka career counselor - someone back at Headquarters Marine Corps in Washington, DC) who is another officer temporarily assigned on his way up the ladder to work with a certain group of people and fill the openings left by others moving on to new assignments.  Again - choices, but now there was some negotiation and you had someone who had a bigger picture than you who could help guide you to the next assignment that would set you up for the one after that, and so on.  

In my dozen years of post-military life I really haven't seen that - at least not at the places where I've worked.  I think there may have been something remotely similar to that at General Motors.  I mean, they did send me to leadership development courses and they did say they "had big plans for me" when I informed them I was leaving.  But, although I enjoyed my time there, I did not stay long enough to find out.