410 likes | 422 Views
WAS for z/OS V5: Assembling and Deploying a J2EE Application. After completing this unit, you should be able to: Plan process to install a new J2EE application Develop a suitable naming convention for deployment Use the Application Services Toolkit (ASTK) to assemble a new J2EE application
E N D
After completing this unit, you should be able to: Plan process to install a new J2EE application Develop a suitable naming convention for deployment Use the Application Services Toolkit (ASTK) to assemble a new J2EE application Use administration tool to deploy the application Plan and execute the "non-GUI" tasks required to complete application setup Test the new application using a local client Describe migration issues between JDK 1.3.1 and JDK 1.4.1 Unit Objectives
Many Pieces • WAS servers are like IMS or CICS regions • Tailored PROCs for controller region and servant region • Tailored environmental variables for each server • Tailored environmental variables for each instance of a server • Tailored libraries for code • Servers may be self-contained or dependent on other servers • Security • Regions have userids associated with them • Users are allowed access to servers and objects within • WLM • Classification of regions and work within • Application environments • Back-end connections • DBRMs • Comm area mappings and objects
You've Got to Have a Template • Server names • Controller Region PROC names • Servant Region PROC names • Application Environment names • Cluster names • Security • User/group/UID/GID • Controller regions • Servant regions • Unauthenticated users • PROCs • Environmental files • Library names • Other • Log names • HFS directory structures and file systems This is just my day job.. not my life!
An Example: Intergalactic Naming System • Everything determined by 4 characters: XXXX (and Y of course) • Naming convention can be extended to: • Server-specific log streams • DataSources • DB2 collections/plans • File systems, and so on Here are the userids/UIDs, change as required. WSXXXXC 1100 WSXXXXS 1101 WSXXXXD 1102 WSXXXXI 1103 Here are the groups/GIDS, change as required. WSXXXXR 1001 WSXXXXP 1002 Appserver short name = WSXXXX APPLENV name = WSXXXX Userid for controller region = WSXXXXC PROC for control region = WSXXXXC Userid for servant region = WSXXXXS PROC for servant region = WSXXXXS Group id for servant region = WSXXXXR Default remote userid = WSXXXXI Default local userid = WSXXXXD Group ID for default IDs = WSXXXXP
Set up New Server Procedures Application Server CR - Start Procedures WSXXXXC //WSXXXXC PROC ENV=,PARMS=' ',Z=WSXXXXCZ // SET ROOT='/WAS510/config' //BBOCTL EXEC PGM=BBOCTL,COND=(8,EQ),REGION=0M,TIME=MAXIMUM, // PARM='TRAP(ON,NOSPIE),ENVAR("_EDC_UMASK_DFLT=007") / &PARMS.' //BBOENV DD PATH='&ROOT/&ENV/was.env' // INCLUDE MEMBER=&Z WSXXXXCZ //* Output DDs //CEEDUMP DD SYSOUT=*,SPIN=UNALLOC,FREE=CLOSE //SYSOUT DD SYSOUT=*,SPIN=UNALLOC,FREE=CLOSE //SYSPRINT DD SYSOUT=*,SPIN=UNALLOC,FREE=CLOSE Application Server SR - Start Procedures WSXXXXS //WSXXXXS PROC ENV=CLT1.NDT1.WSXXXX,Z=WSXXXXSZ // SET ROOT='/WASV510/config' //BBOSR EXEC PGM=BBOSR,REGION=0M,TIME=NOLIMIT, // PARM='TRAP(ON,NOSPIE),ENVAR("_EDC_UMASK_DFLT=007") /' //BBOENV DD PATH='&ROOT/&ENV/was.env' // INCLUDE MEMBER=&Z WSXXXXSZ //* Output DDs //CEEDUMP DD SYSOUT=*,SPIN=UNALLOC,FREE=CLOSE //SYSOUT DD SYSOUT=*,SPIN=UNALLOC,FREE=CLOSE //SYSPRINT DD SYSOUT=*,SPIN=UNALLOC,FREE=CLOSE
Time to "Get Real" Now let's see if this thing really works? Just because the IVT works doesn't mean mere mortals can do it.
Deploying an Application • Several distinct phases to deploying an application • Creating the J2EE application component packages • jar files containing EJBs • war files containing Servlets, JSPs • jar files containing ancillary files • Assembling the application to create an *.ear file • Can be done with development tool such as WSAD or using the Application Services Toolkit (ASTK) • in this step defining/resolving dependencies • Installation of the application via V5 Administration tool • Several steps in each phase
Step 0 • Decide on the naming convention • Understand the application's data requirements • Understand server/application requirements • Understand the security requirements • Understand the WebSphere V5 eccentricities relative to your own installation’s eccentricities • And so on Provide your application developers a check list of information they must provide to deploy an application.
Step 1 • Acquire a workstation with: • A development tool. IBM options • WebSphere Studio Application Developer V5.1.1 (minimum) • WebSphere Studio Application Developer Integration Edition V5.1 (adds WBISF support) • Java 2 SDK V1.4 • Application Services Toolkit V5.1 • Internet Explorer browser for Admin tool • Applications can be developed and assembled on WebSphere Studio • Supporting jar files available • Easiest deployment
Step 2 • Export all application components from WebSphere Studio • Application EJB jar files • Application client EJB jar files • Client bindings jar files • Utility jar files • Servlet classes • Decide the packaging structure • Which classes go in which jar files • Which jar files should be in which ear files • Need assistance of developers
Step 3 • Use WSAD or ASTK to create the application .ear file • Packages components (jars, wars, and connectors) together • Can set attributes on components used by WebSphere containers at run time • Set Transaction attributes • Set Environment variables • Set Resources • Set EJB refs • Set Security refs • And so on • Attributes from assembly stored in deployment descriptor files
J2EE Application Develop, Assemble, and Deploy Win2K/XP z/OS WSAD V5 "develop" Server Instance DD RAR App DD DD CR SR WAR JAR "load" 5 1 2 config HFS temporary HFS ASTK V5 RAR JAR EAR DD DD 3 DD WAR 2 EAR "assemble" "copy" "deploy" WebSphere V5 Administration Application Admin Client wsadmin.sh 4 4 "deploy"
Application Server Toolkit (ASTK) • The Application Server Toolkit is a bundle of tools integrated around the Eclipse platform • Eclipse Workbench - Manages perspectives, views, and editors • Assembly Toolkit - packages J2EE applications for deployment • Debug Component - provides interactive debug of J2EE apps, application profiling, and log analysis tools • For our purposes we need the Assembly Toolkit • GUI for assembling J2EE application Modules (such as EJB jars, webapp war files, RARs, and client jars) • Final application can then be exported into an *.ear file • The tool also enables modification of deployment information for each J2EE module which customizes it for inclusion in a specific application • Linkages between components • Security roles • Transaction attributes • Resource references • Deployment information stored in Deployment Descriptors
ASTK Workbench Concepts J2EE hierarchy J2EE "perspective" ASTK project list Application Server Toolkit EAR project J2EE Application .EAR file App DD DD = Deployment Descriptor EJB project Web project Client project Client Module .JAR file Web Module .WAR file EJB Module .JAR file Web DD Servlets EJB DD Client DD Client class Enterprise Bean JSPs HTML, GIF, etc. • Project for each major J2EE component (EJB jar, webapp war file, client jar) • ASTK perspectives combines set of views and editors for specific environment
Assembly Toolkit Functions Function Description Create new application Create new Enterprise Application (EAR) project on the ASTK project list Import existing EAR file Load J2EE components of an existing application into an existing EAR project Import application components Load contents of a J2EE module (war, EJB jar, client jar, or connector) into an existing application. Modify deployment descriptors Use deployment descriptor editor to modify deployment attributes of J2EE components Validate deployment descriptors Check application deployment descriptors for consistency Set runtime bindings Link J2EE component remote references to the correct target component Compile java code Create Java class files (bytecode) from java source statements Build J2EE modules Create a J2EE module project and import the java components of the module Export EAR files Create application *.ear file ready for deployment to a WebSphere application server Export J2EE modules Create *.jar or *.war module file from contents of a J2EE module project Convert EAR files Convert EAR file format from J2EE 1.2 to J2EE 1.3 Map EJB fields to database fields work interactively with existing database to define J2EE components that use JDBC or SQL access
ASTK from the Driver’s Seat Editor Window J2EE perspective Navigator Window Task Window
Flow • Create Application • Import components exported from WebSphere Studio or other tooling • EJB .jar files • Web app .war files • RAR (Resource Adapter Archive) files • J2EE client jar files • Include any extra files (non-jar and non-war) needed by the application • Resolve application deployment dependencies • Resources • Security • And so on • Verify the application code • Create the deployable .ear file • Contains application and EJB xml descriptor files
Hints, Tips, and Gotchas • ASTK will try to resolve needed classes during validation • WebSphere V5 for z/OS does not include jars for: • Associations, access beans, finderhelpers, record, persistence builder, eab, ccf, and so on • Bring these jars with you in your deployment package or place them into the WAS runtime classpath • Assembly Toolkit is shipped on a CD together with the WebSphere for z/OS product tapes • Insert the CD and double click on "setup.exe" to start the install • Java JDK V1.4.1 is integrated with product • Have an option as to whether to install IBM Agent Controller • When you first start the product, think about where to put default workspace data
Step 4 • Use WebSphere admin tool to install the application • Define new application server • Requires knowledge of runtime and application requirements. • or • Can use existing server • Define data sources and data source instances • Import .ear file • Provide JNDI names, resolve references • Perform non-GUI tasks • Start the application from the administration tool
Server Decisions (1 of 2) • CICS Model • Multiple clients requests being serviced in each servant region • Thread safe applications preferred • IMS Model • One client active in a servant region at a time • Security preferences • May require SSL implementation. • May require Kerberos • Server region replication • More than one servant region for a controller region? • Cluster multiple application servers on one or more z/OS images? • Driven by type of object and/or access to underlying data
Server Decisions (2 of 2) • Environment variables • All changes to the server environment variables should be made through the Admin tool • Refer to "Install & Customize" manual or the WebSphere InfoCenter for details on which variables are appropriate for your server. • Variables will be "inherited" from Cell --> Node --> Server Instance
Step 5 • Create server procedures • Update WLM • Application Environments (only if system does not support dynamic ApplEnvs) • Workload classification • Create logstream (optional) • Create security profiles • RACF (SSL, Kerberos) • Update Automation • Transfer jar files not residing in .ear file to target location in WAS HFS for inclusion on the classpath
WLM • All servant regions should be classified so they can initialize quickly. • Update STC classification to include all controller and servant regions. • Classify work in a server as you see fit. • Only applies to requests which have yet to be classified by the WAS runtime, subsequent object invocations inherit the enclave. • Use server name to classify primarily, use userid secondarily. • Or inherit the enclave from someone who has reasonable classification rules (such as IBM HTTP server).
Security for Your WebSphere Server • RACF Classes • STARTED • Associate user/group/UID/GID with controller and servant regions • USER/GROUP - needed for above • LOGSTRM (logstream_name) • Controller and servant regions require update access to logstream • Ops and application owners need read access to logstream • SERVER (CB.server_instance_name.server_generic_name) • Allow designated servant regions to connect to their control region. • CBIND (CB.generic_name) • Allows access to objects in a WebSphere server • CBIND (CB.BIND.generic_name) • Allows access to a WebSphere server • Controller regions need CONTROL access - "asserted ID" • Don't forget the administrator • EJBROLEs, and so on • Create a REXX exec similar to BBOCBRAJ
Security... • Client Authentication • Unauthenticated • Userid/Password • Passtickets • And so on • DB2 permissions • Package use • "SELECT,..." permission on the data base • Don't forget the stateful session bean DB • Secondary auth-id support requires DB2 external security implementation. • Transaction manager access • OTMA/EXCI • Transaction access
Step 6 • DB2 backed objects • Define database (if new) • Bind DBRMs if SQLJ • Grant authority for server to • Access data in DB2 tables • Use the plan • IMS backed objects • OTMA access • CICS • EXCI access
Step 7 • Start Application Server Control Region • As applications start up, they will register their component names in the dynamic namespace
Starting an EJB Application 5 client sends an object request WLM Application Environment starts servant A/S 6 wsbasec wsbases Control Region Servant Region WLM Queue z/OS console 9 business data 9 10 container proclib EJB Instance 4 "s wsbas1c" J2EE connector 8 HFS 1 EAR 2 3 JAR • ear files • application config • resource config ASTK V5.1 Admin Client WSAD V5
Step 8 • Deploy client • Test client
Step 9 • Celebrate!
Some Issues about JDK V1.4.1 xyz.class WebSphere for z/OS V5.0 JDK 1.3.1 Compiler (JDK 1.3.1) 1.3.1 ORB javac xyz.java JVM SOURCE WebSphere for z/OS V5.1 xyz.class javac JDK 1.4.1 Compiler (JDK 1.4.1) 1.4.1 ORB JVM • Class files compiled by JDK 1.4.1 for z/OS might not be compatible with JDK 1.3.1 for z/OS ORB • Force JDK 1.4.1 compiler to produce 1.3.1 compatible files with "-target" javac -target 1.3 -bootclasspath SDK1.3\lib\classes.zip • -extdirs "" xyz.java • In the Assembly Toolkit, disable option "Server Targetting"
Having completed this unit, you should be able to: Plan process to install a new J2EE application Develop a suitable naming convention for deployment Use the Application Services Toolkit (ASTK) to assemble a new J2EE application Use administration tool to deploy the application Plan and execute the "non-GUI" tasks required to complete application setup Test the new application using a local client Describe migration issues between JDK 1.3.1 and JDK 1.4.1 Unit Summary