Alfred Spector, CTO of IBM's Software Group, gave the opening keynote today at WebSphere Technical Exchange. The topic was "IT Evolution: Limitless Horizons."WebSphere Technical Exchange
is running this week in Miami, Florida. (Its European equivalent, WebSphere Technical Conference
, ran two weeks ago.) WTE, one of the IBM WebSphere conferences
, is run by IBM for WebSphere customers, to teach them about the products and how to use them. Alfred Spector
is the chief technology officer of IBM's Software Group
Here's some of what Alfred talked about:
- The world is flat, flattened not by airplanes, but by IT
- Innovation: The intersection of invention and insight, leading to the creation of social and economic value
- Companies need to look for strategic approaches that drive transformational changes in operational performance
- The IT mission is to architect a better world
- SOA builds flexibility on your current investments: A migration from a messaging backbone to enterprise application integration (EAI) to SOA (with an ESB)
- Five aspects to SOA: runtime, information, infrastructure management, development tools, and people. These just so happen to map nicely to the five software brands: respectively: WebSphere, DB2, Tivoli, Rational, and Lotus.
- SOA is an extension of the distributed computing architecture in two dimensions: technology and business
- An event-driven world forces innovation in middleware
- Unparalleled opportunities remain in IT
- The main challenge in our future: Managing complexity
I've recently been reminded of what a great set of conferences the PLoP conferences are. Let me take this opportunity to explain why.
The PLoP conferences
were started by the Hillside Group
, a collection of visionary computer guys. They wanted to take Christopher Alexander's ideas
about patterns and pattern languages and figure out a way to apply them to our jobs of developing computer software. They decided a good way to do it was to start a conference. The focus of the conference would be not to talk about patterns, not to present patterns, but to write them. And the focus would be not to talk about the patterns they'd written, but to help each other improve the patterns they'd written. The focus would be on the writing, and the writing would produce a library of patterns, literature on how to do software development well.
So how does PLoP work? First, you don't submit an abstract of an idea, or a presentation (a la PowerPoint
) of an idea, or a paper that discusses your idea; you submit a paper that is the idea. It's not "This is a paper about what you should do," it's "You should do this!" Second, when you submit a paper, it's neither accepted nor rejected, it's shepherded
. An experienced author helps you improve you paper to make it good enough for the conference. If a submitter is undedicated, uncommitted, or simply lacks the necessary time and effort, this gets rid of him pretty quickly. But for those dedicated to the task, good shepherding can take an idea expressed awkwardly and make the expression (the paper) much better.
Third, the conference itself is run as a set of writer's workshop
s. In these workshops, the participants are all authors who have submitted papers they want feedback on for improvement. Non-authors and non-submitters are generally not welcome; experience as a writer is what you bring to the group; you're committed to the group knowing that your paper will be one of those reviewed. There's a workshop per paper, whose purpose it to review the paper (see "How to Hold a Writer's Workshop
" and a Writer's Workshop Pattern Language
). The paper's author listens silently while the readers discuss what's good about the paper and make suggestions for improvement. As an author, you often wonder what readers are thinking when they read your paper; this workshop lets you know. The focus of the workshop is on helping the author improve his paper.
Notice that so far, I haven't said anything about patterns. Yet the purpose of PLoP is to help with writing patterns
) and pattern languages
. This is the purpose of PLoP. Shepherding and writer's workshops are the method. The focus is on helping interested authors write good patterns papers.
It's a great process, one I must admit that I'd grown accustomed to and bored with over the years. But I've recently become more interested again, as I'll talk about next.
It seems to me that there are two main aspects to doing a good job in a technical role: Technical proficiency and leadership ability. Many of us tend to focus on the first one; we need to focus on the second one as well.
By "leadership," I don't necessarily mean "being in charge," I mean being influential and persuasive. You've probably at some point worked for a manager who was a poor leader but nevertheless was still your boss. Leadership is not a title that can be bestowed upon you by your company or community; it's a quality of how you conduct yourself and work with others. Many development teams have someone who, when he/she speaks up, everyone listens to what they're saying and is inclined to go along because they're usually right; such a person may be "just a programmer" like everyone else, not a project lead or a manager, but they are a leader because they suggest a course of action that the rest of the team tends to follow. That's leadership.
There's a fairly extensive thread on leadership
on Ward's wiki
. For example, see What is leadership?
and Books on leadership
. Another Web site, The Art and Science of Leadership
, looks pretty good.
In my author spotlight
, about half of my recommended reading list
is non-technical books, many of them on leadership and related topics: see Becoming a Technical Leader
, The Fifth Discipline
, and The Servant
. Heck, even The Pragmatic Programmer
has a lot of leadership aspects to its technical advice; so does Extreme Programming Explained
So maybe this sounds great but unrealistic. Maybe you feel like just a lowly programmer on a lowly team; what can you do? Here are some concrete suggestions:
- Be honest and reliable. Do what you say you're going to do.
- Surprises are bad. If things are going wrong, let others know sooner rather than later so that they can help or at least plan accordingly.
- Be good at your job. But don't just do your job, help others do their jobs.
- Don't ignore problems but don't invent them either. Help find real problems, and help find solutions.
- Lead by example. Do what you would have others do.
It's really just that simple. Think about it: Aren't these the kind of people you'd like to work with? Think about someone you do like to work with: I bet they do these things.
Some organizations may not be very supportive of this. For example, when you report problems like you ought to, the organization may avoid addressing the problem and instead shoot the messenger
(which is you). In this case, you have an even more challenging leadership opportunity; as one friend of mine likes to put it, "You can either change your organization, or you can change your organization."
I've talked about application-oriented networking
(AON), billed by some as the future of SOA. Not to be left out, IBM has acquired DataPower, a leading provider of AON appliances.
For the press release, see IBM Acquires DataPower
. This seems to be part of IBM's SOA flurry
. Interestingly, although the DataPower products are hardware, it looks like the company will be integrated into the IBM Software Group
, which develops the Tivoli and WebSphere products the DataPower products work with and which is spearheading the products side of IBM's SOA push (like WPS, WESB, and WID
). (IBM Global Services can help you develop your SOA apps; see How to identify, specify, and realize services for your SOA
and the SOMA link.)DataPower Technology, Inc.
is already an IBM partner:
Here's some commentary on the acquisition:
From IBM's press release
: "According to IDC, IBM has the highest percentage of worldwide portal market share for 2004 ..." IDC
is a top market analyst firm.
For general info about Portal, see What is WebSphere Portal?
Here are some articles on the IDC ranking:
Another WebSphere product I've mentioned but not talked about a lot is WebSphere Portal.WebSphere Portal
(aka WebSphere Portal Server, the original WPS
) is "a framework for integrating your enterprise into a single, customizable interface called a portal." (WebSphere Protal zone
; also see the Portal catalog
A typical portal screen is a Web browser screen composed of multiple panels, implemented as portlets (JSR 168
; "Introduction to JSR 168 - The Portlet Specification
"), each of which is relatively independent, reusable, and may in fact be built from data and services of otherwise independent applications. One panel might show current stock market conditions, another might show your local weather, and another might show your current investment portfolio positions and values. You can do all this without Portal, but Portal makes it much easier. Portal runs on top of WebSphere Application Server
.A company portal
Here's where you can learn more about Portal:
Here's an interesting article in USA Today
: "Techies: They're everywhere
The most interesting part is a graphic, Techie people
, which shows "a county-by-county analysis of 'early adopters' of technology." It shows where in the United States have the highest concentrations of people who are quick to try new technology and gadgets like DVRs
, etc. They're not just in Silicon Valley
, and they're not just wealthy people, just people who choose to spend a lot on tech.
A totally separate trend I hadn't seen before: The states in the western United States are much larger (in geographical area) than those in the east. This is in part because the east was settled first, then over time settlers moved west and divided the land into larger and larger chunks. What I hadn't seen before is that the counties in the western states also have much more area than those in the east. Perhaps states tend to have a similar number of counties, but bigger states have bigger counties. I don't know what that means particularly, but it's interesting. Another example of Graphical Statistics
, which USA Today
is famous for.
I've been talking about serialization (see Serial Version UID and Eclipse 3.1
, Serialization and Serial Version UID
, and even Serialization: Binary or XML?
). I've heard from several people who describe scenarios where they use serialVersionUID just to make serialization work. I'd never heard of needing to do this, but apparently it can happen, at least with older versions of Java.
The key to making serialization work is that the target JVM deserializing the object should have the same class files (which may be in jars) in its classpath as had the source JVM that serialized the object. As long as the same set of classes are used on both ends, serialization works quite well.
Or at least so I thought. Some readers described scenarios where two JDKs computed two different SUIDs for the same class! This isn't supposed to happen, according to spec. Some people described this with using two different versions of Java, like JDK 1.1 and 1.2. Well, if those are incompatible for serialization, I'm not surprised; they are different versions, after all. When the versions were the same, it sounds like the problem was mostly back in the JDK 1.1 and 1.2 days, not recently, so hopefully the latest specs have resolved the problem. (Let me know if you've run into it in J2SE 1.4 or JSE 5.) So two JDKs implementing the same spec and using the same class files should agree on the SUID.
In any event, if you need to use serialization between two JVMs which compute the SUID differently, I see no choice but to set the class' serialVersionUID manually. Probably best to set it to whatever value your favorite JDK calculates. (Eclipse's Java editor has a menu option to do this.)
As I've said, the problem I've encountered is that someone updates the class files on one end and forgets to update the other end. As long as you don't set serialVersionUID manually, the deserializer will catch this error if the two class versions are incompatible (or simply work successfully if they are compatible). If you set serialVersionUID manually, you override this check. Thus if/when you change the class, it's up to you to update the SUID. Again, the Eclipse Java editor is helpful for this, but you've got to remember to run it after you change the class.
So, ideally, compatible JVMs should calculate the same SUIDs for the same class; if not, they're not so compatible. If you run into this problem, you can overcome it by setting serialVersionUID manually, but then you have to remember to update it manually as well. If you're not running into this problem, you shouldn't set serialVersionUID manually; let the JDK(s) handle it.
has introduced a new compiler warning, Serial Version UID
. (The code review tools in RAD 6
have a similar feature.) This new warning seems to be causing lots of confusion and, as far as I can tell, provides little real value and potentially will badly mislead Java novices who don't know any better.
This new feature in Eclipse seems to have begun as Eclipse Bug #69942
, which claims "Serializable classes that do not declare serialVersionUID are a serious problem ..." That's debatable; see Serialization and Serial Version UID
. In any event, Eclipse now has such a warning. But no documentation, mind you, which has lead to a fair bit of confusion and discussion that is not necessarily more clarifying:
A couple of points of clarification seem to be in order. (These are my informed opinions; I happen to think they're well-founded, at least until proven otherwise.):
So if you get the warning and you want to "fix" your class, what should you do?
- Eclipse (3.1) does not somehow require serialVersionUID. The Java IDE is simply warning you about a possible quality problem with your code. Eclipse will work fine even if you don't fix your code.
- Unfortunately (IMHO), when the Eclipse folks introduced this check, they defaulted it to on and provided no explanation as to what the warning meant. So suddenly your old code has all these new warnings, and novices don't know what it means or what to do about it.
- You can turn off the check. Go to: Java > Compiler > Errors/Warnings > Potential programming problems.
- If you don't know what the warning means and don't know what serialVersionUID is, and if you've been happy with your code in the past, you should probably just turn the check off.
You have a couple of options:
- Add this line of code to your class:
private static final long serialVersionUID = 3487495895819393L;
The value can be any valid long integer value.
- Press CTRL-1 in the Java editor and it'll insert a line like that for you.
But should you "fix" your code this way? I think not; again, see Serialization and Serial Version UID
. So my advice: Either ignore the warnings, or since having a bunch of warnings that you're always going to ignore isn't such a good idea either, just turn off the check. You're generally better off letting serialization manage itself.
Here's an oldie but goodie that's reared its ugly head again: Should a Serializable specify its serialVersionUID?
Before you can even weigh the pros and cons, you have to understand the basics of Java serialization. You might as well go to the source, Sun's documentation: Object Serialization
, specifically the Java Object Serialization Specification
Keep this simple definition in mind: If you serialize and deserialize an object, the old and new instances should be equal (though not identical). Equal means that they should be equivalent and indistinguishable; each (non-transient) instance variable in the two instances should contain equivalent values/objects. (See "Equality versus identity (PDF)
," one of the articles I've written
.) BTW, making a class serializable is usually easy, but it can get tricky. For some problems to watch out for and how to handle them, see another article of mine, "Designing For Object Serialization
Some say any serializable class (that you actually plan to serialize and deserialize instances of) should set its serialVersionUID because that'll improve performance. I tend to be very skeptical of dubious programming practices that supposedly have performance benefits (see Problem with Service Locator Pattern
), and this is one; see "Into the mist of serialization myths
The real question is this: If I change a class, will serialized instances of the old version be able to deserialize as instances of the new version?
In general, no. That's because the computed serialVersionUID is based on lots of parts of the class' code (the so-called Stream Unique Identifiers
), so if you change any of the code, the serialVersionUID changes. (This is the value that's recomputed the first time a JVM serializes or deserializes an instance of a particular class, hence the supposed performance hit.) This change in the serialVersionUID is by design, so that the deserializer (an ObjectInputStream
) won't deserialize an object from one version of the class into another version, presuming that because the versions have different code, this means they're incompatible (or at least that's the safest assumption the deserializer can make). If the two versions are indeed compatible, then that's why you would explicitly specify their serialVersionUID, and set it to the same value for both versions of the class.
For example, to explicitly specify a class' serialVersionUID, add a line of code for a new instance variable like this
private static final long serialVersionUID = 3487495895819393L;
The value can be any valid long integer value.
But while people offer lots of opinions about all this, especially when offering this as quickie advice to people who are apparently Java novices, what they fail to discuss is the dangers of explicitly specifying a class' serialVersionUID. The problem isn't when you first set serialVersionUID, but later when you change the class. (And presumably you're going to change the class, or else the serialVersionUID doesn't matter!) In my experience, programmers often set a class' serialVersionUID, then change around the code, but forget to change the serialVersionUID. In this scenario, serialization gets really weird and unreliable (because you made it so!). As long as you serialize and deserialize from the same class version, things work. But if you do so between class versions, the deserializer will try to make it work (because the classes' serialVersionUIDs are the same!), but the new instance may well be messed up because of the changes to the class structure. What do I mean by messed up? Well, at the very least, the two instances aren't equivalent like they're supposed to be (see above).So should programmers specify serialVersionUID in their serializable classes?
I think not. It just leads to trouble. If you really understand what you're doing with serialization, and you're convinced that two class versions are truly compatible for serialization and deserialization purposes even though their code is different, and if you've tested this well to validate your assumptions, then you can use serialVersionUID to override the deserializer's assumptions and specify that the two versions are compatible. But otherwise, the safe move is that whenever you change a class' code, you should change its serialVersionUID value. But since this is how Java works by default anyway, just don't bother with serialVersionUID and let Java take care of things for you.
Three new authors have been added to WebSphere: Author spotlight
: Joey Bernal
, Steph Parkin
, and me
The Author Spotlight highlights people who have published a lot of articles about WebSphere products
. Each author usually has his or her themes, so it's good to find an author whose themes match your interests. For example, Joey writes about Portal, and Steph writes about how to use tooling like RAD 6
The spotlight on an author is useful in two ways. One, it lists in one place all of his/her articles and other publications, so that you can more easily find what all he/she has written. Two, it lists other publications the author finds helpful, which makes a good reading list of other stuff for you to go check out. For example, both Joey and Steph recommend The Soul of a New Machine
, so that sounds like a good book to go check out.
In my recommended reading list, I've listed the books I think any J2EE developer should have on his bookshelf. Need to learn UML? I've listed a book for that. Use cases? A book for that too. Lots of patterns books. And some books on leadership too, because I'm finding that ability to be as important to a project's success as technical ability.
I'll be making two presentations at WebSphere Technical Exchange.WebSphere Technical Exchange
, an Upcoming IBM Conference
, will be held the first week of November in Miami, Florida. As listed in the agenda (PDF)
, I'll be presenting two sessions, both part of the WebSphere Development track:
- D31 J2EE Application Architecture Using Patterns
- D32 Transaction Hardening: WebSphere Transaction Management Architecture, with Gang Chen
So, if you're going to be at the conference, and these talks sounds interesting to you, please attend.
Happy birthday, not to me, but to my blog.I started my blog
one year ago this week. Since then, I've posted over 250 times; hopefully most of the entries have been interesting to at least someone.
At the time, I planned to use this blog to discuss J2EE issues, and in large part I have. Yet, not too surprisingly in retrospect, the blog has also taken more of a WebSphere bent. This evolution occurred for a couple of reasons. For one, a lot of J2EE documentation already exists, especially on Sun's Java web site
. For another, new news on J2EE has been somewhat sparse; the J2EE 1.4 spec
came out nearly two years ago (Nov 2003), and J2EE 5 (JSR 244
) may not be final before the end of the year.
Meanwhile, the organization I work in, IBM Software Services for WebSphere
, has a mission of teaching current and potential WebSphere customers more about WebSphere products
. So I get exposure to a lot of good information about our products, information IBM is trying to communicate to our customers, but without any perfect approach to get the right information to the right people whenever they need it. So this blog has evolved into an opportunity to help with this effort. Thus I've covered customer relationship topics like Working with IBM Support
, new capabilities like WAS 6 high availability
, new features like the Service Integration Bus
, and new products like WebSphere Extended Deployment
. A very early theme has been What You Should Be Reading
, which has now lead to a whole article, "Where can I learn about WebSphere?
So if you keep up with this blog, hopefully it helps you keep up with new products, what's new in the products, and gives you a better understanding of the products and how to use them. Meanwhile, we'll continue to talk about basic technologies like J2EE and JMS, and technology trends like SOA and ESBs. Thanks for joining.