This covers the design work involved in defining the new Remote API to be exposed to remote clients. The spec is here: http://jopr.org/confluence/display/RHQ/Design-Remote+API
*** IGNORE *** The impl stuff has been moved to separate Jiras *** Initial implementations exist for: ChannelManagerRemote ConfigurationManagerRemote ContentManagerRemote OperationManagerRemote ResourceManagerRemote RoleManagerRemote SubjectManagerRemote The remotes, by design, offer only a subset of the local API to address the specific use cases in the design doc. The tests for the remotes are in TestRemoteInterface. The tests are not all passing at this time, Jiras have ben createdto address the failures when WS API work resumes.
svn rev4097 adds a new remoting connector being delpoyed by the ear. it uses the servlet transport over the http port today. we will have to figure out something later to make this configurable (to allow someone to go over sslservlet port 7443 for security purposes). today, its over unsecured servlet transport , port 7080. We should probably write a subtask jira here so we remember to do this. we will have people that will only want to allow remote clients to go over secure transport. It may be as simple as deploying a second service (remote-api-secure-service.xml) that uses the configured https port (i.e. copy remote-api-service.xml and change the transport to sslservlet and the port to the https property).
The above comment has been moved to its own Jira: http://jira.rhq-project.org/browse/RHQ-2199
I believe the spec is pretty much set. There may be tweaks but they should be minor. The API is here: http://jopr.org/confluence/display/RHQ/Design-Remote+API
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-1181