The Component Control Protocol is a protocol designed for exchange of control and state information over bidirectional channel between Peer Server and components which run on the Peer Server.
Communication Channels
Communication between the Peer Server and components happen over two JMS topics:
- CCP_COMPONENT_TO_PEER_TRANSPORT – Topic on which components send data, status and acknowledgement events to the Peer Server
- CCP_PEER_TO_COMPONENT_TRANSPORT – Topic on which the Peer Server sends control commands and data requests to components.
Message selector which is a function of the GUID of application to which component belongs and the instance name of component is used to identify requests sent to and from components on the control topics.
Events
Javadocs for different events types that are exchanged between component and the peer server can be found at %FIORANO_HOME%/javadoc/esb/ccp.
Events used for CCP communication are described below:
Data request event
Data request event is sent by Peer Server to components. e.g. request for memory usage statistics, request for current log level set in the component etc. In response, a data event is sent by components to Peer Server.
Command Event
Command Event is initiated by peer server to issue command to the component. The possible commands are
INITIATE_SHUTDOWN
The event is sent to initiate shutdown of a component. The component responds by performing necessary cleanup and shutting down itself.
REPORT_STATE
This event is generated when peer servers needs to know the status of component. The component responds by sending appropriate status.
Possible values are COMPONENT_LAUNCH, COMPONENT_CONFIGURATION, COMPONENT_CONNECT, COMPONENT_START, COMPONENT_STOP_TIME_WAIT, COMPONENT_STOP_EXECUTION, COMPONENT_STOP_CLEANUP, COMPONENT_EXECUTION
SET_LOGLEVEL
This event is generated to change the log level of a component. The component changes the level of the logger mentioned.
Handshake Event
HandShake Event is initiated by the peer server. This event is used to check ccp compatibility of server with components. This event has maxVersionSupported, minVersionSupported properties used to specify versions supported by the peer server.
Handshake Ack Event is initiated by the component in response to Handshake event from peer server. It contains information about maximum and minimum versions supported by the component. This event helps in determining whether the component can handle the specific version of CCP.
Component Lifecycle and CCP
A component's life cycle typically consists of following stages:
- Component startup – This stage starts as soon as the component process is created and lasts until component is ready to process requests. The component looks up all required configurations and initializes all required objects
- Transport startup – This stage is a part of component startup where all necessary transport objects like JMS connection, sessions, consumers, producers, message listeners and other related objects are created
- Component runtime – This stage starts as soon as all necessary initialization is done and component can accept requests and lasts until a shutdown is initiated.
- Transport shutdown – This stage is a part of component shutdown. After this stage all processing is stopped and only cleanup of any other objects remain.
- Component shutdown – This stage starts with a shutdown request and lasts until the component terminates. The component cleans up all objects created in an orderly fashion during this stage.
Without CCP, when a component is launched in separate process it has no way to control the how its state is reflected as it cannot provide feedback to the PeerServer on its state. This causes following problems:
A component is considered to be started as soon as a JMS connection used for transport is created and its state is reflected as such in tools.
When a component is stopped there is no way to communicate to component to initiate an orderly cleanup and shutdown. The component process is forcefully destroyed instead.
CCP transfers the control over component states to the component. The Peer Server only sends necessary commands to the component and waits for component to provide feedback on its state.
For startup, the Peer Server wait for COMPONENT_STARTED status event to indicate that component is started instead of relying on JMS connection creation.
For shutdown, a component which has CCP feature enabled would initiate orderly shutdown of the component as soon as a INITIATE_SHUTDOWN command is received from the Peer Server and terminates itself once the cleanup is done. A component can send intermediate status events to indicate the progress of shutdown process which are logged by the server. Peer Server waits for component process to terminate for a configured interval of time. If the component process is not terminated within the configured time, the Peer Server will forcefully terminate the component process. This can be configured in FES profile against ComponentStopWaitTime property on ApplicationController node at path FES > Fiorano > Esb > Application > Controller > ApplicationController
Figure 1: ComponentStopWaitTime property in FES profile
Sample component
A sample component which implements CCP can be found at %FIORANO_HOME%/esb/tools/templates/samples/CCPComponent.