Name Title Company

Dynamic Development with theWebSphere Test EnvironmentandWebSphere Rapid Deployment(Additional presentations, tutorials and technical resources are available at)http://RationalCentral.com Name Title Company

 Based On … Rapid Application Development withRational Application DeveloperRAD Top 10(Adaptable, Automated and Accelerated)(Additional presentations, tutorials and technical resources are available at)http://RationalCentral.com Name Title Company

Agenda • Overview of WebSphere Rapid Deploy (WRD) • Goals of WRD • Design Elements • External Function • RAD In Action! (applies to RWD, RAD and RSA)Using the WebSphere Test Environment (WTE) • Compare WAS V5.1 to WAS V6.0 • Common Developer Usage Patterns • InitialArtifactCreation • IterativeDevelopment “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 cycle • Reduce 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 WebSphere • Reducing 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)

Dynamic Development Understanding J2EE Packagingand the implications to Dynamic Deployment Name Title Company

J2EE Application .EAR file Web Java Utility .jar file EJB Client Module Module Module .WAR file .JAR file .JAR file Client HTML, Web EJB Enterprise Client Servlet JSP Class GIF, etc. App DD DD Bean DD DD J2EE Enterprise Application Packaging DD = Deployment Descriptor

Dynamic Development (Avoiding the “RESTART” Situations) • Two main stages in dynamic development • Creating New Artifacts • Changing Existing Artifacts

Demos End-2-End Application Scenario 12345 • Shows almost all J2EE building blocks in Action! (Java, EJB, Web Services, JMS, etc.) Dev Time Run Time

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” Name Title Company

Demo 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 (12)

Dynamic Development Development ScenariosJSF, SDO, Web Services and other Scenarios Name Title Company

Making it Real: RAD60+WAS60 Scenarios (From Online Help) Search On: “When the test server requires restarting” When the test server requires restarting The 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 Tomcat1, you must restart the server to ensure that the changes are recognized by the server. Changes to server configuration If 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 files If 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 classes If 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 files If 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 resources For 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)

Summary AnalysisDynamic Development (Avoiding the “RESTART” Situations) • Two main stages in dynamic development • Creating New Artifacts • Changing Existing Artifacts

Applications, Transactions and Processes Web Services: SOAP, WSDL, UDDI Middleware Connectors Relational Data Services, EJBs & Process Flows XML, Web Services, Portlets, Servlets, Java Server Faces/Pages Applications, Graphics, HTML, Applets Development Roles Web/Portal Development Java/J2EE Development XML Web Services Development Database App Development Business Process SOA Integration Cobol, CICS/IMS, 4GL Development Application Modeling End-2-End Development Directory and Security Servers Integration Servers TransactionServers Customers Partners Suppliers Employees Edge Servers Web Presentation Servers Web Application Servers DataServers

Applications, Transactions and Processes Web Services: SOAP, WSDL, UDDI Middleware Connectors Relational Data Services, EJBs & Process Flows XML, Web Services, Portlets, Servlets, Java Server Faces/Pages Applications, Graphics, HTML, Applets Development Roles Web/Portal Development Java/J2EE Development XML Web Services Development Database App Development Business Process SOA Integration Cobol, CICS/IMS, 4GL Development Application Modeling JavaServer Faces (JSF) Tools Directory and Security Servers Integration Servers TransactionServers Customers Partners Suppliers Employees Edge Servers Web Presentation Servers Web Application Servers DataServers JavaServer Faces (JSF) Simplifies J2EE Development

JSF Simplifies J2EE, Web Services, Database and Portal Development Demos • Database development drag-n-drop ease-of-use 123 • Web Services development drag-n-drop ease-of-use 123a3b • Portals drag-n-drop ease-of-use 12

Demo 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) • Two main stages in dynamic development • Creating New Artifacts • Changing Existing Artifacts

Demo 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) • Two main stages in dynamic development • Creating New Artifacts • Changing Existing Artifacts

Demos TransferFunds EJB Web Service (Local in RAD Workspace)1(extra: 1234) • http://localhost:9080/BankEJBWebServices/wsdl/com/myco/bank/ejb/AccountMgr.wsdl

Transfer Funds Scenario • Logon 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) • Two main stages in dynamic development • Creating New Artifacts • Changing Existing Artifacts

Banking Application Scenario • Building a J2EE application

JavaServer Faces Ease-of-Use • Logon 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

Demo Demos: JavaServer Faces Ease-of-Use 1 • Logon 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

JavaServer Faces Ease-of-Use 23 • Logon 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

Richer Thin Clients • Drag-n-drop development of J2EE applications (No Coding Required) Spreadsheet Control Tabbed Panels Database Query Web Service Graphing Controls

JavaServer Faces Ease-of-Use12 • Logon 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 – J2EE in a REAL-WORLD-APP • Two main stages in dynamic development • Creating New Artifacts • Changing Existing Artifacts My Best Guess (Not Yet Documented)

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 place • For Instance: Annotated EJBs = less code with generation • When EJB is deployed into apps server, supporting classes/interfaces are generated (i.e. helpers, stubs, skeletons, etc.)

BACKUP CHARTS BACKUP CHARTS  Name Title Company

WebSphere (WAS) Modes of Operation for Testing • Start 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) • V6.x Dynamic (no server or ear restart) • New CMP EJBs (due to datasources) • V5.x Server restart • V6.x Dynamic (no server or ear restart) • Java Classes • Inside Web Project: Dynamic for V5/V6 • Outside 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 above • Changes to existing Java coding artifacts are “more” dynamic in V5/V6, without Smart [auto] Publishing • State is retained (i.e. no need to logoff/logon and re-navigate application being tested)

Development Artifacts • Projects (J2EE Modules – EAR, WAR, JAR) • Java Artifacts • Java Classes in a Java Project or Web Project • EJBs – generated classes & interfaces • Web Services – Implementation Classes (JavaBeans, EJBs) • SDO – • JSP Java contents, Web Service backend, JSP Scripting) • Non-Java Artifacts • Configuration files created with new projects • Deployment Descriptors (application.xml, web.xml, ejb.xml) • JSF faces-config.xml • Struts struts-config.xml • Configuration files created with new artifacts • EJBs • Web Services – webservice.xml; RPC related files; Client files • SDO – XML files describing Records and Record Lists • JSF – faces-config.xml updated when add new • Faces JSPs • Navigation Rules • Managed Beans to pages

Development Scenarios • Creating New Artifacts • Create a new application • EARs, WARs, EJB JARs and Java JARs • Create new application artifacts • Java classes, EJBs, Web Services, web pages, web apps like JSF/Struts (MVC), SDOs • Modifying Existing Artifacts • Java • EJB • Web Services • Web Pages • Web App Content • HTML, JSP, Java, JSF, etc. • SDOs • etc…

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 maintain • Reducing the number of concepts and technologies the developer must understand • Supporting 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 WebSphere • Reducing the amount of information that must be collected by the installer to install the application • Automating the process of activating incremental changes to an application on a running server

Design Elements Deployment improvements consist of two distinct components: • The most visible aspect is implemented as a collection of eclipse plugins • Eclipse provides basic structures that are exploited (builders, etc) • Studio extends this support to define J2EE and server side features • WRD 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 applications • New server function also added • Support for fine grained application updates, Enhanced EAR support

WRD Focus Areas for V6.0 - overview • Annotation-based Programming • Allow the developer to insert metadata into the source code of the application • The developer creates and maintains a single artifact, other artifacts are generated • Change Triggered Processing • Drive processing operations based on the detection of change in artifacts of the application • Used to generate new application artifacts from existing ones • Deployment Automation • Enable automatic installation of applications and modules onto a running WebSphere Server • Support 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 Changes • Minimal 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 server • The UI based support is part of the AST, which is a separately installable part of the application server • The 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 levels • Class, 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 assist • New tags can be introduced through Eclipse plugins • This 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; } }

Name Title Company