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)
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.
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?
Some patterns don't seem to really be patterns, they just seem to define common
terms. So are they really patterns?
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
. 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.
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.
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.
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.
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 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:
- 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 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:
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.
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
). 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.
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!
For more commentary, see:
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.
, 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.
There's a rumor that Google
is considering opening an office in Research Triangle Park
, to tap into the local engineering talent.
Sam Ruby has linked to
a Marketing Pilgrim posting
, with commentary that links to the root Southeast VC posting
(also picked up by Triangle Tech Journal
It looks like Google has U.S. engineering offices
in Mountain View (headquarters), New York, Kirkland WA, Santa Monica, and Phoenix. RTP would be a nice addition.NEW:
Apparently Google is in fact looking for real estate in RTP. From the News and Observer
, Raleigh's local newspaper: "Google looks for local offices
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
) and is now available
. You can read about the features and benefits
, and also the system requirements
); 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
|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.
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.
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:
- More interesting -- If readers are going to have to read through dozens of patterns, if you can make the writing a little more entertaining and a little less dry, the easier it will be for those readers.
- More memorable -- The "BOOM!" quality provokes an emotional response in the reader that makes the pattern reading experience much more significant than it would be at a purely intellectual level. The reader will internalize your pattern better and remember it more easily.
"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!"