| [m2m-iwg] M3DA protocol proposed as part of initial contribution of Mihini (was: Re: AXEDA Comments on MQTT contribution to ECLIPSE PAHO & OASIS) |
Greetings, During our weekly call yesterday, I briefly mentioned the e-mail below that apparently went unnoticed in what was already a pretty long e-mail thread… hence this new thread :) We are hoping it can be a good basis for discussion, and we are looking forward to getting the group's feedback on the protocol, and discuss how it can maybe complement MQTT for some use cases during one of our weekly calls and/or in a Paho call. FWIW I won't be able to make it to next week's call, I'll be on the Eclipse Foundation booth at JFokus demoing our technologies! Cheers, Benjamin. _________________ It's great to see so much interest in that discussion! As you say Rick, there's probably still lots of efforts to do in order to go a step further in terms of enabling M2M communications, but it's really great to see MQTT moving to OASIS. I would like to invite you all to have a look at the attached presentation, as well as to the Mihini wiki page [1] where we provide more information regarding the M3DA (Micro-M2M Data Access) protocol that Mihini will rely on for Device and Asset Management. I think it addresses some of the points you raise, Rick...
The approach we took is indeed to try to have a serialization model that has strong typing, including the ability to describe data structures usually found in M2M applications (vectors of data, smart handling of timestamped values).
FWIW I think having a protocol that, to some extent, describes the payload is important (see the previous paragraph…), but it is probably complementary with having a separate, more complete, model of the full capabilities of a given M2M application (I am sure you remember the discussions we had about [2] :-)) This model is also kind of crucial to support legacy applications (hence legacy protocols) for which the communication protocol does not allow any sort of typing, discovery, etc.
M3DA features a way to acknowledge correct delivery of messages, and the Mihini agent comes with all the logic needed for not losing data in case of unreliable network connection, as well as the logic needed to communicate only once in a while (a Mihini application can send data to specific queues that get "flushed" to the server according to specific policies: cron table, on-demand, …) I'd be happy to hear the group's thoughts on these first elements of information regarding M3DA, and of course there will be more to discuss about when the Mihini source code, hence the reference implementation of M3DA, will actually be available (it's a matter of weeks now, we are still under IP review by Eclipse legal). Best regards, Benjamin. Le 26 janv. 2013 |
Attachment:
M3DA Presentation.pdf
Description: M3DA Presentation.pdf