Bobby Woolf is a Consulting IT Specialist with IBM Software Services for
WebSphere, part of the IBM® Software Group, where he helps customers achieve success with J2EE products such as WebSphere® Application Server and Rational Application Developer, and related technologies
such as service-oriented architecture (SOA).
He is a co-author of Enterprise Integration Patterns, and writes a popular blog on the developerWorks Web site,
WebSphere SOA and J2EE in Practice. Bobby is a frequent conference speaker.
Bobby started his career at Ascent Logic Corp (ALC), where he helped to develop one of the world's
largest Smalltalk applications. This taught him a lot about designing code for clarity and
maintenance, and is where he first experienced the necessity of refactoring code to keep
enhancing its value. Having learned a lot from his ALC co-workers, he then sought out a new
learning environment and found it at Knowledge Systems Corporation (KSC), a leading Smalltalk
consulting company. The variety of consulting projects helped him improve his development
skills quickly and learn about team dynamics. It's also when he first started publishing
articles and started writing patterns. He presented papers at the first five PLoP conferences,
culminating in chairing the conference with Dragos Manolescu in 1999. Meanwhile, Bobby
and Kyle Brown, also from KSC and now with IBM, developed a tutorial, Understanding
Smalltalk Graphics, which used patterns from the
Design Patterns book to describe the
Smalltalk frameworks. They presented this tutorial at the OOPSLA and Smalltalk Solutions
conferences. Bobby and Kyle went on to write
The Design Patterns Smalltalk Companion with Sherman Alpert, also of IBM.
After KSC, Bobby moved on to Java™ and worked a stint at Interpath Communications, a dot com,
where he honed his Smalltalk skills into Java skills, experienced the birth of J2EE, and
learned all about workflow and workflow engines, messaging, and saw the birth of JMS.
Those skills landed him a job at GemStone Systems, consulting with customers using their
GemStone/J product, a J2EE application server with a built in object database.
Bobby and Gregor Hohpe then, at the invitation Martin Fowler and Kyle Brown,
went on to write
Enterprise Integration Patterns. These experiences led Bobby to IBM in 2003, consulting with customers using WebSphere
Application Server. He developed specialties in multiple disciplines, including J2EE application
development, messaging and application integration, and patterns. He publishes frequently on
developerWorks and presents at IBM conferences like WebSphere Technical Exchange.
In his free time, Bobby likes getting involved with activities that help the community,
and helps like-minded individuals develop their leadership skills. He's written a paper for
a community services organization on how to be a successful member of their board, which has
become the best demonstration to his non-technical peers of what he actually does
for a living. Bobby also likes to read non-fiction that explains how the world works.
This is where I talk about whatever is on my mind, roughly organized around J2EE development,
including IBM products and broader technologies like SOA and ESB. It has also become fertile
ground for links to interesting items buried within IBM Web sites.
I plan to use the wiki as a space to organize reference material that hopefully will be relevant over time, I may need to update over time, and you may wish to browse to get a more complete picture. That's hard to do with a blog, which is chronological. I plan to continue to use the blog to post timely material (stuff that isn't as interesting weeks and months later) and to point you to updates on the wiki.
This book has sixty-five interrelated patterns, which comprise a vocabulary and visual notation
for developing application integration solutions using messaging. It includes examples
covering a variety of different integration technologies, such as JMS, MSMQ, TIBCO
ActiveEnterprise, Microsoft®, BizTalk, SOAP, and XSL.
This book discusses the twenty-three patterns from Design Patterns, exploring how
the patterns can be applied when developing business applications. It's written for
Smalltalk, but also applies to Java/J2EE development as well.
Book chapters:
Framework Development Using Patterns (1999)
Chapter 26 in
Implementing
Application Frameworks. This is a book on how to implement
frameworks, so it explains how to do so using patterns. This is not patterns for
developing frameworks, but how to take your favorite patterns and use them to develop
frameworks that embody them. In many ways, this paper builds on Kent Beck's article,
Patterns and Software Development.
The Object Recursion Pattern (1999)
Chapter 4 in
Pattern Languages of
Program Design 4. A GoF-style pattern that explains how behavior surfs though
object structures like Composite, Decorator, and Chain of Responsibility. It's the
recursion technique from procedural programming, updated for object-oriented
programming.
The Abstract Class Pattern (1999)
Chapter 1 in
Pattern Languages of Program Design 4. A GoF-style pattern that explains what abstract classes are for, why you don't just use concrete classes for
everything. This is a subtle issue in Smalltalk; it's much more obvious in Java.
If I were to write this pattern again, I'd adapt it to Java and split it into two
patterns, Abstract Class and Interface.
The Type Object Pattern (1997)
Chapter 4 in
Pattern Languages of Program
Design 3, also available at
Knowledge Systems Corporation.
Another GoF-style pattern, this one describes objects that have
a meta/type relationship to other objects. I updated the GoF format, adding a Keys
section that attempts to serve as a litmus test for determining whether a potential
example fits the pattern.
The Null Object Pattern (1997)
Chapter 1 in
Pattern Languages of Program Design 3. My first pattern written in the Gang of Four format. A Null Object is a special implementation of an interface
that does nothing. Martin Fowler refers to this pattern as a special case of his
Special Case pattern.
Partitioning Smalltalk Code into ENVY/Developer Components (1996)
Chapter 3 in
Pattern Languages of Program
Design 2, also available on the
Portland Pattern Repository. This pattern language
explains briefly what a layered and sectioned
architecture is, and how to map that into ENVY/Developer, a now defunct source code
management system for Smalltalk. Still interesting as a quick overview of how to
broadly architect an application.
Understanding and Using the ValueModel Framework in VisualWorks Smalltalk (1995)
Chapter 25 in
Pattern Languages of
Program Design, also available on the
Portland
Pattern Repository. This pattern language explains how the Value Model framework in
ParcPlace Smalltalk works, using well-known design patterns to explain its design. A
tidbit of trivia: The pattern language is in three parts that are basically problem,
solution, and examples, making the pattern language as a whole a bit of a higher-level
pattern.
In this podcast, I talk about the utilization of event-drivent architecture (EDA) and service-oriented architecture (SOA), and the Enterprise Service Bus (ESB) that enables the use of an EDA and SOA together.
In a world without governance. How do you control who's using your service, and who's responsible for maintaining it, and how much you can rely on the services you're using?
Introducing WebSphere Business Process Management, IBM's solution specifically designed to model, assemble, deploy, and manage applications with service-oriented architectures.
Understand the pieces and how they fit. An architect understands all of the different parts that can go into a complete solution--application, database, workflow, messaging, hardware, security, performance, etc, and how to make them fit together.
There is a vast amount of reference material on WebSphere products available at your
disposal, and nearly all of it is absolutely free. The trick is knowing what information
you need and how to find it.
This article helps you understand why an ESB is a useful and necessary
part of application integration, including SOA. The article doesn't focus on
definitions or products, but on the functions and capabilities an ESB implements
for you so that you don't have to. It shows what an ESB does for you.
Roland and I talk a lot about how the SIB works. He and Chandran already
documented
how the SIB implements point-to-point messaging.
This article documents how the SIB implements publish/subscribe messaging.
Fellow blogger James Snell and I kept talking about what ESBs are good for,
how architectures would be so much simpler if they could leverage a good ESB, and son on.
We finally decided to capture our thoughts in an article.
I answer reader questions about J2EE design and development.
It spawned a
discussion on
The Server Side
about how to handle exceptions in EJBs.
The latter questions (Learn EJB? Synchronous or asynchronous? SOA or ESB?) are really
the most interesting.
This article shows how implementations of the Service Locator pattern that include
a resource cache can cause code to run incorrectly in J2EE 1.3 and later versions.
While the Service Locator pattern itself is still useful, this article shows how
caching with this pattern is harmful rather than helpful, why it should be eliminated
from service locator implementations, and offer some practical alternatives.
This was my first article as an IBM employee, based on my frustration with
learning how to use WebSphere Studio Application Developer, and people's lack of
understanding of what transactions are and how to make use of them. This article shows a template I've since used a lot.
The first half is theory and background info, the second half shows an application using
the products. The second-half may quickly become obsolete, but the principles in the
first half are timeless.
While working on Enterprise Integration Patterns, the JMS 1.1 specifications became public.
The unified domains were very helpful, so I used it to write the JMS code examples for
the book. I then rushed to publish an article on this, before all the vendors came out
with products. Little did I know that the J2EE 1.4 application servers wouldn't hit the
marketplace for another two years!
I got on a project that had certain complex object structures. A small part of
the work was to be able to serialize the structures. This turned out to be rather
difficult. This article describes lessons learned, presented as an explanation of how
serialization works and how to handle the tough cases.
I had been working on my first workflow/business process project for the past year
and decided to document what I learned. Hopefully this article describes what workflow
is all about. Even today, many people are confused about workflow, confusing it with
messaging a data flow, feeling like they should just implement it themselves, so we
still have a long way to go.
Jerry Weinberg is a developer (PL/I Programming Primer) who decided that the
problems with development projects aren't technical, and so started writing books on how
programmers and teams can work better. He has several good books. If you can only read one,
start with BTL.
How to create a learning organization, one that gets better as it keeps running. The secret
is systems thinking, understanding what you do affects others and vice versa, and getting
out of the habit of only worrying about your own work.
The foundation of leadership is not power, but authority. Authority is not exerted by the
leader, but bestowed by those who choose to follow. Authority is built upon relationships of
respect, responsibility, and caring for each other.
Just plain common sense on what programmers should do to do their job well. It's not written
as patterns, but the bits of advice are patterns. If you're not following these practices, why not?
The original XP book. The twelve practices! The four values! How could this
possibly work? It does. A process that brings the humanity back into software development.
A big influence on me on how to do things well.
The mother of all software pattern books. Actually a strange example of the patterns form,
and it totally misses the pattern language opportunity to create synergy between the patterns.
But, still a great way to learn how to create high quality OO frameworks. The first chapter
taught me so much about OO design.
The first and best example I've seen of a software pattern language. Kent said he wouldn't
write a line of code without a pattern to explain the decisions he was making. Shows how
patterns can make an expert out of a novice.
Some very handy patterns for how to use J2EE to architect and how to design an application well.
The second edition is significantly improved over the first.
Similar to Core J2EE Patterns, it's broader in scope, but less specific in application,
because it covers both J2EE and .NET, domain model-based architectures and scripting
architectures.
A very good, but not well-known book on designing the most important part of an
application: the domain model. Rather than a heavyweight methodology like those that
became popular in the 1990's, this is a pattern language that walks the reader through
a simple and useful process.
The best book I know of for learning UML. It has a very simple philosophy,
in that it doesn't try to document all of UML, just the parts you'll actually use.
A very interesting account of how much the world has changed over the past 10-20 years.
From the digitization of information to outsourcing to wireless access, the way we do work
and who can do what is changing radically. Friedman sees what's going on, and has put all
the pieces together to explain it to the rest of us. Use this book to explain to your
parents what you do for a living.
This article describes software reuse through two development roles: abstractors,
who create reusable components; and elaborators, who hook together the components into apps.
The abstractors use patterns to document what the components are good for. This article
really broadened my view of how useful patterns can be.
This paper explains how a Web client should access XML data that it decides how to display,
not an HTML documen. This was way ahead of its time, a precursor to Web
services and SOA. This paper contains what is perhaps my favorite phrase in computerdom,
"XML gives Java something to do."
The most fun way to learn American history and how the government really works.
It looks like a grade school text book, with lots of pictures and quizzes at the end
of the chapters, but it doesn't read like one. Lots of good laughs, and you might even
learn something.
