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.
Bobby Woolf: WebSphere SOA and JEE in Practice
From archive: November 2005 X
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:
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)
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.
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?
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!"
The new developerWorks Architecture Zone features a column, "Insight and outlook."
The Insight and outlook column is where "IBM technical leaders answer pressing questions about IT architecture." The topic of the first column: Why should you care about SOA, and when is it the right choice and when is it the wrong choice?
The question is answered by eleven of IBM's leading thinkers, including two IBM Fellows, Grady Booch and Don Ferguson. The other contributors are leaders in IBM's efforts to help customers with SOA. In there somewhere is even a contribution by me, "The good, the bad, and when to be careful." (Scroll down to the bottom of the article!)
I'm amused that I'm the only contributor that talks about technical details like service orientation and distributed objects, interfaces and security. Most of the others talk about aligning IT with business objectives, open standards, how SOA is not just Web services (JaBoWS), and an emerging favorite whipping boy--service governance. Guess I still think like a programmer; I work with the people who are having difficulty making it all work. Perhaps that's why I'm the only contributor who talked about not only when to use SOA, but when not too.
Anyway, I hope the column will help to give you a better idea of what this SOA stuff is all about. Enjoy.
BTW, we'd like feedback on the column: What you think of the question itself, of the various answers in general, and of my answer specifically. If you have some thoughts, positive or critical (but constructive), please add a comment here or shoot me an e-mail. Thanks.
There's a new service called the Amazon Mechanical Turk. It lets you submit tasks to be performed by Amazon users.
Phil Wainewright describes the service in Fine-grained tail of the Mechanical Turk and Wetware as a service. Whereas Web services, and services in general, are supposed to be coarse-grained, Phil describes this as a rare example of fine-grained Web services. Apparently because the tasks often only take a few seconds to perform. I don't really get where that conclution comes from, but the Turk sounds interesting nevertheless.
I'm tempted to say that the Turk is just workflow. You decide on work categories or task types, then create a worklist for each. Then someone with a task to be performed adds it as a work item to the proper worklist. Someone wishing to perform a task selects an appropriate worklist, then acquires a work item from the worklist and performs it.
But can this be done as Web services? You'd need one for browsing and selecting a worklist, one for adding a work item, one for acquiring a work item, and one for receiving notification that your work item has been completed. Perhaps this is what the Turk does.
I'm not clear on why Amazon users are supposed to want to perform these tasks for free, but what the heck.
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.
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.
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?
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.
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.
IBM has gotten podcast religion.
developerWorks has a neat series on WebSphere, SOA, etc.: WebSphere Technical Podcast series
IBM has a general series on where it thinks the world is going: IBM and the Future of ...
Finally, the IBM System Storage and TotalStorage department has a podcast too: IBM TotalStorage Podcast
Check the various pages for links on how to subscribe, get subscription software, etc.
There's lots of talk about the new Xbox 360 game console. What's not as well known is that the new Xbox, like the original, is powered by a CPU from IBM.
A lot of the industry commentary is on how Microsoft is selling the Xbox at a loss. However, they later discuss how the IBM chip set is key to the Xbox, and to the PlayStation 3 and Nintendo Revolution as well. And why is Microsoft willing to sell Xboxes at a loss? It's more than just marketshare; it's a desire to make the Xbox the digital entertainment console at the center of your livingroom; see "Microsoft's Xbox 360 does a lot more than just play games"
Do you want to know more?
Also, here's an article and whitepaper on the hardware chip set partnerships like this that IBM offers: "Understanding BPTS: Engineering & Technology Services - A new model for creating value in a commoditizing world"