Application Server

Digg This!

Page 2 of 2   « previous page

WebSphere for z/OS V5.1 and higher can support workload classification by URLs, MDB listener ports, and EJB methods. The WebSphere administrator can set up an XML mapping file to map requests to multiple transaction classes. The transaction class-to-service class mapping rule is defined by the zWLM policy. WebSphere for z/OS and zWLM provide a more flexible way to control your application workload than on distributed platforms.

Application Development Impact
The WebSphere for z/OS server has a unique architecture that's deeply integrated with the z/OS platform.

The good news for application development staff is that the architecture doesn't change the J2EE programming model. The application runtime control granularity provided by WebSphere for z/OS can be leveraged to simplify your application design.

Let's walk through an example here.

Image a fictional banking application service provider. It's developing its next-generation Lending process system on WebSphere for z/OS. The Lending process system provides all the functions a loan officer needs to process a loan application and maintain it.

One of the application's functions is to let a loan manager run a campaign report. Since running a campaign report is very time consuming, an architectural decision is made to implement it in an asynchronous process using a Message Driven Bean (MDB). The report requester won't wait for the report online. When the report is ready, the requester will be notified by e-mail. Then he can come back to check and view the report. If the application is to run on a distributed platform, it should have certain kinds of workload management logic built in to prevent the campaign report process from monopolizing application server resources and impacting online transaction processing and system throughput. The alternative is to use a dedicated server with a dedicated application for the campaign report process, but it makes the environment more complicated.

WebSphere for z/OS provides a better solution for this kind of problem. As shown in Figure 3 the problem is solved without implementing any workload management logic in the application itself.

Two service classes are defined for the Lending system:

• LSONLINE - 95% of the transactions finish in 0.5 seconds with an importance number of 2
• LSASYNC - 80% of the transactions finish in 2 hours with an importance number of 3

The online transactions are classified to service class LSONLINE based on URLs. Campaign report requests are classified to service class LSASYNC based on MDB listener ports. Requests with different service class will be processed by different address space. So there's no chance of the campaign report process fighting the online transaction process for threads. zWLM manages computing resource to meet the performance goals set up for the application. It always favors the online transaction process whenever a resource shortage occurs.

The same technique can also be used to meet different customers' service level requirements. The fictional service provider may need to provide a dedicated server for major customers for isolation purposes. As shown in Figure 4, requests coming from different customers are classified to different service classes (Service Class I and II) with their own performance goals. The system provides different levels of service to different customers. The highest importance number (1) can be given to the most important business customer so that the service level agreement is guaranteed. Further more, you can define multiple zWLM policies and active them in different time periods in your application. So you can run your application in an on-demand way.

Application Performance Impact
I'm going to break the bad news here. The WebSphere for z/OS server architecture makes application performance tuning more complicate than for distributed platforms. Application performance tuning is too big a topic. A separate article is needed to cover it. However, it's helpful to point out some basic zWLM-related concepts.

The WebSphere for z/OS server architecture determines that workloads of the J2EE applications running in WebSphere for z/OS are classified to a service class before they get processed. Unfortunately many application developers ignore this fact. I've frequently seen application development teams do load testing and performance tuning without knowing which service classes the application being tested was running under. And people often ask why an application run very well on a distributed platform but was bad when it runs WebSphere for z/OS. When asked about the service classes, people usually have no idea. If your application is running under an inappropriate service class, you'll never get the performance desired no matter how you optimize your application code. You have to understand that if zWLM can meet the performance goals by allocating a certain amount of service units, it won't try to allocate more resource to make the application always exceed its performance goal. That only happens when the whole machine is dedicated to your application. The basic rule is: if you don't ask for it you'll never get it. So try to figure out how many service classes you need and make the performance goals aggressive enough. Of course they should have enough priority.

With applications running on WebSphere for z/OS share resources with other subsystems on z/OS, zWLM treats workloads in WebSphere for z/OS the same as that of other subsystems such as CICS and DB2. The performance goal and priority for your workload should be reasonable. If the performance goal is too aggressive, there are two possible results. One is that zWLM will try very hard to meet the goal if your service class has the highest priority by sacrificing some other subsystems' performance. The other result is that zWLM will just give up because the goal is too hard to meet. Of course, in the latter case the application's performance gets worse.

At first you may feel that WLM is hard to deal with. Try to understand it better. That's key to making your applications run better on z/OS. You may need to be familiar with RMF reports. It tells you how well the system is doing its work.

WebSphere for z/OS is also a CPU-intensive subsystem on z/OS. If the CPU coefficient is high and the service class is aggressive, performance will be optimal.

Conclusion
WebSphere for z/OS is challenging to deal with because of its deep integration with z/OS. The unique server architecture combined with zWLM does produce a better way to control application workload to meet business goals. It makes it possible to develop enterprise applications with better quality of service (QoS).

Subsequent articles will cover other interesting topics such as topology, scalability and high availability, security, performance tuning, connectivity, and trouble shooting.

Resources

WebSphere product library : www-360.ibm.com/software/webservers/appserv/was/library

IBM product manual: z/OS MVS planning: Workload Management SA22-7602

For more information on how to set up workload classification rules, control the servant region workload profile, and control the mini and max servant region number you can refer to these articles.
www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP100449
www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/TD101152

Page 2 of 2   « previous page