*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.
--

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.

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?!

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?!

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).

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.

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 ).

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

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 ).

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

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:

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:

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.

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]