WebSphere Application Server for z/os

(1)

WebSphere Application Server

for z/OS

Martina Schmidt

[email protected]

WebSphere Application Server for z/OS

Application Serving: the Basics

What is an application server?

Operating System Application Server

Service Service Service

Application Application Application

Connection Mgmt Communications High Availability Security Systems Mgmt etc…

WebSphere Application Server is built on J2EE technology and provides:

Web services

JCA Connectors to EIS

J2EE artifacts

Embedded messaging

Distributed caching

Transaction management

Workload management

It also shields applications from platform specifics and allows the application designer to focus on Business Logic

An application server is middleware designed as a fully functioning deployment platform for applications.

(2)

Application Serving: the Basics

J2EE Application Model

Components

Fokus der Anwendungsentwickler, EJBs, Servlets, JSPs und Clients Verhalten der einzelnen Komponenten kann beim Deployment

spezifiziert werden, anstatt im Programmcode Container

Stellen den Komponenten transparent Services zur Verfügung, wie z.B. Transaktionalität oder Resourcenpooling

Container und Connectors verbergen Komplexität und begünstigen Portabilität

Connectors

Definieren portable Service APIs, um sich an existierende Anwendungen anzustecken

Begünstigen Flexibilität, da sie eine Menge von Implementierungen von spezifischen Services ermöglichen

Components

Container

Connectors

Application Serving: the Basics

Typical Deployment

Browser

Internet F ire w all

Web Server

Internet DMZ

Web servers provide static content and support basic application

front-end functions

Application

Server

Internal Network Business applications, data access, integration

F

ire

w

all

Network firewall, often specialized hardware

Often a software firewall

(3)

Application Serving: the Basics

J2EE Application Server

Applet Container J2SE Web Browser Application Client Container J2SE Legacy Application Database J2EE Application Server

EJB Container EJB J2SE J2EE Web Container Servlet J2SE J2EE JSP

Capabilities Customer Needs WebSphere Application Server Network Deployment WebSphere Application Server Community Edition WebSphere Application Server - Express WebSphere Application Server

Built on common WebSphere code Built on open source technology

WebSphere Application Server for zOS Reduced acquisition costs; Small footprint.. Ultimate scalability & performance; functional depth & breadth

Fast deployment of single app; low transaction volumes…

High transaction volumes, High Availability, Advanced Web Services…

Application Serving: the Basics

The WebSphere Application Server Family Summary

Multiple Business Models, Multiple Deployments Options

(4)

Application Serving: the Basics

WebSphere Application Server Services

WebSphere Application Server Enterprise Infrastructure

Web Container EJB Container Java Server Pages Java Servlets Java Ápplication Session Beans Entity Beans Java Servlets Enterprise Assets User Devices Browser HTML Java Applet Desktop .Net Application Java Application Other Devices .Java Client HTTP SOAP IIOP Sockets Enterprise Integration Framework Java Applications HTTP IIOP Non-Java Applications (Packaged or Custom) JCA JDBC DB2 Other SQL JMS SOAP DB2Other SQL

WebSphere Application Server

Typical Middleware architecture

Typical application server runs as a single process

Fatal exceptions that stem from Applications can terminate the entire server process.

In order to scale, we would start multiple server processes.

– Multiple servers would typically run on multiple boxes

Termination of a Server process leads to unavailability of the application unless the application is clustered. Process Application Server App App App Resources CICS TCP/IP Client IMS Database

(5)

WebSphere Application Server

Typical Application Server

Application Server TCP/IP Client Client Client DB Distributed Box

Basic Application Server on non-z/OS platforms –Positive

•Simple –Negative

•Does not Scale •Not Highly Available

•Entire server can fail by Application Code

WebSphere Application Server

Typical Application Server- A little better availability

Application Server TCP/IP Client Client Client DB Distributed Box IP Sprayer/ Web Server … Application Server TCP/IP Distributed Box Application Server TCP/IP Distributed Box … Client Client Client DB DB

(6)

WebSphere Application Server

“Gold Standard” With Distributed Application Servers

Network Switchd HTTP Server HTTP Server WAS WAS WAS … HTTP Server HTTP Server WAS WAS WAS … Network Switch Load Balancer Load Balancer DMZ Trusted Zone Cluster Cluster Cell 1 Cell 2 DB DB DB

WebSphere Application Server

Typical Application Servers

How do you scale the Application? – Add more boxes

How do you scale the Database? – Add more boxes and replicate How do you handle failover?

– Add more boxes

How is an application highly available? – Install the application on many boxes How are requests prioritized?

– Add more boxes to handle Gold Customers

How do I handle peak loads?

– Keep enough boxes available to handle the max possible load

What about when I don’t have peak loads? – The Servers will be underutilized How do you route work evenly to multiple

boxes?

– Round-robin inbound work

How do you ensure that your servers are evenly utilized?

– Best guess based on Application Knowledge

(7)

WebSphere Application Server

WebSphere for z/OS Server Architecture

A WAS z/OS application server is comprised of multiple processes. Controller Servant TCP/IP WLM Mem-to-Mem Client Client Client Mainframe Servant Servant

Logical WAS z/OS Application Server Only authorized, robust system code is executed within the Controller process. Application code is executed within the

Servant Process.

– Theoretically, Servant processes are clones of each other.

– They can be terminated or created without interrupting the overall end-user experience

– Servant processes can be dynamically created or destroyed by Work-load Management. The decisions can be based on user-defined service policies.

Application code is executed within the Servant Process.

– Theoretically, Servant processes are clones of each other.

– They can be terminated or created without interrupting the overall end-user experience

– Servant processes can be dynamically created or destroyed by Work-load Management. The decisions can be based on user-defined service policies.

If a servant process is terminated, the application can still be served by any of the other servants within the Application Server.

WLM Detects that the Servant has terminated and starts a new one.

Controller Servant TCP/IP WLM Mem-to-Mem Client Client Client Mainframe Servant Servant

X

Logical WAS z/OS Application Server

WebSphere Application Server

(8)

Within a WAS z/OS Application Server, one can define a minimum and maximum number of servant processes that are allowed. Workload could suddenly spike, overloading the

WebSphere Server

Work items begin to queue up and wait for an available servant. WLM can detect this and act… If the maximum number of servants has not been reached, WLM can start a new Servant process to handle the load.

Built-in vertical clustering

Controller Servant TCP/IP WLM Mem-to-Mem Client Client Client Mainframe Servant Servant Client Client Client MinSR=2, MaxSR=3

WebSphere Application Server

Why is WAS z/OS Scalable?

After some time, the spike in workload could end. Our workload would then return to normal WLM can detect that the servants are

underutilized and act…

WLM terminates the extra servants until utilization goals are reached. This allows system resources to be freed and available for other system services. Controller Servant TCP/IP WLM Mem-to-Mem Client Client Client Mainframe Servant Servant Client Client Client

WebSphere Application Server

(9)

In order to provide a true high-availability server, the Controller processes would be clustered.

If a controller process fails, the Sysplex Distributor would route work to the other controller process.

ARM detects that the controller failed and restarts it. Client Sysplex Distributor Controller Servant Servant Servant LPAR 1 Controller Servant Servant Servant LPAR 2 Client Client Client Client Client

X

ARM WAS WAS

WebSphere Application Server

Why is WAS z/OS High Available?

WAS uses four distinct functions of WLM: – Routing

• Work is distributed among multiple Servants – Queuing

• Work that cannot be distributed waits until a Servant is available – Prioritizing

• Higher priority work can be distributed before lower priority work – Process Management

• Starts and Stops Servants as needed (to scale, for failure recovery, etc).

WebSphere Application Server

(10)

CPU’s 1

2 3 - Workload can be classified (WLM Service Policies)

- Higher priority work can be given more system resources

Priority

WebSphere Application Server

How does WAS z/OS leverage WLM?

Client Sysplex Distributor Controller Servant Servant LPAR 1 Client Client Client Client Client Servant WLM 34% Util Controller Servant Servant LPAR 2 Servant WLM 38% Util

= Simple Request = Complex Request

54% Util

39% Util 44% Util

Intelligent routing to LPAR’s via WLM and the Sysplex Distributor

WebSphere Application Server

(11)

WebSphere for z/OS Uses Enclaves

Eine „Geschäftstransaktion" ohne Adressraumgrenzen

– Zwei Arten

– Existieren in goal (Ziel) mode und compatibility (Verträglichkeit) mode – System oder Sysplex Geltungsbereich unabhängige Enclaven

– echte SRM Transaktion – Wird in Serviceklasse oder

Performancegruppe separat klassifiziert und verwaltet abhängige Enclaven

– Logische Erweiterung einer existierenden Adressraumtransaktion – Erbt Serviceklasse / pgn vom

existierenden Adressraum

z/OS Resource Recovery Services (RRS) Usage

Erforderlich um 2-phase commits zu benutzen:

– Unterstützt verschiedene & mehrfache Ressourcenmanager: WebSphere, DB2, IMS, CICS, APPC

– Differenziert zWAS von anderen Web Application Servern

Nutzung des Subsystems ist abhängig vom Produkt:

– Nutzen RRS optional wenn es bei ihrer Initialisierung aktiv ist: APPC, IMS, MQ, DB2

– Muss bei Initialisierung gesagt bekommen, RRS zu nutzen: CICS – RRS muss bei ihrer Initialisierung aktiv

(12)

WebSphere AS Security Mechanisms

Sicherheit in WebSphere Application Server Infrastruktur – RACF Profile & Erlaubnisse

– HFS Datei/Verzeichnis Erlaubnis & Eigentum – Administrator Tool Sicherheit

Sicherheit für Anwendungsdeployment – SSL

– Kerberos

– EJB Rollen & Runas Support – Kryptographie Support – JAAS

– CSIv2

How do Developers leverage these QoS? – By writing well-designed J2EE Applications

Is there anything specific that Developers must do on z/OS?

– NO. WAS z/OS provides these qualities of service to J2EE applications, no z-specific application code is required.

If the Java Runtime is platform optimized, will the java code in my application only run on z/OS?

– NO. Java Runtime Optimizations are hidden from the Developer. Developer writes standard code, the Runtime is optimized under the covers

Are there z-specific features that my application code could include?

– Sure… but z-specific code isn’t required to take advantage of WLM, RRS, etc.

WebSphere Application Server

(13)

WAS integration with z/OS System Facilities provides a more robust,

efficient, scalable environment

WebSphere Application Server

WebSphere z/OS Application Server

How do you scale the Application? – Increase the Max Servants per Server How do you scale the Database?

– Use a Shared DB2 Database How do you handle failover?

– Use ARM for Controllers. Servants are handled via WLM

How is an application highly available? – Servants are restartable via WLM. Controllers are recoverable via ARM How are requests prioritized?

– WLM

How do I handle peak loads? – WLM spawns servants

What about when I don’t have peak loads? – WLM eliminates excess Servants, freeing up

system resources for other work How do you route work evenly to multiple

Servers?

– Sysplex Distributor routes work to specific LPAR’s based on WLM metrics for resource utilization

How do you ensure that your servers are evenly utilized?

– WLM Metrics are used to decide where to route work to

System z Application Assist Processor (zAAP)

New specialty assist processor dedicated exclusively to execution of Java workloads under z/OS® – e.g. WebSphere®, CICS, IMS, DB2

Available on IBM Server™ zSeries® 990 (z990), zSeries 890 (z890) and System z9 / z10 BC and EC servers

Used by workloads with Java cycles, e.g. WebSphere, DB2® – Executes Java code with no changes to applications Attractively priced, much lower than standard CPs Significantly lower maintenance costs than standard CPs Traditional IBM zSeries software charges unaffected Sub-capacity eligible IBM software charges can be reduced Up to 1 zAAP per general purpose processor in a CEC

Objective: Enable integration of new Java based Web applications with core z/OS backend database environment for high performance, reliability, availability, security, and lower total cost of ownership

(14)