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 WebSphere Application Server runtime provides are capable of running under the single process model employed by WebSphere Application Server on distributed platforms, or the multiprocess model employed by WebSphere Application Server for z/OS. User MBean providers might need to modify their MBeans so that they work on both the WebSphere Application Server distributed platforms and the WebSphere Application Server for 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.
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 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 process.
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.