Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @


From EGIWiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

EMI Messaging Protocol for Accounting (EMPA)

Discussion about this protocol will take place on the mailing list The page for the mailing list is here: If you subscribe, you can also view the archives. This discussion took place from June to August 2012. I have now added version 1.0 of this protocol to the bottom of this page.


It has been agreed within EMI and EGI to use messaging for transporting accounting data. The APEL team developed software (called SSM) for use with messaging, and although it can be used independently of the message format, it uses a somewhat complex message sequence on top of the STOMP protocol, so it is not easy for other software to interact.

We will discuss ways to simplify the protocol so that it is simple for different accounting software to interact.

We won't consider the message content here - that is covered elsewhere, such as:

The current protocol

This document describes the current protocol used by SSM. It may not be entirely well-defined, because it was written after the software.

Please feel free to comment if this document is unclear or if you think it is incorrect, and I will improve it.

Criticisms of the protocol

This document attempts to describe problems with the current protocol and suggestions for improving it.

Please reply with comments about the listed problems and proposals, so that we can make sure any possible issues are addressed properly.


We have discussed the possibilities on the mailing list, and the emails can be found in the archives for June 2012. The following main points were established:

  • It is useful for clients to sign the messages they send with their certificate
  • We should make it optional whether clients encrypt messages, and use MIME types to determine whether this encryption has taken place
  • Signatures and encryption should be done according to the SMIME specification
  • Accounting message queues should be persistent, so that consumers are guaranteed delivery. How this is implemented should depend on the details of the broker network
  • The 'ack' mechanism in the 'current protocol' listed above will not be retained
  • The certificate request and response messages in the current protocol will not be retained. If a client is to encrypt messages with the server certificate, that certificate should be distributed by another method

Proposed protocol

This is version 1.1 of the protocol specification.