If you login as aesdeveloper go to app explorer and classes started with  PEGA-AES* will be all AES related classes and you can drill down to check what are all the contents it have .

You can get more information from https://docs-previous.pega.com/pega-autonomic-event-services/introduction-pega-autonomic-event-services .

Are you asking about AES itself, or the bits that live on each monitored node to work with AES? AES is an application with classes, connectors, services, portal, harness, work types, data types, etc. At its core there are a few data* types that are fed through SOAP services, including alerts, exceptions, node health stats, nodes, systems and database indexes, a few data* types that are user-entered, including scorecard subscriptions, data* types derived by agents, like node health, indicators and scorecards, and two primary work types that are created by agents and updated by users and agents - exception work and action (alert) work. 

AES application does have a Java library to enhance the engine with logic that could not easily fit into rules or RUF's - primarily for SQL parsing. You must restart an AES server after deployment so activities can find the java library. 

On monitored nodes, there is a PegaAESRemote ruleset that implements services that AES may call if you enable those features and some agents to send data to AES. In addition, in the engine kernel there are the 'dynamic appenders' inside the logging which actually implement the SOAP messaging, and a management daemon that sends AES node health statistics every two minutes. 

Does the SoapAppenderPega play any role in this process. It looks like this appender is not really required. Trying to configure this soap pega appender but without any luck. Have anybody configured this soapappenderpega successfully. please suggest.