Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Newcomers » Proposals » Ponte - M2M Bridge Framework for REST developers
Ponte - M2M Bridge Framework for REST developers [message #1059085] Thu, 16 May 2013 11:15 Go to next message
Wayne Beaton is currently offline Wayne Beaton
Messages: 496
Registered: July 2009
Senior Member
We've just posted a new proposal.

http://eclipse.org/proposals/technology.ponte/

--
The scope of the Ponte project is threefold:

*Define a simple REST API to expose the machines needs through REST, exposing multiple protocols (MQTT, CoAP) through the same API.

*Embrace multiple data formats, such as JSON, XML, Msgpack, Bysant and provide ways to automatically convert between them; eventually, common representation of sensors and actuators data will be defined (or adopted from Paho).

*Define and build a user-driven security solution to support the communication between all these devices.
--

If you have any questions or comments, please ask or pose them here.
Re: Ponte - M2M Bridge Framework for REST developers [message #1059300 is a reply to message #1059085] Fri, 17 May 2013 09:22 Go to previous messageGo to next message
Toby Jaffey is currently offline Toby Jaffey
Messages: 1
Registered: May 2013
Junior Member
I'm interested in having a "common representation of sensors and actuators".

Are you planning to focus on just data (temperature=27, power=1.21), or are you also considering how to define semantics for what is being measured and actuated?

Will you provide ways to use existing ontologies (SSN, SensorML, etc) or are you planning new ways of describing sensors?
Re: Ponte - M2M Bridge Framework for REST developers [message #1059321 is a reply to message #1059300] Fri, 17 May 2013 09:58 Go to previous messageGo to next message
Matteo Collina is currently offline Matteo Collina
Messages: 3
Registered: May 2013
Junior Member
The rationale behind Ponte is simplicity for the developer. It's all about empowering developers and not ease of implementation (albeit, most of the time these concepts comes together). As of adopting proven standards, these will be adopted if they are simple to use, or can be made simple to use. Otherwise we fail.

At the beginning, the focus will be mostly on data and its semantic. It's not about measuring or actuating, but in allowing the developers not to worry about accessing the data. It's a simple goal that gives a clear benefit for the developer.

The data point example you have given (temperature=27, power=1.21) ideally has not enough meaning attached:
1) it does not include the unit of measure of both temperature and power (thanks UOMo);
2) it does not reference what device has sampled it;
3) it does not reference where it was sampled;
4) ....
As a developer, most of the time you need these informations. Everyone keeps reinventing the wheel by modelling their solution on top of low-level protocols. Ponte aims to fill that gap.

SSN makes a lot of sense, but I feel it is VERY complicated. I think we need something simpler to lower the learning curve. However, everything should be aligned with current best-practices whenever possible. So it's very probable that there will be some support for SSN.

We do not need one more non-functioning standard for the same stuff.
Re: Ponte - M2M Bridge Framework for REST developers [message #1061498 is a reply to message #1059321] Sat, 01 June 2013 02:53 Go to previous messageGo to next message
Eclipse User
On 05/17/2013 05:28 PM, Matteo Collina wrote:
> As a developer, most of the time you need these informations. Everyone
> keeps reinventing the wheel by modelling their solution on top of
> low-level protocols. Ponte aims to fill that gap.

Hi,

ECF [1] has a similar mission statement and in fact we already provide a
(remote) communication API abstraction [2] (including REST-based
communication providers). This work might be something Ponte can build
on top?!

Regards
Markus

[1] http://eclipse.org/ecf/
[2] http://wiki.eclipse.org/ECF
Re: Ponte - M2M Bridge Framework for REST developers [message #1061751 is a reply to message #1061498] Mon, 03 June 2013 14:38 Go to previous messageGo to next message
Scott Lewis is currently offline Scott Lewis
Messages: 966
Registered: July 2009
Senior Member
Quote:
Hi,

ECF [1] has a similar mission statement and in fact we already provide a
(remote) communication API abstraction [2] (including REST-based
communication providers). This work might be something Ponte can build
on top?!

Regards
Markus

[1] http://eclipse.org/ecf/
[2] http://wiki.eclipse.org/ECF


I would like to also emphasize what appears to be an overlap between what Ponte wants to do (i.e: 'exposing multiple protocols...through the same API'), and what ECF has done: provide transport/protocol-independent communications APIs...layered/built on one another. As Markus K points out above, we and consumers have already defined, implemented, tested, and used multiple APIs that are independent of protocol and serialization...e.g:

REST, SOAP, RPC, Remote Services (impl OSGi R5 standard), discovery, Distributed Event Admin, Asynch Messaging (datashare API), presence/IM/IRC, filetransfer, shared objects, others. Each of these is an open, abstract API, with multiple providers fully implemented and tested...along with the ability to create new providers based upon new/other (even proprietary) protocols based upon time and use-hardened APIs. Also, in many cases, these APIs have been used in large applications (e.g. Equinox/p2/Eclipse, Coffee, etc).

WRT security, we have leveraged the OSGi and Java 2 security specifications to secure access to remote services. We've recently completed successful testing of ECF with the OSGi remote services/remote service admin TCK to guarantee specification compliance.

We are very open to modifying/enhancing APIs...or adding entirely new APIs...as needed for new use cases, and/or new capabilities enabled by new transports. We've done this frequently over the last 8 years in response to community input.

Please consider leveraging this work and the ECF community rather than duplicating it. To directly engage ECF's committers, please see/join the ECF mailing list [2] and/or feel free to contact Markus K (RT proj rep) or myself (Scott L project lead) directly.

[1] http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/framework/bundles
[2] https://dev.eclipse.org/mailman/listinfo/ecf-dev
Re: Ponte - M2M Bridge Framework for REST developers [message #1062029 is a reply to message #1061751] Wed, 05 June 2013 09:33 Go to previous messageGo to next message
Matteo Collina is currently offline Matteo Collina
Messages: 3
Registered: May 2013
Junior Member
Hi Scott, Markus,

Ponte comes from very different roots and requirements.
I did not know about ECF, and I will have a look at it.

Thanks!

Matteo
Re: Ponte - M2M Bridge Framework for REST developers [message #1062049 is a reply to message #1062029] Wed, 05 June 2013 10:45 Go to previous messageGo to next message
Scott Lewis is currently offline Scott Lewis
Messages: 966
Registered: July 2009
Senior Member
Quote:
Hi Scott, Markus,

Ponte comes from very different roots and requirements.
I did not know about ECF, and I will have a look at it.

Thanks!

Matteo


Perhaps you would state some of these roots and requirements for Ponte here on the forum?

Thanks,

Scott
Re: Ponte - M2M Bridge Framework for REST developers [message #1062178 is a reply to message #1059300] Thu, 06 June 2013 08:02 Go to previous messageGo to next message
Matteo Collina is currently offline Matteo Collina
Messages: 3
Registered: May 2013
Junior Member
Ponte will mediate between MQTT, CoAP, and M3DA protocols and expose all these devices through REST.
In Ponte, the data is coming from the devices and stored in a database for REST syndication. Moreover, each data point is transmitted to all other Ponte instances to support a pub/sub paradigm. Doing this requires using a MQ infrastructure such as RabbitMQ/AMQP.
Look at Ascoltatori, the basis for Ponte: https github.com mcollina ascoltatori (no link for me on this forum Sad).

I hope that clarifies my point. If you are more question, check the proposal and/or ask Smile.


Also, check my presentation at EclipseCon: http www.slideshare.net/matteocollina/exposing-m2m-to-the-rest-of-us
Re: Ponte - M2M Bridge Framework for REST developers [message #1062250 is a reply to message #1062178] Thu, 06 June 2013 13:14 Go to previous messageGo to next message
Scott Lewis is currently offline Scott Lewis
Messages: 966
Registered: July 2009
Senior Member
Hi Matteo,

Matteo Collina wrote on Thu, 06 June 2013 08:02
Ponte will mediate between MQTT, CoAP, and M3DA protocols and expose all these devices through REST.


Is it fair to characterize this as a REST-based access/API to an async messaging layer?

Quote:

In Ponte, the data is coming from the devices and stored in a database for REST syndication. Moreover, each data point is transmitted to all other Ponte instances to support a pub/sub paradigm. Doing this requires using a MQ infrastructure such as RabbitMQ/AMQP.


Ok. So from looking briefly at MQTT...it seems that this protocol has already been adopted into several of the JMS-based messaging systems...e.g. IBM's, ActiveMQ, and others. Is that correct?

Quote:

Look at Ascoltatori, the basis for Ponte: https github.com mcollina ascoltatori (no link for me on this forum Sad).

I hope that clarifies my point. If you are more question, check the proposal and/or ask Smile.

Also, check my presentation at EclipseCon: http www.slideshare.net/matteocollina/exposing-m2m-to-the-rest-of-us


Ok, I viewed the slides.

It does appear to me that what you are shooting for has some overlap with what ECF is/has been doing. I think this is a good thing...as it's possible for Ponte to leverage what we have already done (WRT OSGI remote services support, integration/examples/ui with Eclipse...e.g. for real-time collaboration, and good integration with Equinox and Eclipse).

I like to characterize ECF as defining a set of related, open APIs to enable/simplify building apps that require inter-process communication. We have a layered/extensible structure to our APIs...with small 'core' API (based around identity/ID and a session-like concept we call IContainer). Also in the core is the use of the adapter pattern (in the implementation form of IAdaptable)...which provides a mechanism to expose an arbitrary set of other 'higher-level' APIs. For example, we have APIs (implemented as separate osgi bundles) that provide non-blocking file transfer (used by p2), remote services, networked based discovery, presence and instant messaging, rest-style services, async messaging, object sharing, voip call/session setup, shared editing/replicated model synchronization, and others. We are/have been adding new such APIs when needed.

We refer to implementations of one or more of these APIs as 'providers'. Providers are typically protocol-specific...e.g. for async and sync remote services...we have providers that are based upon our 'generic' protocol (pub sub messages over socket), r-OSGi (http-based osgi remote services), JMS/ActiveMQ, JavaGroups, Restlet 2.2, XMPP, and others. As well, we have multiple implementations/providers for other of the apis described above...e.g. httpcomponents for rest, http/https/ssh/efs for filetransfer, JMS/ActiveMQ, JavaGroups for async messaging, Zookeeper for discovery, zeroconf for discovery, etc., etc. We are always looking to...and being asked to by our community...implement new providers based upon other/new protocols. Here's a little diagram of this basic structure...specifically wrt OSGi remote services:

http://wiki.eclipse.org/OSGi_4.2_Remote_Services_and_ECF

I think there could be room for ECF and Ponte projects to work together. Given the way things are structured with ECF I could easily see one or more providers being created that support the various protocols (MQTT)...perhaps even reusing what we already have in place for JMS-based messaging and ActiveMQ...which is located here, btw:

https://github.com/ECF

for IP/licensing reasons.

All of ECF is built upon one or more OSGi bundles...which makes them quite modular and extensible.

As well, Ponte might benefit from some of what we've done with integrating OSGi remote services and our rest APIs...and/or just the rest API itself...which provides a pluggable set of rest apis...e.g. allowing desired serialization formats (e.g. json, xml, object serialization, etc) to be inserted/replaced easily. I could easily see Ponte defining both new API(s) and new/multiple implementations/providers. Note that one benefit of doing so would be that consumers could then have access to OSGi-spec compliant remote services functionality that uses those transports/providers for spec compliant OSGi services...without having to re-implement the OSGi remote services/remote services admin spec. One of the many benefits of OSGi-supplied modularity.

Hopefully this has helped. I'll look forward to discussing more.

Scott
Re: Ponte - M2M Bridge Framework for REST developers [message #1062467 is a reply to message #1062250] Fri, 07 June 2013 16:54 Go to previous messageGo to next message
Scott Lewis is currently offline Scott Lewis
Messages: 966
Registered: July 2009
Senior Member
FYI: I discovered when looking at mqtt docs that recent versions of ActiveMQ have support for mqtt. We/ECF already have a provider that uses/is based upon ActiveMQ [1], and so can easily support mqtt by updating our ActiveMQ provider. Here's the bug for updating the ECf provider to ActiveMQ 5.8.0 [2]


[1] https://github.com/ECF/JMS
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=410237
Re: Ponte - M2M Bridge Framework for REST developers [message #1064010 is a reply to message #1062467] Mon, 17 June 2013 05:07 Go to previous messageGo to next message
Eclipse User
On 06/07/2013 10:54 PM, Scott Lewis wrote:
> Here's the bug for updating the ECf provider to ActiveMQ 5.8.0 [2]

For the record, this bug has been closed in the meantime.

M.
Re: Ponte - M2M Bridge Framework for REST developers [message #1064360 is a reply to message #1059085] Tue, 18 June 2013 16:58 Go to previous message
Werner Keil is currently offline Werner Keil
Messages: 1083
Registered: July 2009
Senior Member
At least for the MQTT part, this project by Xively (also seems very active
with partners like ARM these days) may sound interesting:
https://github.com/xively/MQTT.js

Can't say, if contribution to Ponte is in its interest, but why not ask
them;-)

Regarding JavaScript and Node.js based support for UCUM or other Unit
standards, UOMo is happz to help where we can.

Werner
Previous Topic:Source code navigation inside internal web browser
Next Topic:New Proposal: Vert.x
Goto Forum:
  


Current Time: Thu Jul 31 09:40:09 EDT 2014

Powered by FUDForum. Page generated in 0.35477 seconds