Monday, November 29, 2010
On the drive home from work last week, I heard a story about unemployment statistics on NPR. The person was saying that unemployment rates should be viewed in a more stratified manner, when it comes to the correlation to education levels of the American workforce. I can't remember the exact numbers, but they were very similar to the 2009 numbers reported by the Bureau of Labor Statistics (BLS), except for the unemployment rate was closer to 10% on average. In this chart from 2009, it is easy to see that more educated workers have lower unemployment rates. This does not take in the consideration the number of potential workers who have fallen off the unemployment lists. These individuals are "unemployed" if not technically reported as such. This would drive the unemployment rate up to around 15-18%.
Sunday, November 21, 2010
It looks like I will be teaching BUS 515 (Operations Management) at the Henrico Campus of Strayer University this Winter, starting in Jan 2011. Thus begins my fourth year of teaching at the post-secondary level, and my second year of teaching at the graduate level.
Monday, November 1, 2010
From the LinkedIn J-Archtiect Group, The question was: Can someone suggest any J2EE design patterns that are available for performance and Scalability of enterprise applications?
First let me say that I am somewhat of a purist and MVC should be the starting point. Beyond that, it’s far too easy to get into a holy war about our favorite patterns. To me, your question was asked in a vacuum without any context, other than the assumed JEE context. Do you have a "green-field" or are you working with a legacy application? I like DTO/VO, DAO, Service Locators, facades, delegates, etc. However, with newer JEE components and other vendor solutions, we now also have to contend with ORM, IOC and DI more than we did in the past. Now the entity POJOs in EJB and DTOs can be one in the same, if you so choose (not trying to start another holy war here). Most of the time, we have a heterogeneous and complex mixture of these components in a single application.
For any scalable solution, caching in my opinion is a must. However, you have not mentioned which is your primary direction of scalability, vertical, horizontal, or a little of both. I have always liked the fly-weight pattern for caching, but it too assumes a strict context with regards to data structures that might not be acceptable given certain application designs. It seems to work very well in portal applications, but is a little more difficult to utilize elsewhere without in-depth data structure and object behavior design.
When designing JEE applications for performance, I always have to reach down into bowels of the system, below the JVMs to choose the right hardware (OS, 64 bit, multi-core, etc.), networking (bandwidth, VLANs), and database systems and configurations. There are also the integration layers: Do you need messaging? Sync or Async?
I also reach upwards above the JVMs for the right front ends with regards to load balancing and fail-over. I am a fan of separate HTTP stacks from your Java Application Servers as well as CMS for non-application content, and I also have to have hardware load-balancing and fail-over, like F5 BIG IP or Redline/Juniper. With horizontal scaling, you have to ensure that your applications are designed and optimized for clustering and that sessions are managed and replicated effectively and efficiently. Then there is the whole view layer category of components; you now need to make sure that you design for usability and reduce network traffic as much as possible via RIA/AJAX. After all, application performance is largely a perspective of the users utilizing the system to get their work accomplished.
You mention garbage collection, but even that is subject to application and object types, as well as server configurations.
To me, the consummate JEE performance pattern is really avoiding the two ANTI-PATTERNS of trying to engineer performance solely in the JEE layer and not building in mechanisms to observe application performance. First, one has to know within which layer to engineer the correct components: business logic in the JEE application, but data logic in the database; session management at the web/application tier, but load-balancing above that in a network hardware configuration. For performance engineering, JEE or otherwise, a more holistic approach is necessary, and that approach will guide the implementation of the lower level component patterns.
The second ANTI-PATTERN is not planning for application observation. All too often, we do not choose designs that allow us to observe application performance. With AOP, we have had the ability to design in cross-cutting logic to look at application execution; however, far too few of us use such techniques until we see the symptoms of poor application performance. And by then, it is more costly to re-engineer. With EJB 3.x, there is an easier way of designing and implementing DI and AOP from the beginning, but many still do not look at AOP during the initial design of the application. In the business world we use the paradigm of Plan-Do-Check-Act (Demming). In the JEE design world, we plan and do, but I don't see a lot of designs that plan for checking and acting. We check when there is a reported issue, and we act by fixing or re-designing what should have been part of the design in the first place.
Keep in mind that we did not even mentioned security engineering and if you need end-to-end, point-to-point or a mixture of both. Of course security engineering should also be designed in when we are designing for performance. They are not necessarily mutually exclusive, but sometimes security and performance collide in poor designs.