Whatever…

U2 can Rock and Save the World. Yes, you too!

This is cool! Here is the SMS I got from Bono! Looks like GonzoMoFo got one too. Sun is making it happen…also featured here on java.com site. Mary has got her band (er, i mean wristband), why not you too? Sign up here: http://www.onecampaign.org and while you are there, don’t forget to act and get your wristband.

Add comment March 30th, 2005

To Control or To Filter ? Why not both?

Question: Should I use Intercepting Filter or Front Controller?

Short answer is: use both. Intercepting Filter and Front Controller are typically used in combination. IMO, the real question is how to separate the concerns of each in my web application.

This is a common question I encounter.
Sometimes, when I need to implement a request/response handling functionality in the presentation tier,
choosing between processing in Intercepting Filter and Front Controller becomes a matter of preference. Both patterns offer a way to centralize control of request/response processing. However, there are some key differences in how you assign responsibilities to each.

• I use Intercepting Filter when I want loosely-coupled pre and post processors for request/response handling.
  Intercepting Filters offer pluggability and configurability so that I can add/remove filters non-intrusively (declaratively). Filters are ideal if the operations they perform are well-encapsulated and discrete so that I can plug and play as I want.

• For all other common request processing, a Front Controller is the way to go for me. Front Controller avoids duplication of code in multiple views. Typically, once I implement a Front Controller, I pretty much want to leave it alone as much as possible. Over time, if I start seeing lots of conditional switching (if-then-else or case/switch) in my Front Controller, then I might refactor conditional logic using Intercepting Filters or delegate the conditional processing to helpers using the Command and Controller Strategy [see Front Controller pattern] implementing a Command [GoF] based services layer.

Bottomline: I want my Front Controllers to be straightforward, simple and easy to maintain, and my Intercepting Filters to be loosely-coupled, pluggable and stateless.

What do you think?

Add comment March 23rd, 2005

How I Use Patterns…

If you are new to software patterns, you might be wondering how to use them. In any case, I would love to hear back from you on how you find patterns useful (or not) depending on your experience. Anyway, based on my experience, I see 3 broad categories of pattern usage.

1. Building a new system
   
   If you are developing a new system, patterns help you to layout the design blueprint for the system. You can design the system using well-known patterns and help your team understand your design rapidly by documenting and explaining your design with patterns. Assuming that the patterns you use are well understood by your team members, you spend very little or no time in explaining the nitty-gritty details that can be encapsulated by each pattern. If someone is not familiar with a pattern that you are using, you simply point them to the pattern documentation and they would quickly get up to speed on it. Patterns streamline the design communication within your team and help your team to focus on the design and implementation instead of arguing about the fine-grained implementation choices underneath. Once you agree upon the overall design and the choice of patterns, you then get on with choosing the right strategies for implementing the design. Remember, there is not one way to implement a pattern. Multiple implementations (or solutions) for a pattern are described as discrete implementation strategies you get to choose and implement after choosing the pattern.

2. Understanding an existing system
   
   If you begin working with an alien system, the first (and hardest) thing to do is to comprehend the system design and architecture. Patterns help you in understanding such systems. You can use your patterns experience to drill down, identify and decompose the system design into comprehensible pieces that can be mapped to well-known patterns. In my job as a consultant, this is what I do. I end up mapping the system back into patterns by investigating the code, design documentations (if I am lucky to find one) and talking to other developers who might have worked with or have some knowledge of system. This helps me to capture and share the design information of the system and to focus on those areas I don't understand well (i.e. those areas that do not easily map to well-known patterns). Understanding a system is essential to managing, maintaining, refactoring and enhancing it confidently and patterns can help you to get there.

3. Refactoring a system
   
   This depends on the above point on understanding a system. Once you understand a system and map the system back to well-known patterns, refactoring becomes easier. You can identify the impact of refactoring by looking at the patterns and their inter-connections. Refactoring may involve such activities as changing a pattern strategy (i.e. same pattern, different implementation), swapping patterns (replace one pattern with another), or introducing a new pattern. Patterns become the targets to which we refactor a system. So there too, patterns provide me a better way to improve my refactoring. In my experience as a consultant to many customers, this benefit of patterns alone has proven to be of great value to perform my job efficiently and with the highest quality.

Useful References

• Refactoring To Patterns by Joshua Kerievsky is an excellent resource on understanding how you can refactor using various patterns as targets.
• Refactoring by Martin Fowler is the original book on the subject that is a must read for all developers.
• Core J2EE Patterns contains 21 J2EE patterns and 14 J2EE design-level refactorings - discusses pattern-based refactoring.
• And you can't forget Design Patterns by GoF that started it all.

Add comment March 18th, 2005

Patterns: Aha! …or… Duh!

I hear from other developers all the time about how they feel that design patterns are over-hyped and not really useful. For example, recently I was talking to an aquaintance Bob (not his real name), who works for a hugely well-known company.
We were talking about some programming stuff, and as it happens, soon wandered into the world of patterns.
Bob said to me that when he first read the GoF book, he felt that there was nothing new in it. He had already implemented those patterns and had reused them over and over in his designs. So, he said, “What is the big deal with patterns? I did not learn anything new!”

In my experience, this sentiment is pretty common among us developers. I, and my co-authors, received similar feedback during the early days of our work on Core J2EE Patterns. I said to him “Bob, it is great that you had implemented those patterns in the GoF book before it was published. But the very fact that you, me and others like us have repeatedly implemented them proves that those patterns are indeed patterns! And that's the whole point about patterns.”

Documenting recurring designs helps us to communicate with other developers. Patterns provide a great mechanism to document and share reusable problem/solution pairs. Patterns also provide a powerful design vocabulary so everyone on the team can talk the same talk and understand each other. This increases productivity and decreases noise and ambiguity in our design discussions. The benefit of such a vocabulary in design is often an overlooked benefit of using patterns in our day to day work.

In the GoF book, they talk about an Aha! experience - when one understands the patterns and gains new insights. I think the experience I have encountered from other developers is a bit different, one that I call the Duh! effect, as in “Duh! I knew that already.” As a pattern practitioner, when I hear the Duh! effect, I no longer have to prove that patterns are useful and that a pattern is a pattern.

Duh! = Game over!

Add comment March 17th, 2005

Relationships between Pattern Catalogs

Martin Fowler (one of my favorite authors) has put together this nice survey of various pattern catalogs that have evolved in the recent years.

We collaborated with Martin when we were developing the Core J2EE Patterns book and were grateful for his comments and suggestions as he reviewed our work. We continue to work with him and others in the Pattern community.

Over the last year or so, many in the patterns community have been working together to create a pattern fabric to collaborate and bring together patterns related work by different people. Microsoft has recently put together a new community site called PatternShare for sharing and collaborating around patterns.

Add comment March 17th, 2005

How To Read My Blog

Here you can find some notes on how to read my blog.

Add comment March 16th, 2005

Swing GridBag + Netbeans 4 = Love

Over the years, I have worked on and off on rich user interfaces. Recently, I have been pluggin away at a Swing UI for a cool project called SALSA that I will write about some other time. If you have ever used the Swing GridBag layout, I am sure you will identify with this cool Flash animated weblog by Matt Quail. I sure do.
So for many years, I have struggled with GridBag everytime I use it.

But ever since Netbeans 4 was released, I have been liberated of this curse of the GridBag. NetBeans makes Swing development fast and easy and no more messing around with gridbag constraints, layout issues, etc. (unless you like to).
As part of my customer facing job, I have used all the Java IDEs out there. But for me, when it comes to Swing in specific, and Java in general, nothing beats the new Netbeans!

I Love NetBeans! Thanks, Netbeans team!

Check it out!

Add comment March 15th, 2005

Hello World!

Well, this is my first ever blog entry! I have been watching and waiting and watching blogging@sun for a while…
I have see some cool blogs by many of my colleagues at Sun at Sun Bloggers.
The blogging revolution at Sun has inspired me to jump in…so here i go…

My name is Deepak Alur and I am a Principal Engineer in the Enterprise Web Services Global Practice at Sun Microsystems, Inc.
I am also a co-author of the book: Core J2EE Patterns.

My current professional interests (subject to change without notice ):

• Patterns and Pattern-based Approaches for design, development and analysis
  of software
• Software Quality: More specifically related to Architecture & Design quality
• Software Comprehension and Refactoring using patterns
• Design and Architecture of Large-scale enterprise software systems

For more information on me and my bio/work,
check out my site or the official site
for Core J2EE Patterns book I co-authored
with John Crupi & Danny
Malks.

Looking forward to share my ideas.

Thanks for reading!

My Visited Countries Map

Create your own visited countries map

Add comment March 14th, 2005