Description of problem:
As seen in Bug #1038364, the manifest headers defined in the remote API JAR's MANIFEST.MF are unreliable and potentially unstable. For example, through compilation of a user application based on Maven, it is possible that an Implementation-Version manifest header could be loaded from the wrong RHQ version based on an incorrectly configured repository or other user introduced errors. 

Additionally, when the remote API is consumed by clients in an embedded form, the original JAR's manifest is not even used.

Commit https://git.fedorahosted.org/cgit/rhq/rhq.git/commit/?id=66fd59f643fdf8f39f199129711d77dfbd5ccbc7 introduced a new method named checkServerSupported which expects a manifest to exist that defines Implementation-Version. However, this is only true when the client libraries are packaged by the JBoss ON or RHQ build systems and do not reflect user or other third-party packaging mechanisms or requirements. 

Instead, the expectation is that an API enforces compatibility based on forward and backward implementation logic based on API levels (major and minor) that determine the level of support of the client and the server. This scheme is normally implemented using a serialization version identifier stored in the class itself or some other static version stored in the class itself.