IBM Inner Circle

version: 1.0
date: 2001-11-05 16:12:52

Thoughts and perspectives on the 2002 IBM Inner Circle conference

11.05.2002

General atmosphere

I attended the IBM WebSphere Inner Circle 2002 conference in San Francisco May 5-9th. This ran roughly parallel to the developerWorks Live! conference, so I was unable to get to any of dW. This paper is intended as an overview of areas that are relevant to our current development and short-term future goals (6-12 months). IBM brought out a tremendous number of managers, architects, and engineers as well as a sizable contingent of support staff to speak and answer questions. They were completely accessible and willing to listen, and IBM officially encouraged the attendees to complain, ask questions, and criticize. The focus was of course IBM-centric, and Jason Restad (USDA, Ft. Collins) noted that he'd like to see a Copernican shift in which IBM realized that the sun was our business, not them. I was able to sit near the IBM engineers during the 5.0 preview session, and noticed that when people were asking questions (particularly difficult ones or ones that IBM did not have good answers for) the engineers were whispering things to each other like "We need to fix that" or "good point". The focus was about 75% on the WebSphere 4.x lineup and 25% on the upcoming 5.0 line. I will focus on three primary areas and what emerged from the conference that is relevant to our project: Linux, Versions, and Tools.

WAS on Linux

John Swainson (VP Software Development) spoke in his keynote about the importance of open standards and open source, and briefly mentioned their commitment to Linux. I spoke with several people during breaks who were interested in linux but hadn't really done anything with it yet. The attendees were IBM's largest enterprise clients, and Swainson noted that while these were the people IBM came to for guidance on where they should be heading they were also generally the slowest to adopt new technologies on a large scale. One of the IBM developers sat with Brenda and I on Monday night. He was very pro linux and recommended developing on Win2k, deploying on linux, noting that his group actually does most of their development work on Linux. Brent Peters (Manager of WAS Development) noted that all their performance benchmarks are done on linux and I spoke with him about the fact that no one at the conference was using linux in production. There are actually quite a few people doing development on linux, but the preferred platform for production tends to be AS400 or Solaris at this point. He did opine that there will be steady growth of production installs of linux in the next year, especially as more sites adopt WAS 4. The speaker after him was also very vocal in support, and said that his group does a lot on linux as well. There was a strong groundswell of support for adding a linux BOF session, but it lost out to adding a 3.x to 4.0 migration session. In speaking with attendees, many of them were interested in or were already working on proof of concept projects using linux and those who were in process had nothing but good things to say about it. Note that these tended to be people currently on Solaris/AIX rather than Windows so they were already used to Unix style system administration in terms of installing and initial setup. Most of the IBMers I talked with were Distinguished Engineer level and all of them were bullish on using linux both on the server and the development workstation. There were no sessions specifically on linux (the only platform that got a special session was zOS), but several sessions did have mentions of it in the Q&A section.

Versions and Migration

WAS 3.x is a fragmented codebase poorly integrated. That is not an exact quote, nor a tacit admission, but it is the essential meaning of the references to 3.x at the conference. There are a lot of known problems in the 3 line, and IBM made no attempt to minimize those issues. Their advice is to move to 4.x. Adoption of 4 has been slower than anticipated and as a result End Of Life for 3 has been extended past the end of CY2002. The mixed codebase makes it very difficult to get 3.x to work well, though many customers have gone through the pain necessary to do so. During the opening session, there were representatives from some 150 top IBM customers. When asked how many were on 4, perhaps two dozen raised their hands. When asked how many had migrated from 3.x, only a handful of hands remained in the air. This is why the special session on migration was created. 4 has a more common codebase (zOS is still outside) and features better management, J2EE compliance, more standards support. One glitch that is particularly relevant to our situation is that struts are not officially supported in any version up to and including 4.0.2. It may be supported in 4.x or it may wait until 5. This is not to say that struts won't work, only that IBM won't help you with it if it doesn't. 4 conforms to the J2EE spec fully, which will mean a change in deployment process. The JAR/WAR/EAR structure is officially part of J2EE and now the development lead will package the application into an EAR and hand off to the admin team for deployment. 4 also features a simplified object model, and replaces OSE with HTTP Transport.

One of the big focuses of the move to 4.x/5.x is common code base for both tools and servers. The idea is that someone should be able to develop an application on any platform and later migrate it to any other platform and not have to change anything or learn any new tools. The developer tools on linux in 3.x are less than stellar (though it could be argued that the Win versions are nothing spectacular either), whereas that admin tools are not noticeably different. In the new dichotomy, the Websphere Studio Application Developer will have a common base across all platforms (it is based on the Eclipse open source IDE framework). The changes in admin tools will be common as well.

5.0 is the "destination" release, with a completely common codebase and full standards support. There will be a single integrated Application Development programming model and set of tools, consistent view of application functionality across platforms, and the return of the express edition. 5 will be J2EE 1.3 compliant (the speaker noted that some of their competitors have claimed to be compliant with various versions of J2EE and then later been removed from the Java site when it turned out that they weren't). 5 is currently available under the Technology for Developers plan and IBM wants to get it into the hands of as many developers as possible in order to ensure that when it is officially released the developers will be happy. The feature set of 5 is extremely large and there are many improvements over the 4 line including better error messages, XML admin repository, further improved object model, better problem determination tools, better performance tuning tools, better failover, and of course the requisite change in names for things for no readily apparent reason. This all of course brought about the question "Should we bother going to 4?"

Migrating from 3.x to 4 is non-trivial in many cases. There are only 9 steps, assuming that all goes well, and you have the option of doing an automated migration. The auto migration is contraindicated. Of the steps, only one has real potential pitfalls: "Repackage your application". Certainly migrating security, converting clones, and migrating the administration configuration database could conceivably go horribly wrong, but in comparison to repackaging an application they are not as serious. When repackaging the application, it is highly recommended that you go in and make sure all your code is compliant with the new standards supported in 4. For example, if you are coding to a prior EJB spec, you will need to do some rewrites. If you are using JSP 0.91, you will have to recode. Session scope changes as well, so that could end up being very ugly indeed. Obviously, the thing to do is use a tool of sorts to verify code compliance (in particular, remove deprecated code as it is strongly frowned upon in J2EE), such as XMLConvert, MigrateWC, and a java codesweeper that IBM plans to make available Real Soon Now(tm). This was the longest session of the conference, and it was well attended. Migrating from 4 to 5 will be slightly different. If you have a fully J2EE compliant application in 4, it will run just fine in 5 without having to do anything. It would still be advisable to refactor your code to meet the 1.3 standards, but it will not be required. Obviously, migration from 4 to 5 is not expected to be an issue at all. The support team has been testing different migration scenarios and said that if you really really want to wait and just go from 3.x to 5, you can do that. They recommend having a full team that works only on the migration and a really good support contract.

Tools

Visual Age is dead, long live Visual Age. Websphere Studio is the new line, built from scratch and based on the Eclipse.org framework. Eclipse is an open source project created by IBM and donated to the open source community. "The Eclipse Platform is an open extensible IDE for anything and yet nothing in particular. The Eclipse Platform provides building blocks and a foundation for constructing and running integrated software-development tools. The Eclipse Platform allows tool builders to independently develop tools that integrate with other people's tools so seamlessly you can't tell where one tool ends and another starts." (from the Eclipse.org website). IBM is of course the first vendor to release a toolset based on eclipse. There are four products in the WS line: Site Developer (integrated Java/JSP/XML/Web Services coding support, integrated J2EE test environ, UDDI tools, Rational ClearCase lite, deployment automation tools, web and rich media tools, "we fixed all the problems with VAJ"), Application Developer (as above plus: EJB, advanced code generation, performance tuning, web services wizards, generating integration adapters/workflows), Enterprise Developer (as above plus: advanced EAI tools, remote edit/compile/debug for host COBOL/PL1 assets, Visual Application Structure, 4GL RAD), Device Developer (targeted at J2ME, remote device test and debug). Enterprise edition is coming Real Soon Now (tm). The difference between 4.x and 5.x developer tools will be accretive and will not involve UI changes. You can use 5.x to develop for 4.x servers (eBay is doing so now in production).

One of the prime features of the studio line is the ability to write third party plugins. Currently Rational is developing a plugin for ClearCase integration (Studio ships with a lite version) and their eXtended Development Environment modeling tools are already available. Instantiations provides refactoring and migration tools, Parasoft has a JTest plugin, Merant has a PCVS plugin, and Serena has a ChangeMan one. According to IBM, all SCM companies are working on plugins for integrating their tools with Studio. There have also been plugins written for JBoss, Tomcat and WebLogic. Studio by default provides support for their own repository and CVS as well as an IBM C/C++ plugin. Some other interesting plugins available from the open source community include source code formatters, Ruby language support, database managers, ANT integration tools, decompilers, Perforce support, ObjectWeb support, Tapestry integration, defect tracking, tutorials, ALDL diagnostics, code auditors, medical information systems, and Visual Composition Editors. The freedom to use whatever SCM tools you want combined with the ability to integrate whatever other tools you need makes Studio a very compelling development platform. It is interesting to note that IBM encourages anyone writing plugins to target eclipse if at all possible rather than Studio (the idea being that if it works in eclipse it will work in studio, but if you target studio it may use things not available in eclipse).

Resources:

Eclipse Plugins
Eclipse Workbench
Sourceforge
Websphere Studio
Linux Devices
Eclipse

Going forward

Based on my conversations with dozens of customers and IBM engineers, it is my opinion that we would to well to migrate to Websphere Application Server 4.0 in a timely and organized fashion. I will be receiving some unreleased tools (notably the API Checker) that will assist us in migration, and Mike Blecha and I expect to have the proof of concept ready early the week of the 13th (assuming he is not in Dallas). I would recommend that developers spend some time familiarizing themselves with the Websphere Studio Application Developer toolkit as time allows in order to reduce the learning curve once we actually start the migration. There has been some discussion of using struts, but as noted it is not supported in 3.x or 4.x. Once the decision is made to move to 5.0 (due for release 3Q2002) we could consider conversion at that point.

Sessions attended:

WebSphere Foundation
Business Integration Direction
Building an Effective Website
Eclipse and WebSphere Studio Tooling
Advanced Edition 4.0 Insider
Advanced Edition 5.0 Preview
Information Connectivity and Process Integration
New Research
Heuristics and Predicting Web Behavior
Advanced Edition Highlights, Core, and Migration from 3.x
Failover
3.x to 4.x Migration
Self Tuning and Self Healing
Optimizing for Performance
Special Session: Migrating from 3.x to 4.0 panel (as a panelist)

Disclaimer:The foregoing has been prepared solely for informational purposes. It does not purport to be a complete description of the software, conference, or developments referred to in the material. All expressions of opinion are subject to change without notice. The information is obtained from internal sources and external sources generally considered reliable but I have not independently verified such information and we do not guarantee that it is accurate or complete.