JMX MBean multiprocess model request flow for WebSphere Application Server for z/OS
Use the JMX dynamic proxy capability, applications that depend on JMX operations can exhibit consistent behavior whether the server architecture uses a single process model or a multiprocess model.
All the MBeans that the product run time provides are capable of running under the single process model employed on distributed platforms, or the multiprocess model employed by the product for z/OS . User MBean providers might need to modify their MBeans so that they work in the product on both distributed platforms and z/OS. For more information, view the APIs documentation.
The simplified dynamic proxy model presented here discusses the two general request flows that exist in the multiprocess model. Operation requests on an MBean can be initiated from one of two places:
- Within an application component running under the same servant
process as the MBean.
- Outside the server through one of the JMX connectors (SOAP, Remote Method Invocation (RMI), HTTP, and so on).
Requests that come from an application component generally follow this flow. The application component sends its request to the servant components. The servant components redirect the request to the control process where the dynamic proxy for the MBean runs. WebSphere Application Server automatically generates the MBean dynamic proxy during runtime. If the request calls a method that the MBean provider defined with a unicall option, the dynamic proxy in the control process randomly dispatches the work, with MVS™ workload management (WLM), to one servant process. If the request calls a method that the MBean provider defined with a multicall option, the dynamic proxy in the control process, in conjunction with WLM, distributes the work to all the servant processes that have activated the MBean.
MBeans associated with application components are automatically registered with the dynamic proxy in the control process as part of the MBean activation process when WLM starts the servant process. MBeans that are activated in a single servant process, such as an MBean created and registered dynamically by an application component, cannot participate in multicall operations. Refer to the topic Extending the WAS administrative system with custom MBeans for information on how to register an MBean.
Each servant process that completes the work optionally sends a response back to the control process. If the MBean was defined with a unicall option, and the return type is anything but void, the control process returns the response to the servant that made the request. The servant server components then return the response to the application component. If the MBean was defined with a multicall option, the MBean inside each servant process runs separately and finishes processing the request at different times. After all the requests are processed, we might need a result aggregation and an event aggregation to properly return a result to the application component.
Requests that come from a remote location outside the server generally follow this flow. The remote location sends its request to the control process where the dynamic proxy for the MBean runs. WebSphere Application Server automatically generates the MBean dynamic proxy during run time. The next part of the request process behaves the same as a request that originates from an application component. If the request calls a method that the MBean provider defined with a unicall option, the dynamic proxy in the control process randomly dispatches the work, with MVS workload management (WLM), to one of the servant process in the list of servant processes that have activated the MBean. If the request calls a method that the MBean provider defined with a multicall option, the dynamic proxy in the control process, in conjunction with WLM, distributes the work to all the servant process that have activated the MBean.
The flow of the response back to the remote location is similar to the response back to the application component. Each servant process that completes the work optionally sends a response back to the control process. If the MBean was defined with a unicall option, and the return type is anything but void, the control process returns the response to the remote location. If the MBean was defined with a multicall option, the MBean that runs inside each servant process runs separately and finishes processing the request at different times. After all the requests are processed, we might need a result aggregation and an event aggregation to properly return a result to the remote location.
Subtopics
- (zos) JMX dynamic proxy concepts
A JMX dynamic proxy coordinates MBean requests among multiprocess servers. This section discusses the main terms associated with a JMX dynamic proxy. - (zos) Example: The SampleStateMBean MBean
Use this example to guide you in developing user MBeans that work for the WAS on both the distributed platforms and the z/OS platform. The example uses all the special handlers to show its dynamic proxy MBean responsibilities and capabilities. The SampleStateMBean example keeps track of its state and generates state change events when it invokes setter methods.
Related concepts