websphere studio overview - pdfs.semanticscholar.org · websphere application server and its...

WebSphere Studiooverview

by F. BudinskyG. DeCandioR. EarleT. FrancisJ. JonesJ. Li

M. NallyC. NelinV. PopescuS. RichA. RymanT. Wilson

In this paper we provide an overview of IBMWebSphere Studio, a family of tools fordeveloping distributed applications for J2EE™servers for state-of-the-art informationtechnology systems. In today’s businessenvironment such systems are complex,comprise multiple platforms, and make use ofa wide range of technologies and standards.Through a representative developmentscenario we illustrate the way WebSphereStudio satisfies the challenging requirementsfor a modern integrated developmentenvironment. The scenario covers a variety oftechnologies and standards, includingdatabase access, Web services standards,Enterprise JavaBeans™ implementation,integrated application testing, Web pagedesign, and performance optimization. Wealso describe the Eclipse ModelingFramework, the open source technology baseon which WebSphere Studio is built.

Modern n-tiered applications integrate function thatis developed by using many different technologies.J2EE** technologies,1 such as JavaServer Pages**(JSP**), servlets, Java** Database Connectivity(JDBC**) database access, and Enterprise Java-Beans** (EJBs**), are used to develop distributedapplications that also use eXtensible Markup Lan-guage (XML)2 for a technology-neutral representa-tion of data, as well as Web services3 for integratingvarious applications and platforms.

Application development tools are increasingly re-quired to integrate with an overall application so-

lution that includes tools and runtime environments.Such integration leads to synergy between tools andruntime environments and enhances developers�productivity. Not surprisingly, integrating a rich setof tools within a single user interface is a significantchallenge.

To meet this challenge, major software tool vendorsrely on a category of software known as an integrateddevelopment environment, or IDE. IBM�s entry in thisfield is IBM WebSphere Studio,4 a family of tools fordeveloping applications for the IBM WebSphere Ap-plication Server5 (the IBM middleware platform) andother J2EE servers, Web servers, and database serv-ers. WebSphere* Studio tools run on an open-sourceextensible base, the Eclipse platform.6 The tools areavailable on multiple operating-system platforms, aretranslated into many languages for worldwide dis-tribution, and are accessible by persons with phys-ical disabilities.

Integrated development environments. In order tosupport the development of sophisticated n-tieredapplications in today�s highly competitive applica-tion development tools market, IDEs must addressa challenging set of requirements, including thefollowing.

Productivity: Developers must be able to rapidly buildand test applications. Repetitive processes should be

�Copyright 2004 by International Business Machines Corpora-tion. Copying in printed form for private use is permitted with-out payment of royalty provided that (1) each reproduction is donewithout alteration and (2) the Journal reference and IBM copy-right notice are included on the first page. The title and abstract,but no other portions, of this paper may be copied or distributedroyalty free without further permission by computer-based andother information-service systems. Permission to republish anyother portion of this paper must be obtained from the Editor.

BUDINSKY ET AL. 0018-8670/04/$5.00 © 2004 IBM IBM SYSTEMS JOURNAL, VOL 43, NO 2, 2004384

simplified. (Other requirements such as integrationand reuse contribute toward the main goal of en-hancing productivity.)

Integration: The tools must work together to createa seamless development workflow that encompassesdesign, implementation, testing, analysis, and Webdevelopment. They must be able to cope with mul-tiple programming languages and heterogeneousruntime environments.

Flexible, user-friendly interface: The user interface (UI)must be able to mask the full complexity of the IDE,providing novice users with simple access to the corefunctionality. At the same time, the UI must also sup-port the full range of functionality for expert users.

Shared development model: The tools should be ableto share the same development model (sharing de-velopment artifacts and an integrated workflow) andshould be able to use a different model when it wouldlead to greater productivity. The development modelshould support bottom-up or top-down applicationdevelopment as needed.

Reuse: The IDE should provide the ability to reusecomplex application artifacts and Web resources(this boosts productivity, increases runtime perfor-mance, and reduces storage requirements).

Scalability: The tools must support the developmentof applications that operate within a wide range ofenvironments. Specifically, for building large-scaleJ2EE applications, the tools must handle large num-bers of application objects and the associatedfunctionality.

Extensibility: The IDE must allow the incorporationof new function and components in a natural way,including tools that are custom-built to fulfill spe-cific user requirements.

Testing: Given today�s complex runtime environ-ments, developers must be able to exercise their codewithout having to publish it, and to test their codeon remote servers.

The major IDE products are Microsoft Corporation�sVisual Studio** .NET, BEA WebLogic** Workshop,Borland Software Corporation�s JBuilder**, Sun Mi-crosystems, Inc.�s ONE Studio, and Oracle Corpo-ration�s JDeveloper.

Microsoft Visual Studio .NET is focused entirely ondeveloping applications for the Microsoft .NET plat-

form. Microsoft uses its own tools platform for de-velopment of Visual Studio .NET and has been suc-cessful in attracting third-party software developersto this platform to enhance and extend the Microsofttools.7

BEA WebLogic Workshop is a development environ-ment for J2EE applications that run on its BEA Web-Logic server and is part of BEA WebLogic Platform8.1. WebLogic Workshop is notable in that it has at-tempted to reduce the skill requirements for J2EEdevelopment by translating features found in VisualStudio. NET, such as application logic controls andsource code annotations, into the world of Java.(Many of these features are proprietary.)8

Borland JBuilder is a popular IDE for Java and J2EEprogramming. JBuilder is not aligned with a partic-ular middleware platform and offers support for sev-eral, including the market leaders, IBM and BEA. Be-cause of this breadth of support, it does not coverthe IBM middleware platform to the same depth orlevel of integration as WebSphere Studio. The prod-uct is implemented on a proprietary tools platformthat includes support for third-party extensions.9

Sun ONE Studio is an IDE for Java and J2EE program-ming, focused primarily on support for the Sun ONEApplication Server.10 Sun ONE Studio is imple-mented on top of an the open-source tools platformNetBeans**,11 which is offered as an alternative tothe Eclipse open-source tools platform.

Oracle JDeveloper, another IDE for Java and J2EEdevelopment, is focused on development for the Or-acle Application Server, but supports other platformsas well. It is built on a proprietary Oracle tools plat-form (older versions were built on a tools platformlicensed from Borland).12

IBM has competed in the IDE marketplace with theVisualAge* family of products since the early 1990s.Since then the application development environmenthas become increasingly complex. IBM WebSphereStudio emphasizes breadth and depth in its supportfor the IBM middleware platform, while also provid-ing support for competitive and open-source J2EEservers.

WebSphere Studio approach to IDE requirements.The IBM middleware platform is a rich software envi-ronment for the deployment and execution of n-tierapplications, based on J2EE with significant IBM ex-tensions. Because of the richness of this platform,

IBM SYSTEMS JOURNAL, VOL 43, NO 2, 2004 BUDINSKY ET AL. 385

it requires a large and complex programming model.Middleware can be defined as the layer of enablingsoftware that mediates between applications that ei-ther run on different platforms, or come from dif-ferent vendors, or both. Generally, middleware me-diates between applications and an operating system.IBM�s middleware for Web applications includes theWebSphere Application Server and its extensions,WebSphere MQ messaging products, DB2* and as-sociated database products, Lotus Domino*, andTivoli* application management products. For thepurposes of this article, the programming model in-cludes the programming concepts, application pro-gramming interfaces, and file formats used for thedevelopment, deployment, and field support of ap-plications running on this platform.

WebSphere Studio represents the result of a mul-tiyear effort by IBM to reinvent its application de-velopment tools portfolio in order to address the re-quirements of its middleware platform. In the late1990s, it became clear that the current extensive toolsportfolio was too fragmented for modern n-tieredapplications (which involve a range of diverse tech-nologies). An ambitious project was started to simul-taneously develop a new platform for integratingtools (later named Eclipse) and a new generation ofIBM application development tools, implemented ontop of that platform. The result of that effort is theWebSphere Studio family of products and theEclipse workbench.

There are two main approaches to the design of ap-plication development tools: the direct-to-middlewareapproach and the model-driven approach. In the di-rect-to-middleware approach, the concepts of the un-derlying middleware execution platform are exposedto the application developer. IDE tools use themiddleware APIs and create files in the formats re-quired by the middleware. The direct-to-middlewaretools operate almost exclusively on the file formatsof artifacts defined by the middleware programmingmodel. They give the application developer full ac-cess to the features of the underlying middlewareprogramming model. Well-designed direct-to-middleware tools can significantly simplify program-ming tasks and reduce the number of concepts anddetail a developer is required to deal with. Web-Sphere Studio takes the direct-to-middlewareapproach.

The tools that use the model-driven approach ex-ploit more abstract, higher-level concepts than thoseof the target middleware environment, and then gen-

erate the code that runs in the target environment.The goal of tools using the model-driven approachis to allow applications to be defined using conceptscloser to the business problem domain than to theinformation technology domain. Such tools use fileformats different from those in the target middle-ware environment and do not give developers ac-cess to all the features of the target middleware. IBMRational Software Corporation* produces many ex-amples of model-driven development tools.

We believe that the direct-to-middleware approachand the model-driven approach are not competingbut rather complementary approaches. Both ap-proaches address the fundamental requirement ofenhancing productivity, but for different develop-ment circumstances. Direct-to-middleware tools fa-cilitate productivity by potentially reducing the num-ber of new concepts and tasks a programmer isrequired to understand, especially for developmentin a familiar middleware environment. The model-driven approach allows an application to be spec-ified at a higher level of abstraction. It can also en-able the development of applications from the samespecification for different versions of a target middle-ware platform, or even for different platforms. It ispossible to use both kinds of tools together on thesame project. In this paper we do not cover tools thatfollow the model-driven approach.

WebSphere Studio facilitates tight integration withother tools, including model-driven tools (especially,but not exclusively, the IBM Rational Software Cor-poration tools), by exploiting WebSphere Studio�splatform APIs. WebSphere Studio also provides a richplatform for integrating third-party tools. In addi-tion to the UI and source-code-management integra-tion facilities offered by the Eclipse workbench, Web-Sphere Studio uses the Eclipse Modeling Frameworkto provide a common technology for the implemen-tation of shared in-memory object models and APIlibraries. This technology enables the manipulationof all the concepts and file formats of the WebSphereplatform.

In an IDE in which each tool is responsible for read-ing, writing and manipulating the objects and filesrequired by the middleware platform, the integra-tion of the various tools takes place at the file level,and is relatively loose and coarse-grained. In con-trast, WebSphere Studio provides a rich set of APIabstractions over a wide range of files, which sim-plify the implementation of associated tools and pro-vide a more tightly integrated experience for the de-

BUDINSKY ET AL. IBM SYSTEMS JOURNAL, VOL 43, NO 2, 2004386

veloper. Tools integrating with WebSphere Studiocan share a single memory copy of a middleware ar-tifact, and tools integration can occur at the finer-grained level of the individual objects stored withinthe files. Use of the Eclipse Modeling Frameworkprovides a powerful approach to the fundamentalrequirements of enhancing productivity and enablingintegration. A more detailed discussion of the frame-work is found near the end of this paper.

WebSphere Studio is not a single product, but rathera family of products. WebSphere Studio Site Devel-oper (or Site Developer, for short) is intended forWeb application developers and includes tools forrelational database access, Web services, Web pagedesign, performance profiling, and testing. Web-Sphere Studio Application Developer (or Applica-tion Developer, for short), is intended for J2EE de-velopers and contains all the functions in SiteDeveloper. In addition it supports EJB development.The development scenario that anchors this paperfocuses on the functionality in these two core prod-ucts. (See “A development scenario” later in thispaper.)

The WebSphere Studio family of products also con-tains advanced extensions for specific categories ofusers. These extensions adhere to the same UI ar-chitecture as the core products and include much ofthe same functionality. WebSphere Studio Applica-tion Developer Integration Edition extends Appli-cation Developer with features aimed at developersof business integration applications. WebSphere Stu-dio Enterprise Developer enables development forthe entire range of IBM mainframe environments.WebSphere Development Studio Client addressesthe needs of IBM eServer* iSeries* developers andthose integrating iSeries components into distributedapplications. These products are beyond the scopeof this paper.

The rest of the paper is structured as follows. In thenext section, we start with an extended overview ofthe user interface, which illustrates key mechanismsfor the integration of tools and workflow. This leadsinto our chosen development scenario that exercisesdifferent aspects of WebSphere Studio functional-ity. Whereas many different scenarios are possible,the chosen scenario demonstrates many of the prod-uct�s most useful functions in an integrated work-flow. Next, we describe the Eclipse Modeling Frame-work, which provides the basis for WebSphereStudio�s file sharing among tools. We conclude with

a look at future challenges for IDEs, and WebSphereStudio in particular.

WebSphere Studio UI

In this section we describe some of the UI design fea-tures of the WebSphere Studio family. Because theUI is the mechanism that integrates WebSphere Stu-dio�s large number of tools, it provides the contextfor understanding the product�s overall concepts andusage.

WebSphere Studio provides a user interface that isattractive and easy to use and that can be used indifferent combinations in a wide variety of develop-ment scenarios. This requires that a simple user expe-rience be available for simple tasks while allowingexpert users access to the full power of the under-lying programming model. In order to satisfy this re-quirement, WebSphere Studio provides severalnested levels of integration. We consider them intheir logical order, building up from the simplest tothe most general (note that the typical user expe-rience might involve the higher level integrationfirst).

Development of the WebSphere Studio products fol-lowed the User-Centered Design (UCD) methodol-ogy.13 This methodology places the user at the cen-ter of all design decisions. It includes a range ofspecialized techniques to acquire feedback from rep-resentative samples of users during all stages of de-sign and development. User testing sessions wereconducted to understand the tasks that users typi-cally perform and the problems they experience withtheir tasks, to iteratively evaluate the high-level andlow-level design of the products, and to assess theproducts� design against user experience with theprime competitors� design.

The results from these activities indicated that userswould like to see less clutter in the workbench UIand better UI support for task flows in the tools. Thisuser feedback led us to further refine the design ofperspectives and cheat sheets (described later) to in-crease user productivity and the task flow integra-tion among our products.

The UI techniques described in this article provideWebSphere Studio with layered integration that pullstogether plug-ins into a single tool suite and unifiesuser task flows. In order to encourage third-partyplug-ins to exploit these various UI integration mech-


anisms in a consistent way, WebSphere Studio ad-heres to the Eclipse UI guidelines, produced for de-signers and developers of all Eclipse-basedproducts.6 The Eclipse platform that underlies Web-Sphere Studio is very flexible and extensible, but theplatform framework can only enforce UI consistencyamong the registered components to a certain ex-tent. The UI guidelines provide platform-specificguidance and best practices for plug-ins to consis-tently and tightly integrate into the workbench.

We describe below the various UI mechanisms usedin WebSphere Studio that enable layered integra-tion and provide an integrated user experience ontop of the J2EE programming model.

Menus, toolbars, action sets, and extension points.In addition to the core functionality of its workbenchplatform, WebSphere Studio is designed to be ex-tensible by plug-ins, which can contribute new views,editors, wizards, menus, and tool items to the plat-form. Plug-ins can be open-source tools or third-party vendor tools. Although each plug-in is imple-mented as a separate component in the platform, UImechanisms such as merged menus, context menus,toolbars, and action sets (as well as perspectives andcheat sheets, to be discussed later) give the platform�sUI the illusion of seamlessly integrated components,as shown in Figure 1.

Each workbench window contains a menu bar anda toolbar. These are prepopulated by the platform,but a plug-in can add items to each. This is accom-plished by using an action set, a set of task-orientedactions that users can show or hide. The actionswithin an action set are often distributed through-out the window�s menu bar and toolbar. For exam-ple, by using the Window3Customize Perspectivedialog, users can enable the EJB action set to haveEJB development-related actions available in themenu and toolbar.

In addition to supporting the standard content as-sistance in any of its several editors, the WebSphereStudio workbench also provides UI extension points,such as Quick Fixes and Quick Assist, to further en-hance the user experience. For example, users canclick on the light-bulb marker on the lefthand mar-gin of an editor for suggestions on how to fix prob-lems with the source code.

These kinds of UI extension points give users a con-sistent and context-sensitive way to perform tasks.The workbench has well-integrated support for the

popular open-source build tool ANT,14 which allowsdevelopers to automate repetitive tasks. Other ex-ternal tools, such as word processors and spread-sheets, can also be integrated with the workbench.The UI extension points in WebSphere Studio pulltogether an integrated tool suite that works as a sin-gle entity and helps users be more efficient in accom-plishing their J2EE application development tasks.

Editors and supporting views. In WebSphere Stu-dio, text editors are used to interact with entities ofinterest, which may be documents or data objects.The focus of attention is a reflection of the task athand. For example, when the task is to create, edit,and debug Java code, the focus is the Java code, andan editor is used to interact with that code.

WebSphere Studio�s next level of UI integrationcomes in the relationship between the editors andthe additional views provided to support the editors,primarily the Navigator, Outline, and Propertiesviews. Whenever an editor is active, an outline of itscontent is displayed in the Outline view (Figure 1).The outline is used to navigate through the edit dataor interact with the edit data at a higher level of ab-straction. For example, if a user opens EJB imple-mentation code in an editor, the structure of the classis displayed in the Outline view. Then, if a methodor field is selected in the Outline view, the text dec-laration of that item is revealed and selected in theeditor. If a user selects a method or field and invokesits context menu, the user can interact with the se-lected item as a conceptual unit, rather than just asequence of characters.

The interaction between editor and view is two-way,with the editor driving the content of the supportingviews. The editor and supporting views contributeuser task-related actions to the menu bar, toolbarand context menu. The supporting views can thenleverage these action contributions to further en-hance the in-context user experience. For instance,in an EJB editing scenario, users can select methodsin the Outline view and invoke an action to promotethe methods to be remote interfaces.

Not all views are associated with editors. Some viewsprovide information about the overall state of theworkbench or its contents, for example, the Javapackage explorer view (see Figure 1), which showsa logical view of the Java packages and classes con-tained in files in the workbench. Other examples arethe J2EE navigator and J2EE hierarchy views, which


provide a simplified, logical view of the J2EE filestructures.

Dealing with J2EE file formats in an IDE like Web-Sphere Studio presents some design challenges. J2EEdefines a rich, complex model for the formats of filesthat are executed on a J2EE application server. Filesassociated with Web user interfaces are structuredin a particular directory structure inside an archivefile called a Web application archive (WAR) file. Sim-ilarly, EJBs are defined by particular file and direc-tory structures within EJB module archive files. WAR

files and EJB modules are, in turn, nested inside anenterprise application archive (EAR) file. It is desir-able to allow developers access to all of the detailof the files and directory structures in order to allowexploitation of all the available features of the ap-plication server. However, experience with previousdevelopment environments within IBM has shownthat using an alternative, tools-based model for re-sources causes problems, particularly integrationwith other tools that use the application server�s filestructures directly and with the application server�sown capabilities, such as the administrative console

Figure 1 Typical workbench configuration


and problem determination tools. On the other hand,exposing the details of these files and their structuresdirectly, as in WebSphere Studio�s standard Navi-gator view, makes for an intimidating experience, es-pecially for simple scenarios and novice users.

For this reason, WebSphere Studio offers the J2EEhierarchy view as an alternative to the J2EE naviga-tor. The J2EE hierarchy view shows a simplified, log-ical view of the project, directory, and file structure.It also shows logical J2EE information that is encodedin the contents of the files themselves, such as EJBand servlet definitions. Together, the J2EE naviga-tor and hierarchy views fulfill the requirement of pro-viding simplified views of J2EE while allowing devel-opers access to the full detail of the J2EE artifacts.

Perspectives. The fundamental building blocks un-derlying the UI of any product based on the Eclipsearchitecture are editors, views, and action sets. Typ-ically, editors allow the user to create and modifyresources; views allow the user to navigate amonga set of resources or see alternate logical presenta-tions of those resources, and action sets allow theuser to invoke groups of operations against these re-sources. Because Eclipse is an open system, it hasno limit on the number of editors, views, and actionsets that are integrated at any one time. Furthermore,no single component has control over the integratedUI, so that if left unchecked, it could easily becomea chaotic collection of bit parts. To create an orga-nizing principle that builds on the previous layers ofUI integration, WebSphere Studio introduces theconcept of perspectives. Perspectives provide the UIwith order and integration by governing the set ofeditors, views, and action sets visible at any one time.

Three of the more commonly used perspectives arethe J2EE perspective, the Web perspective, and theserver perspective. At any given time, only one per-spective can be visible in a workbench window (al-though the user may have several windows open ina workspace). The selected perspective determinesthe views that are visible, the spatial arrangement ofthese views, the default location of the editors wheninvoked, as well as the actions available on the win-dow�s menu and toolbar. Of the more than 80 viewsthat exist in WebSphere Studio Application Devel-oper, only eight are initially presented in the J2EEperspective; and of the more than 50 action sets thatcan be added to the menu and toolbar, only 16 areadded by default.

The product itself determines the set of views andaction sets to pull together within a perspective, aswell as the number of perspectives to provide. Theoverriding principle is that WebSphere Studio per-spectives encapsulate sets of views and actions thatallow users to complete major application develop-ment tasks without having to switch their workingcontext. Consequently, WebSphere Studio providesperspectives targeted to particular user roles (e.g.,Web developer), to distinct phases of the develop-ment life cycle (e.g., profiling and logging), and tospecialized resource types (e.g., data). The individ-ual user is able to customize most aspects of a per-spective, as well as create entirely new perspectives,but the design point is to provide a default collec-tion that is immediately useful “out of the box.”

Perspectives are also responsible for one final layerof order and integration, control over tool selection;for example, controlling the list of perspectives towhich users might switch from their current one, con-trolling the list of views users might load into theircurrent perspective, and controlling the list of wiz-ards users might launch from the current perspec-tive. Of all the possible entries (for wizards, that num-ber runs into the hundreds), WebSphere Studio isdesigned to select those ten or so that are most use-ful to the task at hand (or, in the case of perspec-tives, the set to which users are most likely to switchas they proceed to their next major task). As withviews, editors, and action sets, these lists arecustomizable.

Cheat sheets. WebSphere Studio includes many in-stances of long-running macro-tasks in which numer-ous smaller tasks must be completed. These macro-tasks often span multiple component areas, requiringthe use of any number of wizards, editors, and views.Often, the smaller tasks that make up a macro-taskneed to be completed in a specific order, require re-petitive data entry, and require context-related in-formation to be maintained as the user traverses thevarious wizards, editors, and views. In the past, suchmacro-tasks have been extremely difficult for newusers to complete or understand. To help new usersthrough these long-running tasks, especially whenthe task sequence is non-intuitive, WebSphere Stu-dio introduces a form of user assistance known ascheat sheets (Figure 2).

Cheat sheets list a linear sequence of steps whereeach step contains a step title, a short textual over-view of the step, and an action link that invokes awizard, an editor, or a view. Each step additionally


includes a visual indication of step completion, a linkto the help system for further details, and, option-ally, the ability to repeat or skip a step if appropri-ate. In other words, the cheat sheet is a form of userassistance similar to a traditional help system, ex-cept that it is interactive and highly integrated withthe rest of the UI. The state of the cheat sheet is pre-served if the user needs to close it (or even the prod-uct) midway through a task. The cheat sheet capa-bilities support macro-tasks that might take manyminutes, if not hours, to complete and enable Web-Sphere Studio to support many more substantive taskflows than can be done with wizards alone. Wizardsare ideally suited to integrating a series of micro-tasks under a single unifying umbrella UI, but theirstrength is in supporting tasks that typically take nomore than a couple of minutes to perform. Cheatsheets take task support well beyond those bounds.They offer a way of scaling up traditional user as-sistance to match the increased complexity of the IDEitself.

A development scenario

Now that we have introduced the WebSphere Stu-dio UI, we will examine a development scenario thatmakes use of many of the UI features and the as-sociated tools. The scenario is designed to introducesome of the functions of WebSphere Studio Appli-cation Developer for creating J2EE applications. Thescenario has been greatly simplified to focus on rep-resentative capabilities and techniques. More de-tailed information is available in the extensive tu-torial and reference information provided with theWebSphere Studio products.

In this scenario, a fictitious manufacturing company,Global Widgets, has decided to deploy an enterpriseapplication based on Web services so that client ap-plications running on application servers, personalcomputers, personal digital assistants (PDAs), and cellphones can access information stored in the corpo-rate Human Resources (HR) database. Web serviceshave been chosen so that a single programming in-terface to the HR database can support this large va-riety of client applications, thereby reducing costsand speeding development. The scenario also devel-ops a Web user interface application using Struts15

and JSP technologies.

The scenario covers the following application devel-opment phases:

1. Developing database reporting functions andpublishing them as Web services.

This phase introduces the WebSphere StudioSQL query building and debugging tools, andshows how SQL queries and stored procedurescan be published as Web services.

2. Defining a Web service that performs updatesto the data.

This phase shows how to define a more com-plex database interaction as an EJB implemen-tation that can also be published as a Web ser-vice.

3. Creating the EJB implementation.

This phase uses WebSphere Studio�s UML**(Unified Modeling Language) Visualizer andJava Editor to create the code for the EJB ses-sion bean defined in the previous phase.

4. Testing and debugging the application.

This phase explores the features of the ServerTest Facility and shows how to use them to testthe EJB session bean.

Figure 2 Cheat sheet for creating an EJB


5. Testing for WS-I conformance and publishing toa UDDI (Universal Description, Discovery, andIntegration) registry.

This phase tests the application for conformanceto the Web Services Interoperability (WS-I) or-ganization�s Basic Profile and shows how to pub-lish the completed Web service to a company�sinternal Web service registry (UDDI).

6. Creating the Web application.

This phase creates a robust user interface to ac-cess the newly developed Web service.

7. Analyzing and optimizing performance.

The final phase uses the Performance Profilingtool to identify any performance bottlenecks inthe completed application.

Note that the WebSphere middleware platform andthe corresponding WebSphere Studio tools offermany options for application architecture and ap-plication deployment topologies, most of which wecannot cover in this paper. In this scenario, we chooseto follow a single representative topology that pro-vides some idea of the range of WebSphere Studio�scapabilities. We develop a set of Web services usinga combination of WebSphere and IBM DB2 technol-ogies, and use the Web service interfaces we createin the development of our Web UI (as alternativesin our UI implementation, we could have used DB2access, stored procedures, or EJBs directly). The bestchoice of architecture for a particular application de-pends on many factors, and the interested reader canconsult Reference 16.

Creating data access reporting functions and pub-lishing them as Web services. The initial phases ofthe Global Widgets scenario highlight WebSphereStudio support for data access functions. Databasesupport covers a wide range of products, includingIBM DB2, IBM Informix*, IDS Server, Oracle Data-base, Microsoft SQL Server, and others. This supportincludes, among other things, creating tables andviews and sampling their data, accessing DB2 feder-ated data, graphically building and executing SQLstatements, and developing and testing DB2 Java andSQL stored procedures and deploying them in J2EEapplications. The scenario is based on the DB2 SAM-PLE database that contains sample data for a num-ber of fictitious departments and their employees.Associated with each employee there is an ID num-

ber, a name, a salary, an education level, and a de-partment. Departments have an ID number, a name,and a manager.

This phase of the scenario uses WebSphere Studiotools to develop data access reporting functions andthen publishes those functions as Web services, thusmaking them easily available through the wide va-riety of devices and applications that Global Wid-gets supports. The reporting functions produce thelist of all departments, the list of all employees ina given department, and the management chain fora given employee. These reporting functions are im-plemented bottom-up, using SQL queries and a DB2SQL procedure, and then deployed as DB2 Webservices.

The reporting functions are implemented by directlyaccessing the database. Two of the functions, list alldepartments and list all employees in a department,are simple queries implemented as SQL SELECT state-ments. The third function, list the management chainfor an employee, is a more complex query and is im-plemented as a DB2 SQL stored procedure. These func-tions are then deployed as a Web service. This illus-trates a bottom-up approach to Web service creation.

A few simple steps with minimal coding are all thatis required to begin development of these functions.After launching Application Developer and creat-ing a new dynamic Web project, named HR, the de-veloper opens the data perspective, creates a con-nection to the DB2 Universal Database* V8.1 SAMPLEdatabase, and imports the database into the project.The next step is to open the SQL Query Builder, us-ing the pop-up menu in the Statement folder. Thequery builder enables users to build SQL statementsgraphically by selecting tables and columns from thedatabase, linking them to specify JOIN operations,and building expressions to qualify the data to beretrieved.

Figure 3 shows a query defined against the SAMPLEdatabase, which itself was built with only a few mouseclicks. The data returned by this query will be dis-played in the Department List page of the client ap-plication. While this example shows a relatively sim-ple query, the graphical query builder can be usedto build extremely sophisticated SQL statements. Thequery can also be executed directly within the editorto verify that it returns the intended data.

The statement that returns the list of employeeswould be defined in a similar manner. Because the


department whose employees will be listed must bepassed as a parameter to the query, this statementwould illustrate the tools support for defining que-ries that contain host variables (the standard SQL termfor a formal parameter in a query, the value of whichis set at execution time). When this type of query isexecuted by using the query builder, the user isprompted for values for any required host variables.

Our third statement, which lists the managementchain, is implemented as a stored procedure that runsdirectly in the database. This provides an importantsecurity benefit: the database administrator can au-thorize users to execute the stored procedure andget results without having to authorize the same users

to view all of the data accessed by the stored pro-cedure. Users can be granted authority to call thelistManagementChain procedure and get managementchain information from the EMPLOYEE table, with-out being able to view the sensitive salary data storedin the same table.

WebSphere Studio provides sophisticated tools toassist with the development of stored procedures, in-cluding wizards, editors, and debugging capability.Figure 4 shows the WebSphere Studio desktop withthe source code editor for creating SQL procedures.

Stored procedures need to be uploaded and installedinto DB2 in order to run. WebSphere Studio takes

Figure 3 Query defined against SAMPLE database


care of these mechanics with a single click. In ad-dition, WebSphere Studio offers source-level debug-ging capability for SQL procedures. Figure 5 showsour SQL procedure being debugged.

An important architectural aspect of WebSphereStudio is that many components are shared acrossdifferent features of the product. For example, themodel of the database catalog that was imported inthis scenario, as well as the SQL editor and other userinterface components, are also used in JSP and EJBdevelopment scenarios.

WebSphere and DB2 provide the ability to publishSQL statements and SQL and Java stored proceduresas Web services in a simple, declarative manner.WebSphere Studio wizards simplify the task of cre-ating the configuration files necessary for publish-

ing DB2 Web services. A single WebSphere Studiowizard captures the specification of the database con-nection and maps the Web service operation to thedatabase operation. The wizard then deploys the ser-vice to a test server and can optionally start the testserver. The built-in test page enables us to test ourWeb service without needing to develop a customWeb application, as illustrated in Figure 6.

Defining a Web service that performs updates tothe data. Now that the data reporting functions havebeen created and published as Web services, the nextphase of the scenario is the development of an ad-min Web service that allows applications to performadministrative functions, such as updating the nameof an employee or a department, updating salariesand education levels, transferring an employee fromone department to another, and creating or delet-

Figure 4 Source code editor for SQL procedures


ing an employee or department. The admin Web ser-vice is more complex than the reporting Web ser-vices in that it must enforce specified authorizationrules. For example, only a department manager mayperform a salary change or employee transfer. In ad-dition, the admin Web service must respond to in-valid input parameters by returning detailed faultmessages. These considerations lead to the choiceof EJBs as the implementation technology, insteadof SQL UPDATE, INSERT and DELETE statements. TheWeb service will be implemented as a stateless ses-sion EJB that will access the database using Depart-ment and Employee entity EJBs.

EJB-based Web services may be developed using ei-ther a bottom-up or a top-down approach. In the top-

down approach a Web Services Description Lan-guage (WSDL)3 document is developed first and askeleton session EJB is generated from it. The meth-ods of the generated session EJB are then coded. Inthe bottom-up approach, a session EJB is developedfirst and is then deployed as a Web service, with theWSDL document being generated from the sessionEJB. For a further discussion of these developmentapproaches, see Reference 17.

The bottom-up approach is the fastest way to getstarted with Web services because it builds on tra-ditional programming skills. However, the top-downapproach has several important benefits, includingimproved interoperability. In Web services, WSDLacts as the programmatic contract between clients

Figure 5 Debugging an SQL procedure


and services. In the top-down approach, WSDL is acentral development artifact, being the source forgeneration of both service skeletons and clientproxies.

Industry experience over the last few years has shownthat the best way to achieve interoperability is to de-scribe Web services as an exchange of XML docu-ments, which, when using SOAP (Simple Object Ac-cess Protocol), is referred to as the document/literalstyle. WebSphere Studio includes many new featuresthat directly support document/literal style Web ser-vices, such as top-down creation of WSDL, validationof WSDL, generation of HTML (HyperText MarkupLanguage) documentation from WSDL, and conform-ance-checking of both WSDL documents and SOAP

messages against the Web Services InteroperabilityOrganization Basic Profile (WS-I BP). The Basic Pro-file specifies versions, clarifications, and constraintsfor SOAP, WSDL, and UDDI. For additional informa-tion on these Web services standards see References18 and 19.

For the Global Widgets scenario, we start top-downdevelopment of the admin Web service by creatinga new WSDL document in project HR, admin.wsdl, andthen edit it with the WSDL editor as follows:

● We create a new port type for the service and adda new operation for each of the administrative func-tions in the service, for example, ChangeDepart-

Figure 6 Web service output


mentName, ChangeEmployeeName, and Transfer-Employee.

● We create an input and an output message for eachoperation and, optionally, some faults.

● We specify the format of the messages andfaults using the XML Schema Description Lan-guage (XSD) editor integrated into the WSDLeditor.

● We complete the WSDL document by creating aservice element that contains a single port, bind-ing the port type using document/literal style SOAPover HTTP.

Figure 7 shows an example of creating a WSDL doc-ument. Our document, admin.wsdl, is open in thegraph view of the WSDL editor. The input messageof the ChangeDepartmentName operation is selectedand its XSD definition is expanded to show the input

parameters, DepartmentNumber and Name. In gen-eral, a message format may be an arbitrarily com-plex XSD document. In this example, the message ismerely a wrapper for some simple parameters, andthe message type is referred to as the wrappeddocument/literal style.

Now that the WSDL document has been created, thenext step is to generate a skeleton EJB Web servicebased on the WSDL document. At the same time wewill generate a Java client proxy and sample JSP testclient in order to exercise the service. The Web Ser-vice wizard can perform all the required tasks includ-ing creating the EJB project, HR EJB; generating theskeleton stateless session EJB, deployment code, andall deployment descriptors; starting the service in theWebSphere test environment; and generating the cli-ent proxy and JSP test client.

Figure 7 Graph view of WSDL editor


After this is completed, we have a running Web ser-vice and can test it using the JSP client. However, theservice does nothing because it does not yet includeany business logic. Implementing the business logiccalls for WebSphere Studio�s Java development toolsand normal EJB programming. The following phasesof the scenario introduce some of the tools that areavailable to simplify the job of developing and test-ing the EJBs. See Reference 20 for more informa-tion on Web services tools in WebSphere Studio.

Creating the EJB implementation. Now that we havecreated a session bean skeleton to implement ouradmin Web service, we can use the EJB tools to com-plete the service implementation. Using a sessionbean for the service implementation gives access tothe services provided by the EJB container, such asmanagement of transactions to ensure data integ-rity and security to allow control over which usershave access to HR functions.

The admin service will work with the data from theEMPLOYEE and DEPARTMENT tables. In the EJB pro-gramming model, entity beans provide access to per-sistent data of this kind. WebSphere Studio providestools to generate container-managed persistence(CMP) entity beans from table definitions. In partic-ular, the EJB-to-RDB mapping wizard creates entitiesusing a bottom-up map. This generates CMPs that pro-vide a direct representation of the underlying tablesto our HR EJB project. The wizard generates the twoCMPs required by the admin service and automat-ically maps them to the EMPLOYEE and DEPART-MENT tables. We can view the detailed results usingthe map browser, as shown in Figure 8. Now thatthe two CMPs have been generated, we can imple-ment the admin bean by using simple EJB/Java APIson the CMPs to manipulate the data.

The mapping wizard automatically uses local-onlyentities (a best-practice behavior). Because only the

Figure 8 Map browser


session bean can be remote, we are able to maintainencapsulation of the persistent data. Because theCMPs are local entities, we must define local refer-ences in order for the session bean to work with them.These references can be created graphically usingWebSphere Studio�s UML Visualizer. The only stepsrequired are to add the three beans to a new classdiagram, and then use the Visualizer palette to drawthe two local references. The resulting EJB class di-agram is shown in Figure 9.

The UML Visualizer provides powerful graphical ed-iting capabilities for EJBs. For example, Figure 9 alsoshows annotations that we added to show the inher-itance among the generated Java interfaces. The UMLVisualizer uses UML object-modeling notation thathas been standardized by the Object ManagementGroup, Inc.21

The diagram created by the UML Visualizer is savedin the admin EJB project and can be shared with thedevelopment team along with the other development

artifacts. The Visualizer has no additional model datathat needs to be synchronized with the EJB deploy-ment descriptor and supporting Java source. Becauseits visualization is derived dynamically from thosesources, it is always in synchronization. Changesmade in the EJB deployment descriptor editor or Javaeditor are reflected immediately in any class diagram,and vice versa.

Once the local references have been created for theentity beans in the admin session bean implemen-tation, the developer can switch to the Java editorto complete the implementation. The body of thechangeDepartmentName method can use a standardcoding pattern for JNDI (Java Naming and DirectoryInterface) lookup of the Department home via theejb/Department local reference. Figure 10 shows howthe developer would complete the method using theJava editor.

The WebSphere Studio Java editor is extended withfeatures to assist EJB developers. For example, the

Figure 9 UML visualizer with EJB class diagram


method outline adds decoration to distinguish homeand remote/local interface methods, and provides anEnterprise Bean submenu to facilitate adding andremoving implementation methods from the appro-priate interfaces. The task list is extended to pro-vide feedback on the correctness of EJB and otherJ2EE artifacts along with feedback on the Java com-pilation process.

This scenario shows a basic path through the Web-Sphere Studio EJB tools and illustrates how Web-Sphere Studio simplifies the task of building and de-veloping applications with EJBs. The capability forusing a scenario of this kind is important for initial

developer experience with the products, as well asfor programmer productivity. It is equally important,even for experienced developers, that WebSphereStudio provides deep and detailed control over ev-ery aspect of EJB development defined in the J2EEspecification and over the application server exten-sions to these capabilities. One example of this is themultipage custom editor provided to assist with view-ing and modifying EJB deployment descriptors, illus-trated in Figure 11.

In the EJB phase of the scenario, we completed theimplementation of the admin bean (the Ad-minSOAPPortImpl session bean) and connected it to

Figure 10 Session bean in Java editor


the database using entity beans. The next step is test-ing and debugging the Web service application.

Testing and debugging the application. We have al-ready made references to the ability to simply andimmediately test a function by executing it on a Web-Sphere Application Server. In each case, we havedone this by selecting a simple menu item or check-box in a wizard, without installing, configuring ormanually starting the application server, and with-out packaging and installing the application contain-ing the function. This capability is provided by theServer Test Facility. Testing the admin bean for theGlobal Widgets scenario requires the use of the Uni-

versal Test Client (UTC), which is the most complexcomponent of the Server Test Facility. To understandits usage, we will take an extended look at the ServerTest Facility as a whole and at the test environmentsthat it supports.

The Server Test Facility. This facility allows the userto explicitly manage and edit server configurationsas part of the development environment and also au-tomatically creates default server configurations forapplications under development. This allows for im-mediate testing without the need for an explicit con-figuration step. The Server Test Facility supportsmultiple application servers including various ver-

Figure 11 Multipage custom editor


sions of WebSphere Application Server, BEA Web-Logic, and Apache Tomcat.

In addition to being able to create a single defaulttest server configuration that supports the simple testexperience described above, the test environment al-lows the developer to explicitly create and managemultiple test server configurations and server in-stance definitions. Because the files that form theserver configuration are saved in the source codemanagement system, complex configurations can beshared between team members to help with consis-tent, repeatable testing.

Server configurations and server instances providea very flexible test environment, but with this sup-port comes the inherent complexity of having mul-tiple servers, server configurations, and associatedprojects. Rather than requiring developers to learnthe entire structure just to test a simple application,WebSphere Studio provides a staged introductionto the test environment that starts with simple menuselections and wizards. If a project is not already as-sociated with a server configuration, a new config-uration is created for it. If the configuration is notassociated with a server instance, a new instance iscreated. Finally, the server is started with the con-figuration and displayed in a browser integrated intothe workbench. Other server configuration details,such as the definition of data sources required forCMP beans, the generation of EJB deployment code,and even relational database table creation, are han-dled as part of this process.

In addition to the support for this simple experience,WebSphere Studio Server Test Facility also providesextensive tooling for expert developers who need tocontrol each and every detail of their server config-urations, such as the Server Test Facility multipagecustom editor. Further discussion and additional de-tails on the WebSphere Studio Server Test Facilityare available in Reference 22.

WebSphere Unit Test Environment. This environmentis a key implementation of the Server Test Facility.It consists of a complete instance of the WebSphereApplication Server, which is shipped and installedwith the Studio development environment. Becausethe server is tightly coupled with the desktop, theapplications under development can be easily exe-cuted and tested without the overhead of publish-ing the application or installing it into a separateserver. Studio includes multiple versions of the ap-plication server, in order to allow testing of appli-

cations that target an older version of the runtime.It is even possible to apply WebSphere ApplicationServer fixes to the test environment.

The critical distinguishing feature of the WebSphereUnit Test Environment is its locality; because it isinstalled as part of the development environment,it is possible to bypass the file distribution and pub-lishing step otherwise required to install an appli-cation. Because the WebSphere Studio organizesfiles according to the J2EE specification, the Unit TestEnvironment can generate a server configurationthat points to the application as it exists in the work-space. This means that even after the application hasstarted running, the developer can make changes tothe files. The server will detect that the files havebeen updated and immediately reflect the changes.This tight coupling provides an extremely produc-tive edit/compile/debug experience, in which theoverhead of republishing and redeploying changesmade while debugging is almost zero. For furtherinformation on configuring the WebSphere Unit TestEnvironment, refer to Reference 23.

WebSphere Studio provides a related feature calledhot method replacement, which has the capability toreplace, in memory, the byte-codes for a previouslyloaded class. This means that the developer can makecode changes to an application that is running onthe WebSphere Application Server and has stoppedat a breakpoint. When the source file is saved, theincremental Java compiler updates the JVM** withthe new code. The current execution point resets tothe start of the current method, but no other appli-cation state is lost.

WebSphere Remote Test Environment. The RemoteTest Environment refers to the capability of Studioto publish to, configure, start, and interact with aserver defined on a remote system. This capabilityshould not be confused with the runtime system man-agement function. Rather, it is intended to allow test-ing on a server other than that included as part ofWebSphere Studio.

As with the Unit Test Environment, the Remote TestEnvironment can use different versions of the Web-Sphere Application Server, but each server instancemust be installed separately from WebSphere Stu-dio. The installation can be on the same machine onwhich WebSphere Studio is running, on another ma-chine running on the same operating system, or evenon a different operating system. This model can alsobe used to mitigate the performance impact of run-


ning the application server on the development envi-ronment machine—a single dedicated test machinecan provide the execution capabilities for a completedepartment. After a remote server has been com-pletely defined, it is used in exactly the same way asthe Unit Test Environment.

Testing an EJB in the Universal Test Client. When cre-ating a Web application, the unit test mechanism isrelatively straightforward—we display the applica-tion pages in a browser. However, when creating anEJB or Web-service-based application, it is muchmore difficult to unit-test the constituent parts of theapplication. The UTC is a Web application includedwith WebSphere Studio that provides an easy mech-anism for testing a server-side component such asan EJB without the need to develop a custom appli-cation to drive the EJB. The UTC is enabled in theserver configuration, which results in the additionalapplication being included in the server when theconfiguration is published.

Interaction with the UTC occurs via a browser—ei-ther the one integrated into WebSphere Studio oran external browser. The UTC includes a number ofpages, all accessible from the application home page:the JNDI explorer and properties pages allow us toview and modify the JNDI namespace, and the beanpage allows us to explore active Java beans and EJBs.The typical test experience occurs in the bean page,but the first step is to load the EJB. The JNDI nameof the EJB in question can be located via the JNDIexplorer, and the EJB home can be added to the beanpage. Alternatively, the bean page can load a Javaclass and then create a new instance of that type, asin Figure 12.

The interaction within the bean page mirrors the J2EEprogramming model. In the case of our admin bean,the first step is to select the home bean. The variousmethods are dynamically determined and displayedin the browser: we can then select a method to cre-ate or find the bean, and that method returns an in-

Figure 12 Bean page in Universal Test Client


stance of the admin bean (which is displayed in thebrowser). The next step is to click the Work with Ob-ject button and invoke methods on the bean: selectthe method, define the parameters to pass, and in-voke it. This provides an indication of whether theadmin bean is working as designed.

The result of the method invocation can be furtherinspected and invoked, or just displayed as neces-sary. Equally importantly, we can set breakpoints atany point in the application and use the UTC as thetrigger to run to that point. The UTC usage modelis very consistent with the best practice usage ofEJBs—the UTC is a Web application that invokes theEJB.

It is important to note that EJBs are not the only ar-tifact type that can be displayed and invoked. In fact,any Java class can be loaded via the UTC, making itan ideal mechanism to invoke multiple application

paths. This includes the Java proxy that is generatedfor Web services or any user-provided class file.

Testing for WS-I conformance and publishing to aUDDI registry. After the business logic of the adminsession bean has been unit-tested in the UTC, the sce-nario shifts to a focus on the Web service aspect ofthe implementation. The implementation is validatedfor conformance with the WS-I Basic Profile andthen published to the Global Widget�s internal UDDIWeb service registry.

The TCP/IP Monitoring Server is the WebSphere Stu-dio tool used to test for WS-I conformance. Thisserver acts like a tunnel between the client and theWeb service. It captures, displays, and records allmessage traffic. In addition to being a valuable de-bugging tool, it can save the recorded messages toa log file, which can be validated against the BasicProfile. Figure 13 shows the TCP/IP Monitor after it

Figure 13 TCP/IP Monitor view with Web service operation invocations


has captured three Web service operation invoca-tions. The third invocation is selected, and its inputand output messages are shown in the bottom leftand right panes.

To validate the captured SOAP messages, simply clickthe checklist icon at the top of the TCP/IP Monitorview. This action saves the messages to a log file inthe standard XML format specified by the WS-I TestTools and runs the validator on the log file. Any er-rors or warnings detected by the validator are asso-ciated with the log file and appear in the Tasks view.In our example, the service is valid, but the valida-tor detects a warning in the client: the Basic Profile

specifies that messages should be sent using HTTP1.1, but here the client is using HTTP 1.0. The log fileand Task view are shown in Figure 14.

The final task in developing the admin Web serviceis to publish the service description to a UDDI reg-istry. WebSphere Studio�s Web Services Exploreracts as a universal client to any compliant UDDI reg-istry. The Web Services Explorer lets us easily ex-port a WSDL service description from a developmentproject and publish it in a UDDI registry. The firststep is to export the service description into Web-Sphere Studio�s private UDDI test registry, which canbe installed into the WebSphere test environment.

Figure 14 Log file and task view


After the service description has been tested and val-idated, it can be published to the private UDDI reg-istry used by Global Widgets by using either the reg-istry�s standard programmatic SOAP interface or itsWeb interface.

At this point, the admin Web service has been designed,implemented as a session bean, tested, validated, andpublished. It is now ready for use in client applications.

Creating the Global Widgets Web application. Sofar, the Global Widgets scenario has used a varietyof WebSphere Studio tools to implement the logicand data access components for the Global WidgetsWeb application. The next phase focuses on the setof tools used for developing a Web user interface.The tight integration between the Java tools and Webdevelopment tools supports a task flow that had pre-viously been difficult because the tools may have beenbased on different models and may have not workedwell together.

The user interface for the Global Widgets applica-tion will support login, reporting, and updates. Thereporting will include a master-detail data grid show-ing the list of departments and allowing users to drilldown into the employees in a department. The cli-ent will be developed as a Struts application. (Strutsis a popular open-source framework that supportsdevelopment of Web user interfaces using the widelyaccepted model-view-controller architecture. For adetailed discussion of all the elements in the Strutsprogramming model see References 15, 24, and 25.)WebSphere Studio supports the building of Struts-based applications through a set of tools illustratedin Figure 15.

The Web Diagram Editor is used to lay out the flowof a Web application graphically. The other impor-tant tool here is the Struts Explorer. It shows howall the elements of the application relate to eachother and shows these relationships from differentperspectives in the form of a hierarchy. From any

Figure 15 Tools for Struts


given node in the hierarchy, one can traverse linksbetween the elements. The underlying infrastructureunderstands how these indirect references would re-solve at runtime and shows this relationship directlyin the hierarchy at development time. In this way thetool can tell the user at development time whetherall the linkages are correct in much the same waythat compilers show how references to named ele-ments resolve.

Application developers often start designing a Webapplication by drawing diagrams of how the appli-cation pages relate to each other. WebSphere Stu-dio provides this capability. Using the Web DiagramEditor (Figure 16), users can draw diagrams in whichthe nodes represent pages and actions and the ar-rows represent transitions to other pages or actions.

Figure 16 shows a diagram of the Global Widgetsapplication at some point in the development. The

rectangular icons represent JSP pages, and the“gears” represent code (actions) that will be invokedwhen each page is submitted. Struts concepts, suchas form beans, Java beans, modules, and Web ap-plications, can also be represented in the Web Di-agram Editor.

At this point, all the nodes are gray, and the arrowsare dotted. Nodes and arrows in this state are saidto be unrealized. This is because there are no run-time artifacts that implement any of the diagram el-ements. We now go through a process of realizationto create runtime artifacts. When artifacts becomerealized, the nodes representing them on the dia-gram will become colored. Arrows emanating fromrealized nodes become solid if the reference repre-sented by the arrow is valid. When realized, the di-agram represents the actual deployment artifacts: thetool does not maintain a separate abstract modelfrom which the artifacts have been generated. Be-

Figure 16 Web Diagram Editor


cause of this, even Struts applications that were notcreated with this tool can be rendered and modified.This also means that the diagram will stay completelyin synchronization with the deployed code if furthermodifications are made outside the tool.

A developer can realize any node by simply double-clicking on it and completing the resulting wizard.The wizard uses relevant information from the di-agram to provide default values. In this way the de-veloper can work on successive nodes and realize theentire diagram very quickly. After each wizard iscompleted, an appropriate editor for the given ar-tifact opens. In the case of JSP pages, the Page De-signer tool opens. (Details of this tool will be cov-ered when we realize the Global Widgets JSPs.)

The logic elements created earlier are integrated intothe Web application by implementing a Struts ac-tion (gear icon). This is done by double-clicking onthe Struts action to invoke the New Struts Actionwizard, completing the wizard, and inserting a fewlines of Java code in the Java editor. For instance,for the GetDepartments action, this means invokingthe Web service that returns a list of departmentsand then forwarding the list to Departments.jsp.

Designing the Web pages. The Web developmenttools include a full-function Web page editor thatmakes creating, editing, and maintaining Web pagessimple and easy. This editor, named Page Designer,uses a drag-and-drop metaphor for adding elementsto a page and includes sophisticated page layout func-tions to create pages with a professional look andfunction. The Page Designer specializes in handlingtypically hard-to-edit dynamic JSPs, as well as staticHTML pages (for more information on JSPs, see Ref-erence 26). The editor contains both a WYSIWYG(what you see is what you get) design page and asource page. The two pages are completely synchro-nized, so that developers can switch between themdepending on their task. An important feature ofPage Designer is that it preserves the exact formatof surrounding HTML and JSP source while the de-sign page is being used to modify an element.

The Page Designer Editor (Figure 17) opens when-ever a JSP or HTML page is realized in the Struts ed-itor. The wizard creates default page content to helpjump-start the page design. If the page is connectedto a form bean in the Web Diagram Editor, the wiz-ard automatically creates page content that containsa Struts form connected to the form bean.

Page templates. Page templates are used to createa common look and feel for an application. A pagetemplate can factor out common visual elements ofall pages in a site into a single file. This permits chang-ing the look of the entire site quickly and easily bychanging only one or more page templates. Web-Sphere Studio automatically propagates changesmade to a page template to all pages based on thetemplate. One way to think about a page templateis as a Web page with “holes” in it. These holes, orcontent areas, are the only areas that Web develop-ers can modify in a page instantiated from a pagetemplate. All other areas are read-only.

Page templates can be created quickly with the sameprocess used to create regular Web pages. For ourscenario, we can easily create a page template by us-ing drag-and-drop techniques in the Page DesignerEditor. First, we add a common header and a left-side navigation area. Then we drag and drop a Con-tent Area from the Page Template category of thepalette. When pages are created using this page tem-plate, page editors will only be able to modify con-tent within the BODY content area. Our completedpage template is displayed in Figure 18.

We can apply page templates to Web pages whenthey are created using the JSP wizard, or apply themto existing pages while editing them in Page Designer.In the scenario, we apply the template to the exist-ing pages in the Global Widgets Web site.

The Global Widgets page template uses CascadingStyle Sheets (CSS) to specify default text style andbackground colors. Style sheets are useful in abstract-ing fonts, color, and other design elements of a Website and can be referenced within HTML/JSP pages.You can change the look and feel of the page tem-plate by using the WebSphere Studio CSS editor,which is called CSS Designer (Figure 19). CSS De-signer is integrated with Page Designer so that youcan change styles for a page and see the results im-mediately. By linking to the CSS style sheet fromwithin the page template, the style sheet is appliedto all pages instantiated from the template.

Adding navigation bars with Web Site Designer. Thenext step is to add navigation bars to the Global Wid-gets Web pages using WebSphere Studio�s Web SiteDesigner tool. Managing navigation structure can bedifficult and time-consuming because sites often re-quire different navigation bars on each page, for ex-ample, if each page�s navigation bar only showed itsparent page and its direct child pages. Web Site De-


signer automates the process of creating, organiz-ing, and maintaining the navigation structure.

To add a navigation bar to the Global Widgets pages,we use Web Site Designer to build up a “map” ofthe site pages that we want to include in the nav-igation. This “map” can include existing pages as wellas new pages that will be realized later, in the man-ner of the Struts editor. Figure 20 shows an exampleof a hierarchy that could be built for the Global Wid-gets site.

After we have created the hierarchy, we can add thenavigation bars described by this hierarchy by usingthe navigation tags in the site parts drawer of thepalette, which is displayed when a JSP or HTML fileis open in Page Designer. For the Global Widgetspages, all that needs to be done is to open the pagetemplate in Page Designer and drag a vertical nav-igation bar into the left area of the page. When thetemplate is saved, all the files that use the template

are automatically updated with the appropriate nav-igation links. Furthermore, if Web Site Designer isused to reorganize the site, every navigation bar inthe site will be updated accordingly. Figure 21 showsa sample page from the Global Widgets applicationwith navigation bars added.

Performance analysis and optimization. Now thatthe Global Widgets Web application is more or lesscomplete, the next step in the scenario is to tune theapplication performance. For this step, we use theWebSphere Studio Performance Profiling tool toidentify and isolate performance bottlenecks, objectleaks, and system resource limits.

The Performance Profiling tool. The PerformanceProfiling tool is capable of reconstructing the appli-cation execution path and displaying the interactionof business components such as servlets, EJBs, andJSPs. The tool can also collect execution informationat the class instance and method invocation level.

Figure 17 Page Designer Editor

Palette for adding HTMLto page usingdrag and drop

WYSIWYGdesign surface

Color paletteallows quickmodication ofcolor schemes

Attributesview allowsquick editingof selectedelement

Gallery organizedartwork andimages for quick access

Design,source andpreview pages


The tool targets applications at all levels of complex-ity, from simple, standalone Java applications to com-plex, multitiered enterprise applications running onmultiple machines, and even on different platforms.

Two different types of data collectors, also knownas profiling agents, are provided with the tool: theJ2EE Request Profiler and the Java Profiling Agent.They allow us to gather profiling information usedto analyze application execution from differentangles.

The J2EE Request Profiler agent is used to visualizethe application execution logic, without going intomethod invocation details, as it collects data fromrequests arriving on EJB and Web containers. Thisdata collection mechanism enables the creation ofsequence diagrams, which represent interactionsamong servlets, JSPs, and EJBs, while ignoring otherartifacts of the application infrastructure that do notrepresent the business logic. As the application ex-

ecution crosses the boundaries of a host, the remotediscovery mechanism causes an attachment to otherinstances of the J2EE Request Profiler.

The Java Profiling Agent runs in the JVM processand receives notifications of JVM events, based onthe JVMPI (Java Virtual Machine Profiler Interface).This agent is best used to identify performance de-tails such as the classes or methods responsible forpoor execution performance.

The WebSphere Studio Performance Profiling toolprovides a powerful user interface for profiling anapplication and for analyzing the profile data. A setof statistical views helps us identify performance hotspots at the package, class, or method-invocationlevel. The tool also provides a set of graphical viewsthat help us better understand the application ex-ecution at the node, process, thread, or method-in-vocation level.

Figure 18 Global Widgets page template


Analyzing performance. This phase of the scenariofocuses on solving a specific performance problem:the time taken to change the department name isvery high the first time the operation is executed,

while the next call to the same operation is visiblyfaster. The best way to start analyzing enterprise ap-plications is to have an overall view of the applica-tion execution flow. The J2EE Request Profiler agent

Figure 19 CSS Designer

Figure 20 Global Widgets site hierarchy

Home

Login Department Results

Widget A Widget B

Products

Widget CAdd Department Query Employees


is used to collect this type of information. While theagent is monitoring the Global Widgets application,we will change a few department names and thenreturn to the WebSphere Studio Performance Pro-filing tool and analyze the execution results.

In Figure 22, the Object Interactions view displaysthe application execution in a UML format. Noticethe interaction among servlets and JSPs. In the fig-ure, we can see that three department change op-erations were executed. The method AdminSOAP-PortImpl.changeDepartmentName call results in a callto the ProgrammingModel.findByPrimaryKey method.For the first and last execution, the department wassuccessfully found, and, as a result, there followeda call to the ConcreteDepartment_.setDepartment beanmethod. The red indicators on the left side of thediagram represent the elapsed time between consec-utive events. Double-clicking on any of the indica-tors locates the sections with high execution time.

Next, the Java Profiling Agent can be used to getmore details on the application execution, based on

method invocation details. The Performance Pro-filing tool provides a set of statistical views to helpanalyze the execution performance at the package,class, or method level. The Package Statistics view(Figure 23) is a good starting point because it iden-tifies the packages responsible for slow executiontime. From here, we can drill down and look for theclass or method responsible for poor executionperformance.

In Figure 23, the Package Statistics view shows sta-tistics of the different classes, grouped by their con-taining packages. The view can be customized to dis-play any type of statistical data, such as memoryallocation or time-based statistics. In this particularexample, because the interesting information is theexecution time, the packages are sorted using the ex-ecution Cumulative Time column. The figure iden-tifies the com.globalwidgets package as the executionhot spot, and within this particular package, Admin-SOAPPortStub is the class responsible for the slowexecution time.

Figure 21 Global Widgets page with navigation bar


In a like manner, we can use the Class Statistics viewto identify the method responsible for the Admin-SOAPPortStub class�s overall poor performance,which turns out to be the changeDepartmentNamemethod. Next, we use the Method Invocation viewto analyze the execution pattern for AdminSOAPPort-Stub.changeDepartmentName. The Method Invoca-tion Table shown in Figure 24 displays the methodinvocations in a tabular format.

It is interesting to note that for the first method in-vocation the execution time (see the CumulativeTime column) is high compared with the secondgetAdminSOAPPort invocation. Analyzing the methodinvocations stack, we can finally determine that theinvocation of the Stub$Invoke.invoke method on thefirst execution of AdminSOAPPortStub.changeDepart-mentName is responsible for the poor performance.

This example introduces only one of the capabili-ties of the Performance Profiling tool. Additional ca-pabilities include finding memory leaks, performingheap analysis, and tracing application execution (loganalysis and correlation).

The Global Widgets scenario and developer pro-ductivity. Now that the Global Widgets applicationdevelopment scenario is complete, we can summa-rize its general tasks and the WebSphere Studio toolsthat were used.

1. Develop database reporting functions.a. Create the reporting functions, using SQL

Query Builder and Source Code editor and de-bugger for SQL stored procedures.

b. Publish the database reporting functions as aWeb service, using WebSphere Studio wizards.

Figure 22 Object Interactions view


2. Develop an EJB implementation for data update.a. Define the data update (admin) Web service

using the WSDL editor.b. Generate a skeleton EJB Web service from the

WSDL definition by using a Web service wizard.c. Create CMPs to represent the data to the EJB

implementation, again by using a wizard.d. Define references to the CMPs by using the UML

Visualizer.e. Create the business logic for the Web service

session bean by using the Java editor with EJBextensions.

3. Test and debug the implementation using theServer Test Facility�s UTC.

4. Publish the Web service.

a. Test the Web service for conformance to theWeb Services Interoperability Basic Profile(WS-I BP).

b. Publish to the Global Widgets Web servicesUDDI by using the Web Services Explorer.

5. Develop the Web application.a. Create the Global Widgets Web UI as a Struts

application by using the Web Diagram Editor.b. Design the JSP Web pages by using the Page

Designer editor, page templates, and CSSDesigner.

c. Create a Web navigation hierarchy by usingWeb Site Designer.

6. Analyze and optimize performance by using thePerformance Profiling tool.

Figure 23 Package Statistics view


Rather than attempting a comprehensive overview,this scenario has focused on a single representativeworkflow. Other scenarios just as easily could havebeen chosen that would have illustrated the samedegree of integration and productivity while exer-cising different functionality. It is worthwhile to notethe wide variety of tools utilized in this single, tightlyintegrated workflow, and the ease with which appli-cation artifacts can move from one tool to another.For many tasks, wizards automate most or all of theprogramming steps. The high level of tools integra-tion contributes greatly to developer productivity.

Eclipse Modeling FrameworkThe underlying framework that enables the fine-grained data integration between the WebSphere

Studio tools is known as the Eclipse ModelingFramework (EMF).27 This section provides a tech-nical overview of the EMF. In addition to having gen-eral technical interest, this technology is notable forthe manner in which it enables WebSphere Studioto be extended in an extremely tightly integratedfashion.

One future goal of WebSphere Studio is to providean extensible tools platform that tools vendors andeven customers can extend as a platform for creat-ing J2EE and WebSphere applications. Such a plat-form would leverage the EMF technology used to im-plement the internal model APIs of WebSphereStudio. EMF is also a powerful technology for im-plementing object models outside of WebSphere

Figure 24 Method Invocation Table


Studio. In the future, we expect to expose many ofthe internal WebSphere Studio object model APIs de-veloped with EMF, along with ancillary APIs that fa-cilitate manipulation of these models, to allow tooldevelopers outside of IBM to reuse this functionwithin other tools that can be integrated with Web-Sphere Studio.

EMF is an Eclipse subproject that provides a Java run-time framework and code generation facility forbuilding tools and other applications based on struc-tured models. Unlike many tools of this type, EMFmodels are surprisingly simple—essentially the classdiagram subset of UML—providing a large percent-age of the benefits of modeling with a very low costof entry. Most importantly, EMF modeling enablesand supports data sharing between applications, acritical requirement for an open, extensible tool envi-ronment like WebSphere Studio.

The EMF framework provides a metamodel, calledEcore, for describing EMF models. Ecore is basedon the Object Management Group�s MOF** (MetaObject Facility) specification. Ecore started out asan implementation of MOF but evolved based on theexperience gained while using it to implement theWebSphere Studio tools. The resulting EMF frame-work is a highly efficient Java implementation of acore subset of the MOF API. Ecore corresponds tothe EMOF (Essential MOF) portion of the recentlyaccepted MOF 2 specification.

The canonical form of an EMF model is an XMI (XMLMetadata Interchange) serialization of an Ecoremodel. One of the main strengths of EMF is its flex-ibility with respect to the means of defining an Ecoremodel:

● XMI—we can create an Ecore XMI document di-rectly by using an XML or text editor or by usingEMF�s simple tree-based sample Ecore editor.

● UML—We can define the model by using a com-mercial UML modeling tool such as RationalRose*, or by using a free Eclipse plug-in such asOmondo�s EclipseUML graphical editor.28

● Java—We can use basic Java interfaces with a fewsimple annotations to describe an Ecore model.

● XML Schema—We can convert an XML Schemadefining the data structures for the model directlyinto an Ecore model.

The XMI document approach is the most direct butgenerally only appeals to XMI experts. The UML

choice is desirable if we are already using modelingtools, while the Java approach provides the benefitsof modeling in a pure Java development environment(for example Eclipse�s JDT [Java DevelopmentTools]). The XML Schema approach is most desir-able when the tool or application is intended to ma-nipulate XML data that is already defined using anXML Schema, such as with Web services. Regard-less of which input form is used to define an EMFmodel, the benefits are the same.

From an Ecore model, EMF�s generator can createa corresponding set of Java implementation classes.Every generated EMF class implements an interface,EObject, that provides an efficient reflective API foraccessing the object�s properties generically. In ad-dition, change notification is an intrinsic property ofevery EObject, and an adapter framework can beused to support open-ended extension to the objects.The runtime framework also manages bidirectionalreference handshaking, cross-document referencingincluding demand-load, and arbitrary persistentforms with a default generic XMI serialization thatcan be used for any EMF model. EMF even providessupport for dynamic models; that is, Ecore modelsthat are created in memory and then instantiatedwithout generating code. All of the benefits of theEMF runtime framework apply equally to them.

Most of the tools in WebSphere Studio model theirdata using EMF. These include models for XSD (XMLSchema), WSDL (Web services), RDB and SQL (re-lational databases and queries), Java and EJB (J2EEtooling), and many more. A generic EMF mappingmodel and framework is also used to implementWebSphere Studio�s mapping tools, such as EJB-to-RDB mapping and XML-to-XML document transfor-mation. This kind of reusable mapping frameworkis possible because of the consistent use of EMF tomodel the data being mapped.

Some models in WebSphere Studio simply use thedefault XMI serializer provided by EMF to persist theirmodels. Others implement customized serialization,enabling the model to be persisted in its natural (na-tive) format. For example, XML Schema models arepersisted as .xsd files, Java models as .java files, andso on. Other models, for example, mappings, are typ-ically persisted using XMI, although specific types ofmappings may be serialized differently. For exam-ple, XML Schema mappings can also be serialized inXSLT (Extensible Stylesheet Language Transforma-tions) format.


There are two fundamental benefits from Web-Sphere Studio�s use of EMF. First, it results in a pro-ductivity gain in implementing the tools by provid-ing a high-level method (UML) to represent thedesign for communication among teams and by gen-erating part of the implementation code. Second,while Eclipse itself provides an effective platform forintegration at the UI and file level, EMF allows theWebSphere Studio tools to integrate at a much finergranularity than would have been possible otherwise.EMF modeling provides the foundation for fine-grained data integration in WebSphere Studio.

A framework called EMF.Edit extends and buildson the core EMF framework, adding support for gen-erating adapter classes that enable viewing and com-mand-based (undoable) editing of a model, and evena basic working model editor. EMF.Edit is also usedby several of the tools in WebSphere Studio. Moreinformation on EMF (and EMF.Edit) is available inReference 27.

Future directions and challengesExperience with WebSphere Studio has shown thatas the functionality provided to the user grows, es-pecially in higher-end versions of the product, it be-comes a challenge to keep the user interface unclut-tered and easy to understand. This is true even withskillful use of Eclipse UI structuring mechanisms suchas perspectives and views. In response to this chal-lenge, the Eclipse community is introducing new UIorganizing concepts, namely activities and contexts.Future versions of WebSphere Studio will exploitthese concepts to provide a simpler, more task-fo-cused user experience in products that continue tohave very rich function.

We will also explore techniques for implementingtools that can be made available either on an indi-vidual computer or over the Web. Classic develop-ment tasks, such as compiling source code, are al-most always performed by individual developersworking on dedicated computers. However, for sometools it would be desirable to use them not only inthe context of an IDE running on a personal com-puter but also on a server with access through a Webbrowser UI. Tools for configuring and administrat-ing systems are typical examples.

Finally, an important goal for the WebSpheremiddleware platform is simplifying the developmentprocess. We consider an approach based on furtherseparation between tasks performed by application

programmers focused on the implementation of bus-iness logic and tasks performed by specialists deal-ing with the IT infrastructure. This direction is a jointeffort between IBM tool and runtime teams; an im-portant example can be seen in the recently publishedSDO architecture,29 which is supported in the latestrelease of the WebSphere Studio Web tools andWebSphere runtimes. We expect to see more of thiskind of runtime and tool simplification to ease thedevelopment of applications that run on the Web-Sphere platform.

*Trademark or registered trademark of the International Bus-iness Machines Corporation.

**Trademark or registered trademark of Sun Microsystems, Inc.,Microsoft Corporation, BEA Systems, Inc., Borland Software Cor-poration, or Object Management Group, Inc.

Cited References and notes

1. Java 2 Platform, Enterprise Edition (J2EE), Sun Microsystems,Inc., http://java.sun.com/j2ee/.

2. Extensible Markup Language (XML) 1.0, World Wide WebConsortium (W3C) (2000), http://www.w3.org/TR/REC-xml.

3. World Wide Web Consortium (W3C), http://www.w3.org/.4. IBM WebSphere Studio Family, IBM Corporation, http://

www.ibm.com/software/ info1/websphere/ index. jsp?tab�products/studio.

5. WebSphere Application Server Version 5.1 Information Center,IBM Corporation, http://publib.boulder.ibm.com/infocenter/ws51help/index.jsp.

6. Eclipse.org, Eclipse Foundation, http://www.eclipse.org/.7. Product Overview for Visual Studio .NET 2003, Microsoft Cor-

poration, http://msdn.microsoft.com/vstudio/productinfo/overview/default.aspx.

8. BEA WebLogic Workshop, BEA Systems, Inc., http://www.bea.com/ framework.jsp?CNT� index.htm&FP� / content /products/workshop.

9. Borland JBuilder X, Borland Software Corporation, http://borland.com/jbuilder/index.html.

10. Sun Java Studio Standard, Sun Microsystems, Inc., http://developers.sun.com/prodtech/javatools/index.html.

11. NetBeans� Products, NetBeans.org, http://www.netbeans.org/products/.

12. Oracle JDeveloper 10g, Oracle Corporation, http://otn.oracle.com/products/jdev/index.html.

13. D. A. Norman and S. W. Draper, Editors, User Centered Sys-tem Design: New Perspectives on Human-Computer Interac-tion, Lawrence Erlbaum Associates, Hillsdale, NJ (1986).

14. Apache Ant, Apache Software Foundation, http://ant.apache.org/index.html.

15. The Apache Struts Web Application Framework, Apache Soft-ware Foundation, http://jakarta.apache.org/struts/.

16. J. Adams, S. Koushik, G. Vasudeva, and G. Galambos, Pat-terns for e-Business: a Strategy for Reuse, IBM Press, DoubleOak, TX (2001).

17. A. Ryman, “Tools for Building Web Services,” in Java WebServices Unleashed, R. Brunner et al., Sams Publishing, In-dianapolis, IN (2002), pp 641–674.

18. A. Ryman, “Understanding Web Services,” developerWorks,IBM Corporation (July 2003), http://www.ibm.com/


developerworks/websphere/library/techarticles/0307_ryman/ryman.html.

19. Basic Profile Version 1.0a, Final Specification, Web ServicesInteroperability Organization (2003), http://www.ws-i.org/Profiles/Basic/2003-08/BasicProfile-1.0a.htm.

20. C. Lau and A. Ryman, “Developing XML Web Services withWebSphere Studio Application Developer,” IBM SystemsJournal 41, No. 2, 178–197 (2002).

21. See G. Booch, J. Rumbaugh, and I. Jacobson, The UnifiedModeling Language (UML): User Guide, Addison-Wesley,Upper Saddle River, NJ (2001); and OMG Unified ModelingLanguage Specification, v. 1.5, UML Revision Task Force, Ob-ject Management Group (March 2003).

22. T. Francis, E. Herness, R. High Jr, J. Knutson, K. Rochat,and C. Vignola, IBM WebSphere 5.0 Application Server, WroxPress, Birmingham, UK (2003).

23. H. Kushner, Developing J2EE Applications with IBM Web-Sphere Studio, IBM Press, Double Oak, TX (2003).

24. C. Cavaness, Programming Jakarta Struts, O�Reilly, Cam-bridge, MA (2003).

25. T. Husted, C. Dumoulin, G. Franciscus, D. Winterfeldt, andC. R. McClanahan, “Struts in Action: Building Web Applica-tions with the Leading Java Framework,” Manning, Greenwich,CT (2003).

26. M. Hall, More Servlets and JavaServer Pages, Prentice Hall,Upper Saddle River, NJ (2002).

27. Eclipse Modeling Framework, Eclipse Foundation, http://www.eclipse.org/emf/.

28. Eclipse, Omondo EclipseUML, http://www.omondo.com/index.jsp.

29. IBM and BEA Joint Specifications Overview, IBM Corpora-tion and BEA Corporation (2003), http://www.ibm.com/developerworks/java/library/j-commonj-sdowmt/.

Accepted for publication January 30, 2004.

Frank Budinsky IBM Software Group, IBM Toronto Lab, 8200Warden Ave, Markham, ON L6G 1C7, Canada ([email protected]). Mr. Budinsky is leader of the Eclipse Modeling Frame-work (EMF) project at Eclipse.org, co-architect and implemen-tor of the EMF framework, and EMF code generator. Frank hasbeen involved in the design of several frameworks and genera-tors, including the IBM/Taligent Compound Document Frame-work in VisualAge/C��, the Composed Business Object Builderin Component Broker, and a common framework for mappingtools in WebSphere Studio. He holds B.Sc. and M.Sc. degreesin electrical engineering from the University of Toronto and islead author of Eclipse Modeling Framework: A Developer�s Guide(Addison-Wesley, 2003).

George P. DeCandio IBM Software Group, Research TrianglePark Lab, 3039 Cornwallis Road RTP, NC 27709 ([email protected]). Mr. DeCandio is a Senior Technical Staff Memberand senior manager of Web and portal tooling for WebSphereStudio. He is one of the original architects and developers of Web-Sphere Studio. Most recently he and his teams have been involvedin defining the JavaServer Faces specification (JSR 127) and inarchitecting and developing the IBM tooling for this new tech-nology. He has also worked as a programmer and team lead onthe Visual Builder portion of IBM�s VisualAge products. He re-ceived a B.S. degree at the Rochester Institute of Technology in1989.

Ralph Earle IBM Software Group, Research Triangle Park Lab,3039 Cornwallis Road RTP, NC 27709 ([email protected]). Dr.Earle is a senior software engineer in the Rational Division, andmanager of User Assistance Development for WebSphere Stu-dio.From1998–2003,hewasthecontentarchitectforIBM�sVisual-Age and WebSphere Developer Domains. He is the co-authorof Enterprise Computing with Objects (Addison-Wesley, 1998).

Tim Francis IBM Software Group, IBM Toronto Lab, 8200 War-den Ave, Markham, ON L6G 1C7, Canada ([email protected]).Mr. Francis, who joined IBM in 1990, is a Senior Technical StaffMember and development manager of the WebSphere Tools teamin the IBM Toronto Lab. In 2001 he received an IBM Outstand-ing Technical Achievement Award for his work on WebSphereStudio. Tim is a senior member of the WebSphere ArchitectureBoard, a core member of the Rational Desktop Tools Develop-ment Council, and is a co-author of Professional IBM WebSphere5.0 Application Server (Wrox Press, 2003).

Julian Jones IBM Software Group, IBM Toronto Lab, 8200 War-den Ave, Markham, ON L6G 1C7, Canada ([email protected]).Dr. Jones, a Senior Technical Staff Member at the IBM TorontoLab, joined IBM in 1988 and worked on the usability of appli-cation development tools. He received a B.Sc. degree in occu-pational psychology from University of Wales in 1984 and a Ph.D.degree in human-computer interaction from the University ofYork in 1991. In 2002 he received an Outstanding TechnicalAchievement Award for his work on the Eclipse project.

Jin Li IBM Software Group, IBM Toronto Lab, 8200 Warden Ave,Markham, ON L6G 1C7, Canada ([email protected]). Mr. Li is aUser Experience lead for the IBM Rational tools products, with afocus on usability. He participated in many customer engagements,helping IBM customers build their business applications. He hasan M.Sc. degree in computer science from the University ofToronto, is a certified Sun Java developer, and is an IBM solu-tion developer.

Martin Nally IBM Software Group, Research Triangle Park Lab,3039 Cornwallis Road RTP, NC 27709 ([email protected]). Mr.Nally, who joined IBM in 1990, was lead architect for VisualAge/Smalltalk, one of the architects of VisualAge/Java, and the leadarchitect and development manager for WebSphere Studio. Hiscurrent title is Chief Architect for Rational Desktop Products.

Connie Nelin IBM Software Group, IBM Austin, 11501 BurnetRoad, Austin, Texas 78758 ([email protected]). Dr. Nelin is a Dis-tinguished Engineer in the Data Management Architecture andTechnology department. Since joining IBM in 1987 she hasworked on database application development support and tool-ing. She currently has overall responsibility for application de-velopment tooling strategy, architecture, and development for theDB2 family of products.

Valentina Popescu IBM Software Group, IBM Toronto Lab,8200 Warden Ave, Markham, ON L6G 1C7, Canada ([email protected]). Valentina is an advisory software developer, leadinga team that develops user interfaces for profiling, tracing, andlogging tools for the Eclipse platform. She is currently interestedinuser interface issues includinganalysis, correlation,andvisualiza-tion of problem determination data (such as profiling, tracing,andloggingdata).In2003shereceivedanIBMOutstandingTechni-cal Achievement Award for her work on autonomic computing.


Scott Rich IBM Software Group, Research Triangle Park Lab,3039 Cornwallis Road RTP, NC 27709 ([email protected]). Mr.Rich is a Senior Technical Staff Member, the development man-ager of WebSphere Studio Application Developer, and leader ofthe Rational Desktop Tools Development Council. He has beenwith IBM for 15 years, holding a number of technical positionsinvolving VisualAge/Smalltalk, VisualAge/Java, and WebSphereStudio.

Arthur G. Ryman IBM Software Group, IBM Toronto Lab, 8200Warden Ave, Markham, ON L6G 1C7, Canada ([email protected]). Dr. Ryman is a Senior Technical Staff Member anddevelopment manager in the Rational Desktop Products group.In 2001 he received an IBM Outstanding Technical AchievementAward for his work on Web services. Dr. Ryman is a member ofthe IBM Academy of Technology, an Adjunct Professor of Com-puter Science at York University, a senior member of the Insti-tute of Electrical and Electronic Engineers, and a member of theAssociation for Computing Machinery.

Timothy W. Wilson IBM Software Group, Research TrianglePark Lab, 3039 Cornwallis Road RTP, NC 27709 ([email protected]). Mr. Wilson is a Senior Technical Staff Member in theWebSphere Studio Tools group. He has been working with in-tegrated development environments and programming languagessince 1987. He is currently chief architect of Enterprise Gener-ation Language, a business language tool set based on Eclipse.In 2003 he received an Outstanding Technical Achievement awardfor the creation of the WebSphere Studio tool set surroundingthe Struts open-source framework.


websphere studio overview - pdfs.semanticscholar.org · websphere application server and its...

Documents