Introduction to WebSphere for z/OS V5 - Student Notebook

backdamagedInternet and Web Development

Jul 30, 2012 (5 years and 16 days ago)

1,027 views


Student Notebook


© Copyright IBM Corp. 2005

Unit
5.
Introduction to WebSphere for z/OS V
5
5
-
1

Course materials may not be reproduced in who
le or in part

without the prior written permission of IBM.

Unit 5.

Introduction to WebSphere for z/OS V5

What This Unit is About

The product WebSphere for z/OS V5.1 is the latest WebSphere product to
run on OS/390 and z/OS systems. The transition from WebSphere V4.0x for
z/OS and OS/390 to WebSphere for z/OS V5.1 has litt
le impact on existing
z/OS J2EE applications, but a very large impact on the z/OS WebSphere
administration team. This is because the WebSphere infrastructure on z/OS
has been substantially changed so as to match the partner product
WebSphere V5.1 for distr
ibuted systems.


WebSphere for z/OS V5.1 has the ability to build robust commercial Java
applications using Enterprise Java Beans (EJBs). This first unit provides a
conceptual overview for a technical IT professional into the world of
distributed Java appl
ications in general, and also to the functionality provided
in WebSphere for z/OS V5.1 which implements the J2EE environment on
z/OS.

What You Should Be Able to Do

After completing this unit, you should
have a conceptual base of
:



Java programming



The role

of Enterprise Java Beans in distributed Java applications



The Java application architecture described by the JavaSoft J2EE 1.3
specification




The topology of the WebSphere for z/OS Version 5 (WebSphere V5)
runtime environment on z/OS



The functional suppor
t provided by other products for WebSphere V5
applications



How J2EE applications are developed and deployed into a WebSphere
V5 cell



e
-
business scenarios for WebSphere V5

How You Will Check Your Progress

Accountability:



Machine exercises

References

GA22
-
79
57

WebSphere V5.1: Getting Started
Student Notebook


5
-
2

e
-
business for z/OS

© Copyright IBM

Corp. 2005


Course materials may not be reproduced in whole or in part

without the prior written permission of IBM.


















Figure
5
-
1

Unit
Objectives

ESNEG1.0

Notes:

Introducing WebSphere V5

This unit is a technical introduction to Java applications and to the WebSphere for z
/OS V5.1
production and development environment.

The aim of this unit is to provide you with the fundamental concepts that underpin the
implementation units that you will be working with for the rest of the week.




Student Notebook


© Copyright IBM Corp. 2005

Unit
5.
Introduction to WebSphere for z/OS V
5
5
-
3

Course materials may not be reproduced in who
le or in part

without the prior written permission of IBM.


















Figure
5
-
2

What Is WebSphere Version 5.1?

ESNEG1.0

Notes:

The WebSphere software platform is the IBM product that supplies the i
nfrastructure needed
to support the deployment, execution, and management of J2EE based application
components on all IBM servers. The product line has two streams
-

one stream is based on
the WebSphere for z/OS product, while the other stream is based on
the WebSphere for
distributed platforms product. With WebSphere Version 5.1, both streams now provide an
identical environment for deployment and execution of J2EE applications.

The WebSphere V5.1 platform is now incorporated in two products:



WebSphere App
lication Server Version 5.1
-

This product must be installed first. It provides
the base WebSphere support for J2EE application servers compatible with the standard
J2EE 1.3 specification.



WebSphere Business Integration Server Foundation Version 5.1
-

This

is an optional
product that may be installed on top of the WebSphere base. It includes enhanced
features for J2EE application support. This includes using a workflow type environment
where multiple J2EE applications and services can be built into an execu
table business
process, as well as programming extensions to J2EE functionality.

©
Copyright IBM Corporation 2005
IBM zSeries
3

WebSphere V5.1 is an infrastructure for open e
-
business applications
supported on all IBM hardware servers

WebSphere V5.1 for z/OS applies to zSeries only

WebSphere V5.1 for distributed platforms applies to other IBM se
rvers

Provides a platform for deployment and execution of Java
applications and web services

Consists of two separate products:

WebSphere Application Server Version 5.1

WebSphere Business Integration Server Foundation Version 5.1

WebSphere Application Server V5.1 for z/OS

Required base platform for executing J2EE applications
-
installed first

WebSphere Business Integration Server Foundation V5.1 for z/OS
(often called WBISF for z/OS)

Optional
-
installed on top of WebSphere Application Server V5.1

Adds support for Java business processes and IBM J2EE programmin
g
extensions
What Is WebSphere Version 5.1?

Student Notebook


5
-
4

e
-
business for z/OS

© Copyright IBM

Corp. 2005


Course materials may not be reproduced in whole or in part

without the prior written permission of IBM.




Student Notebook


© Copyright IBM Corp. 2005

Unit
5.
Introduction to WebSphere for z/OS V
5
5
-
5

Course materials may not be reproduced in who
le or in part

without the prior written permission of IBM.


















Figure
5
-
3

WebSphere 5.1: Major Themes (1 of 2)

ESNEG1.0

Notes:

There are several main motivations at the base of WebSphere for z/OS V5.1. A prominent one
is represented by J2EE 1.3 compliance. Not only does IBM want to comply with the latest
lev
els of the Java standards, but it also recognize the intrinsic value of the new functions
introduced by this level of the specifications.

EJB 2.0 brings EJBs to a degree of maturity that makes them suitable for the most
sophisticated commercial application
s.

Messaging is also an important area addressed by the specs, with Message Driven Beans and
the requirement for an integrated messaging infrastructure.

Security and interoperability also present significant enhancements.

Another area of focus is Web Serv
ices enablement. WebSphere for z/OS V5.1 improves
SOAP support, and ships a Private UDDI registry, enabling customers to install and run their
own Web Services directory without further requirements. The base also includes the Web
©
Copyright IBM Corporation 2005
IBM zSeries
4
WebSphere 5.1: Major Themes (1 of 2)

WebSphere Application Server V5.1 for z/OS

J2EE 1.3 Compliance

EJB 2.0, servlet 2.3, JSP 1.2

Integrated, built
-
in JMS provider

Interoperable naming service

J2EE 1.3 security: Java 2 security, JAAS, enhanced pluggable
authentication

Extended Web services support

Enhanced SOAP support, private UDDI registry, UDDI utilities

Web services gateway

Open, flexible administration model

Based on Java Management Extensions (JMX)

Provides improved failover capability and high availability

User interface enhancements and application management

Standard programming model extensions (coming on z/OS)

Student Notebook


5
-
6

e
-
business for z/OS

© Copyright IBM

Corp. 2005


Course materials may not be reproduced in whole or in part

without the prior written permission of IBM.

Services Gateway, which i
ncreases the opportunities to interoperate with heterogeneous Web
Services infrastructures.

In addition, the administrative model of WebSphere has been designed to improve availability,
to reduce interdependencies among processes, to increase usability, an
d to adopt standard
resource management interfaces (JMX).



Student Notebook


© Copyright IBM Corp. 2005

Unit
5.
Introduction to WebSphere for z/OS V
5
5
-
7

Course materials may not be reproduced in who
le or in part

without the prior written permission of IBM.


















Figure
5
-
4

WebSp
here 5.1: Major Themes (2 of 2)

ESNEG1.0

Notes:

In particular, the IBM WebSphere V5.1 platform provides the capability to develop and deploy
J2EE applications that may optionally be deployed into a z/OS or non
-
z/OS WebSphere
environment. There are some ex
tra extensions to areas such as Quality of Service (QOS)
provided by WebSphere for z/OS V5.1 but typically these differences are resolved at an
administrative rather than application level.

The internal coding of the distributed and z/OS WebSphere adminis
tration tools is not yet the
same, but the user and scripting interfaces of WebSphere administrators are 99.9% identical
(there are a few extra input fields in a few panels).

WebSphere Studio Application Developer (WSAD) is the IBM tool of choice to develo
p and
package J2EE components for both z/OS and distributed environments. And application
assembly for both environments is done using either WSAD or the WebSphere Assembly
Toolkit.

©
Copyright IBM Corporation 2005
IBM zSeries
5
WebSphere 5.1: Major Themes (2 of 2)
WebSphere Application Server V5.1 for z/OS (cont)

Family Programming Model Convergence

Common architecture for z/OS and Distributed editions

Common code base (some differences that exploit z/OS QoS)

Common administration model
-
GUI and scripting

Common terminology and topology (still continue to exploit z/OS
Sysplex)

One set of development tooling: WebSphere Studio Application Dev
eloper
WebSphere Business Integration Server Foundation V5.1 for z/OS

Supports WebSphere Business Process Choreography

Tools and functions to construct new business applications by re
using
existing services packaged as J2EE components

Uses GUI type interface and workflow approach to connect existin
g services

Provides enhanced business objects for J2EE applications

Advanced application enablement functions for J2EE

Student Notebook


5
-
8

e
-
business for z/OS

© Copyright IBM

Corp. 2005


Course materials may not be reproduced in whole or in part

without the prior written permission of IBM.

IBM WebSphere Business Integration Server Foundation (WBISF) Version 5.1
builds on the
WebSphere Version 5.1 base platform to deliver a “next generation” composite application
platform for J2EE applications. The main components are:



The ability to build, deploy, and execute on WebSphere J2EE business processes using
the Busines
s Process Choreographer. Developers can use a GUI tool to build
a

long
running application workflow called a business process, which models a real
-
world
customer business interaction. The business process integrates the invocation of J2EE
components or web

services with business logic steps, and with multiple real
-
time
interactions with one or more people involved in the modeled task.



Enhancements made to J2EE business data objects improve the performance of
applications using business data, by improving b
usiness object lifetime and reducing the
frequency of requests to build the same object.



Enhancements made to the J2EE application programming interface can be used by an
application developer to provide better operational control of J2EE applications and
use
more efficient ways of programming J2EE components that use asynchronous messaging.



Student Notebook


© Copyright IBM Corp. 2005

Unit
5.
Introduction to WebSphere for z/OS V
5
5
-
9

Course materials may not be reproduced in who
le or in part

without the prior written permission of IBM.


















Figure
5
-
5

WebSphere V4 and V5 on OS/390 and z/OS

ESNEG1.0

Notes:

This visual shows the development of WebSphere on OS/390 and z/OS.

WebSphere Application server V1R2 was the initial product. Capable of handling JSPs and
servlets, it was

integrated with OS/390 V2R9. It is now functionally stabilized.

The next products were WebSphere V3.02 Standard edition (SE) and V3.02 enterprise edition
(EE). They were separately ordered products and are no longer orderable.

The SE edition only supporte
d JSPs and servlets, and was based on Java 1 specification. The
EE edition provided a test bed to start working with EJBs. It had support for CORBA and
partial support for EJBs at EJB 1.0 specification

WebSphere Standard Edition 3.5 updated the WAS V3.02 s
ervlet and JSP environment to
support the Java 2 level of the Java product. When moving to this level, it was necessary for
customers to migrate existing application source to Java 2.

WebSphere for OS/390 and z/OS V4.0 was the next product. Based on Java 2

level, it fully
supports servlets, JSPs, and J2EE EJBs at the EJB 1.1 specification. It complies with the
©
Copyright IBM Corporation 2005
IBM zSeries
6
WebSphere Application Server for OS/390 and z/OS

WebSphere Application Server V3.02 and 3.5 Standard Edition for
OS/390

WebSphere Application Server V3.02 Enterprise Edition for OS/390

WebSphere Application Server V4.01 for z/OS and OS/390

WebSphere Application Server for z/OS V5.0 (only supports OS/390
V2R10)
IBM HTTP Server for
z/OS
JSPs, servlets
WebSphere Application
Server for z/OS &OS/390 V4.01
EJBs
Standard Edition
3.02 and 3.5
Enterprise
Edition 3.02
WebSphere Application
Server for z/OS V5.0
JSPs
servlets
EJBs
MDBs
WebSphere
Transport
Handler
WebSphere
Transport
Handler
WebSphere V4 and V5 on OS/390 and z/OS

Student Notebook


5
-
10

e
-
business for z/OS

© Copyright IBM

Corp. 2005


Course materials may not be reproduced in whole or in part

without the prior written permission of IBM.

J2EE 1.2 specification. WebSphere V4.0x for z/OS and OS/390 is effectively a Java
application subsystem implemented on z/OS. There were two refresh l
evels of 4.01 and 4.04
which added functionality. It was a fully capable platform, but was very different in
infrastructure from the distributed WebSphere platform. The management tools were also
specific only to the z/OS and OS/390 platform.

WebSphere for

z/OS V5.1 is the latest version of WebSphere for z/OS. It supports the J2EE
1.3 specification, including the EJB 2.0 specification level. The infrastructure of the product
has been considerably changed so that now the application interface, the topology,
and the
management tools are (for the most part) identical to the WebSphere V5 Distributed product.
WebSphere for z/OS V5.1 is also much lighter on use of z/OS resources than WebSphere
V4.0x for z/OS and OS/390, and provides a sophisticated process to mana
ge complicated
networks

The IBM HTTP server can optionally be used to provide a web interface to WebSphere for
z/OS but it is not required. WebSphere for z/OS V5.1 can use an integrated component called
the HTTP transport handler to receive HTTP requests f
or WebSphere services.


Student Notebook


© Copyright IBM Corp. 2005

Unit
5.
Introduction to WebSphere for z/OS V
5
5
-
11

Course materials may not be reproduced in who
le or in part

without the prior written permission of IBM.



















Figure
5
-
6

WebSphere V5.1 on z/OS

ESNEG1.0

Notes:

WebSphere for z/OS V5.1 was made generally available in May 2004. It is the first
WebSphere for z/OS release which does not support OS/390, and the product requires a base
platform of z/OS V1R2 or higher.

The WebSphere Application Server for z/OS V5.1 prod
uct provides support for the same core
J2EE application components supported in WebSphere V5.0. It conforms still to the J2EE 1.3
standard specifications. Remote J2EE application clients on network hosts still communicate
with J2EE applications through eit
her the IBM HTTP server or the WebSphere transport
handler.

Customers have the option to install WebSphere Business Integration Server Foundation
(WBISF) for z/OS V5.1, which will give them the ability to exploit new J2EE application
components called Bus
iness Processes. J2EE applications can also use functionality provided
by Programming extensions for the standard J2EE 1.3 interfaces to create more sophisticated
J2EE application environments.

©
Copyright IBM Corporation 2005
IBM zSeries
7
IBM HTTP Server for
z/OS
WebSphere Application
Server for z/OS V5.1
JSPs
servlets
EJBs
MDBs
WebSphere Transport
Handler
WebSphere Business
Integration Server Foundation
(WBISF) for z/OS V5.1
Business
processes
Programming
extensions

WebSphere for z/OS V5.1 requires z/OS V1R2 or higher

WBISF V5.1 is installed on top of WebSphere for z/OS

Java 1.4.1 SDK is shipped with WebSphere V5.1
WebSphere V5.1 on z/OS

Student Notebook


5
-
12

e
-
business for z/OS

© Copyright IBM

Corp. 2005


Course materials may not be reproduced in whole or in part

without the prior written permission of IBM.

WebSphere for z/OS V5.1 uses the Java V1.4.1 run
-
time to sup
port applications. This runtime
is compatible with components compiled using JDK 1.3.1.

WebSphere for z/OS V5.1 base is very similar to WebSphere V5.0 base when looking at the
types of components supported. The move to Java 1.4.1 SDK is positioning fu
ture version of
the product to be able to meet the J2EE 1.4 specification but older J2EE 1.3 components will
execute happily using the new 1.4.1 JVM
.


WBISF V5.1 is the really “new” component in WebSphere for z/OS V5.1. The new J2EE
components provided wit
h this product are IBM extensions that are not yet part of the J2EE
specification, but they are supported by all major
J
ava exploiters and it is expected that all the
enhancements will become part of the
J
ava standards
.


Student Notebook


© Copyright IBM Corp. 2005

Unit
5.
Introduction to WebSphere for z/OS V
5
5
-
13

Course materials may not be reproduced in who
le or in part

without the prior written permission of IBM.



















Figure
5
-
7

Java Components: JavaBeans

ESNEG1.0

Notes:

Java Beans are reusable software components, written in

Java that can be manipulated
visually in a builder tool. They are modular, reusable, object
-
oriented component. They can
easily be used with visual programming tools to build customized Java applications or servlets
which can be used across platforms.

Jav
a Beans are classes with a defined public interface. A Java Bean is a reusable software
component that can be visually manipulated in builder tools. Beans publish their attributes and
behaviors through special method signature patterns that are recognized
by beans
-
aware
application construction tools, allowing the designer to link beans together visually. They often
have a GUI functionality, but may be “non
-
visual” components.

EJBs are more than just bigger, more powerful, mature Java Beans. They are “ente
rprise
-
level” applications that are transactional, multi
-
user secure, and scalable.


Student Notebook


5
-
14

e
-
business for z/OS

© Copyright IBM

Corp. 2005


Course materials may not be reproduced in whole or in part

without the prior written permission of IBM.



















Figure
5
-
8

The J2EE Application Model

ESNEG1.0

Notes:

This chart stresses the platform independence of components. The component developer
(bean provider) does not have to be aware of unique features if the operating system
environment or platfo
rm on which the components are to be run. Nor do

they

need to be
concerned with the specific enterprise information system or database to which the component
is to be connected.

©
Copyright IBM Corporation 2005
IBM zSeries
9

Components

The key focus of application developers
-
these are
the EJBs, servlets, JSPs, and clients.

Many component behaviors can be specified at
deployment time, rather than in program code.

Containers

Provide services to components transparently,
including transaction support and resource pooling.

Containers and connectors conceal complexity and
promote portability.

Connectors

Sit under the J2EE platform, defining portable service
APIs to plug into existing enterprise vendor offerings.

Connectors promote flexibility by enabling a variety of
implementations of specific services.
The J2EE Application Model


Student Notebook


© Copyright IBM Corp. 2005

Unit
5.
Introduction to WebSphere for z/OS V
5
5
-
15

Course materials may not be reproduced in who
le or in part

without the prior written permission of IBM.



















Figure
5
-
9

EJB Server

ESNEG1.0

Notes:

The term “server” is a
much

overloaded term. There are “zSeries” servers, “application
servers”, “generic servers
”, “server instances”, “server address spaces”, “servers of this and of
that”.

The definition of an EJB server and distinction between a server and a container is not clearly
defined in the Java 2 EJB specification. In this context, an EJB server is a ven
dor
-
provided,
platform
-
specific implementation and dispatching of EJB runtime services.

An EJB server's job is to manage the EJB environment, provide J2EE services such as
naming, transaction context, and persistence. A server also manages containers by
di
spatching work to them, managing their activities, and cleaning up after them.

In WebSphere for z/OS V5.1, a server is a dispatcher of work (using a collection of address
spaces) for a particular application or collection of similar applications.


Student Notebook


5
-
16

e
-
business for z/OS

© Copyright IBM

Corp. 2005


Course materials may not be reproduced in whole or in part

without the prior written permission of IBM.



















Figure
5
-
10

EJB Module/Container

ESNEG1.0

Notes:

EJBs are packaged into JAR files
and EAR files containing class files, a manifest, and
deployment descriptors.

An EJB container is a logical entity in the run
-
time environment that manages one or more
enterprise beans. The EJB container manages the life cycles of enterprise bean objects,
coordinates distributed transactions, and implements object security. Generally, each EJB
container is provided by an EJB server and contains a set of enterprise beans that run on the
server.

The container is responsible for making the home interfaces of i
ts deployed enterprise beans
available to the client through JNDI API extension. Thus, the client can look up the home
interface for a specific enterprise bean using JNDI API.

WebSphere for z/OS V5.1 provides containers for web components (JSPs & servlets)
, EJBs,
and for Java 2 clients. In WebSphere for z/OS V5.1, each EJB has its own container. Don't go
looking for containers in z/OS; they are logical things, rather similar in concept to the MVS
scheduler that provides the infrastructure needed to execute
an MVS program.



Student Notebook


© Copyright IBM Corp. 2005

Unit
5.
Introduction to WebSphere for z/OS V
5
5
-
17

Course materials may not be reproduced in who
le or in part

without the prior written permission of IBM.



















Figure
5
-
11

Session Beans and Entity Beans

ESNEG1.0

Notes
:

A session bean is a non
-
persistent object that implements some business logic running on the
server. Think of a session object is as a logical extension of the client program that runs on the
server.

An entity bean is a component that represents an objec
t
-
oriented view of some entities stored
in a persistent storage, such as a database, or entities that are implemented by an existing
enterprise application. In general, an entity bean should represent an independent business
object that has an independent
identity and life cycle, and is referenced by multiple enterprise
beans, clients, or both. Property values are rolled back in case of an abort.

A common model for an application uses a session bean to contain most of the business logic,
and it calls one or

more entity beans to create, update, and delete persistent objects.

As an example, in CICS TS (V2) session beans will reference entity beans in WebSphere for
z/OS V5.1 for persistent objects.


Student Notebook


5
-
18

e
-
business for z/OS

© Copyright IBM

Corp. 2005


Course materials may not be reproduced in whole or in part

without the prior written permission of IBM.



















Figure
5
-
12

Session Beans

ESNEG1.0

Notes:

A session object is a non
-
persistent object that implements some business logic running on
the

server. One way to think of a session object is as a logical extension of the client program
that runs on the server. A session object is not shared among multiple clients.

A typical session object has the following characteristics:



Executes on behalf of
a single client.



Can be transaction
-
aware.



Updates shared data in an underlying database.



Does not represent shared data in the database, although it may access and update such
data.



Is relatively short
-
lived.



Is removed when the EJB Container crashes. (Th
e client has to re
-
establish a new session
object to continue computation.)



Student Notebook


© Copyright IBM Corp. 2005

Unit
5.
Introduction to WebSphere for z/OS V
5
5
-
19

Course materials may not be reproduced in who
le or in part

without the prior written permission of IBM.

Session beans can come in two flavors:



STATELESS


the session bean instances contain no conversational state between
methods; any instance can be used for any client.



STATEFUL


the session bean instances contain conversational state which must be
retained across methods and transactions.

Student Notebook


5
-
20

e
-
business for z/OS

© Copyright IBM

Corp. 2005


Course materials may not be reproduced in whole or in part

without the prior written permission of IBM.



















Figure
5
-
13

Entity Beans

ESNEG1.0

Notes:

An entity bean is a component that represents an object
-
oriented view of some entities stored
in a persistent storage, such as a database, or entities that are implemented by a
n existing
enterprise application.

A typical entity object has the following characteristics:



Provides an object view of data in the database.



Allows shared access from multiple users.



Can be long
-
lived (lives as long as the data in the database).



The enti
ty, its primary key, and its remote reference survive the crash of the EJB
Container.

CMP EJBs do not write the database access calls in the entity bean. Instead, the Container
Provider’s tools generate the database access calls at the entity bean’s deploy
ment time.

BMP EJBs write database access calls (such as using JDBC API technology or SQLJ) directly.



Student Notebook


© Copyright IBM Corp. 2005

Unit
5.
Introduction to WebSphere for z/OS V
5
5
-
21

Course materials may not be reproduced in who
le or in part

without the prior written permission of IBM.

In WebSphere for z/OS V5.1 base, CMPs can only persist data in DB2 table data which they
access via JDBC. If you install WBISF V5.1 for z/OS, CMPs have ex
tra options to persist
object data:



Send object data as an XML structure to a web service



Pass object data to a stored procedure

Use a Java Connection Architecture (JCA) adapter to pass the object data to another
application running on z/OS such as CICS, I
MS, or MQSeries.


BMPs can access the following:



JDBC 2.0 (1.2 supported for compatibility)



J2C CCI
-

Client Connection Interface is provided as “beta” code (or “tech preview”) for
CICS via EXCI, and IMS via APPC. (Server Provider Interface (SPI) is not cu
rrently
supported)

Student Notebook


5
-
22

e
-
business for z/OS

© Copyright IBM

Corp. 2005


Course materials may not be reproduced in whole or in part

without the prior written permission of IBM.



















Figure
5
-
14

EJB Architecture

ESNEG1.0

Notes:

Here we h
ave some more terms, using the “Employee” class for our example:



The
EJBHome

is our “Home Interface” which specifies the available methods for locating,
creating, and removing instances of enterprise bean classes.



The
EJBObject

is our “Remote Interface” wh
ich specifies the remote business methods
that a client can call on an enterprise bean.



The
Enterprise Bean

itself is a non
-
visual component of a distributed, transaction
-
oriented
enterprise application.



The
Deployment Descriptor

is a serialized object tha
t contains run
-
time settings for an
enterprise bean and passes information to the EJB container about how to manage and
control the enterprise bean.



The
EJB Context

allows the instance to obtain information from the container.

Many of these classes, method
s and interfaces are automatically created by the GUI
development tool, such as WebSphere Studio Application Developer (WSAD).



Student Notebook


© Copyright IBM Corp. 2005

Unit
5.
Introduction to WebSphere for z/OS V
5
5
-
23

Course materials may not be reproduced in who
le or in part

without the prior written permission of IBM.



















Figure
5
-
15

EJB Local Interface


bgB OKM

bpkb䜱KM

Notes:

An EJB client for the remote interface can be:



Java client



EJB or Servlet within the same or different JVM (Application Server).

EJB client for
Local interface can only be EJB or Servlet within the same JVM (Application
Server).

In a typical application, about 60 to 80% of the calls to an EJB are from clients that are local
within the same Application Server. Using local interface to invoke anothe
r J2EE component
removes RMI/IIOP overhead. Local Interfaces are defined in the Deployment Descriptor.

Local Interfaces are also the foundation for New Container Managed Relations (CMR) among
entity beans.

Clients must specify EJB Local Reference or EJB Re
ference (remote) as needed.

Advantages: Better performance, since there is no overhead of remote method call,
marshaling, de
-
marshalling, and so on.


Student Notebook


5
-
24

e
-
business for z/OS

© Copyright IBM

Corp. 2005


Course materials may not be reproduced in whole or in part

without the prior written permission of IBM.



















Figure
5
-
16

JMS and MDB Support in J2EE 1.3

ESNEG1.0

Notes:

For compliance of J2EE 1.2, JMS support was mandatory, but JMS/XA was not. However,
WebSphere 4.0 Advanced Edition had s
upported JMS/XA as a value
-
add feature.

J2EE 1.3 specification has two requirements related to messaging:



Provide an implementation of the Java Messages Server (JMS), version 1.0



Support the Message
-
driven Beans programming model, defined in the EJB 2.0
s
pecification.

Hence, as per the first criterion, WebSphere provides an embedded JMS Server that can be
installed along with a WebSphere base install. JMS is the standard Java API for applications
to use to perform messaging. It has two “domains” correspond
ing to two ways of using
messaging: point
-
to
-
point and publish/subscribe.

J2EE 1.3 introduced mandatory support for JMS/XA
-

the XA support makes it possible to
protect both the message processing (put or get) and the business logic under the "umbrella"
o
f an individual XA transaction. It has to be clearly understood that the transaction that


Student Notebook


© Copyright IBM Corp. 2005

Unit
5.
Introduction to WebSphere for z/OS V
5
5
-
25

Course materials may not be reproduced in who
le or in part

without the prior written permission of IBM.

produces an inbound message and the transaction that consumes that same message are two

separate transactions.

J2EE 1.3 introduced a new type of bean called Message d
riven bean. A message
-
driven bean
is an enterprise bean that allows J2EE applications to process messages asynchronously. An
MDB consumes messages from queues and topics that are sent by a JMS Client.

Student Notebook


5
-
26

e
-
business for z/OS

© Copyright IBM

Corp. 2005


Course materials may not be reproduced in whole or in part

without the prior written permission of IBM.



















Figure
5
-
17

Contents of IBM for z/OS SDK 1.4.1

ESNEG1.0

Notes:

The IBM SDK for z/OS, Java 2 Technology Edition, V1.4 is the z/OS

product that delivers
basic
J
ava platform support for z/OS. This product is an implementation of the
J
ava
community J2SE standard specification.

The Java 2 Platform, Standard Edition (J2SE) specification defines the requirements for a
complete
Java

enviro
nment for applications development on desktops and servers. It also
serves as the foundation for J2EE and Web Services. J2SE functionality components include
(from the bottom)



A
Java Virtual Machine

(JVM) that manages byte code execution and interfaces wit
h the
hardware of the proprietary system hosting a
Java

platform. The standard allows for a
differentiation between client and server platform JVMs.



The
core APIs

(Application Program Interfaces)
-

these are the classes and interfaces that
provide basic fe
atures and fundamental functionality for the Java platform. All
Java

platform implementations must support this set
.

©
Copyright IBM Corporation 2005
IBM zSeries
18
z/OS
UNIXes
Windows
Other
Java Compiler
Java Debugger
Javadoc
JPDA
System platforms
Java Virtual
Machine
Core APIs
Integration APIs
User Interface
Toolkits
Deployment
Technologies
Development
Tools and APIs
JRE
SDK
Lang
Util
New I/O
Networking
Preferences
Collections
JNI
Security
XML
Logging
Beans
Locale
Support
RMI
JDBC
TM
JNDI
TM
CORBA
Sound
Input
Methods
Java 2D
TM
Accessibility
Swing
AWT
Java
TM
Web Start
AWT
Java
TM
Plug
-
in
Java
TM
Plug
-
in
Java
TM
Plug
-
in
Java Hotspot
TM
VM Runtime
Java Hotspot
TM
Client
Compiler
Java
Hotspot
TM
Java Hotspot
TM
Java
Hotspot
TM
Java Hotspot
TM
Server Compiler
Java Hotspot
TM
VM Runtime
J2SE
APIs
SDK conforms to Java 2 Platform, Standard Edition (J2SE) 1.4.1 s
pecification
Contents of IBM for z/OS SDK 1.4.1


Student Notebook


© Copyright IBM Corp. 2005

Unit
5.
Introduction to WebSphere for z/OS V
5
5
-
27

Course materials may not be reproduced in who
le or in part

without the prior written permission of IBM.



The
integration APIs

-

Can be used by
Java

applications, typically on server side, to
connect to networked resources such as other
Java

app
lications (RMI), relational data
bases (JDBC), a naming and directory service (JNDI), and other objects (CORBA).



User Interface Toolkits

-

Support the multimedia type APIs typically used by
Java

applications on a client platform to interact with
user
s
.



Dep
loyment technologies

-

These APIs can be used by a
Java

platform to deploy
Java

applications to other networked hosts. This includes Java Plug
-
In interfaces (deploy
applets) and Java Web Start (deploy full function Java applications)
.



Development tools

-

T
ools needed to develop and debug
Java

applications
.

The SDK for z/OS V1R4 product implements a large part of the J2SE 1.4.1 specification. The
SDK does not include the user interface toolkits, and the JVM is optimized only for a
Java

server platform.

The
z/OS SDK, like any J2SE implementation, can be split into two parts



Java Runtime Environment (JRE)
-

This provides the libraries, Java virtual machine, and
other components necessary to run applets and applications written in Java.



Java 2 Software Develo
pment Kit (SDK)
-

This is a superset of the JRE. The SDK contains
everything from the JRE, plus additional tools such as compilers and debuggers that are
necessary for developing applets and applications.

For a
Java

developer, the J2SE functionality is ma
de visible as a number of specialized
Application Programming Interfaces

(APIs), where the structure and semantics of each
interface protocol is defined in a
Java

standard specification
.

z/OS SDK V1.4 relates to standard
Java

specifications. The J2SE archi
tecture defines the
structure and functionality of the basic
Java

application platform as a whole. Java platforms
can come in many
flavors
; for example standalone workstations,
Java

web clients,
Java

application servers and
Java

wireless type platforms are

common examples. Therefore actual
Java

implementations in the form of an SDK can tailor the J2SE specification to their own
requirements. In z/OS which acts as an application server, the
user

interaction functionality for
GUIs and speech is obviously not
relevant.

The Java 2 SDK provided by Sun contains two implementations of the Java virtual machine
(VM).



Java HotSpot Client VM

-

the default virtual machine of the Java 2 SDK and Java 2
Runtime Environment. It is tuned for best performance when running ap
plications in a
client environment by reducing application start
-
up time and memory footprint.



Java HotSpot Server VM

-

designed for maximum program execution speed for
applications running in a server environment. The Java HotSpot Server VM is invoked by

using the
-
server command
-
line option when launching an application
:


Student Notebook


5
-
28

e
-
business for z/OS

© Copyright IBM

Corp. 2005


Course materials may not be reproduced in whole or in part

without the prior written permission of IBM.

java
-
server MyApp

The various API protocol standards are required so that the portability of
Java

byte code
applications across any host platform will work. The practical implementatio
n of a protocol
standard consists of a number of class files that package the functionality for that interface. In
most cases, higher levels of a protocol will provide downward compatibility with previous
levels, but when this is not the case, a
Java

appli
cation may need to be re
-
compiled with the
higher level SDK, so that the byte code will work with the new JRE in the SDK

Note that it is often still possible for two applications compiled with different levels of a Java
SDK (and therefore different standa
rd API levels) to interoperate over a network connection.
The applications could be running on systems that use different levels of the
Java

platform
(SDK)
.
This works if the
Java

message protocol for the network connection provides
downward compatibility.


From a WebSphere perspective, the entire JRE needs to be accessible to application
components in an application server, so the JVM and associated API
Java

classes must be
loaded to the application server address space.


Student Notebook


© Copyright IBM Corp. 2005

Unit
5.
Introduction to WebSphere for z/OS V
5
5
-
29

Course materials may not be reproduced in who
le or in part

without the prior written permission of IBM.



















Figure
5
-
18

How Java Standards Affect WebSphere

ESNEG1.0

Notes:

The J2EE specification defines the architect
ure, the components, and the necessary
functionality that must be provided by any software product that supports a J2EE application
server platform. What are the main points?

The specification defines the types of J2EE application components supported, whi
ch includes
JSPs, servlets, and EJBs. It defines the internal structure of these components when stored as
a file in the program repository, the required metadata that describes each component, and
how the component is represented in storage. Components ar
e deployed for execution into
J2EE application servers.


The specification defines the types of J2EE containers (such as web and base) that must be
supported on the platform. Containers provide the execution “envelope” in which an
application component exe
cutes.



Application components only interact with each other via the container



Containers control the interface between an application and standard J2EE services

©
Copyright IBM Corporation 2005
IBM zSeries
19
Connectors
JDBC
JMS
JAAS
JTA/JTS
JavaMail
JAXP
EJB
Servlets
JSP
J2SE APIs
J2SE runtime
J2EE Product Provider
Application threads, container, extended runtime
EJB Container
Web Container
J2EE APPLICATION
PLATFORM
J2EE + Web services APIs
J2SE JVM
J2EE runtime
Servlet
EJB
JSP
Connector
SPI
JDBC
SPI
Relational
Database
Managers
Enterprise
Information
Managers
J2EE
standards
J2EE
standards
SDK for
z/OS V1.4
WebSphere
for z/OS
WebSphere
classes

CICS

IMS

....

DB2

CloudScape

....
J2EE
standards
How Java Standards Affect WebSphere

Student Notebook


5
-
30

e
-
business for z/OS

© Copyright IBM

Corp. 2005


Course materials may not be reproduced in whole or in part

without the prior written permission of IBM.



Containers are created by the J2EE product as part of the application server structure.

Contain
ers must be able to load components into storage. As part of this process, they
process the component deployment metadata and implement J2EE application control
mechanisms such as transaction control and security checks.

Application components interact
with the J2EE application server by means of a number of
application services
. Each service is typically associated with a standard
Java

protocol (i
n
other words,
JDBC, JNDI and so forth), and presents a standard
Application Program
Interface

(API) for use

by
application components
. During execution, the services are
provided by
Java

class libraries which come from two sources:



The
Java

SDK

provides the classes for services based on J2SE standard
Java

platform



The
J2EE product

(for example
,

WebSphere) provi
des classes for services which are part
of the J2EE specification, and are not part of J2SE specification

Resource manager drivers are software that link application components to other system
resources that are not managed by the J2EE platform. For exampl
e, application components
can use a JDBC resource manager driver to access any proprietary system relational
database in a single standardized way. In this case, the J2EE specification for such a resource
will have two standard interfaces defined
.

The appl
ication programming interface (API), already discussed, describes how the application

processes a reque
st through the resource manager.

The
Service Provider Interface

(SPI) defines how a proprietary resource manager interacts
with the J2EE product (say Web
Sphere) to process a user request
.

See how the
Java

and J2EE standards relate to a J2EE product such as WebSphere for z/OS
V5.1



S
ee how the J2EE standards referred to in the next visual apply to a real J2EE
implementation such as WebSphere; what do they
actually control
?



S
ee how the theory of the J2EE architecture specification relates to the real products of
WebSphere for z/OS V5.1 and the z/OS
Java

SDK V1.4
.


The SPI definitions allow different software vendors to provide “plug
-
and
-
play” proprietary
re
source managers which all use the same standardized protocol to interact with the J2EE
platform, and therefore support a J2SE or J2EE service. The following protocol standards
have an SPI associated with them:



JDBC
-

Access to proprietary relational databa
ses.



J2C
-

Java connector attachments to other software products (CICS, IMS
, and so on
)



JNDI
-

Naming and directory services for WebSphere



JTA
-

Java transaction API
-

connect to system transaction managers (actually in J2EE
V1R4)



JavaMail


Student Notebook


© Copyright IBM Corp. 2005

Unit
5.
Introduction to WebSphere for z/OS V
5
5
-
31

Course materials may not be reproduced in who
le or in part

without the prior written permission of IBM.

J2EE Applica
tion Components

-

The J2EE runtime defines four application component
types that a J2EE product must support:

Application clients

-

Java

programs, typically GUI
-
based,
that
execute on a desktop
.


Applets

-

GUI components that typically execute in a web bro
wser
.

Servlets, JSP pages, filters, and web event listeners (
web components
)
-

typically execute in
a web server environment, may respond to HTTP requests from clients.

Enterprise JavaBeans

(EJB)
-

components execute in a managed environment that supports

transactions and typically the business logic for a J2EE application.

The J2EE servers provide deployment, management, and execution support for conforming
application components. The components are divided into 3 categories: according to their
dependence

on a J2EE server:

Components deployed, managed, and executed on a J2EE server (web components and
EJBs)
.

Components deployed and managed on a J2EE server, but loaded to and executed on a client

machine (includes HTML and applets).

Components whose deploym
ent and management is not completely defined by this
specification
-

for example Application Clients.

J2EE Containers

-

Containers are supplied by the J2EE product provider (i.e. WebSphere)
and provide the runtime support for J2EE application components.

J2EE components never interact directly with each other. They use protocols and methods of
the container for interacting with each other and with platform services.

This isolation allows the container to transparently inject the services defined by the
co
mponents’ deployment descriptors, such as declarative transaction management, security
checks, resource pooling, and state management.

A J2EE product should provide a container for these component type
s
: application client
container, applet container, web
container, and enterprise bean container.

Note that containers must provide a
Java

compatible runtime as is defined by the current
J2SE specification. Also, the J2EE specification defines a set of standard services that each
J2EE product must support. The
J2EE containers will provide the APIs that application
components use to access these J2EE services.

The container tools must understand the file formats for the packaging of application
components for deployment.

Student Notebook


5
-
32

e
-
business for z/OS

© Copyright IBM

Corp. 2005


Course materials may not be reproduced in whole or in part

without the prior written permission of IBM.

Underlying a J2EE container is the server

of which it is a part. A J2EE Product Provider (such
as IBM WebSphere) typically implements the J2EE server
-
side functionality using an existing
transaction processing infrastructure in combination with J2SE technology.

J2EE Resource Manager Drivers

-

Th
is is a system
-
level software component that
implements network connectivity to an external resource manager. A driver can extend the
functionality of the J2EE platform in several ways:



B
y implementing a J2EE standard service APIs (such as a JDBC™ driver),

which can
connect to proprietary relational databases
.



B
y defining and implementing a resource manager driver for a connector to an external
software application system (for WebSphere this would be CICS, IMS
, and so on
).

Drivers interface with the J2EE p
latform through the J2EE
service provider interfaces

(J2EE
SPI). A driver that uses the J2EE SPIs to attach to the J2EE platform will be able to work with
all J2EE products.

J2EE Database

-

The J2EE platform requires a database, accessible through the JDBC

API,
for the storage of business data. The database should be accessible from application
components running in the containers
.

J2EE Standard Services

-

The J2EE platform in the container must provide access to a
specified set of J2EE standard services. S
ome of these standard services are actually
provided by the J2SE run time component, while others will be packaged as part of the J2EE
product that builds the containers. (A list follows of required services and levels
.
)


Student Notebook


© Copyright IBM Corp. 2005

Unit
5.
Introduction to WebSphere for z/OS V
5
5
-
33

Course materials may not be reproduced in who
le or in part

without the prior written permission of IBM.



















Figure
5
-
19

WebSphere 5.1: J2EE Standards Checklist

ESNEG1.0

Notes:

The tables show the significant Java sta
ndards which are included in the WebSphere for z/OS
V5.1 implementation of a J2EE application server. You can find this list in more detail by
searching in the WebSphere for z/OS V5.1 info center using the keywords “J2EE
specification”.

Participants in
the Java standards process initially request a standard to be created by
submitting a Java Specification Request (JSR) to the
Java Community Process
. Once the
standard has been finalized, Java platform providers have the option to implement the new
protoco
ls (if any) related to that standard.

The J2EE standard include the entire set of J2SE core standards
-

the J2SE standards table
above shows the most important of them specifically quoted in the J2EE standard.

Java web services standards are not currently
part of J2EE, but as WebSphere for z/OS V5.1
implements Java web services as well as J2EE, they are relevant.

©
Copyright IBM Corporation 2005
IBM zSeries
20
J2EE
Standard
Level
WebSphere V5.1
J2EE
1.3.1
Fully certified and part
of Sun's JCEE list
J2SE
1.4.1
Only the core APIs
HTTP/S
1.1
Client access
EJB
2.0
EJB 2.0, 1.1 support
Servlet
2.3
Servlet 2.3
JSP
1.2
JSP 1.2
JTS/JTA
1.0
with distributed
transactions
JMS
1.0.2
With Native Provider,
and MQ plug
-
in
JDBC
2.0
2PC across hetero
-
geneous databases
Javamail,JAF
1.2
Plus Domino support
J2C
1.0
Bean, container mgmt
JAXP
1.0
XML in EJBs
JAAS
1.0
authentication service
JMX
1.0
(pending)
J2SE 1.4.1
Standard
Level
WebSphere V5.1
RMI
-
IIOP
1.4.1
RMI protocol
JIDL/CORBA
1.4.1
ORB support
JNDI
1.4.1
Naming service
Security
1.4.1
JGSS, JCE, JSSE,
CertPath
Web
Services
Standards
Level
WebSphere V5.1
JAX
-
RPC
1.0
XML RPC (JSR 101)
UDDI
2.0
WS directory
SOAP
2.3
XML message
protocol
Web services
for J2EE
1.1
WS infrastructure in
J2EE (JSR 109)
WebSphere 5.1: J2EE Standards Checklist

Student Notebook


5
-
34

e
-
business for z/OS

© Copyright IBM

Corp. 2005


Course materials may not be reproduced in whole or in part

without the prior written permission of IBM.

The full names of the protocols mentioned are:



J2EE

-

Java 2 Platform Enterprise Edition Specification



J2SE

-

Java 2 Platform, Standard Edition



E
JB

-

Enterprise JavaBeans



JSP

-

JavaServer Pages



JTS/JTA

-

Java Transaction Service/Java Transaction API



JMS

-

Java Message Service



JDBC

-

Java Database Connectivity



JAF

-

JavaBeans Activation Framework



J2C

-

J2EE Connector Architecture



JAXP

-

Java API fo
r XML Parsing



JAAS

-

Java Authentication and Authorization Service



RMI/IIOP

-

Remote Method Invocation
-

Internet Inter
-
ORB Protocol



JIDL/CORBA

-

Java Interface Definition Language/Common Object Request Broker
Architecture



JNDI

-

Java Naming and Directory
Interface



JGSS
-
API

-

Java Generic Security Services Application Program Interface



JCE

-

Java Cryptography Extension



JSSE

-

Java Secure Socket Extension



CertPath

-

Java Certification Path



JAX
-
RPC

-

Java API for XML
-
Based RPC



UDDI

-

Universal Description, Di
scovery and Integration



SOAP

-

Simple Object Access Protocol

Details



There are actually multiple Java standard collections involved in defining the group
of standards required to be supported by a J2EE application environment such as WebSphere
for z/OS
V5.1. The J2SE standards listed are only the most important standards for J2EE as
J2EE specification requires all the core J2SE APIs to be supported.

Currently in J2EE spec 1.3, the Java web services standards are covered by a separate
standards group from

those of the J2EE group. Web services developed in a parallel path to
J2EE, and there is no need for a server to implement a J2EE platform so that it can execute
web services. However, the Web Services for J2EE standard based on JSR109 is included in
the
J2EE 1.4 specification which WebSphere V6 will support. JSR 109 will also
require

most of
the other listed web services standards, so web services will become formally part of the J2EE
platform

You can get the official J2EE 1.3 spec
ification

at:

http://ja
va.sun.com/j2ee/1.3/docs/index.html

Additional Information


I
nfo
rmation

on each standard
:

J2EE 1.3

-

In full, the Java™ 2 Platform Enterprise Edition Specification, v1.3. This lays down
the standards for the complete J2EE platform. It defines:



Applicati
on components such as EJBs, servlets, JSPs, and application clients


Student Notebook


© Copyright IBM Corp. 2005

Unit
5.
Introduction to WebSphere for z/OS V
5
5
-
35

Course materials may not be reproduced in who
le or in part

without the prior written permission of IBM.



J2EE application servers



Container types and requirements



Resource manager drivers for access to databases or other software programs



Database requirements to store J2EE applications and c
onfiguration data



J2EE standard application services (interfaces) required



Database requirements to store J2EE applications and configuration data

J2SE

-

Java 2 Platform, Standard Edition
-

The standard Java platform discussed before
.

HTTP/S

-

Inherited fr
om J2SE networking protocols. It includes a pluggable mechanism for
supporting multiple URL protocols that Java programs can use to access remote web sites.
Note that this is nothing to do with application server transport handler processing
.

EJB

-

Enterpr
ise JavaBeans. This specification defines what a J2EE product (WebSphere)
must do to provide support for enterprise beans. It includes the specification of the EJB
interoperability protocol based on RMI
-
IIOP.

Servlet

-

defines the packaging and deployment

of web applications, whether standalone or
as part of a J2EE application. The servlet specification also addresses security, both
standalone and within the J2EE platform.

JSP

-

JavaServer Pages
-

The JSP specification depends on and builds on the servlet
framework by adding the support of JSPs in web containers
.

JTS/JTA

-

Java Transaction Service/Java Transaction API
-

Defines the User

Transaction
interface that is used by applications to start, and commit or abort transactions. It also defines
a number of

interfaces that are used by an application server to communicate with a
transaction manager, and for a transaction manager to interact with a resource manager (for
example needed by connectors).

JMS

-

Java Message Service
-

Defines JMS provider implementa
tion which must provide
support for both JMS point
-
to
-
point and publish/subscribe messaging, and also make the
facilities available using the required APIs.

JDBC

-

S
tandard is part of the J2SE platform. The J2EE specification requires that a relational
dat
abase be available and accessible from a J2EE product through the JDBC API. It also must
be accessible for application components. Also defines SPI for JDBC drivers that connect to
data base manager
.

Java
M
ail

-

Should include the JavaMail API along with a
JavaMail service provider that allows
an application component to send e
-
mail. Requires an e
-
mail API used by the application
components, and an SPI to connect to mail providers
.

JAF

-

JavaBeans Activation Framework
-

Must support this, required by JavaMai
l
.

J2C

-

J2EE Connector Architecture
-

Defines a required J2EE SPI that allows resource
adapters that support access to Enterprise Information Systems to be plugged in to any J2EE
Student Notebook


5
-
36

e
-
business for z/OS

© Copyright IBM

Corp. 2005


Course materials may not be reproduced in whole or in part

without the prior written permission of IBM.

product. The architecture defines a standard set of system
-
level contracts b
etween a J2EE
server and a resource adapter.

JAXP

-

Java API for XML Parsing
-

This provides support for the industry standard SAX and
DOM APIs for parsing XML documents, as well as support for XSLT transform engines.

JAAS

-

Java Authentication and Authori
zation Service
-

This enables services to authenticate
and enforce access controls upon users. It implements a Java technology version of the
standard Pluggable Authentication Module (PAM) framework, and extends the access control
architecture of the Java
2 Platform in a compatible fashion to support user
-
based
authorization.

JMX

-

Java Management Extensions
-

used by the J2EE Management API to provide required
support for management of a J2EE product. This is not officially part of J2EE 1.3 specification
b
ut is part of J2EE 1.4 specification. WebSphere for z/OS V5.1 includes JMX x.x.

RMI/IIOP

-

(Remote Method Invocation
-

Internet Inter
-
ORB Protocol)
-

This defines how to
support a Java application component that uses RMI to call a method in another applica
tion
component. The IIOP protocol is inherited from the CORBA architecture which was not
developed as a Java specification. There are other RMI protocols that are supported in the
J2EE specification including RMI
-
JRMP (Java Method Protocol) but these are n
ot suppo
rted
by WebSphere for z/OS V5.1
.

JIDL/CORBA

-

(Java IDL/CORBA)
-

allows J2EE application components to invoke external
CORBA objects using the IIOP protocol. These CORBA objects may be written in any
language and typically live outside a J2EE produ
ct.

JNDI

-

(Java Naming and Directory Interface)
-

inherited from the J2SE specification.
It is the
stan
dard API for object naming and directory access. The JNDI API has two parts:



A
n application
-
level API used by the application components to access nam
ing and
directory services



A
n SPI
to
define how to attach to a provider of a naming and directory service.

Security

-

i
nherited from the J2SE specification

JGSS
-
API

-

The Java GSS
-
API contains the Java bindings for the Generic Security Services
Application

Program Interface (GSS
-
API) defined in RFC 2853. GSS
-
API offers application
programmers uniform access to security services atop a variety of underlying security
mechanisms, including Kerberos.

JCE

-

Java Cryptography Extension
-

provides a framework and

implementations for
encryption, key generation and key agreement, and Message Authentication Code (MAC)
algorithms. Support for encryption includes symmetric, asymmetric, block, and stream ciphers.
Also supports secure streams and sealed objects

JSSE

-

Ja
va Secure Socket Extension
-

enables secure Internet communications. It provides
a framework and an implementation for a Java version of the SSL and TLS protocols and

Student Notebook


© Copyright IBM Corp. 2005

Unit
5.
Introduction to WebSphere for z/OS V
5
5
-
37

Course materials may not be reproduced in who
le or in part

without the prior written permission of IBM.

includes functionality for data encryption, server authentication, message integrity, and

optional client authentication.

CertPath

-

Java Certification Path
-

A certification path consists of a chain of certificates that
must be validated in order to establish trust in a subject's public key. CertPath provides a set
of classes and interfaces
for developers who need to integrate this functionality into their
applications

JAX
-
RPC

-

Java API for XML
-
Based RPC
-

You can use the Java API for XML
-
based RPC
(JAX
-
RPC) to build Web applications and Web services, incorporating XML
-
based RPC
functionalit
y according to the SOAP 1.1 specification. JAX
-
RPC is for Web services
interoperability across heterogeneous platforms and languages.

UDDI

-

Universal Description, Discovery and Integration
-

Provides a business registry and
repository service which gives

programs using web services an easy way to locate target web
services

SOAP

-

Simple Object Access Protocol
-

This is an XML based protocol for exchanging
information between computers in the form of a bit stream message. It is platform independent
and can

run over multiple transport protocols

Web
S
ervices for J2EE

-

(JSR 109)
-

This specification defines the programming model and
architecture for implementing web services in Java. The specification will build on the work of
JSRs 67, 93 and 101. The specif
ication will also build on the JSRs for J2EE technologies,
including J2EE itself, Servlets
,

and JSPs.

.

Student Notebook


5
-
38

e
-
business for z/OS

© Copyright IBM

Corp. 2005


Course materials may not be reproduced in whole or in part

without the prior written permission of IBM.



















Figure
5
-
20

What about CICS TS 2.2 and EJBs?

ESNEG1.0

Notes:

CICS support for EJB Session Beans facilitates deployment of server
-
side business logic that
exploits existing and new traditional CICS applications. Enterprises wi
th a strong investment in
CICS skills can evolve them at an appropriate pace into enterprise Java skills.

Operational personnel can deliver all styles of CICS applications. Enterprises continue to take
advantage of investment in traditional AD practices wh
ile building new Enterprise Java AD
practices.

CICS only supports the parts of J2EE which fit naturally with its role as a server
-
side business
logic tier for core transactional business logic that is appropriate to a typical CICS skill set.



It does not pr
ovide the services of a broad web
-
application server.



It does not provide a run
-
time for Java servlets and JSPs.

CICS and WebSphere together can provide an excellent solution for e
-
business!



Student Notebook


© Copyright IBM Corp. 2005

Unit
5.
Introduction to WebSphere for z/OS V
5
5
-
39

Course materials may not be reproduced in who
le or in part

without the prior written permission of IBM.



















Figure
5
-
21

What about WebSphere on Linux?

ESNEG1.0

Notes:

Here are some thoughts about the similarities and differences between WAS WebSp
here
V4.0x for z/OS and OS/390 and WAS AE V3.5 on Linux using zSeries hardware:

Both Linux and z/OS can benefit from zSeries hardware.



Example: IEEE binary floating point hardware assist

z/OS is highly optimized to the zSeries environment.



Linux for zSerie
s contains no zSeries
-
specific enhancements

WAS V4 for z/OS makes explicit use of z/OS QOS capabilities.



WAS AE on Linux for zSeries contains no zSeries
-
specific enhancements

The “traditional” S/390 customer requiring high QOS and significant integration w
ith CICS,
IMS, or DB2 will be best served by WebSphere for z/OS.

The “new” S/390 customer (ASP/ISP) requiring speedy deployment with less stringent
requirements will be attracted to WebSphere on Linux for zSeries.

©
Copyright IBM Corporation 2005
IBM zSeries
22
No
differentiation
RISC/Intel
Linux
WebSphere
AE
Portable Java
Components
zSeries
Linux for
zSeries
WebSphere
AE
Portable Java
Components
zSeries
z/OS
WebSphere
for z/OS
Portable Java
Components
No
differentiation
Relative HW
advantage
Fully exploit
zSeries, z/OS
Provides z/OS
functionality and
availability
Relative HW
advantage
"Traditional" S/390 customers requiring high QoS and integration
with CICS, IMS
or DB2 will be best served by WebSphere for z/OS.
"New" S/390 customers requiring speedy deployment with less stri
ngent
requirements will be attracted to WebSphere on Linux for zSeries
.
What about WebSphere on Linux?

Linux and z/OS benefit from zSeries hardware
-
example IEEE H/W assist

z/OS highly optimized for zSeries hardware compared to Linux for
z/Series

WebSphere for z/OS V5 explicitly uses z/OS QoS capabilities, unl
ike Linux

Student Notebook


5
-
40

e
-
business for z/OS

© Copyright IBM

Corp. 2005


Course materials may not be reproduced in whole or in part

without the prior written permission of IBM.



















Figure
5
-
22

WebSphere for z/OS 5.0

ESNEG1.0

Notes:

WebSphere for z/OS V5.0 was made available in May 2003. It provi
des a “J2EE” 1.3 platform
enablement and supports the J2EE technical specifications at the level required. The Java
language level is Java 2 JDK 1.3.1.

Java applications that executed on WebSphere V4.0x for z/OS and OS/390, needed to be re
-
deployed into We
bSphere for z/OS V5.0 configuration when customers moved to the
WebSphere for z/OS V5.0 product. However, the Java code did not need to be altered in the
application (unless you wanted to take advantage of new functionality). Therefore, this was an
evoluti
onary change for existing Java application programs

However, the WebSphere for z/OS V5.0 infrastructure is very different from the WebSphere
V4.0x for z/OS and OS/390 implementation. It is much more efficient, having removed
requirements for LDAP and DB2 a
s required infrastructure support components, but it also has
a very different address space set up from V4.01. Customer V4.01 application and run
-
time
configuration information cannot be re
-
used as is
-

it has to be manually migrated to the new


Student Notebook


© Copyright IBM Corp. 2005

Unit
5.
Introduction to WebSphere for z/OS V
5
5
-
41

Course materials may not be reproduced in who
le or in part

without the prior written permission of IBM.

administra
tion environment. For the systems administrator/implementation professional it is a
revolutionary change, involving significant migration effort.

A summary of some of the major changes and enhancements:



A single HFS data set stores the systems management c
onfiguration data that used to be
kept in DB2, the JNDI namespace that used to be kept in LDAP, and the application
components which were previously in a separate HFS.



The HTTP transport handler is a required component for any application server that
suppo
rts access to web applications from the intranet/internet.



The HTTP server plug
-
in can still receive requests to run WebSphere for z/OS V5.0 web
applications, but they are redirected through the server transport handler, using HTTP
protocol instead of goin
g straight to web container



The support for Java Management Services (JMS) is now integrated into the product and
multiple JMS servers can be configured in a WebSphere cell



Component broker is no longer part of the run time support services, and CB applica
tions
are no longer supported.



There is a new GUI based administration tool where the client requires only a standard
web browser and applets to execute. The SMEUI is gone.

The internal topology of the WebSphere for z/OS V5.0 components now matches the top
ology
of the WebSphere V5 distributed product. As a result, both WebSphere for z/OS V5.0 and
WebSphere distributed V5 use the same administration and operations management tool and
the same administration processes. An administrator that is familiar with t
he WebSphere
distributed product will see very little difference between the two environments, except for
some extra input fields on a few panels.

It is now much simpler to migrate J2EE applications between WebSphere Distributed and
WebSphere for z/OS V5.0
. There is no difference between the two WebSphere versions in the
areas of application development tools, administration of applications, automation of
management functions, and overall configuration management. There is a small difference in
deployment b
etween the two environments, so an application developed for a distributed
WebSphere environment does need to be re
-
deployed to run in z/OS. This does not however
require any change in the application code, but the application must be “re
-
packaged” for z/O
S
execution.

Student Notebook


5
-
42

e
-
business for z/OS

© Copyright IBM

Corp. 2005


Course materials may not be reproduced in whole or in part

without the prior written permission of IBM.



















Figure
5
-
23

WebSphere for z/OS V5.1

ESNEG1.0

Notes:

At first

glance, WebSphere for z/OS V5.1 looks very similar to WebSphere for z/OS V5.0 and
this is quite true. There are no significant changes in the way the applications interact with the
WebSphere J2EE platform, or in the product structure and topology.

So what

has changed?

WebSphere for z/OS V5.1 requires the SDK for z/OS V1.4.1 to provide the core Java platform
for applications. Applications compiled using the 1.3.1 SDK are fully compatible, but there are
issues when you create new applications that might run
in mixed WebSphere V5.0 and V5.1
environment

A new, optional, Web Services Gateway can be configured as a proxy agent to front web
services requests to Java application components. It provides a fully scalable and manageable
web services application enviro
nment, and reduces the IP ports needed.



Student Notebook


© Copyright IBM Corp. 2005

Unit
5.
Introduction to WebSphere for z/OS V
5
5
-
43

Course materials may not be reproduced in who
le or in part

without the prior written permission of IBM.

A migration utility can be used to migrate the WebSphere for z/OS V5.0 configuration including

all installed application programs into a new WebSphere for z/OS V5.1 configuration data set.

Details



The general messa
ge is that there are a few changes due to enhanced functionality
but other than that, WebSphere for z/OS V5.1 is very similar to WebSphere for z/OS V5.0.

Although WebSphere for z/OS V5.1 requires the SDK V1.4.1, it does not significantly exploit
the new se
rvice options in the J2SE 1.4.1 platform. However, this now positions WebSphere
for z/OS V5.1 alongside the WebSphere distributed product which had already made the
move in WAS V5. The SDK will be fully exploited in WebSphere V6 which will be compatible
wi
th the J2EE 1.4 standard specification.

The issue about mixed V5.0 and V5.1 application support will be discussed later in this topic.
For now, tell them that Java applications compiled using the SDK V1.4 Java compiler will not
execute successfully on Web
Sphere for z/OS V5.0 application servers unless a special option
is set.

As mentioned earlier, web services standards are not part of the J2EE 1.3 specification,
although they are part of J2EE 1.4. However, WebSphere for z/OS V5.0 did provide a
technical
preview of an environment which could run web services based on J2EE application
components executing in WebSphere. A precursor of the web services gateway was also
shipped with WAS V5.02. With WebSphere for z/OS V5.1, the web services environment has
been

updated to support the Java standards for web services that are in J2EE V1.4, and the
new gateway provides a robust execution environment for web services which includes use of
QOS and security to scale and control the web services workload.

The migratio
n utility is needed if you want to move an existing WebSphere for z/OS V5.0
application environment immediately into a new WebSphere for z/OS V5.1 platform. In a multi
-
node cell, this can be achieved one node at a time. Essentially the tools build a new
co
nfiguration HFS in V5.1 format, and then import the contents of an existing WAS V5.0
configuration HFS.

Student Notebook


5
-
44

e
-
business for z/OS

© Copyright IBM

Corp. 2005


Course materials may not be reproduced in whole or in part

without the prior written permission of IBM.



















Figure
5
-
24

Packaging Modules


tebpphere sRK1

bpkb䜱KM

Notes:

The WebSphere Distributed product provides two separate deliverables (packages).

The
Base Application Server
includes the code for the
Version 5 Application Serve
r

-

providing full J2EE 1.3 compliance. It also includes the code for the
Node Agent,

which will be
dormant if installed in a single server environment.

The
Network Deployment

deliverable includes the
Deployment Manager
. This configuration
enables customer
s to run multiple application servers, on a single or multiple distributed
systems that are centrally administered. This package fully exploits the Node Agent support

The old
Enterprise

Edition V5.0 deliverable is now integrated into a new separately insta
lled
package named
WebSphere Business Integration Server Foundation V5.1
.

The
WebSphere for z/OS V5.1

product arrives in a single package which includes the Base
Application Server, the Node Agent support and the Deployment Manager.

Note that all package
s are delivered bundled together with SDK 1.4.1 Java code.

©
Copyright IBM Corporation 2005
IBM zSeries
25

Two product packages
-
can be ordered and installed separately

"WebSphere V5 Enterprise Edition" V5.0 has been replaced by "Web
Sphere
Business Integration Server Foundation" V5.1
Base App Server
Network Deployment
Distributed
z/OS
App
Server
App
Server
Node
Agent
Node
Agent
Deployment
Manager
Deployment
Manager

Single product package " WebSphere Application Server for z/OS"
Packaging Modules
-
WebSphere V5.1


Student Notebook


© Copyright IBM Corp. 2005