|
Problem |
This is a summary of the basic differences
exist between WebSphere® Application Server on z/OS® or OS/390® and the
corresponding version on the workstation platforms. |
|
|
|
Solution |
COMMONALITY OF CODE
The z/OS and OS/390 versions of WebSphere Application
Server incorporate updates from the workstation or distributed platforms
about once every six months. The z/OS and OS/390 versions of the
Application Server are usually compatible with the distributed versions.
The following discussions cover the main differences.
EBCDIC FILES VERSUS ASCII FILES
On the distributed platforms, HTML files and JAVA™
Server Pages, are stored in ASCII format. On z/OS and OS/390 it depends on
the JSP specification level. If running with level 0.91 and 1.0 files are
stored in EBCDIC format. If running specification level 1.1 files served
by the Application Server are stored in ASCII.
Files in the classpath
deployedwebapp.<webapp-name>.classpath require an ASCII format.
For more information on using EBCDIC versus ASCII
formats for WebSphere Application Server on z/OS or OS/390, see the latest
documentation for the appropriate version of the Application Server at the
following URL:
http://www.ibm.com/software/webservers/appserv/library_390.html
SESSION INVALIDATION
Currently the Application Servers on z/OS or OS/390
have implemented a stricter set of rules for the invalidation of sessions
than the Application Servers on the distributed platforms.
Whether you use z/OS, OS/390, or a distributed
platform, a session can become invalid in one of the following
ways:
- The session can automatically expire
after a set amount of time.
- You can use the invalidate( ) method on
a specific request to invalidate a session that was previously obtained
for this request through a getSession( ) method.
Because the Application Servers on the distributed
platforms are more lenient, a session can become invalid on these
platforms for the following reason:
- You can invalidate a session on a
request using a session ID that was not obtained through a getSession( )
method for that request. For example, you can invalidate one session on a
request associated with another session.
If you create your application on a distributed
platform using this technique, and then port this application to the z/OS
or OS/30 operating system, you will not be able to invalidate the session.
The Application Servers on the z/OS or OS/390 operating systems throw
an
IllegalStateException.
A description of this technique used on the
distributed platforms follows:
- You open a browser, access your Web site, and log
into your application as username.
- The Application Server creates a session object and
a session ID associated with this request if the application did a
getSession( ) method. The session is called Session 1, the session ID is
called S1, and the request is known as Request 1.
- While logged onto your application from the same
browser, the user makes a new request. This request is known as Request 2.
Given that the application did a get session for Request 2, the session ID
returned by the Application Server is the same session ID created for
Request 1.This session ID is S1.
- The Application Server associates the session ID of
S1 with Request 2 because a cookie passes S1 to the Application Server,
with the request object for Request 2.
- If you open another browser, access your Web site
and log in as username, the Application Server creates a session object and a
session ID associated with the second browser, given that the application
did a getSession( ) method. This session is called Session 2, the session
ID is called S2, and the request is known as Request 3. A new session
object, Session 2, was created because Request 3 came from a new instance
of the browser. The new browser instance did not have any cookie
information. Therefore, no session ID was passed to the Application Server
on Request 3.
- When you make additional requests with the second
browser session, a cookie passes the session ID of S2 to the Application
Server.
Customers have written applications that save the
session ID reference for Session 1. When the customer makes Request 3, the
application can then determine that jsmith associated with Session
1 and jsmith associated with Session 2 represent the same user. The
application determines that Session 1 is older than Session 2. Because
Session 1 is older, the application attempts to explicitly invalidate the
session ID of S1 on Request 3 by using the invalidate method. However, S1
is associated with Session 1 and Request 3 is associated with Session
2.
The z/OS and OS/390 versions of the Application Server
do not allow invalidation of the session ID of one session on a request
from another session. Invalidate S1 by issuing a request that contains the
S1 session ID established for Session 1. Otherwise, the Application
Servers on the z/OS or OS/390 operating systems will throw an
IllegalStateException.
The Application Server on the distributed platforms do not throw this
exception. |
|
|
|
|
|
|
|