Level: Intermediate Alan Little (alanl@us.ibm.com), Software Architect , IBM
03 Mar 2003 This question and answer article features Alan Little, lead architect for WebSphere z/OS, who answers top questions from users about WebSphere Application Server for z/OS.
This month we ask Alan Little to answer your
WebSphere® Application Server for z/OS questions.
WebSphere Application Server for z/OS is for enterprise customers requiring the benefits of the J2EE platform coupled with the robustness of zSeries hardware and the power of z/OS software.
Alan is lead architect for the WebSphere Application Server for z/OS development team.
For more information, see WebSphere Application Server zone.
We appreciate and thank all the WebSphere developers who submitted questions.
Question: We're using WebSphere Application Server for z/OS V4 in my company. Our main question is should we use the HTTP Server or HTTP Handler as an entry point to our applications? Indeed, IBM's position is not very clear on that point. In the general documentation, it seems that IHS won't have new evolutions (after version 5.3). On the other hand, in the WebSphere Application Server redbooks, it is said that the HTTP handler can't properly be used for session affinity outside the control region. What's your opinion on that? (submitted by Frederic Fadda)
Answer: It depends on who the client is and how much control over the client you have. The HTTP Handler, a HTTP compliant server side runtime, follows the standard to the letter. Not all browsers follow the standard so closely. Most Web servers (HTTP servers) make accommodations to get around the differences in browsers. The rule is the server makes right, meaning that it is the Web server's responsiblity to handle things that are correct from the browser. They also do additional logging and handle static file server better. Therefore, Web servers make good intermediaries between the browsers and the application server. With the latest plugin support in WebSphere for z/OS V4 and in the upcoming V5 release, there are no issues with session affinity managed from the
Web server to the application server. Internal protocols between the plugin and the application carry enough information to get requests to the proper control region (and then on to the server region), where the HTTP session exists.
Going directly to the HTTP Handler in the application server to obtain access to servlets or JSPs will perform better than going through the HTTP Server. However, the HTTP server handles the session affinity routing for stateful workloads.
If your company controls the client side of the application, going directly to the application server through the HTTP Handler would be my first choice. If you do not control the client, or for performance reasons feel that you need a large Web tier in front of the application server (to handle static portions of your application), then the HTTP Server with a plug-in driving servlet and JSP requests to the application server seem to be the right choice. Both configurations have their place in the design of Web application environment. There are advantages and trade-offs for each configuration.
Question: Do you have recommendations on the deployment of applications in production? How many servers and how many instances must we use virtual host and context root, and how many VIPAs? The administration of these applications: unplanned and planned outages, new version, new application, and the impact on other applications? (submitted by FV)
Answer: This is a very open question, and it really depends on the applications and what characteristics that you want for those applications. For most z/OS customers, high availability is a major concern so one recommendation is to ensure that you run your application servers as part of a cluster. Also, put the cluster members on different systems in the sysplex. WebSphere for z/OS uses the z/OS Workload Manager (WLM) to balance work across the cluster members according to service level definitions that an installation provides. You can configure the cluster to use the z/OS automatic recovery manager (ARM) to recover cluster members upon failures.
For applications that have different life cycles (need to be started and stopped at different times), then it is important to separate these into different clusters. Unlike the traditional z/OS environments, WebSphere allows you to group workloads into different processes (servers). The local/remote transparency capability of J2EE lends to the separation of workloads into separate servers for operational reasons. The application does not have to be recoded to separate them. The J2EE application assembly process allows the application to be assembled in multiple ways.
VIPA (a virtual IP address, which allows a single IP address to be shared across a cluster) improves the single system image of the cluster. It is dependent on the communications protocols as to when they should be used.
Question: Do you know if a new version of the IBM ® HTTP Server for z/OS is coming? And if not, why? Is there an equivalent of the Edge Server for distributed platforms on z/OS?
Can we use a sysplex distributor? (submitted by FV)
Answer: The HTTP Server for z/OS is shipped with the z/OS operating system. There is no major releases planned for
the HTTP server. WebSphere for z/OS delivered an additional plugin for the HTTP server that
allows forwarding of HTTP requests to the application server for servlets and JSPs. The previous plugin that
was provided did a protocol conversion from HTTP to IIOP. The new plugin performs better and is consistent
with the plugins provided for off platform Web servers.
There is no Edge Server that runs on z/OS. However, WebSphere for z/OS makes the Edge Server for the distributed
platforms available for WebSphere for z/OS customers.
Yes, you can use the sysplex distributor to distribute requests to the Web server, which then forwards requests to the
application server. The plugins in the application server handle any affinities created due to HTTP sessions.
Question: Given that WebSphere Application Server V5.0 for z/OS includes WebSphere MQ under the covers as the local JMS provider, can I from a remote Solaris system use a WebSphere MQ client application to retrieve messages held on a z/OS local queue? (submitted by LS)
Answer: Yes, it is possible to connect to a queue being messaged by the Integral JMS Provider (IJP) that is running on z/OS from a remote Solaris. The host name and port address from the z/OS instance of the IJP is used to configure the queue for the remote Solaris machine.
Question: If you consolidate multiple J2EE applications in one J2EE server, are there any possibilities for hot deployment and dynamic reloading? At the moment it seems as if the complete J2EE server will be restarted if you redeploy just one of its EAR files. By the way, what is the recommended way of deploying hotfixes
with V4? (submitted by Andre Mueller)
Answer: One of the design points of WebSphere for z/OS depends on replication to allow applications to be upgraded or replaced without a perceived outage for the clients of the application. This means that it is expected that you will have at least two server instances for a server in V4 or two cluster members for a cluster in V5 (this is a terminology change that is being introduced in V5). To upgrade the application, the server instance is removed from the server, upgraded, and then returned to the server. This is performed until all of the server instances have been upgraded. It is the application provider's responsibility to ensure that all interfaces that are upgraded are done so in a compatible manner. Incompatible changes need to consider another application, which means that the client needs to change as well. However, the old application level could run along side the new application in the server at the same time.
WebSphere for z/OS is a deployment platform, where you run production workloads. The replication approach is a proven approach for production workloads on z/OS. For the development platforms for WebSphere (Windows, Linux, and so on), it makes more sense to provide a mechanism to reload applications. This enables the edit-compile-debug cycle to move much more quickly, but there is a significant risk that a change causes the server or the application to fail. On production systems where the applications are stable, dynamic reloading approach is too risky and uses system resources that could be applied to getting production work completed.
Question: What information can you share about the relationship (functionality, configuration requirements, etc.) between the JTA support in Version 5 with Resource Recovery Services? (submitted by Mitch Johnson)
Answer: Java Transaction API (JTA)
is a set of APIs that are associated with the Java Transaction Service (JTS). On z/OS, JTA and JTS are mapped on to our previous implementation of OTS, which is the Corba-based Object Transaction Service. The OTS protocol allows for distributed object servers to coordinate a distributed 2-phase commit transaction across multiple application servers that support the protocol. This OTS protocol allows for the transaction coordination within an application server to be managed by a local transaction manager. WebSphere for z/OS maps down on to Resource Recovery Services (RRS) to perform this local transaction management.
Over the last several years, the z/OS operating system has been providing a local transaction manager, RRS, in the base operating system. This transaction manager allows for 2-phase commit transactions to be coordinated across the resource managers that exist on z/OS (CICS, IMS® TM, IMS DB, DB2®, MQ). Mapping OTS on top of RRS, along with new connection packages to the resource managers, allows WebSphere to coordinate transactions that are composed of resources that exist in all of these resource managers.
In Version 5 of WebSphere for z/OS, there is a requirement to support the XA protocol in addition to the existing RRS protocol.
This requirement allows the protocols to pass
the J2EE 1.3 compliance test for JCA connectors. The JCA connector specification provides a set of service provider interfaces (SPIs) that require XA resources. This has been accomplished within WebSphere by mapping the protocol on RRS. This mapping, along with additional code in WebSphere, allows XA-based connectors to be plugged into WebSphere.
Question: When do you think will Websphere 5.0 support JDK1.4? Can the JDK component in WebSphere Application Server be made pluggable just like any other application server? (submitted by SE)
Answer: The plans for moving WebSphere to SDK 1.4 are still being worked on.
We are looking at making the SDK component pluggable so that you can use different levels.
One of the issues for
WebSphere for z/OS is the tight relationship between the Java ORB and the z/OS runtime. This area that has changes
between SDK 1.3.1 and SDK 1.4 will require code to be delivered by WebSphere in order to change the SDK levels.
In addition to actual code changes that are required, the WebSphere development team spends a tremendous amount of
time regression testing the WebSphere runtime with new levels of software. Changes in the SDK
require a full regression test so that we can certify that the runtime can run with the new SDK level.
Question: Can I create a JCA-based solution to access a CICS transaction on z/OS?
Can I use WebSphere Studio Application Developer IE 5.0, or should I use EAB of VisualAge for Java 4.0 as the development tool? Our solution will be
deployed on WebSphere for z/OS 4.02 and we will be using CTG 5.0. (submitted by Surajit Dutta)
Answer: You say that you are going to deploy your solution on WebSphere 4.02 on z/OS. I would recommend
WebSphere 4.0.1 SL 4 (the release equal to 4.0.4 on the distributed implementations). With this level of code, I
recommend that you stick with VisualAge for Java 4.0 and the Enterprise Access Builder (EAB) runtime. This deploys in the
WebSphere for z/OS 4.0.1 SL 4 runtime, using a JCA connector to CICS using the CICS Transaction Gateway (CTG).
Look for WebSphere for z/OS V5, WebSphere Studio Application Developer (hereafter called WebSphere Studio) IE 5.0, and CTG 5.0 runtimes in the middle of 2003
when the application server is generally available. I would then migrate from the VisualAge for Java solution to a
WebSphere Studio IE 5.0 solution.
The VisualAge for Java 4.0 solution is scheduled to go out of service later this year.
Question: We have a J2EE application under JBOSS that we want to port to z/OS OS390 under MVS USS.
Some are considering porting JBOSS as opposed to using WebSphere because of cost ($35K per engine).
I do not think this a wise move for this platform. I need some technical help stating reasons why this
should not be done and the benefits WebSphere would offer on this platform over JBOSS. (submitted by Mike S.)
Answer: (Long answer) While I agree with your assertion that it may not be a good idea, it depends on the requirements for the application.
WebSphere on z/OS is designed for scale, availability, and integration with the operating system and the middleware that
exists on the platform.
Scale: The architecture for the WebSphere Application Server on z/OS is designed with parallel sysplex in mind.
Many of the designers and developers that built the application server are the same ones that built parallel sysplex. This
design takes replication as a critical design point. Many design points that were built into CICS, IMS, and DB2 have
been included into WebSphere. For example:
- A split server design, this includes a control region that is included in the kernel of the operating system. This
process serves as the communication end point for requests landing in the server. The communications layer uses
true asynchronous I/O for receiving requests from the network, and uses highly scalable dispatching capabilities within
the operating system (SRBs) to receive and process work. Once a request has been received, there are hooks into
the z/OS Workload Manager to classify the work request. This classification allows the operating system and WebSphere
to manage the performance of the request by adjusting resources that are available for the request to use (such as
CPU cycles, memory, I/O bandwidth, and many others). Once the request has been classified, it is then placed on a queue
where the other half of the server picks it up to operate on it.
The second process type is a servant (server region). There are multiple servants processing work for a
server. The number of servant processes is controlled by the z/OS Workload Manager (or installation policy). This
is the process where the application runs in application state (Key 8, problem state). The servant takes
a request from the WLM queue. The servant then obtains the
request from the controller region and dispatches the request through the Web or EJB container onto the application.
What this split design gives the installation is the ability to isolate workload. There are policies to allow only a single
request into the servant process or multiple requests, depending on the installation's level of trust of the application
code. This isolation also hides the application's security information from the application in protected memory.
This design also allows the Workload Manager to segment work that has similar performance goals in the same processes. This
allows for a more efficient management of system resources.
This design also segments the bulk of the runtime processing from the application processing, it is possible to run many
servant processes to a single control process, thus greater scaling for a single server over JBOSS.
- The split server design also allows fewer processes to restart upon a failure. Only the controller processes need
to restart to recover transactional locks.
For a single process server, each process would need to be restarted.
This is extremely important when attempting to recover a system that has failed.
Availability: The architecture for WebSphere Application Server promotes clustering. It is recommended that each server is
replicated into a cluster. This allows the runtime to route around components when they fail. One important lesson from
parallel sysplex is that no matter how much time or effort you spend on a component, it will fail. The goal is to have redundant components that can take over for the failing component, and recover the component as quickly as possible.
Integration: WebSphere Application Server pushes down on a component of the z/OS operating system, Resource Recovery Services, to provide transactional capabilities. This layering allows a WebSphere application to access resources
that are housed in z/OS resource managers such as CICS, IMS TM, IMS DLI, DB2, MQ, and to coordinate a two-phase transaction
across these resources managers.
The application server also has strong integration with various components of the z/OS environment such as RACF for security,
z/OS consoles for automation, SMF for charge back accounting, and Tivoli for performance monitoring.
Question:
We have WebSphere Application Server z/OS 3.5 SE. We have only one application running on it that requires no J2EE. Simple JSP/HTML/JAVAScript. Internal use. Less than 50 users. For now, the application will stay on z/OS.
For the application mentioned above, which version of z/OS is the simplest and cheapest to have?
(submitted by Bijan A.)
Answer:
I would use what you are using now, WebSphere Application Server for z/OS 3.5 SE. Note that 3.5 goes out of service in August 2003. If this is a concern, then I would upgrade to WebSphere Application Server 4.0 using the simple configuration option, which should run this application unchanged.
Resources
About the author  | 
| | Alan Little
is a WebSphere Application Server for z/OS expert in IBM Poughkeepsie, New York.
|
Rate this page
| 
