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 @ egi.eu.

Difference between revisions of "APEL/MessagingProtocol"

From EGIWiki
Jump to navigation Jump to search
 
(15 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= Accounting Messaging Protocol =
[[Category:Accounting]]
= EMI Messaging Protocol for Accounting (EMPA) =


Discussion about this protocol will take place on the mailing list emi-jra1-messaging@eu-emi.eu.
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 ==
== Background ==
Line 11: Line 12:
* the Compute Accounting Record (CAR): see https://twiki.cern.ch/twiki/bin/view/EMI/ComputeAccounting  
* the Compute Accounting Record (CAR): see https://twiki.cern.ch/twiki/bin/view/EMI/ComputeAccounting  
* the Storage Accounting Record (StAR): see https://twiki.cern.ch/twiki/bin/view/EMI/StorageAccounting
* the Storage Accounting Record (StAR): see https://twiki.cern.ch/twiki/bin/view/EMI/StorageAccounting
[[APEL/NewPage]]




Line 26: Line 25:


Please reply with comments about the listed problems and proposals, so that we can make sure any possible issues are addressed properly.
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 ==
== Proposed protocol ==


When a new protocol is proposed, it will be added here.
This is version 1.1 of the protocol specification.
 
[https://wiki.egi.eu/wiki/File:EMI_Accounting_Messaging_Protocol_v1.1.pdf EMI_Accounting_Messaging_Protocol_v1.1.pdf]

Latest revision as of 13:06, 20 February 2013

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