Exported Services and Batch Jobs

A typical CoreWallet service provides methods to query or process certain entities. These methods can be exported via HttpInvoker to the external-webapp, and can be invoked by batch-jobs as well.

The batch-jobs are meant purely as a trigger for a service-method, they contain no significant logic. This way, the service-method can be called from the AdminAPI as well, or using other triggers, if needed.

Exported service method

The following diagram shows a typical exported service method structure.

Typically, the following happens when an API call is made, starting at the ApiController which handles the HTTP requests received by the application server:

  • The ApiController calls the service-method on the service-interface with the mapped parameters from the HTTP request
  • The HttpInvokerProxy exposes the service-interface, and handles any calls made to it. It generates call-statistic-events for every invocation, and sends the invocation via HTTP to the webapp-internal.
  • The HttpInvokerServiceExporter receives the invocation, and validates it using the TokenValidator service, and sets up the security-context. Then it delegates the invocation to the service-implementation. It generates call-statistic-events for every invocation.
  • The service-implementation may use DAOs to access entities from the database.
  • The service-implementation may use accounting-handlers to generate accounting-relevant events and actions, such as transferring emoney between accounts.
  • The service-implementation may generate events though a listener interface, typically when something relevant happens to an entity (e.g. a state-change).

Batch job service method

The following diagram shows a typical batch-job service method structure.

Typically, the following happens when a batch-job runs, starting at the Quartz scheduler, which manages all jobs and triggers:

  • The Quartz-Scheduler executes the BatchJob
  • The BatchJob sets up the security-context, and invokes the service-method on the service-implementation
  • The service-implementation typically loads a set of entities on which the action should be performed, and delegates the action for each single entity to a process-implementation
  • The process-implementation may use DAOs to access entities from the database.
  • The process-implementation may use accounting-handlers to generate accounting-relevant events and actions, such as transferring emoney between accounts.
  • The process-implementation may generate events though a listener interface, typically when something relevant happens to an entity (e.g. a state-change).