IBM Inner Circle

Thoughtsand perspectives on the 2002 IBM Inner Circleconference

11.05.2002

General atmosphere

I attended the IBM WebSphere Inner Circle 2002 conference in SanFrancisco May 5-9th. This ran roughly parallel to the developerWorksLive! conference, so I was unable to get to any of dW. This paper isintended as an overview of areas that are relevant to our currentdevelopment and short-term future goals (6-12 months). IBM brought outa tremendous number of managers, architects, and engineers as well as asizable contingent of support staff to speak and answer questions. Theywere completely accessible and willing to listen, and IBM officiallyencouraged the attendees to complain, ask questions, and criticize. Thefocus was of course IBM-centric, and Jason Restad (USDA, Ft. Collins)noted that he'd like to see a Copernican shift in which IBM realizedthat the sun was our business, not them. I was able to sit near the IBMengineers during the 5.0 preview session, and noticed that when peoplewere asking questions (particularly difficult ones or ones that IBM didnot have good answers for) the engineers were whispering things to eachother like "We need to fix that" or "good point". The focus was about75% on the WebSphere 4.x lineup and 25% on the upcoming 5.0 line. Iwill focus on three primary areas and what emerged from the conferencethat is relevant to our project: Linux, Versions, and Tools.

WAS on Linux

John Swainson (VP Software Development) spoke in his keynote about theimportance of open standards and open source, and briefly mentionedtheir commitment to Linux. I spoke with several people during breakswho were interested in linux but hadn't really done anything with ityet. The attendees were IBM's largest enterprise clients, and Swainsonnoted that while these were the people IBM came to for guidance onwhere they should be heading they were also generally the slowest toadopt new technologies on a large scale. One of the IBM developers satwith Brenda and I on Monday night. He was very pro linux andrecommended developing on Win2k, deploying on linux, noting that hisgroup actually does most of their development work on Linux. BrentPeters (Manager of WAS Development) noted that all their performancebenchmarks are done on linux and I spoke with him about the fact thatno one at the conference was using linux in production. There areactually quite a few people doing development on linux, but thepreferred platform for production tends to be AS400 or Solaris at thispoint. He did opine that there will be steady growth of productioninstalls of linux in the next year, especially as more sites adopt WAS4. The speaker after him was also very vocal in support, and said thathis group does a lot on linux as well. There was a strong groundswellof support for adding a linux BOF session, but it lost out to adding a3.x to 4.0 migration session. In speaking with attendees, many of themwere interested in or were already working on proof of concept projectsusing linux and those who were in process had nothing but good thingsto say about it. Note that these tended to be people currently onSolaris/AIX rather than Windows so they were already used to Unix stylesystem administration in terms of installing and initial setup. Most ofthe IBMers I talked with were Distinguished Engineer level and all ofthem were bullish on using linux both on the server and the developmentworkstation. There were no sessions specifically on linux (the onlyplatform that got a special session was zOS), but several sessions didhave mentions of it in the QA section.

&

Versions and Migration

WAS 3.x is a fragmented codebase poorly integrated. That is not anexact quote, nor a tacit admission, but it is the essential meaning ofthe references to 3.x at the conference. There are a lot of knownproblems in the 3 line, and IBM made no attempt to minimize thoseissues. Their advice is to move to 4.x. Adoption of 4 has been slowerthan anticipated and as a result End Of Life for 3 has been extendedpast the end of CY2002. The mixed codebase makes it very difficult toget 3.x to work well, though many customers have gone through the painnecessary to do so. During the opening session, there wererepresentatives from some 150 top IBM customers. When asked how manywere on 4, perhaps two dozen raised their hands. When asked how manyhad 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 morecommon codebase (zOS is still outside) and features better management,J2EE compliance, more standards support. One glitch that isparticularly relevant to our situation is that struts are notofficially supported in any version up to and including 4.0.2. It maybe supported in 4.x or it may wait until 5. This is not to say thatstruts 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 indeployment process. The JAR/WAR/EAR structure is officially part ofJ2EE and now the development lead will package the application into anEAR and hand off to the admin team for deployment. 4 also features asimplified 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 forboth tools and servers. The idea is that someone should be able todevelop an application on any platform and later migrate it to anyother 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 itcould be argued that the Win versions are nothing spectacular either),whereas that admin tools are not noticeably different. In the newdichotomy, the Websphere Studio Application Developer will have acommon base across all platforms (it is based on the Eclipse opensource IDE framework). The changes in admin tools will be common aswell.

5.0 is the "destination" release, with a completely common codebase andfull standards support. There will be a single integrated ApplicationDevelopment programming model and set of tools, consistent view ofapplication functionality across platforms, and the return of theexpress edition. 5 will be J2EE 1.3 compliant (the speaker noted thatsome of their competitors have claimed to be compliant with variousversions of J2EE and then later been removed from the Java site when itturned out that they weren't). 5 is currently available under theTechnology for Developers plan and IBM wants to get it into the handsof as many developers as possible in order to ensure that when it isofficially released the developers will be happy. The feature set of 5is extremely large and there are many improvements over the 4 lineincluding better error messages, XML admin repository, further improvedobject model, better problem determination tools, better performancetuning tools, better failover, and of course the requisite change innames for things for no readily apparent reason. This all of coursebrought about the question "Should we bother going to 4?"

Migrating from 3.x to 4 is non-trivial in many cases. There are only 9steps, assuming that all goes well, and you have the option of doing anautomated migration. The auto migration is contraindicated. Of thesteps, only one has real potential pitfalls: "Repackage yourapplication". Certainly migrating security, converting clones, andmigrating the administration configuration database could conceivablygo horribly wrong, but in comparison to repackaging an application theyare not as serious. When repackaging the application, it is highlyrecommended that you go in and make sure all your code is compliantwith the new standards supported in 4. For example, if you are codingto a prior EJB spec, you will need to do some rewrites. If you areusing 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 dois use a tool of sorts to verify code compliance (in particular, removedeprecated code as it is strongly frowned upon in J2EE), such asXMLConvert, MigrateWC, and a java codesweeper that IBM plans to makeavailable Real Soon Now(tm). This was the longest session of theconference, and it was well attended. Migrating from 4 to 5 will beslightly different. If you have a fully J2EE compliant application in4, it will run just fine in 5 without having to do anything. It wouldstill be advisable to refactor your code to meet the 1.3 standards, butit will not be required. Obviously, migration from 4 to 5 is notexpected to be an issue at all. The support team has been testingdifferent migration scenarios and said that if you really really wantto wait and just go from 3.x to 5, you can do that. They recommendhaving a full team that works only on the migration and a really goodsupport contract.

Tools

Visual Age is dead, long live Visual Age. Websphere Studio is the newline, built from scratch and based on the Eclipse.org framework.Eclipse is an open source project created by IBM and donated to theopen source community. "The Eclipse Platform is an open extensible IDEfor anything and yet nothing in particular. The Eclipse Platformprovides building blocks and a foundation for constructing and runningintegrated software-development tools. The Eclipse Platform allows toolbuilders to independently develop tools that integrate with otherpeople's tools so seamlessly you can't tell where one tool ends andanother starts." (from the Eclipse.org website). IBM is of course thefirst vendor to release a toolset based on eclipse. There are fourproducts in the WS line: Site Developer (integrated Java/JSP/XML/WebServices coding support, integrated J2EE test environ, UDDI tools,Rational ClearCase lite, deployment automation tools, web and richmedia tools, "we fixed all the problems with VAJ"), ApplicationDeveloper (as above plus: EJB, advanced code generation, performancetuning, web services wizards, generating integrationadapters/workflows), Enterprise Developer (as above plus: advanced EAItools, remote edit/compile/debug for host COBOL/PL1 assets, VisualApplication Structure, 4GL RAD), Device Developer (targeted at J2ME,remote device test and debug). Enterprise edition is coming Real SoonNow (tm). The difference between 4.x and 5.x developer tools will beaccretive and will not involve UI changes. You can use 5.x to developfor 4.x servers (eBay is doing so now in production).

One of the prime features of the studio line is the ability to writethird party plugins. Currently Rational is developing a plugin forClearCase integration (Studio ships with a lite version) and theireXtended Development Environment modeling tools are already available.Instantiations provides refactoring and migration tools, Parasoft has aJTest plugin, Merant has a PCVS plugin, and Serena has a ChangeMan one.According to IBM, all SCM companies are working on plugins forintegrating their tools with Studio. There have also been pluginswritten for JBoss, Tomcat and WebLogic. Studio by default providessupport for their own repository and CVS as well as an IBM C/C++plugin. Some other interesting plugins available from the open sourcecommunity include source code formatters, Ruby language support,database managers, ANT integration tools, decompilers, Perforcesupport, ObjectWeb support, Tapestry integration, defect tracking,tutorials, ALDL diagnostics, code auditors, medical informationsystems, and Visual Composition Editors. The freedom to use whateverSCM tools you want combined with the ability to integrate whateverother tools you need makes Studio a very compelling developmentplatform. It is interesting to note that IBM encourages anyone writingplugins to target eclipse if at all possible rather than Studio (theidea being that if it works in eclipse it will work in studio, but ifyou 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 WebsphereApplication Server 4.0 in a timely and organized fashion. I will bereceiving some unreleased tools (notably the API Checker) that willassist us in migration, and Mike Blecha and I expect to have the proofof concept ready early the week of the 13th (assuming he is not inDallas). I would recommend that developers spend some timefamiliarizing themselves with the Websphere Studio ApplicationDeveloper toolkit as time allows in order to reduce the learning curveonce we actually start the migration. There has been some discussion ofusing struts, but as noted it is not supported in 3.x or 4.x. Once thedecision is made to move to 5.0 (due for release 3Q2002) we couldconsider 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 ProcessIntegration
New Research
Heuristics and Predicting Web Behavior
Advanced Edition Highlights, Core, andMigration from 3.x
Failover
3.x to 4.x Migration
Self Tuning and Self Healing
Optimizing for Performance
Special Session: Migrating from 3.x to4.0 panel (as a panelist)

Disclaimer:The foregoing has been prepared solely for informationalpurposes. It does not purport to be a complete description of thesoftware, conference, or developments referred to in the material. Allexpressions of opinion are subject to change without notice. Theinformation is obtained from internal sources and external sourcesgenerally considered reliable but I have not independently verifiedsuch information and we do not guarantee that it is accurate orcomplete.