Home » General (non-technical) » Project Proposals » Ponte - M2M Bridge Framework for REST developers
| |
| Re: Ponte - M2M Bridge Framework for REST developers [message #1059321 is a reply to message #1059300] |
Fri, 17 May 2013 13:58   |
 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 06:53 |
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 18:38 |
Scott Lewis
Messages: 1038
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 #1062250 is a reply to message #1062178] |
Thu, 06 June 2013 17:14 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Matteo,
Matteo Collina wrote on Thu, 06 June 2013 08:02Ponte 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  .
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
|
|
| | | |
Goto Forum:
Current Time: Thu Apr 18 04:23:47 GMT 2024
Powered by FUDForum. Page generated in 0.02299 seconds |
] 
Search
Help
Register
Login
Home
