Using Jolokia in proxy mode enables for agentless operation on the target server. A dedicated agent deployment proxies by accepting Jolokia requests as input, translating them to JSR-160 requests for the target. This setup is described in Chapter 2, Architecture. As noted there, the real target is given within the original request, which must be sent as a POST request.
Agents of all types support the proxy mode. However, since one has usually the free choice of platform for a dedicated Jolokia proxy, an enviroment optimized for HTTP communication should be used. These are either servlet container or JEE server hosting the WAR agent or an OSGi runtime with an OSGi HttpService (which in turn is typically based on an embedded serlvet container like Tomcat or Jetty). The two other agents, the Mule and JVM agents are not that well suited for this job.
All client libraries (jmx4perl, Java and Javascript) support the usage of proxy mode in its API.
The proxy mode has some limitations compared to the direct agent mode, so it is recommended to use a direct agent deployment if possible. The limitations are:
PlatformMBeanServer (which is always
present). Each MBean is registered only in one MBeanServer. The
choice of which MBeanServer to use has to be
given up front, usually as a part of the JMX Service URL. But even
then (as it is the case for JBoss 5.1) you might run into problems
when selecting the proper MBeanServer.
list might fail in the proxy mode
because of serialization issues. E.g. for JBoss it happens
that certain MBeanInfo objects requested for the list
operation are not serializable. This is a bug of JBoss, but
I expect similar limitations for other application servers
as well.