If you're reading this after December 17th, the cartoon is probably gone. (I would copy the cartoon into this post, but United Feature Syndicate might not like that.)
Also, check out the Dilbert Blog by Scott Adams. (Thanks, Bob.) (NEW)[Read More]
I've added Irving Wladawsky-Berger's blog to my "blogs I read" list.
Irving (Bio, Meet the Experts) is IBM's Vice President of Technical Strategy and Innovation, which makes him one of the company's most senior spokespeople on its technical direction. As he says in About me, "I am responsible for identifying emerging technologies and marketplace developments that are critical to the future of the IT industry, and then organizing activities in and outside IBM in order to capitalize on them." He was a big part of getting the whole "e-business on-demand" thing started. So it's cool to hear what he's thinking about.
I've just discovered that Irving and I are thinking about some of the same things. (Which is really no coincidence. He helps originate ideas that IBM starts disseminating and then I eventually pick up on). For example, we've both been blogging about values (him, me). Some other interesting posts: The Economic and Social Foundations of Collaborative Innovation, The "Outside-In" Enterprise, and On Demand Three Years Later - A Personal Reflection which includes "What is an On Demand business and why should I become one?"
As you can see, Irving talks more about business issues whereas I usually talk about how WAS works (so you can see why he's a vice president and I'm not). All the same, I think these sorts of business issues are important and should be of interest to a J2EE- and WAS-oriented audience like you. So, check it out.
Bill picked up on Irving's blog as soon as it started. Now that I see some of his discussion tying into some of mine, I think you'd be interested, so I've added to my "blogs I read" list. BTW, you can see the list in the right column of my blog page.
I've talked about Sharing a Test Environment Configuration in RAD. Here's another idea to try.
Check out Exporting a server configuration and Importing a server configuration. I believe you can use these steps to copy a config from one machine's server to another.
This approach is probably better than using OS commands to copy the files in the profile directory. Those files may contain machine-specific values, like the machine's IP address. Export and import should filter out those specifics.
wsadmin scripts are probably still the best approach, because ultimately you'll need those for deploying your app in test and production. But the export and import approach is simpler in the short run.
Some patterns don't seem to really be patterns, they just seem to define common
What reminded me of this issue is a post concerning Enterprise Integration Patterns. The author, Mark Carlson, states:
So far, I've found that many of the "patterns" in the book fall into what I would have normally called definitions. Examples of these foundational patterns include Message (66), Message Channel (60), Message Endpoints (95), Point-to-Point Channels (103), Publish-Subscribe Channels (106) and others.
However, I don't want to pick on Mark. Since Gregor and I started working on the book, I've heard several people express that concern. I'm just quoting Mark as an example.
This debate has occurred for years, and I probably won't settle it today, but here's my $0.02 worth.
Not too surprisingly, I contend that these items are patterns, not just definitions. What's the difference? A definition tells you what an item is. A pattern tells you not only what it is, but what to use it for and how. The definition of a Message Channel tells you that it transmits messages from senders to receivers. OK, that's nice to know, but so what? The Message Channel pattern tells you when to use separate channels, so that you start to get some idea of how many you need and why you can't use just one. The definition of a Message tells you that it contains data to be transmitted between a sender and receiver. The Message pattern tells you why you can't simply dump a data structure or a bunch of bytes into a message channel and hope to have it come out the other end properly, how you need to design your messages to have a format that the sender and receiver agree on. As pattern documents, these sets of prose should (and hopefully do) have some Therefore, BOOM! to them, which helps you understand why the problem is difficult to solve and then solves it anyway.
I often feel like one person's pattern is another person's "obvious solution that we use all the time." This discussion comes up a lot at PLoP. The sentiment Mark expressed seems similar; one person's pattern is another person's "definition of the term." It probably seems more like a definition to readers who already know the term, but it's new news to readers who are still learning these terms.
If it's a language or product feature, is it still a pattern? The JMS names for Message Channel and Message are Destination and Message. A Point-to-Point Channel is what JMS calls a Queue, as do most messaging products such as WebSphere MQ. But these are still patterns because you need to know not just that they are features, but when to use those features. Sean Neville addresses this issue when he says, "When a pattern's tactic or implementation strategy is standardized, the pattern does not wane in usefulness, replaced by that standard; instead, quite the opposite occurs." A pattern that is a product feature is a pattern that's much easier to apply!
Patterns are decisions: What should you do and when should you do it? Many definitions do not make good patterns because they don't represent decisions. As discussed, Message is a pattern because you need to decide when to use one and how many. Our pattern document explains that a message is composed of two parts, a header and a body, thereby defining what those terms mean. Header and body are not good patterns because you don't decide when to use them; you get them whenever you decide to use a message. OTOH, a good pattern might be "header field," because sometimes you have to decide whether and how to put a value in the message header. You might need your own custom header fields for a request ID to be used as a Correlation Identifier, or as a flag to be used by a Content-Based Router. Notice that I'm not talking so much about what a header field is--that's a definition; I'm talking about what a header field is used for--that's a pattern.
So don't think of patterns as definitions. A pattern document that just defines a term shouldn't call itself a pattern. Think of them as the fundamental building blocks of a pattern language, the parts we've all got to agree on before we can get to the harder stuff.
BTW, I wonder whatever happened to the webMethods paper Mark was working on? It sounds interesting; I'd like to take a look at it.
There's been some discussion of how to implement a service in J2EE: use a stateless session bean (SLSB), a plain old Java object (POJO), or a combination thereof.
Awhile back, I discussed How to Implement a Service in J2EE. (Where I abbreviated "stateless session bean" as "SSB". And the abbreviation for "stateful session bean" would be ...?! I meant to use the abbreviation SLSB (which is not a SFSB). Duh!) Synchronous clients could invoke the service by calling the method in the SLSB's local or remote interface. Asynchronous clients could use JMS messages; an MDB would receive the request, invoke the method in the SLSB's local interface, then return the result in a reply message. For HTTP clients (such as a Web service), the MDB would be a servlet. I go on to say that the object could be a POJO, but making it a SLSB adds the advantages of being an EJB.
Eugene Kuleshov has discussed this further on his blog on BEA's dev2dev. In Implementing J2EE-based services for a real world, Eugene shows a design whereby the service is implemented as a POJO, which can then be invoked by a SLSB or a MDB. He points out that this is more dependency injection (IoC) friendly. I agree.
My bias is that I use WAS and I don't use enterprise Java w/o EJBs frameworks like Spring (which also supports EJBs for good measure). So my first pass at an implementation is usually to go ahead and put the code in the EJB. Nevertheless, if I see or later discover the need to use code separately without going through an EJB (perhaps because I'm already going through another EJB), I would certainly refactor the code to move the logic into a separate POJO class. Whether that should always be done preemptively, just in case--I rarely (never?) do.
I will say that I believe it's a good practice to pretty much always have an MDB delegate to a SLSB, not directly to a POJO as Eugene shows. This way, synchronous and asynchronous clients will always experience the same QoS, whatever you configure in the SLSB--security, transactions, etc. An MDB or servlet calling the same access point that synchronous clients do--usually a SLSB--is the typical implementation of the Service Activator pattern (EIP, Core J2EE).
So, Eugene makes some good points. His approach and mine are pretty similar, but with a little difference that depends on one's desire to fit into frameworks like Spring. If you're interested in this stuff, check out what Eugene has to say.
Whatever happened to the Gluecode acquisition anyway? Gluecode SE has been reborn as WebSphere Application Server Community Edition (WAS CE).
WAS CE has been announced (press release) and is now available. You can read about the features and benefits, and also the system requirements (details); the supported platforms are Linux and Windows. You can also keep up with the recommended updates. And of course there's a WAS CE Infocenter and support docs. The download includes an Eclipse 3.1 plug-in "that enables you to use [WAS CE] as a test environment while you develop J2EE assets."
WebSphere Application Server Community Edition zone is the new developerWorks product zone for WAS CE, under the WebSphere zone. Some of the interesting articles in the new zone:
Like Gluecode SE, WAS CE is built on Apache Geronimo, specifically the M5 build, the first Geronimo J2EE 1.4 certified release. Unlike Geronimo, WAS CE runs on IBM's JRE and includes the Cloudscape embedded database. For more info, see:
For commentary on IBM's WAS CE announcement, see:
2005/11/26 Update: Check out Michael O'Connell's posting on WAS CE.
IBM developerWorks, home to some of the best blogs around, has a new zone: the developerWorks Architecture zone.
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.
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.
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:
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: