Java Management Extensions MBean multiprocess model request flow for WebSphere Application Server for z/OS

Using the Java™ Management Extensions (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 application programming interfaces documentation.

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 that is created and registered dynamically by an application component, cannot participate in multicall operations. Refer to the topic Extending the WebSphere Application Server 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, you 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, you might need a result aggregation and an event aggregation to properly return a result to the remote location.