While WAS CE and WAS Base are both J2EE application servers, WAS CE is being positioned as the simpler, more introductory product, primarily for smaller businesses which may not (yet) need the full power of WAS Base and ND. I see it as an easier path for a development team new to J2EE to give it a try. WAS Base is still the better production platform, but because they both support J2EE 1.4, a team can use WAS CE for development and defer the cost of WAS Base licenses until testing and production.

It seems to me that even a WAS CE development team will be more productive if they have a J2EE IDE like RAD 6.0. I assume the Eclipse plug-in for the WAS CE test server works in RAD as well.

The Architecture zone contains resources for software architects, many of which are not necessarily language or product specific. For example, check out the IT Architecture Resource round-up, with advice on how to become an IT Architect and what to do once you are one.[Read More]

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.

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.

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.

For its part, BEA's press release--BEA WebLogic Server(R) 9.0 Continues to Set Performance Records--declares that their app server (WLS) is more efficient, "providing the best hardware utilization in the industry" and "setting a new performance record" which "requires fewer CPUs per JOPS" therefore "reducing total cost of ownership (TCO)." Whereas IBM focuses on total JOPS, BEA focuses on CPUs per 1,000 JOPS. The "Recent SPECjAppServer2004 results" table lists how their product performed in the October 2005 round but (shockingly!) they seem to have forgotten to list the results for WAS.

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!

Dedication to every client's success -- IBM's relationships with its clients are no longer based on product sales, but often on deep, long-term partnerships built around our knowledge of each client's business and the market environment.

Innovation that matters, for our company and for the world -- At their best, IBM's innovations transcend the technology industry, enabling others to innovate as well. We also pursue innovation in education, work/life balance, environmental protection, and all the ways a company organizes and runs itself.

Trust and personal responsibility in all relationships -- The heart of IBM is the personal commitment each IBMer makes to building and preserving trust even if things don't go smoothly with all the constituencies of our business: clients, partners, communities, investors and fellow IBMers.

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 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.)

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 WebSphereclients, 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.

Changing the culture of your company isn't easy. It takes time, effort and a very specific kind of leadership. To learn more about it, we spoke to IBM's Senior Vice President Linda Sanford and General Manager Ross Mauri.

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?[Read More]

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.

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:

So, which to use? Well, the Javadocs for the Session version say that this method is optional and an expert facility that is not used by regular JMS clients. Hmm, that doesn't sound so good. Indeed, if you try to use it in WAS, you get a runtime error:

WSCL0100E: Exception received: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60) at java.lang.reflect.Method.invoke(Method.java:391) at com.ibm.websphere.client.applicationclient.launchClient.createContainerAndLaunchApp(launchClient.java:656) at com.ibm.websphere.client.applicationclient.launchClient.main(launchClient.java:437) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60) at java.lang.reflect.Method.invoke(Method.java:391) at com.ibm.ws.bootstrap.WSLauncher.run(WSLauncher.java:218) at java.lang.Thread.run(Thread.java:568)Caused by: javax.jms.IllegalStateException: CWSIA0045E: The optional JMS operation Session.setMessageListener is not supported by this implementation. at com.ibm.ws.sib.api.jms.impl.JmsSessionImpl.setMessageListener(JmsSessionImpl.java:1011) at Main.main(Main.java:18) ... 14 more

Turns out that Session.setMessageListener is a hook for application servers to use to set up message-driven beans (MDBs). So that's not what we're looking for.

The method in MessageConsumer is a better bet. As advertised, it sets the message consumer's MessageListener.

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.[Read More]

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.

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!).

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 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:

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.

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?[Read More]

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.[Read More]