WIXLIB

Schematic Diagram of WebSphereApplication ServerHere’s a semi-conceptual view of what WebSphere Application Server is:The real product is of course far more sophisticated than this but this gets the key points acrossJava Runtime2Java Virtual MachineWeb Container*EJB Container*1. Server is Started On z/OS that’s done with a START command (more later) This native code is what establishes the lower-level“plumbing” and allows for the invocation of the Javaenvironment2. Java Runtime Established, including JVM4 Once the native base is ready, it establishes Java runtimeenvironment and launches the JVM3. WebSphere Java Components Loaded into JVM3Implementation of all the openstandard specifications forapplication server framework With the JVM launched, WebSphere Application Servercan now load the Java components that make up the JavaEE environment This is the “framework” we mentioned earlier This is why WebSphere Application Server is more thanjust a JVM.4. Your Applications Loaded and StartedPlatform native code1Lower-level “plumbing” and interactionwith native platform services* “Containers” are just logical software constructs inside theJVM that provide services specific to the type of applicationthat runs in them. “Web Container” is for web applications;“EJB Container” is for EJBs. If they’re deployed in the server and configured to startautomatically, WebSphere will do that for you.Now we’re ready to see howthis is implemented on z/OSHow it’s implemented 18

How It’s Implemented on z/OSThe developers of WebSphere on z/OS chose to implement the functionof WebSphere Application Server as a series of z/OS started tasks:LPAR ACellDaemonCRDMGRCRNode AgentCRIt provides an implementation very familiar to z/OSsystem administratorsSRAppServerCRSRIt maps very well to z/OS utilities such asautomation and monitoringBut what are those things in the picture? The small boxes inside the curved boxes CR and SRNodeAppServerCR DMGR? Node Agent? Node? Cell?SRWe’ll start with the servers where your applications run:AppServerCRSRThis icon will be used throughout this presentation torepresent the “application server,” which is whereapplications run. The small boxes inside are a designunique to z/OSPeek inside CR/SR 19

A Peek Inside the Application ServerArchitectureWe see that inside our little curved-box picture of the Application Server residestwo or more address spaces as well as integration with zWLM:START command(MVS or Admin Console)JCLzWLM Manages starting of SRs Manages stopping of SRs Requests queued to zWLM, then to SRController RegionAppServerCRServant RegionJVMJVMzWLMSRNative CodeAppAppSR: Application Infrastructure Maintains app JVM runtime May support one or moreapplications Connectivity to data from SR Min/Max controllable by adminNative CodeJCLCR: WAS “Plumbing” Code Native and JavaNo application codeTCP listeners reside hereQueues requests to WLMServant RegionJVMAppAppNative CodeDefault: min 1, max 1This is a built-in “vertical scaling” mechanism. Also allows forredundancy of application JVM to prevent single point of failureExploits platform 20

Exploits the Strengths of the PlatformThe WebSphere code base is not completely the same across all platforms.There is a a degree of unique code to exploit the underlying platform:Direct ExploitationCode is written to realize it’s on a given platform and unique code is then invoked. zWLM -- managing servant regions to defined goals; internal routing of IIOP based onenvironment awareness; classification of workload RMF and SMF -- reporting on transactions and server components SAF -- security profile repository, including things such as keyrings and digital certificates- Thursday 9:30 Room 310 “Security Architecture: How does WebSphere Play” Specialty Engines -- zAAPs and zIIPs / Coupling Facility -- for logging “Type 2” connectors -- native code implementation; true cross-memory communicationsIndirect - Value of “Just Showing Up”Common code employed, but because it rides on System z and z/OS it benefits Sysplex Distributor and DVIPA support -- for intelligent balancing of traffic (Distributor) and theprotection against adapter or TCP stack outage (DVIPA) Intra-Sysplex or inter-LPAR communications -- XCF (cross coupling facility) or Hypersockets Sysplex data sharing -- for common data access: DB2, MQ, CICS, IMS Hardware design -- fault tolerance; redundancy; hot-pluggable, etc.The node 21

Multiple Application Servers and theConcept of a “Node”There are many reasons* for creating multiple application servers. A“node” is simply the logical collection of applications servers on an LPAR:LPARLPARKey Points: Nodes are a logical thing it’s not a started RAppServerCRSRAppServer“Node”SRCRSRAppServerCR They logically organizeapplication servers on anLPAR No architectural limit to thenumber of applicationservers in a node; limitedonly by system resources Rule: node must stay on anLPAR; it can’t span LPARsin a SysplexSRWhat’s the point?* Requirement for separation of application. Applications have differentcustom JVM settings. Different performance requirements(We’ll see in a moment)DMGR 22

First -- The Administrative Application ServerThere is a special purpose server called the “Deployment Manager”that runs the Administrative Console:LPARLPARKey CRSRCan CRSR DMGR structure like applicationserver -- one CR and one ormore SRs. Only the Administrative Consoleis allowed to run in this specialpurpose server. The Administrative Console isreally just a very smart web appthat knows how to translate yourconfiguration mouse clicks intoupdates to XML configurationdocs. Properly configured, the DMGRcan be started on other LPARs Only one DMGR is allowed per“Cell” (which we’ll describesoon)Something is missing Node Agents 23

Node Agents -- Act on Behalf of DMGR inthe NodeNode Agents are single-CR structures that update the node’s configurationon behalf of the DMGR, which sends updates to the Node Agent:LPARLPARDMGRCRNode AgentCR WebSphere is a distributedarchitecture -- this allows theconfiguration to be on separatemachines and still work.SRAppServerCRSRNode AgentCRAppServerCRKey Points:“Master Configuration”CRSRAppServerSRConfigurationfiles for thisnodeAppServerCRSRConfigurationfiles for thisnodeAppServerCRSRAppServerCRSR This design frees the DMGRfrom requiring write access toeach node’s configuration filesystem. Node Agents are just that -agents that work on behalf of theDMGR to make the changes inthe node. Act of copying down changes iscalled “synchronization” Trivia - DMGR maintains mastercopy of configuration, changesmade there first, then copied outto the nodes.Clusters 24

Clusters -- Grouping of Servers to form aLogical OneWebSphere allows you to define multiple servers that acts as a kind of“single logical server”. These are clusters:LPARLPARKey Points:DMGRCRNode AgentCRSRAppServerCR The application servers are infact separate servers, butWebSphere treats them as onefor application deploymentSRNode pServerSR These are used in HAconfigurations when mutlipleconcurrent copies of anapplication is desired. We are intentionally skipping thetopic of “front end loadbalancing” interesting topicbut too much for this session.AppServerClusterCRSRCell 25

Now We Can Introduce Concept of the “Cell”The Cell is really nothing more than the extent of administrative control a DMGRhas. In this example it controls two nodes on two LPARs that’s the cell.LPARLPARKey Points:DMGRCRNode AgentCRSRAppServerCR The Cell is a logical thing it isnot a started task or addressspace.SRNode pServer The Cell marks the boundary foradministrative isolation youcan limit who has access tomodifications to the Cell. This ishow QA, Test and Production isbest kept separate.SRAppServerClusterCRSRFlexible Management . . .26

Flexible ManagementAdditional architectures were introduced in WAS V7 to deal with theadministration of large groups of WAS cellsLPARLPARJob Manager:Job MgrCRDMGRSRND CellNodeagentAppAppServersServersDMGRND CellAppServerNodeagentCRAppAppServersServers Job Manager is a central consolefor the administration of manycells (ND or stand alone) Job Manager differs from DMGRsince it does not centrally storeconfiguration and can managemultiple cells Asynchronously submit jobs atscheduled timesSR Each cell maintains autonomyLPARAdmin AgentCRAppServerCRAdministrative RSR Replaces the administrationconsole for a group of standalone application servers Reduces the footprint of eachapplication server by removingadministrative overhead Each server maintains autonomyAnswering a few Q’s 27

Anticipating Some QuestionsMay I have more than one Cell?Yes no limit to the number of cells you can create.May I have a cell that spans z/OS and distributed servers?Yes but start out with z/OS-only until you gain experience. Thenmove to the more complicated topic of “heterogeneous cells”Complication comes chiefly from security issues and the coordination of digital certificates, and the creation ofan external userid repository such as LDAP.What about the Daemon Server?We intentionally skipped over that to keep things simple Can an application server belong to two cells at the same time?No overlapping of resources like that is not allowed.Installation and configuration 28

Installation and Configuration29

SMP/E Installation of WebSphereApplication Server for z/OS 7.0Relatively straight-forward SMP/E ere/V7R0Unix Systems ServicesFile SystemAnd a short list of relatively simple systemprogrammer steps, all well documentedNo module libraries that’s different from in the past. Now the entireproduct is contained within a file system (HFS or zFS)This is just the product itself this is not your customizedconfiguration. That’s a separate set of sets which we’ll cover next.Customization at high level 30

Customization at a Very High LevelThe whole objective is to create the configuration information, which is kept inan HFS or ZFS:Supply names andvalues so yourconfiguration iscustomized to yourneedsLPAR ADaemonCRUpload generatedbatch JCL jobs toz/OS and mentManager/profiles/defaultNode AgentCRAppServerCRSRWhole bunch ofcustomized XML t ServersAppServerCRSR/profiles/defaultWhole bunch ofcustomized XML filesDon’t worry what’s in thoseXML files detail you don’tneed to know right awayThe key is the configuration“tree” needs to get built andpopulated with yourspecific information.That’s one piece of theconfiguration puzzle what are the other pieces?Fundamental pieces 31

Fundamental Pieces of a CustomizedConfigurationIt’s helpful to focus on three fundamental things that make up a customizedconfiguration of servers, nodes and a cell:LPAR ADaemonCRCellDMGRCRSRConfiguration File System HFS or ZFS, this contains all the XML files that make up the configuration. Each node has its own configuration file systemJCL Start Procedures This is what is used when starting the servers, Node Agents andDeployment Manager.Node AgentCRNodeAppServerCRSRSAF Profiles They are what provides the essential z/OS security for the started tasks -Userids and Groups for file ownership and administrative access;STARTED profiles for assignment of IDs, etc.AppServerCRSRTwo key points:1. To discard a configuration you don’t like, all you need do isclean up these three things (SAF being the most complicated)2. These things are created by the configuration tool called the“WCT” and are customized with your specific names andvaluesThe WCT 32

The WCT Configuration ToolIs a workstation graphical tool that captures key names, values and inputfrom you and consistently imbeds those values in customized batch jobs.Hmmm, I’ll supply thefollowing values Made up of two tools zPMTand zMMTCustomizedBatch JCL jobsThese get uploaded to z/OSwhere they’re submitted, oneafter another, to create theconfiguration runtime.Uploading and running thejobs is the easy part.The real challenge is coming up with all the names and values and portsthe WCT is going to ask for. Without a plan for those names you’ll veryquickly get str.nsf/WebIndex/PRS3357Spreadsheet 33

The PRS3341 Planning SpreadsheetAn Excel spreadsheet that makes planning values and using the WCTmuch easier it helps enforce a disciplined “top down” design:Provide key variables inthe “Variables” sheetCopy the generated variablesfrom the appropriateworksheet and paste intoNotepad to create a fileThen point to the file in the“Response File” field of thewindow where you gave thedefinition a nameThen just tab through the WCT windowsand generate the jobsJobs 34

The Generated Jobs and Running ThemLet’s look at example of generated job -- this will help “demystify” this:BBOCCINSInstruction checklistKey DHFSABBOWWPFDCreates the RACF profiles No real magic to this justbatch jobs that do mundanethingsCopies customized JCLprocs into PROCLIB. Key is how the jobs arecustomized, and that’s wherethe spreadsheet/zPMT comes inAllocates HFS, creates directorystructure, copies in customizedXML, and does final build ofconfiguration “profile” Running the jobs is easy making sure jobs have rightinformation is the keyTypical problems are -- typos in the input data (spreadsheet helps avoidthis) and insufficient authority (what you need is well documented)Federation 35

Build Nodes and FederateThe jobs build a node. To build a bigger cell you do what’s called “Federate.”This involves running a batch job to join one node into the DMGR’s cell:LPAR ALPAR ACellKey Points:DMGRCRFederateNode AgentCR Build as big a cell as youwant using this techniqueFederateAppServerCR This is a “building block”approachSRSRNode AgentCRAppServerCRSR The DMGR’s cell grows topick up the nodes beingfederatedDetails of this deliberately left out don’t worry about those right now. Keyis the concept of joining a node into the DMGR’s cell to make it grow. Getthat concept and you’re half-way home.Further customization and usage 36

Post-Creation Customization andUsing the WebSphere Runtime37

What You Have After You’ve Built Your CellAfter you’ve done all that you have a configuration that is capable ofaccepting applications to run:LPAR ADaemonCRCellDMGRCRNode AgentCRAdministrativeConsoleSRBut your cell will nodoubt require morepost-creationcustomizationAppServerCRSRFour Main Pieces to this:NodeAppServerCRSR Adding more servers if you see the need for them Creating clusters Adding things like JDBC, JCA and MQ Deploying applications and starting themThis post-creation customization is common across all platforms it’s not just a z/OS thing.In fact, it’s common across all middleware -- DB2, CICS, MQ all require some customizationAdministrative Console 38

The Administrative ConsoleAs we said, this is a very smart web application that knows how to update XMLfiles in the configuration based on the point-and-click actions you doConfigurationFile SystemKey Messages: There are a lot of options within the Administrative Console You learn this over time you can’t master this right away Always remember what it’s doing -- updating configuration XML with your newinformation, such as JDBC, MQ, applications, etc.WSADMIN 39

WSADMIN Scripting InterfaceThere’s also a programmatic scripting interface that allows you to automatetasks. You can do nearly anything with WSADMIN you can with Admin Console.LPAR ADaemonCRCellDMGRCRNode AgentCRNodeSRAppServerCRSR# -------# Set variables# -------app srv ‘mysr01a'app node ‘mynodea'app ear ‘/u/myhome/MyApp.ear'# -------# Install application# -------print 'Installing application'options '[-node ' app node ' -server ' app srv ']'AdminApp.install(app ear,options)AdminConfig.save()AppServerCRSRKey Messages: Very handy for repetitive tasks Useful to insure consistent deployments across QA, Test, Production Does take some getting used to like any programming languageDeploying Apps 40

Overview -- Deploying ApplicationsIn WebSphere, an application is typically packaged as an “EAR” file -a zip format file that contains all the piece-parts of the application:Development toolsuch as RationalApplication Developer(RAD)Admin Consoleor WSADMINDeveloperDeployerKey Messages:ApplicationEAR file The Admin function will “break open” the zip-format EAR file and put the individualfiles in the proper places in the configuration file structure Who performs role of “deployer” is different in each customer sometimes aseparate group; sometimes the z/OS system programmers. Some knowledge of the application and what’s it’s designed to do is necessary. Youcan’t deploy applications blindly. Talk to your developers and understand what’s going on in the application!Front-end balancing 41

WebSphere Feature PacksRevolutionizing the way customers consume application servertechnology now and in the futureWeb servicesWeb 2.0EJB 3.0WAS 6.11. Choose theapplication servertechnology you need.Web 2.0Web servicesEJB 3.02. Install additionalfunctionality on coreWAS Application ServerSCACEASAMLOLAXMLOSGI/JPAWAS 7.03. Build the ApplicationServer you want withoutwaiting for new releases.As new technology evolves, so does WebSphere –Get the technology you need now without waiting for a new release!4242Innovation That Matters

Front-End Load Balancing DevicesEach WebSphere application server has its own HTTP listeners sosomething “out front” is typically required.LPAR ADaemonCRCellDMGRCRNode AgentCRSRFront-EndDeviceUsersAppServerCRSRKey Messages:NodeAppServerCRSR Lots of options -- Routers, “Plugin,” ProxyServers, Sysplex Distributor, ODR Complex topic -- lots of pros and consOther topics 43

Grand SummaryAnd we come to the end with a single summary chart: “Application Server”Provides a common set of functions and services so developers can focus on business-value, not plumbing code. “Open St

3 Session Objective and Agenda Overview of key concepts, terminology and technologies What an “Application Server” is Java and the role of open standards Review of the kinds of applications WebSphere can and can not run Review of the notion of a “three tier” architecture -- very common with We