APEL/MessagingProtocol

From EGIWiki
< APEL
Revision as of 14:06, 20 February 2013 by Wrogers (talk | contribs) (Proposed protocol)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

EMI Messaging Protocol for Accounting (EMPA)

Discussion about this protocol will take place on the mailing list emi-jra1-messaging@eu-emi.eu. The page for the mailing list is here: http://mail.eu-emi.eu/mailman/listinfo/emi-jra1-messaging. 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.

Background

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.

Conclusions

We have discussed the possibilities on the mailing list emi-jra1-messaging@eu-emi.eu, 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.

EMI_Accounting_Messaging_Protocol_v1.1.pdf