The JBoss ON server is a Java application. All of the subsystems — like resources and groups, monitoring, alerting, drift, and provisioning — are contained in Enterprise JavaBeans in the server. The different JBoss ON APIs interact with those EJBs.
Specifically, most of the server EJBs are stateless session beans (SLSBs). These core server SLSBs follow a certain naming logic:
The implementing class is *ManagerBean. This implements both the local API and the remote API.
SLSBs that are used internally by the server are *ManagerLocal.
SLSBs that define the remote API are *ManagerRemote.
Each SLSB exposes its remote interface in the CLI with the naming convention *Manager. For example, all of the methods associated with managing a resource belong to ResourceManager.
The server itself uses EJBs to create its data structure. The CLI interacts with the server EJBs through the remote API, the
*Managers. The remote API is the compilation of the
*Remote interfaces of the server's EJBs.
Figure 1.1. The Server Interfaces and Client Interactions
So, how does all of that fit in with the JBoss ON server and using server-side scripts?
All of the different APIs interact with clients and with the server in slightly different ways.
Agents, and their underlying resources and resource plug-ins, use the plug-in API to communicate to the core server (over the remoting framework). Agent and server plug-ins frequently work in pairs to extend JBoss ON functionality. For example, implementing an additional recipe style for bundles would require an agent plug-in to work with resources and a corresponding server plug-in to work with the server-side data structures.
The JBoss ON CLI uses the remote and domain APIs to communicate to the core server, also over the remoting framework. Unlike the agent, the CLI does not implement functionality (or at least not a lot); rather, it calls on the existing functionality to perform management tasks.