Program guide > (deprecated) Partitioning facility > z/OSzOS platform considerations > z/OSzOS restrictions in WPF
|
| |
|
|
Deprecated feature: The partitioning facility (WPF) feature is deprecated. You can configure partitioning with WebSphere eXtreme Scale.
WPF programming pattern in z/OSzOS
This article describes the partitioning facility (WPF) programming pattern in Extended Deployment for z/OS v6.0.1.
Since the WPF-WLM Internet Inter-ORB Protocol (IIOP) routing is not supported in Extended Deployment for z/OS v6.0.1, applications must handle their partition routing using the Java™ Message Service (JMS) technology or other mechanisms.
The Java Message Service (JMS) based routing mechanism is illustrated in the following figure. Two requests are shown, request 1 and request 2. Notice that each request must go to a designated JMS topic/queue for a partition routing. The JMS topic/queue should forward the request to the target partition, which prepares to process the request and sends the response to a designated JMS topic/queue for routing responses. Though the execution steps are the same, the order of request execution is not guaranteed since many factors depend on execution, including machine location, server performance, and the network setup.
The request routes for request 1 (1-1.3) and request 2 (2-2.3) are shown in the following graphic, resulting in the Appclient getting responses (3).
The following steps describe the route of request 1. Note that for request 2 or any other request follows this same route. Each request execution is independent from each other and the order in which they are received is not guaranteed.
- 1. AppClient determines the target partition for the request, and sends the request as a JMS message to the target JMS topic/queue that represents the application partition.
Application partitions in ClusterMembers are tied to and always listen to their corresponding JMS topic/queue (using AsyncBean). For example, in Partition 1 (P1), the application partitions receive the JMS messages whenever new messages arrive at their corresponding JMS topic/queue.
Just like normal WPF enabled applications, there is a partitioned stateless session bean (PSSB) that implements the PartitionHandlerLocal interface. The partitionLoadEvent(String partitionName) and partitionUnloadEvent(String partitionName) method of the PartitionHandlerLocal interface are the points to bind and unbind a partition to a JMS topic/queue.
partitionLoadEvent(String partitionName) - this means the partition with the name as the passed partitionName is activated on this system . Start or bring up the partition worker thread (or you can use the AsyncBean worker thread) that is bound to the JMS topic/queue that is designated for the partitionName partition. You should keep a reference to the partition worker thread in order to stop or destroy it when corresponding partitionUnloadEvent occurs.
partitionUnloadEvent(String partitionName) - this means the partition with the name as the passed partitionName is deactivated on this system. The partition worker thread will unbind with the JMS Topic/Queue that is designated for the partitionName partition, and stop or destroy the corresponding partition worker thread.
- 1.2 The JMS topic/queue forwards the request to its corresponding application partiton.
- 1.3 The application partition processes the incoming request and sends the response to a JMS topic/queue that is designated for routing all responses.
- 3. AppClient receives responses from the response JMS topic/queue to check the execution result.
Parent topic:
z/OSzOS restrictions in WPF
Related concepts