IBM Software Group Name Title Company Dynamic Development with the WebSphere Test Environment and WebSphere Rapid Deployment (Additional presentations,

IBM Software Group

Name

Title

Company

Dynamic Development with the

WebSphere Test Environmentand

WebSphere Rapid Deployment

(Additional presentations, tutorials and technical resources are available at)http://RationalCentral.com

IBM Software Group

Name

Title

Company

Based On … Rapid Application Development with

Rational Application Developer

RAD Top 10(Adaptable, Automated and Accelerated)

(Additional presentations, tutorials and technical resources are available at)http://RationalCentral.com

IBM Software Group |

© 2003 IBM Corporation3

Agenda

Overview of WebSphere Rapid Deploy (WRD)Goals of WRDDesign ElementsExternal Function

RAD In Action! (applies to RWD, RAD and RSA)

Using the WebSphere Test Environment (WTE)Compare WAS V5.1 to WAS V6.0Common Developer Usage Patterns

Initial Artifact CreationIterative Development “Day in the life of a developer”



The Goals of WebSphere Rapid Deploy

To simplify the development experience for WebSphere applications by:Increase the seamlessness of the iterative Build/Test cycleReduce or eliminate server restarts

During initial artifact creation (i.e. create Java, EJBs, Web Services, etc.)During iterative build scenarios (i.e. coding the logic in Java, etc.)

To simplify the deployment experience for WebSphere applications by:Automating the process of installing an application on WebSphereReducing the amount of information that must be configured manually on WAS (i.e. Datasources, etc.)Automating the process of activating incremental changes to an application on a running server (i.e. Add/Change code/configuration of an application)

IBM Software Group

Name

Title

Company

Dynamic Development

Understanding J2EE Packaging

and the implications to Dynamic Deployment



J2EE Enterprise Application Packaging

DD = Deployment Descriptor

EJB DD

Web DD

Client DD

HTML, GIF, etc.

Enterprise Bean

Client ClassServlet JSP

EJB Module .JAR file

Web Module

.WAR file

Client Module .JAR file

J2EE Application

.EAR file

JavaUtility

.jar file

App DD



Dynamic Development (Avoiding the “RESTART” Situations)

Two main stages in dynamic developmentCreating New ArtifactsChanging Existing Artifacts



End-2-End Application Scenario 1 2 3 4 5

Shows almost all J2EE building blocks in Action! (Java, EJB, Web Services, JMS, etc.)

DevDev

TimeTime

DevDev

TimeTime

Run Run TimeTimeRun Run TimeTime

IBM Software Group

Name

Title

Company

Dynamic Development

Hot Method Replace

Changing Code on-the-fly

(What Microsoft and BEA wish they could do)IBM’s better version of “Code and Continue”

IBM Software Group




Java code syntax checked as you type, incrementally compiled, persistent Undo cache (Local History)

Web pages are automatically hot-redeployed so you can immediately test changes

EJBs and Web Services can be automatically and manually hot-redeployed without restarting the servers

Changing code on-the-fly is supported with patented “Hot Method Replace” technology

UML Class Diagram Model Code Synchronization facilitates Model Driven Development

(1 2)

IBM Software Group

Name

Title

Company

Dynamic Development

Development Scenarios

JSF, SDO, Web Services and other Scenarios



Making it Real: RAD60+WAS60 Scenarios (From Online Help)Search On: “When the test server requires restarting”

When the test server requires restartingThe following subtopics describe different situations where you might need to restart the test server. The table at the end of this topic summarizes these situations.In the development environment, you may want to make changes to an application while it is running on a server, for example, if you are debugging an application on a server. In some cases you can dynamically reload modified code without restarting the server. You may or may not lose the state of the program, depending on the type of resource modified and the type of server.When an application is running on a server and you make changes to the code, the Java™ virtual machine will keep running the initial code until the code is reloaded automatically or manually. For example, you can modify JSP source and the changes will reload automatically on the server. For other resources, such as Java classes running on Tomcat 1, you must restart the server to ensure that the changes are recognized by the server.

Changes to server configurationIf you make any changes to the server or the server configuration while the server is running, for example, if you change the port number, you need to restart the server.

Changes to JSP, HTML, graphic and non-Java filesIf you make any changes to a JSP file, HTML file, GIF file, JPG file, or similar resource, and save the file while the server is running, you will only need to refresh the Web Browser for the server to recognize the change. The state of the program is not lost.

Changes to servlets and related classesIf you make any changes to a servlet and save the file while the server is running, the servlet will be reloaded if you have enabled reloading for that application. If you have enabled hot method replace for the server, the changes will take place automatically without needing to refresh the browser. If you have disabled hot method replace, the server recognizes the change when you refresh the Web Browser and the state of the application is not lost. Session data for that project will be lost but the state of other projects within the application will be unchanged. You can restart the project from the project's pop-up menu in the Navigator view. For WebSphere Application Server v5.x2, if you do not have reloading enabled, you must restart the EAR. If you are running Tomcat and do not have reloading enabled, you will need to restart the server. For WebSphere Application Server, the above rules also apply to any dependent classes or deployment descriptors of the Web project. If you modify the security or login configuration properties of the web.xml deployment descriptor running on WebSphere Application Server, you will need to restart the server. For Tomcat, a restart of the server is required for any of these changes.Tip: To disable reloading, open your Web project with the deployment descriptor editor. On the Extensions page, clear the Reloading enabled check box.

Adding servlets, classes, or JSP filesIf you add a new servlet, dependent class, or JSP file to a Web project while the server is running, the changes will be recognized if you have enabled reloading. If you have not enabled reloading, you will have to restart the EAR project if you are running WebSphere Application Server, or restart the server if you are running Tomcat. If you have enabled hot code replace in debug mode, changes to Java classes will be automatically recognized.

Changes to EJB resourcesFor WebSphere Application Server, the server will dynamically restart the EJB project in the EAR. If you have enabled hot code replace in debug mode, changes to Java classes will be automatically recognized.Important: Tomcat does not support EJB testing and publishing.

Changes to resources within an Enterprise Application project For WebSphere Application Server, if you change any resource within an Enterprise Application project while it is running on the server, the server will dynamically restart the EAR. Tomcat does not support Enterprise Application project testing and publishing.For WebSphere Application Server v6.0, if you change any resources within the WebSphere Enhanced EAR editor, you need to restart the server and re-publish the application. The WebSphere Enhanced EAR editor is the Deployment page in the Application Deployment Descriptor editor.



Making it Real: RAD60+WAS60 Scenarios (From Online Help)



Making it Real: RAD60+WAS60 Scenarios (From Online Help)



Summary AnalysisDynamic Development (Avoiding the “RESTART” Situations)


IBM Software Group




Web Presentation Servers

Web Application Servers

Directory and Security Servers

DataServers

Integration Servers

TransactionServersCustomers

PartnersSuppliers

Employees

Applications,Graphics,

HTML, Applets

XML, Web Services, Portlets, Servlets,

Java Server Faces/Pages

Services, EJBs & Process Flows

RelationalData

Applications, Transactions

and Processes

Mid

dle

ware

Connect

ors

Web

Serv

ices:

SO

AP

, W

SD

L,

UD

DI

Ed

ge

Se

rve

rs

End-2-End Development

ApplicationModeling

Web/PortalDevelopment

Java/J2EEDevelopment

XML Web ServicesDevelopment

Database AppDevelopment

Business ProcessSOA Integration

Cobol, CICS/IMS,4GL Development

Development Roles



Web Presentation Servers

Web Application Servers

Directory and Security Servers

DataServers

Integration Servers

TransactionServersCustomers

PartnersSuppliers

Employees

Applications,Graphics,

HTML, Applets

XML, Web Services, Portlets, Servlets,

Java Server Faces/Pages

Services, EJBs & Process Flows

RelationalData

Applications, Transactions

and Processes

Mid

dle

ware

Connect

ors

Web

Serv

ices:

SO

AP

, W

SD

L,

UD

DI

Ed

ge

Se

rve

rs

ApplicationModeling

Web/PortalDevelopment

Java/J2EEDevelopment

XML Web ServicesDevelopment

Database AppDevelopment

Business ProcessSOA Integration

Cobol, CICS/IMS,4GL Development

Development Roles

JavaServer Faces (JSF) Tools

JavaServer Faces (JSF) Simplifies J2EE Development



JSF Simplifies J2EE, Web Services, Database and Portal Development

Database development drag-n-drop ease-of-use 1 2 3

Web Services development drag-n-drop ease-of-use 1 2 3a 3b

Portals drag-n-drop ease-of-use 1 2



Temperature Web Service Scenario (Internet Web Service) 1

http://uddi.xmethods.net/inquire and http://www.xmethods.org drag-n-drop ease-of-use



Dynamic Development – JSF + Web Service(www.xmethods.org Temperature Web Service)




Dynamic Development – JSF + Web Service(www.xmethods.org Temperature Web Service)




Weather Web Service Scenario (Internet MS.NET Web Service) 1

www.serviceobjects.com (WSDL: http://ws2.serviceobjects.net/fw/FastWeather.asmx?WSDL)



Dynamic Development – JSF + Managed Bean + Web Service(www.serviceobjects.com FastWeather Web Service)




TransferFunds EJB Web Service (Local in RAD Workspace) 1 (extra: 1 2 3 4)

http://localhost:9080/BankEJBWebServices/wsdl/com/myco/bank/ejb/AccountMgr.wsdl



Transfer Funds ScenarioLogon page and binding customer number into user session/state

Main Menu page with welcome greeting using user session & Relational Record SDO

Account Balances page using Relational Record SDO and user session

Transfer Funds page using Web Service and SDO account numbers combo box

Web site navigation and common look-and-feel using Web Site Designer & Templates

Rich thin client tab panel view for account summary consolidation

Portal Portlet development, testing, customization and Click-to-Action integration



Dynamic Development – JSF + EJB Web Service(http://localhost:9080/BankEJBWebServices/wsdl/com/myco/bank/ejb/AccountMgr.wsdl)




Banking Application ScenarioBuilding a J2EE application



JavaServer Faces Ease-of-UseLogon page and binding customer number into user session/state









Demos: JavaServer Faces Ease-of-Use 1

Logon page and binding customer number into user session/state









JavaServer Faces Ease-of-Use 2 3




















JavaServer Faces Ease-of-Use 6 7 8 9 10 11










JavaServer Faces Ease-of-Use 12










JavaServer Faces Ease-of-Use 13










Richer Thin Clients

Drag-n-drop development of J2EE applications (No Coding Required)

Spreadsheet Spreadsheet ControlControl

Spreadsheet Spreadsheet ControlControlTabbed Tabbed

PanelsPanelsTabbed Tabbed PanelsPanels

Web Web ServiceService

Web Web ServiceService

Graphing Graphing ControlsControlsGraphing Graphing ControlsControls

Database Database QueryQuery

Database Database QueryQuery













Dynamic Development – J2EE in a REAL-WORLD-APP




Summary - The Goals of WebSphere Rapid Deploy

To simplify the development experience for WebSphere applications by:Less Server and Application Restarts

To simplify the deployment experience for WebSphere applications by:Less Server and Application Restarts

To reduce the number of artifacts created in the first placeFor Instance: Annotated EJBs = less code with generationWhen EJB is deployed into apps server, supporting classes/interfaces are generated (i.e. helpers, stubs, skeletons, etc.)

IBM Software Group

Name

Title

Company

BACKUP CHARTS

BACKUP CHARTS



WebSphere (WAS) Modes of Operation for TestingStart Server (non-debug)

Web Projects (a.k.a. WAR – Web Modules – Web Apps)Changes to existing content (Java, JSPs, etc.)

V5.x and V6.x Dynamically refresh running application (no Server or Project EAR restart)

New Web Apps and configuration file changes (i.e. Struts, JSF config files)V5.x Server restart for new web apps, Project EAR restart for configuration file changes

V6.x Dynamic (no server or ear restart)

EJB Projects (a.k.a. EJB JAR)Changes to existing EJBs and New Session EJBs

V5.x Project EAR restart (no server restart)


New CMP EJBs (due to datasources)V5.x Server restart


Java ClassesInside Web Project: Dynamic for V5/V6Outside Web Project: V5 ear restart; V6 Dynamic

Web Services: New or changes to existing: V5 ear restart; V6 Dynamic

Debug Server (“Start in debug” with Hot Method Replace - HMR box checked)New artifacts same as aboveChanges to existing Java coding artifacts are “more” dynamic in V5/V6, without Smart [auto] PublishingState is retained (i.e. no need to logoff/logon and re-navigate application being tested)



Development ArtifactsProjects (J2EE Modules – EAR, WAR, JAR)Java Artifacts

Java Classes in a Java Project or Web ProjectEJBs – generated classes & interfacesWeb Services – Implementation Classes (JavaBeans, EJBs)SDO – JSP Java contents, Web Service backend, JSP Scripting)

Non-Java ArtifactsConfiguration files created with new projects

Deployment Descriptors (application.xml, web.xml, ejb.xml)JSF faces-config.xmlStruts struts-config.xml

Configuration files created with new artifactsEJBsWeb Services – webservice.xml; RPC related files; Client filesSDO – XML files describing Records and Record ListsJSF – faces-config.xml updated when add new

Faces JSPs

Navigation Rules

Managed Beans to pages



Development Scenarios

Creating New ArtifactsCreate a new application

EARs, WARs, EJB JARs and Java JARs

Create new application artifactsJava classes, EJBs, Web Services, web pages, web apps like JSF/Struts (MVC), SDOs

Modifying Existing ArtifactsJavaEJBWeb ServicesWeb PagesWeb App Content

HTML, JSP, Java, JSF, etc.

SDOsetc…



The Goals of WebSphere Rapid Deploy

To simplify the development experience for WebSphere applications by:

Reducing the number of artifacts the developer must produce and maintainReducing the number of concepts and technologies the developer must understandSupporting the development model and tools the developer desires to use

To simplify the deployment experience for WebSphere applications by:

Automating the process of installing an application on WebSphereReducing the amount of information that must be collected by the installer to install the applicationAutomating the process of activating incremental changes to an application on a running server



Design ElementsDeployment improvements consist of two distinct components:

The most visible aspect is implemented as a collection of eclipse pluginsEclipse provides basic structures that are exploited (builders, etc)Studio extends this support to define J2EE and server side featuresWRD adds additional builders and WebSphere specific functionality

As an Eclipse based implementation, there is completely seamless integration with the Studio development tools

WRD also provides a “headless” mode that allows directory monitoring, supporting “Notepad” style development scenarios

Several features are also being implemented in the V6.0 WebSphere Application Server to improve the deployment scenarios

Existing server capabilities exploited to deploy and control applicationsNew server function also added

Support for fine grained application updates, Enhanced EAR support



WRD Focus Areas for V6.0 - overview

Annotation-based ProgrammingAllow the developer to insert metadata into the source code of the applicationThe developer creates and maintains a single artifact, other artifacts are generated

Change Triggered ProcessingDrive processing operations based on the detection of change in artifacts of the applicationUsed to generate new application artifacts from existing ones

Deployment AutomationEnable automatic installation of applications and modules onto a running WebSphere ServerSupport both local and remote servers

Introduction of an “Enhanced EAR”The Application (EAR) file will contain server configuration and deployment information

Support for Fine Grained Application ChangesMinimal application impact - affect the application in the minimum way possible to reflect the desired change



Availability of WebSphere Rapid Deploy

WRD will be available in several forms:The most basic (non-UI) support is included as part of the application serverThe UI based support is part of the AST, which is a separately installable part of the application serverThe complete support is fully integrated as part of the Rational Studio family



Annotations

Represented as Javadoc tags, in comments, within Java source code

Eventually will move to (or add) JSR 175 based annotations (J2SE 1.5)

Available at four scope levelsClass, Method, Field, Package

Existing XDoclet defined tag syntax will be used where it exists

WRD defines additional tags for elements of the WebSphere Programming Model

WRD provides automatic Java editor content assistNew tags can be introduced through Eclipse pluginsThis means annotation support can be exploited in other tools



Annotations Example

package com.example.wrd;

/**

* @ejb.session

* name="Hello" type="Stateless" view-type="remote" jndi-name="HelloBean"

*/

public class Hello

{

/**

* @ejb.interface-method view-type=remote

*/

public String hello(String name)

{

return "Hello: " + name;

}

}



Change Triggered Processing

The WRD infrastructure is implemented as Eclipse BuildersBuilders use resource change notifications to provide detailed information about the changes that have taken place

Add/Change/DeleteWhat Type of Change (CONTENT, MOVED, REPLACED)

Annotation processing, deployment code generation, builds and application installation are all triggered automatically as requiredEclipse 3.0 resource deltas are generated automatically as changes are made in the file system

Uses OS specific mechanisms where possibleThis provides mechanism for non-Eclipse editors to initiate the processing (in “headless” mode)



Other aspects of WRD

Deployment AutomationApplications can be installed from the Eclipse environment, into a running Application Server instance

Local and Remote servers are supportedBasically automates the application install wizard

Enhanced EAR FileSupport an application that includes ALL of the information needed to run the application on a server

J2EE EAR/Module, Bindings Information, Deployment.xml settings, Resource definitions, Per application security settings, …Information is respected by the application installation process

Fine-grained Application UpdateAbility to introduce small delta-changes to installed applications Ability to add modules to installed applications



Free Form Applications

Construct a single J2EE application on the fly, piece-by-piece, from a free-form directory

Can be used for simple “Notepad” based development

A flat “Hot Deploy” directory is used as the applicationA single EAR application is created from the directoryAnnotation processing and artifact generation produces artifacts that are not directly maintained by the developerArtifacts are copied into their correct location in the J2EE application

Application is deployed and installed on the server automaticallyOnly available in command line (non-UI) mode for V6

IBM Software Group

WebSphere Test Environment 6.0



WebSphere Studio 5.x Test Environment

Studio 5.x provides two types of test environmentsLocal Unit Test: A complete instance of WAS is included with StudioRemote Unit Test: A real install of WAS, may be on local machine

Eclipse (SWT based) server configuration editors allow the configuration to viewed and changed

The complete configuration is saved in the workspace

On “Run on Server” action:The complete server configuration is copied (overwriting any existing configuration)The application(s) to run are published (locally, or via FTP)The server process is started (locally or remotely)

The admin console can be used to view/modify the configuration

Changes are made into the workspace, but the user must refresh eclipse view



Problems with the 5.x test environment

Not all WebSphere platforms are supported (Solaris, …)No mechanism to re-use a configuration from the test environment, on a real serverNo mechanism to test an application on a staging server (single image shared by multiple users)

Implies no support for deploying to a production server either (SMB users, etc)

Poor performance for unit test users (who have to wait for the server to start up, just to test their application)



Key Scenarios for the V6.0 Test Environment

Local test server used by a single developerLocal test server used by a group of developers who want to shared a common configuration for that serverRemote test server used by a single developer (“Test on my other box”)Remote shared team server used by a group of developers, each developer getting their own server instanceRemote shared team server used by a group of developers where the actual server instance is sharedTransition from a local test server to a staging server to …



Overview of the V6 (WRD based) test environment

A single solution for both remote and local test servers (with local optimizations)

The Studio install will also run a silent install of the application serverConfigured (by default) to start as a service on system startup

When the user wants to run an application under development, Studio will prompt for the hostname & Soap (JMX) port of the test machine

The Studio project will use the WRD mechanics to publish the application The application is always installed, ensuring correct runtime semanticsOptimizations will apply for localhost (such as eliminating the binary copy of the app)

The server configuration is not in the development environment, an enhanced EAR is used

The Studio “Server Configuration” editors become “Enhanced EAR” editors

The application is properly installed, with configuration details read from the EAR

The server is already running, the app is started, and can be tested



Benefits of the WRD based test environment

Support will be available for deploying to all WebSphere platformsThe WebSphere application server is “installed”, so all extensions should workThe enhanced EAR provides the configuration for the application

The same EAR (and configuration) can be used for multiple test environments

Because the application is properly installed into the application server, a server shared by multiple users (i.e., a staging server) can be used

By extension, the development environment can also be used to deploy applications to a production server

The server is always running, so developers do not need to wait for the server process to start

This offers significantly improved usability and productivity

The fine grained app update support should reduce (or eliminate) the number of required server restarts, moving instead to application restarts (or less)



Demo



( And please complete your feedback forms. Thanks! )

Documents

IBM Software Group Name Title Company Dynamic Development with the WebSphere Test Environment and WebSphere Rapid Deployment (Additional presentations,