Welcome to my blog. Thanks for dropping by. I hope you'll find it time well spent and will be back again.
The topic of this blog is "J2EE in Practice." I plan to use this space and your time to discuss issues of relevance to people who are developing applications using J2EE
and related technologies. Any facet of application development is fair game: requirements gathering, architecture, design, coding, testing, deployment, maintenance, configuration management and version control, version migration, specifications and standards, agile development, and team organization are a few of the topics I can think of. We'll probably come up with more as time goes on. And of course I'll be discussing patterns and best practices for any of these topics whenever I can.
I'd like for this to be a discussion, not a sermon, so I'd appreciate your comments, especially when you have additional information that will be helpful to all of the readers.
When I need concrete examples, I'll draw on WebSphere Application Server
and WebSphere Studio Application Developer
, since these are the products I know and use.
Lastly, a disclaimer my fellow blogger Doug Tidwell
applied to his blog applies to mine as well:
The stuff you read here is based on my own opinions and does not represent the view of IBM, its subsidiaries, its marketing and advertising agencies, its customers, or basically anyone with any sense anywhere. If you've been assuming this blog is corporate-approved content, you should check your medication.
Couldn't have said it better myself.
Having used my initial post
to describe what my blog is about, I now find myself thinking of issues I don't plan to discuss. To get this off my chest, I'll briefly discuss here what I don't plan to discuss further in the future.
I can think of at least two topics I won't be spending much time on:Emerging technologies
- While it's interesting to talk about where technology is going, that insight is difficult to apply to the applications we're developing in the present. I'll be focusing on development using the commercial-quality products we have today and techniques that can be applied now. Not too surprisingly, given my employment, the products I'll focus on will be WebSphere Application Server
and WebSphere Studio Application Developer
. For a discussion of the future, please visit my fellow blogger James Snell
- As long as I've been developing software (fourteen years or so professionally), there have been competing mega-processes for software development. They tend to be about 87 steps long and can require an army of consultants just to handle the paperwork. Making 85 of the steps optional doesn't make using the process any easier; then you don't know which steps to keep and which to skip. If you find that applying a methodology is helpful to you and your team, then more power to you. But I've seen plenty of teams get in trouble either because they get bogged down with following all of the methodology's steps or because they dutifully adhered to some methodology's dictates without truly making their development process better. "How can our application not work? We followed the methodology precisely." It's up to you to monitor how your project's doing; keep what works and change what doesn't.
I'm often asked how to learn Java or what book to read on J2EE. (As a book author, I like it when people want to learn by reading books.)
If you don't know Java or J2EE at all, I don't know how you should learn the basics. I started by hacking other people's examples and writing my own little "hello world" programs, adding features to learn them: a "hello world" servlet, a "hello world" session bean, "hello world" in a JMS message, etc. I remember that running a simple one-class J2SE program was harder than writing it. I had the darnedest time with classpaths; seems like I was always getting NoClassDefFoundError
whenever my code was supposed to run.
Where can you get a more guided education? Sun has its tutorials
. This site (developerWorks) has a whole page of links on learning Java
, and another on getting started with WebSphere
. I've also heard good things about the book Thinking in Java
(and not just from Bruce!). If you've recently learned Java or J2EE, please add a comment to this blog entry and let us know what resources you've found helpful. Or, if you don't want to post a comment, send me e-mail and I'll post a summary of the suggestions I receive.
Once you know the basics, I can help you improve your skills. The best book I know of for becoming a great J2EE developer is Core J2EE Patterns
, Second Edition. (I bet you thought I'd name a book I wrote. I'll get around to that sometime, but not now.) Its advice applies to programming in any J2EE application server, including WebSphere Application Server.
For WebSphere audiences, two more books I recommend are from colleagues of mine in ISSW: Enterprise Java Programming with IBM WebSphere, Second Edition
on application development with WebSphere Studio and IBM WebSphere: Deployment and Advanced Configuration
on, well, deployment and advanced configuration with WebSphere Application Server.
I'll talk more in a later entry about other good stuff to be reading, but this should be a good start.
In a previous post
, I commented on how I don't like mega-process methodologies. So what do I think you should be using instead?
For me, I prefer the so-called agile methodologies
(kind of an oxymoron, but that's what they're called), particularly the teachings of Kent Beck
: Extreme Programming
(XP), Test Driven Development
(TDD), and its practice of using JUnit
. It also advocates continuous integration; an especially helpful tool for doing this is CruiseControl
, originally developed by ThoughtWorks
(who are big on agile methodologies in general). Another resource for agile development is the Agile Alliance
and their simple yet insightful Agile Manifesto
I think this sort of lightweight approach beats some 87-step methodology anytime.[Read More
I'm currently attending IBM WebSphere Technical Exchange
2004 in San Francisco, California. In one of my talks, "Architecting and Developing J2EE Applications Using Patterns," I talk about the Business Object
and Domain Model
patterns and how to persist these objects. I suggest that, in general, when developing a J2EE application, you should implement your business/domain objects as Enterprise JavaBeans
(EJB), more specifically entity bean
s, more specifically those implemented using container-managed persistence
Some of my audience members asked a rather interesting question: What about Java Data Objects
(JDO) or Hibernate
? Why use CMPs instead of those? Here's the answer I gave them.
CMP entity beans are part of EJB and therefore J2EE
. Thus there is built-in runtime support for them in WebSphere Application Server
(WAS). Furthermore, there is built-in support for entity beans and specifically CMPs in WebSphere Studio Application Developer
(WSAD). This support provides tooling for developing the O/R mappings
needed to make CMPs (or any other persistence approach) work (see "Developing and Testing CMPs with the Table and Data Source Creator in WebSphere Studio Application Developer Version 5.1
"). The tooling supports three development approaches:
- Top down - You've already developed an object model using entity beans, so the tooling generates the relational database schema for your data model, which you can then execute to configure your database.
- Bottom up - You've already developed a database schema, so the tooling generates a set of entity bean classes for an object model that matches you data model.
- Meet in the middle - You've already developed entity bean object model and a database schema, so the tooling takes a stab at mapping the two and then lets you adjust and finalize the mappings.
In any of these approaches, if you're using CMPs, the tooling also generates the necessary parts of the deployment descriptor
to perform the O/R mappings.
JDO, Hibernate, and similar approaches for solving the O/R mapping problem are admirable efforts. But bottom line, they're not part of J2EE and are not supported by WebSphere products nor by most (any?) other J2EE products. I (and many (most?) of my IBM colleagues) recommend that you develop your J2EE applications to the J2EE specification, maximizing use of the J2EE services. CMPs are part of J2EE; JDO and Hibernate are not.
Because approaches like JDO and Hibernate are not part of J2EE and WebSphere, to use these approaches, you have to add this support. This means that you have to add libraries and frameworks to the application server runtime to support the approach. And you should have tooling for your approach to support developing the O/R mappings (which should ideally be Eclipse plug-in
s so that it can easily be added to your Eclipse IDE or to WSAD). WebSphere customers have already invested money and time into using WAS and WSAD; I would be hesitant to invest more cost and effort into additional products to solve the same problem.
I was very excited about JDO when it was developed and finally released. However, the process took a long time, and in the meantime, the entity bean spec evolved to incorporate many of the innovations that were also going into JDO (the evolution of dependent objects and container-managed relationships in EJB 2.0
comes to mind). Hibernate has gotten a lot of favorable attention, and in fact EJB 3.0
), the next version of EJB (unofficial FAQ
), will incorporate many Hibernate-like features. This is no coincidence; Gavin King
of Hibernate is a member of
the EJB 3.0 committee.
So bottom like, I think WebSphere customers should use CMPs. They increasingly have many of the advantages of JDO and Hibernate, are a standard and supported part of J2EE and WebSphere, and will have an upgrade path to future versions of J2EE and WebSphere. This seems like the best of all worlds.
Having said all this, I also have to agree with Don Box
when he said
: "As an aside, I really wonder how many O/R mappers the world needs. It's frightening how much energy goes into building these things (on both sides of the aisle I might add)."
Thinking about Kent Beck
and Extreme Programming
have gotten me thinking about some great quotes I've heard from him over the years. Some that come to mind are:
An audience member asks: "Can you prove that XP scales to work on large projects?" Kent responds: "Can you prove your favorite heavyweight methodology does?" Touche!
"Reuse is easy. Just separate the part that changes from the part that doesn't."
"There are only two ways to improve some code's performance: Make it do fewer things, or make those things go faster."
In a discussion about TDD
, an audience member asks: "Isn't building all of those tests a hassle and unnecessary? They're not part of the product you ship to customers." Kent responds: "The same can be said for the scaffold used to build a building. Once the building's complete, you dismantle the scaffold. Therefore, if you could build the building without building the scaffold as well, that'd be a lot easier. But until there's a way to do that, the scaffold is necessary too."
I also remember a very simple quote from Ward Cunningham
: "You have to stop and ask yourself: 'What's the simplest thing that could possibly work?'" When I heard this back in the mid-1990s, little did I know that this nugget of truth would become the foundation for XP.
I've just published an article in the IBM WebSphere Developer Technical Journal
: "Eliminate caching in service locator implementations in J2EE 1.3: When bad things happen to good applications
." It explains how shared resource names can become overloaded, and how the cache that is usually part of a Serice Locator implementation will not handle that overloading properly. The simplest solution? Take out the resource cache.
If you use the Service Locator pattern in your application, you should check out this article. If you don't use the Service Locator pattern, you should; then check out this article.
My colleague Bill Higgins has a new blog here on developerWorks, Enabling IBM's own On Demand transformation
. I think Bill's job is really interesting (OK, for a computer job; he's not an international man of mystery
or anything) because, within IBM, he actually has to eat his own dog food
. Whereas people like me can advise IBM customers as to what they should do, Bill and his team actually have to do it and live with the consequences. Thus I expect some very practical insights into what it really means to become an On Demand
organization and what it really takes. Check it out.[Read More
Another quote from Kent
is a simple three-step code development process
for developing any code component, framework, application, etc.:
- Make it work
- Make it right
- Make it fast
(Imagine Kent ticking the points off on his fingers as he's saying this.)
I'll cover these steps in detail in my next three blog entries.
The first step in Kent's simple three-step code development process
Make it work
First, you gotta make the code work. Even if it's totally unmaintainable, duplicates code, and performs slower than molasses, at least it works. That beats beautiful code that doesn't work any day. Code has gotta do what the users want.
A number of times over the years, I've worked on a programming problem I found challenging at the time. To make progress, I backed-off trying to write good code, and just tried to write something that would work. Once you've got it working, then you can say with 20/20 hindsight, "Now that I know what I need to know, knowing what I know now, here's how I would do it differently."
Some people interpret the first two steps, make it work and make it right, as meaning that code can somehow work even if it doesn't work right. That's not what's meant here. Work means that it passes your JUnit
tests, even if it's really ugly code. Right means that it's well designed code that also works, which I'll talk about next.
I just attended this month's meeting of the Research Triangle Park Java User's Group (TriJUG
). The speaker tonight was Patrick Linskey
, speaking on "The Future of Object Persistence
." Patrick is the CTO of SolarMetric
(an IBM partner
), the makers of Kodo JDO, a JDO
-compliant persistence engine. Patrick is also a member of the JSR 220
(EJB 3.0) and JSR 243
(JDO 2.0) specification efforts.
Patrick directed us to A Letter to the Java Technology Community
, a rather generic title for a very significant announcement: Sun Microsystems (working through the JCP
) intends to develop a unified spec for persisting POJO
s that combines the best features of both entity beans
and JDOs. (Commentary: Javalobby
) For the time being, Patrick has dubbed this new feature the Unnamed Persistence Specification (UPS).
This new feature will be part of both J2SE
is) and will be available in the J2EE 5.0 (JSR 244
) timeframe. It will be developed as part of the EJB 3.0 JSR, yet will be run by a separate committee (consisting of six members from the JDO JSRs and six members from the previous EJB JSRs) and the resulting spec will be usable with or without EJB and therefore with or without an EJB/J2EE container
. Thus Patrick predicts that this UPS effort will be spawned off into a separate JSR from the rest of the EJB 3.0 effort (such as Hibernate
-like annotations on the bean class), which seems sensible but has not yet been decided.
Parts of the current vision for "UPS beans":
- They will not support remoteness like an entity bean with a remote interface, since that would require an ORB.
- They will not support declarative security like EJBs do, since that would require a container.
- They will support the EJB container-managed transactions (CMT) model so that you don't have to write transaction delimiter code, can manage the transaction model in the deployment descriptor, and (very importantly) so that UPS beans and other EJBs (i.e. session beans) can participate in the same transaction.
In a previous entry
, I made the case that WebSphere customers should stick with entity beans for persistence because they're part of the J2EE spec and thus supported by WebSphere Application Server
and WebSphere Studio Application Developer
. On the other hand, JDO does seem to support developing much purer Java domain models. So hopefully this new UPS solution will be the best of both worlds. This is getting interesting.
The second step in Kent's simple three-step code development process
Make it right
Once the code works, then make it right. Eliminate duplicate code. Split large methods into smaller ones that each only does one thing and at one level of abstraction. Spit classes into ones where each one only has one set of responsibilities and only contains the code for doing that. Use intention revealing method names
This is called "refactoring
." A great way to learn more about this process is to read the book Refactoring
by Martin Fowler with a lot of input from Kent Beck. Although the title doesn't say so, the material is organized as patterns, repeatable solutions for improving the design of existing code. Refactoring is a key part of Extreme Programming
) and one of the main motivators for writing a lot of JUnit
tests: First make sure all your tests pass, then refactor, then rerun your tests. If any fail, fix the code. Once all of the tests pass again, the code must work as well as it did before, but is now designed better.
Two of the contributors to Refactoring
are Don Roberts
and John Brant
, now of The Refactory
, who developed the Refactoring Browser
for VisualWorks Smalltalk
in the late 1990's as part of professor Ralph Johnson
's (co-author of Design Patterns
) program at UIUC
. Today, we take it for granted that IDE
s like Eclipse
and WebSphere Studio Application Developer
(and others) offer lots of automated refactoring features
, but Don and John are the guys who started the whole thing. (Back then, I thought, "Why not just refactor code by hand?" This is what we all did at the time. Don and John were more visionary than me.)
My fellow blogger James Snell's recent post about DNS Endpoint Discovery
, a technology for discovering UDDI
servers, reminded me of one of my favorite rants lately. I can summarize this rant in two words:
Perhaps I should elaborate. UDDI seems like a reasonable solution to the stated problem, namely how to find the endpoint URL for a web service you want to invoke. I just think the problem is the wrong one to solve.
What do I think is better? I can summarize that in three words:
Enterprise Service Bus (IBM hype, dW article, Redbook)
There's a lot of reasons for why ESB is better, but the main differentiator is this: With UDDI, you have to know the address of all the providers of a service and choose amongst them. With ESB, you just have to put your request on the right queue and it'll get fulfilled without you having to know who the providers are or which one should handle your request. The ESB does the work for you.
For a discussion of the basics of this design, see the Message Bus
pattern. The complete pattern is in the book Enterprise Integration Patterns
The third step in Kent's simple three-step code development process
Make it fast
Only once the code works and is written well should you bother to try to improve its performance. Otherwise, you tend to waste a lot of time on premature optimization
: fixing slow spots in code that either turn out not to be slow, turn out not to have much affect on the overall performance of the application, or turn out to get eliminated or greatly changed in a refactoring
You gotta have working code to improve its performance; code that runs fast but does the wrong stuff isn't very useful
. And there's no use tuning the implementation of badly written code; make it well-written first; often, well designed code runs faster anyway.
Performance tuning without performance testing is like shooting in the dark. Don't guess at what code's gonna be a performance bottleneck; ask the program
. Performance testing
tells you definitively where the bottlenecks are so you can start widening them, which is the best way to produce real performance benefits for your users.
BTW, there's a very good book on performance tuning J2EE applications that's been rather overlooked: Performance Analysis for Java Web Sites
, sample chapter
) by Stacy Joines
, Ruth Willenborg
, and Ken Hygh. These are three sharp people in IBM SWG
development (Ruth) and services (Stacy and Ken); their whole job at IBM is gto figure out how to get WebSphere Application Server itself and the J2EE applications deployed in it to run faster.
Turns out Ward's Wiki
has an Extreme Programming Roadmap
. A good place to go find out about all things XP.
I'm attending OOPSLA 2004
. Steve McConnell
, author of Code Complete
, gave this morning's invited talk, "Realities of Modern Software Construction." He made a lot of really great points, some of which I may relate in the future, but today I want to focus on an analogy he made, the Swiss Army knife.
A Swiss Army knife
is a knife whose handle not only contains the knife blade, but also contains a bunch of other tools like a corkscrew, scissors, tweezers, and so on. This can be a really handy pocket device if you indeed need all of these tools.
The analogy for programmers is that too much of the code we write is too much like a Swiss Army knife. What our customers need is a knife, but that's not what we build them. Rather, while we're building them a knife, we also build them a whole lot of other stuff they haven't asked for and don't necessarily need. Because of these extra and unneeded features, the program is unnecessarily complex, takes longer to develop than it should, and costs more than it would if it were just a knife. And sadly, the knife often isn't very good, mostly because we couldn't focus on making it good because we had too many other features to work on.
This is a failure to apply the principle You Aren't Gonna Need It
. This principle is that you should only develop what your customer needs right now and no more. If they need more in the future, you can develop it for them at that time. This is likewise a principle of Test Driven Development
: Develop tests for what the customer needs, and then only develop code that helps make tests pass.
It's very tempting, while developing a needed piece of functionality, to develop a bunch of other related and interesting pieces of functionality while you're at it. Resist the temptation. Develop what you need and no more. It'll make you a better programmer.
|Microsoft has quite a presence at the OOPSLA conference this year. Microsoft historically hasn't been very involved at OOPSLA, but as they're trying to participate better with the rest of the industry, they seem to be doing so at OOPSLA. (See comments by MSDN and Harry Pierson on the topic.)|
A few examples:
- Keynote, "The Future of Programming" by Rick Rashid, head of Microsoft Research. Decent keynote, but then he took time out to let someone from the Visual Studio team supposedly demonstrate some new domain specific language features in Visual Studio 2005. (See "The Role of Models.") Like Visual Studio really needs the publicity. The whole demo came across badly; seemed to mostly demonstrate that Microsoft has reinvented HotDraw twenty years later. I still don't know what Visual Studio does for DSL.
- Invited talk, "Realities of Modern Software Construction," by Steve McConnell. (See "Swiss Army Knife Designs.") Steve's not a Microsoft employee, but his book, Code Complete, is from Microsoft Press.
- Invited talk, "Objects, Patterns, Wiki and XP: All Systems of Names," by Ward Cunningham. Ward has accomplished a lot, as he recounted in his talk. About a year ago, he joined Microsoft.
- Invited Talk, "Concrete Languages on Virtual Platforms," by Herb Sutter of Microsoft. He is developing C++/CLI, a new standard version of C++ that runs on virtual machines. Visual C++ 5.0 will be built on C++/CLI.
- Each attendee received a free (no extra cost) copy of Jack Greenfield's new book, Software Factories (with the scary-sounding subtitle "Automating Application Development"), a big topic at Microsoft.
So Microsoft is very active at OOPSLA this year. They're embrassing and extending
objects and the whole OO thing. The question is where this will lead.
To return back to Rick Rashid's keynote, here's one assessment
from the OOPSLA wiki
Tuesday's opening keynote by Rick Rashid was quite interesting until it was derailed by an offensive (and irrelevant?) commercial product announcement and demonstration. A sizable number of oopsla participants left the keynote in disgust and there were several unsavoury words directed towards the hucksterism by the disgruntled crowd gathered outside. Disappointing to say the least.
When Bill Gates
gave an invited talk
at OOPSLA 2002
(in Seattle), there was a lot of concern that it would just be a Microsoft promo (and/or that the audience would be quite hostile). Indeed, his assistants gave demos of a couple of interesting technologies Microsoft was working on, including the handwriting recognition algorithms that went into their new tablet version of Windows
. Rather than being commercial, this came across as educational. The talk was well received.
The demo part of this year's keynote was not well received because it came across as being a commercial and self-serving, not educational and serving the interests of the conference community. Hopefully this example is not typical of what Microsoft's participation will be like in the future.
My fellow blogger James Snell
and I are having a friendly debate about the relative merits of UDDI
. In UDDI and DNS-EPD
, responding to my subtlety-titled UDDI Sucks
entry, James rightly points out that different tools work for different purposes. Indeed, as I said, "UDDI seems like a reasonable solution to the stated problem... [but] the problem is the wrong one to solve."
So, what's wrong with the approach UDDI solves? Here are some of the problems:
- Synchronous, point-to-point web services -- UDDI enables the client to lookup the URL for invoking a web service over HTTP. This requires invoking the service synchronously. Assuming the caller invoking the web service is another application, application-to-application integration is best accomplished asynchronously.
- Multiple matches -- With UDDI, the client specifies the WSDL for the web service it wants, and UDDI returns a list (URLs) of providers of that service. It is then the responsibility of the client to choose one of those service providers, yet it has very little information with which to make an informed decision.
- Repeated lookups -- After a caller looks up a service's address, things may change. The service may relocate to a new URL, other providers of the service may become available, the quality of the connection to the various providers can fluctuate. This makes the client defensive, repeatedly looking up the service to see if there's anything new. Likewise, the chosen provider may become unavailable, forcing the client to go look up an alternative (unless it has cached that information, but then it may become stale).
An Enterprise Service Bus
(ESB), on the other hand, encapsulates all of these details and handles them for the client so that it doesn't have to:
- Asynchronous -- One client thread fires and forgets the SOAP request, another thread listens for the SOAP response (or fault). This also enables multiple network paths to the same provider, and resiliency (via queuing) in cases where none of the providers are available at the moment.
- One channel per service -- To invoke a service, the caller puts the request (whose format is described by the WSDL) on the proper channel/queue/pipeline, then listens for the response on the appropriate reply channel (either specified in the WSDL or specified by the caller in the request message). If there are multiple service providers, the ESB figures out which one to dispatch the request to. This can be based on real-time metrics like load, latency, availability, etc. The way most messaging systems work, this balancing is done automatically--a provider which is overloaded or out-of-service simply won't consume the request.
- Single point of contact -- The caller need only know how to address the request channel (such as its URL). This can remain fixed even as service providers come and go and sometimes change their addresses. It's a level of isolation between the callers and the providers that adds stability.
One more point: An ESB can act as a directory service in the same spirit as UDDI. Basically, a caller would ping the ESB much the way it pings a UDDI server, saying "who implements this WSDL?" and the ESB responds with the request and reply channels to use. So maybe DNS-EPD
should provide a way to find ESB hosts as well as UDDI hosts. (And it probably does.)
has a new section I didn't know about, the Power Architecture Zone
, dedicated to Power Architecture technology. You might ask, "What is Power Architecture technology?
" It's a set of microporcessors produced by IBM
that are the CPUs for Macintoshes
and a lot of IBM eServer
There's also a blog on this topic, Power Architecture zone editor's notebook
, by Nora Mikes, who just so happens to be the editor of the zone. She also has an article, "POWER to the people: A history of chipmaking at IBM
So, if you want to learn more about the hardware used to run some of J2EE and WebSphere Application Server software, go check this out.[Read More
The recent OOPSLA 2004
conference featured a panel, "The Great J2EE vs. Microsoft .NET Shootout
" The speakers were Don Box
(Microsoft), John Crupi
(Sun Microsystems), Rob High
(IBM), Anders Hejlsberg
(Microsoft), and Alan Knight
(Cincom). See "Programming Legends Debate .Net, J2EE
(biased towards Java? Nah!) has captured some of the more memorable quotes that were said in the article "Microsoft's "Java Envy" Is Undeniable, Don Box Admits
." This is something Don has talked about in this blog. Now Microsoft's paying attention: "Does Microsoft Have Java Envy?
I was there. Honestly, each side had nice things to say about the other. Each technology is influencing the other. The main difference is that Java is a federation of separate companies and individuals who thus debate alternatives in public, whereas .NET is run by one company ("the big house") which debates alternatives in private. The debate on where to go next is happening with both technologies; we just don't hear about the private conversation we're not invited to.