In the theme of Keeping WAS Up-To-Date, there's a new fix pack for WAS 6: 126.96.36.199: WebSphere Application Server V6.0.2 Fix Pack 3 (Reference #4010724 for the Windows version, for example).
This is the latest update since WAS 6.0.2 became available back in July. The new update is listed on the Recommended Updates for WebSphere Application Server Base and Network Deployment editions page. Readme for IBM WebSphere Application Server V188.8.131.52 (Reference #7006756) describes in general what has changed; 184.108.40.206 - 220.127.116.11: List of Updates for Base, Network Deployment, and Express Editions lists all of the APARs (the interim fixes). You can use the WAS Update Installer to install the refresh pack.
Bobby Woolf: WebSphere SOA and JEE in Practice
From archive: November 2005 X
One quality a well written pattern has, a style that separates it from not-so-well written patterns, is what we call "Therefore, BOOM!"
We figured this out at the first couple of PLoP conferences--writing patterns, reading each others' patterns, and discussing what seemed to work best. Ken Auer has documented this well in "Therefore, BOOM!" It's already described in Sun's Java Patterns Community, so I'll let you read about it there.
Simply put, as a pattern author, to the extent you can write your document to embody this "BOOM!" quality, the better your pattern is. I believe that it makes your pattern better in at least two respects; it makes your pattern explanation:
"BOOM!" is one of, if not the, major reasons why well-written patterns work so much better than just using standard prose. A pattern is not an experience report, and it's not an account of a cleaver trick; it's a mind-meld from an expert to a novice of what works well. It's a best practice that you know not just in your head, but in your heart and your gut as well. "BOOM!" gets that gut feeling across in a way that words alone cannot.
Think about a pattern you've read that really resonated with you, where you knew as soon as you read it that the author knew exactly what he was talking about. (And if you've never had this experience, you need to read more and better patterns.) Remember how you felt (not what you thought, but how you felt) when you read that pattern? That's "BOOM!"
A well written pattern has a style we call "Therefore, BOOM!" We've now decided that a well written antipattern has a style we've christened "Therefore, D'OH!"
Last week, I helped run a conference on antipatterns. We ran it very much like the PLoP conferences. It's given me the opportunity to teach a new group of people about patterns and pattern languages, writer's workshops and shepherding--all good stuff that I learned at PLoP. It's always fun to be a member of a smart group of people who are eager to learn.
A lot of what I talked about at the conference was my ideas and experience with how to write good patterns, that is, how to write patterns well. I've learned this over several years working with many knowledgeable people at PLoP, and through practice, practice, practice.
One practice we've found for writing a pattern well is "Therefore, BOOM!" I wasn't sure how well this idea would go over in an antipatterns conference, but it took quite well indeed. Being that an antipattern is the opposite of a pattern, we found the opposite of "BOOM!" as well.
We call this quality of an antipattern "Therefore, D'OH!" (And no, I didn't coin the term, but I loved it as soon as I heard it.) It's where the antipattern paper makes you, the reader, realize how stupid (i.e. uninformed, misguided, naive) you were to apply this common but misguided solution. The writing style makes you realize, "Darn, why did I do that?!"
Where does the name come from? "D'oh!" (listen to 32 Dohs (WAV file)) is the sound Homer Simpson makes when he realizes that he's made a mistake. It signifies his sudden realization of his own stupidity.
Much like suddenly realizing that in your actions, you've followed an antipattern.
Way back in The Relationship between RAD 6 and WAS 6, I talked about test environment servers in RAD 6, a feature from WSAD 5.x. According to comments on that posting, there seems to be some confusion about how to create a test environment server for WAS 6.
I guess this is not obvious (enough), but simply put, WebSphere 6.0 Server is the test server; see Creating a WebSpherev6.0 server. RAD distinguishes between a WAS 5.x Test Environment server, used for testing in RAD, and a WAS 5.x server for publishing, used for deploying to a WAS install outside of RAD. The WAS 6.0 server option can be used for both (which I don't think is actually explained anywhere).
Also, be sure to create a separate profile for each of your test servers, so that you can admin them independently; see RAD 6: How to Create a Server. Those instructions are a little out of date now; I think the latest versions of RAD now have a menu choice for running the profile wizard. Anyone want to add a comment on what that menu choice is?
Back when I was talking about test servers in RAD 6, this question kept coming up in the comments: "How would you address the issue of many developers wanting to share a common server configuration?" Let me try to address this issue (finally!).
For context, see:
First off, let me say that I've never done this. If I had, I would have documented this a long time ago. But I've been thinking about it and conferring with my co-workers, and here's what I think will work.
The simplest approach is to copy the profile directory and distribute that. See WAS 6: Application Server Profiles and "Easier system management with profiles."
The best approach is to write wsadmin scripts to create the configuration you want. Each developer can run it on his test server to config it, and you can use it as the basis of deployment scripts when you're ready to go into production (but test them first!). For help, see:
Another suggestion: In RAD, go to the Windows --> Preferences --> Server page and check the Create server resources in workspace box. You can then copy and share these files.
So, hope that gets you going. If you find that one of these techniques works especially well for you, please add a comment to this posting.
BTW, let me say thanks to my ISSW colleagues Roland Barcia, Paul Glezen, and Saravana Chandran for their help with this posting.
Also see: Sharing a Test Environment Configuration (part 2)
Antipatterns should be ameliorative. For that matter, patterns should be too. For that matter, so should you, at least in the way you do your job.
Ameliorate (verb): to make a situation better or more tolerable
I've been talking about antipatterns. It's not just enough for an antipattern to give a common solution, to say "Bet you did this, didn't you? D'oh!" It then needs to offer a preferred solution. This makes the document ameliorative; it helps the reader understand not just why their situation sucks, but also figure out how to make their situation better.
Any pattern should be ameliorative. It tells the reader what to do to make their situation a good one, perhaps better than it was, in any event better than it would be if they applied a less-than-best practice. If a pattern documents an approach which is not ameliorative, whatever it's documenting is not much of a pattern.
When you're doing your job, are you ameliorative? Are you making the situation better? Or worse? Perhaps you're trying to make it better but the situation fights back; that's just a bad (but common) situation. But in a reasonable situation, if you're not helping to make things better, why not? See the importance of leadership. Leaders ameliorate.
So, be ameliorative. Get out there and ameliorate.
Sometime back, I discussed how you Can't Use MessageListeners in J2EE. Turns out that how you're supposed to do this in a client container isn't exactly obvious either.
Turns out there are two setMessageListener(MessageListener) methods:
So, which to use? Well, the Javadocs for the
WSCL0100E: Exception received: java.lang.reflect.InvocationTargetException
Turns out that
The method in
This makes sense. A single session can have multiple message consumers, and each can have its own message listener. So, remember to use the right method.
I've discussed the IBM Java Developer Kits that you can download and use, including the new J5SE betas. We now have a JDK for the Apache Harmony project.
IBM Development Package for Apache Harmony is for use with Apache Harmony, which IBM is participating in. IBM says this JDK can be used with the Harmony code but is not (yet?) part of the Harmony code (which I think explains why you have to download it from our site instead of Apache's). The JDK is free, but unsupported.
James Governor, one of the brains over at RedMonk, has been blogging a lot about IBM lately.
In SOA is going to need mainframe skills and disciplines, his general theme is that mainframe development skills will be helpful for developing SOA apps; perhaps so, perhaps a new career opportunity for some people. I really like this line from the posting: "The last few years have not been about SOA, but JBOWS (just a bunch of web services)." JaBoWS (I like my spelling better); I like that; have to'll keep that in mind.
Most of the postings on that Mainframe blog are about z/OS and IBM. (Gee, I wonder why?!) The postings seem to be by a number of people, not just James.
On his MonkChips blog, James has been blogging a lot about IBM lately:
I haven't had time to digest all that yet, but it looks like interesting stuff, so check it out.
For a while now, we've had this thing going on inside of IBM. We're not supposed to call the people who buy our stuff "customers" anymore, we're supposed to call them "clients." What's that all about?
It's explained in "IBM's Management Makeover" (Nov. 2004) in Fast Company magazine.
To begin with, the best executives no longer thought of the folks to whom they sold stuff as customers; they saw them as clients. The difference? "A customer is transactional," says Harris Ginsberg, IBM's director of global executive and organization capability. "A client is somebody with whom you have a longstanding relationship and a personal investment." It's no longer enough to sell a customer a server. An IBMer should be so focused on becoming a long-term trusted partner that she might even discourage a client from buying some new piece of hardware if it's in the client's best interest to hold off.
So a customer is a one-time sale. A client is an ongoing relationship, with additional sales from time-to-time as needed. We want a buyer to be customer again and again; that's a client. And check out that last part: We don't want to sell you something if we think you don't need it! Such a sale might be good for a customer, but not a client.
Personally, the term "client" kinda messes me up, because it makes me think of client/server and EJB clients. Then again, maybe IBM is and should act that way to its buyers, acting as a server providing services (hardware, software, knowledge workers). Anyway, I guess I'm just getting too caught up in computer-speak and need to adjust more to business-speak in this case.
Our CEO, Sam Palmisano, talked out the customer/client difference in this article in Fortune magazine, "Can IBM Get Great Again?" (but you need a subscription). Here's some guy talking about very much the same thing: What You Call Your Customers Matters.
Say that you're nobody's boss, you're just a cog in the big machine (so to speak). How do you get anything done? A technique IBM (and others?) terms "collaborative influence."
Collaborative influence is another topic discussed in "IBM's Management Makeover" (Nov. 2004) in Fast Company magazine, the same article that discussed how IBM Customers Are Clients:
The 33 leaders [who had been identified as outstanding leaders in the new on-demand era] were also adept at a skill IBM calls "collaborative influence." In a highly complex world, where multiple groups might need to unite to solve a client's problems, old-style siloed thinking just won't cut it, and command-and-control leadership doesn't work. "It's really about winning hearts and minds -- and getting people whose pay you don't control to do stuff," says Mary Fontaine, vice president and general manager of Hay's McClelland Center for Research and Innovation.
So collaborative influence is how you work with people you have no direct control over, yet persuade them to do what you'd like, what is hopefully beneficial for the group.
I wasn't familiar with this term, but as a consultant to some of IBM's WebSphere clients, I often feel like this sort of persuasion is the only real power I have. I can't fire anyone; in fact, if anything, they can "fire" me (from their project, not IBM). Yet I need to convince them to stop doing some of what they're doing, since apparently that's limiting their success with WebSphere products, and start doing things differently, even though they may well not want to.
I'd argue that in our modern workplaces, and in life in general for that matter, the only real power any of us really has is collaborative influence. We all work with lots of people we can't fire, yet whom we need to persuade to take certain actions to help all of our success. Even bosses have pretty limited authority: Yeah, they can fire you; but if you have good skills, you'll just go get another job somewhere else, and now your boss and his/her team are without the benefit of your skills. D'oh! The best bosses, I find, are those who attract the best people they can find to their teams, encourage everybody to work together, and then get out of the way. That's collaborative influence.
I think collaborative influence is an important component of leadership, a quality we all need to get better at. Many of the non-programming books I read are on leadership, teamwork, and that sort of thing; I'd suggest you should too.
I'm pleased to find that IBM has an article on collaborative influence called "Changing Minds":
You can upgrade your IT. You can rewrite your processes. But you won't change your business if you can't change your people--how they think, how they work together and how they use the resources around them.
It's on a section of our web site called "Boost team performance," kind of a developerWorks for workplace skills. It has articles, case studies, and executive guides. (Shockingly enough, we even have some services we'll sell you to help you achieve this.) The theme of boost team performance:
Bring your people, departments and partners together to boost productivity, streamline the workload and sharpen employee training for a constantly changing world.
So not only is your IT on-demand, your whole company and workplace is an On Demand Business. Yeah, this gets kind of hypish, but the focus here is on helping people to work together, and I think that's important.
So, do you have collaborative influence? What can you do to get more? How can you use it to do your job better?
IBM has published a set of values that help guide the company, namely its employees, and how we work with clients.
As documented in Our Values at Work on being an IBMer and elaborated on in Corporate profile: Values, the values are:
Yeah, hoopla, but I can tell you, IBM reminds us employees of this stuff all the time and really expects us to live it. It's the basis of our Business conduct guidelines. It guides us on making sure to treat our clients right, work on what's important, and stay out of trouble.
These values are discussed in--you guessed it, my favorite year-old article that I just discovered this week--"IBM's Management Makeover" (Nov. 2004) in Fast Company magazine, the article that also discusses how IBM Customers Are Clients and Collaborative Influence. The article casts the values as "IBM's New Leadership Traits," which ties in nicely to the leadership stuff I've been thinking about.
These values seem to have spawned imitation, if not word-for-word duplication. A company called BizAtomic appears to have cribbed our values. Ditto for the CEMA Territory Champion award, and for ProGroup. Two of the three values of JSB Intelligence seem familiar (guess they don't innovate). But I guess that's the sincerest form of flattery. Although I might quibble about the irony of apparently plagiarizing the wording of a value espousing trust and personal responsibility. D'oh! (Disclaimer: I'm not trying to talk trash about any of these companies, and I don't know for sure where they got their wording from. But they appear to be copying IBM, and not giving IBM credit.)
Here's where you can do some more reading about these values:
IBM has announced the results of the SPECjAppServer2004 performance benchmark. In it, WebSphere Application Server beat the competition (BEA) by 64 percent.
The press release is IBM Software Smashes Java Performance Record, which discusses the SPECjAppServer2004 Results, which include the Fourth Quarter 2005 SPECjAppServer2004 Results.
In the results, the best time came from WAS 6.0 ND running on a IBM eServer p5 550 with SUSE LINUX Enterprise Server 9 and DB2 Universal Database 8.2 (details). This configuration clocked in at 2921.48 JOPS (jAppServer Operations Per Second). By comparison, the other configuration benchmarked this quarter was BEA WebLogic Server 9.0 running on a Sun Fire X4100 Cluster, which produced 1781.47 JOPS. (2921.48 - 1781.47) / 1781.47 = 63.99%, so WAS did 64% better.
So what is SPECjAppServer2004? From SPEC's home page:
The Standard Performance Evaluation Corporation (SPEC) is a non-profit corporation formed to establish, maintain and endorse a standardized set of relevant benchmarks that can be applied to the newest generation of high-performance computers. SPEC develops benchmark suites and also reviews and publishes submitted results from our member organizations and other benchmark licensees.
Members include IBM, BEA Systems, Sun Microsystems, Oracle, Hewlett-Packard, JBoss, and Microsoft. You can learn more about the benchmark itself from the SPECjAppServer2004 User's Guide.
Dec 16, 2005 Update: IBM, at BEA's request, has asked me to modify this blog posting from its original content to no longer discuss the BEA press release. The use of and comparison of the CPUs/1000JOPS was a violation of the SPEC organization's SPECjAppServer2004 benchmark rules as outlined in SPECjAppServer2004 Run and Reporting Rules V1.02. IBM wishes to emphasize their desire to support the rules of the benchmarking organizations it belongs to. Although I am hesitant to make major changes to historical blog postings, it is important that IBM cooperate with other industry organizations and it is always my intention to support that; this includes remedying statements that are later found to be inconsistent with agreed upon rules. Accordingly, as per my employer's request, I have struck out the paragraphs in question.
Incredibly, the BEA table actually shows that their results are getting worse!?! Whereas they achieved 7.21 CPUs per 1,000 JOPS (CPU/KJ) back in the Aug 05 benchmark, they've now fallen to 11.23 CPU/KJ in Oct 05. They didn't include the latest WAS benchmark in their table, but the figure is (32 / 2921.48) * 1000 = 10.95 CPU/KJ. So WAS in Oct 05 actually did better than WLS in Oct 05, though neither did as well as WLS in Aug or Sept. At least WAS is better now than the figures listed for Jan 05 and Dec 04 (11.99 and 14.89, according to BEA).
So BEA isn't really bragging that they're more efficient now, but that they were two months ago; except their efficiency is getting worse whereas WAS's is getting better. Is this really what BEA is saying?! Gotta love statistics!
For more commentary, see:
I'd heard Ward Cunningham had left Microsoft, but now I've found confirmation.
I first heard the confirmation on Bill's blog, Mini-microsoft on Ward Cunningham. It points to Goodbye Ward, which points to So Long Ward!. It's also on Waynes blog, I couldn't be more excited!, which links to Ward Cunningham Joins the Eclipse Foundation. Also see "Father of Wiki Quits Microsoft; Moves to Open-Source Foundation"
Ward is an influential guy wherever he goes; Microsoft will miss him. He invented wikis, helped invent software patterns start the PLoP conferences, helped make CRC cards popular, started PatternShare, and a lot more. He even has his own Wikipedia page.
Ward has now gone to Eclipse, obviously one of IBM's favorite open source groups and one that seems to be on the move these days. They've also just hired Wayne Beaton.