|
On 12/8/2015 12:10 PM, David Ingham
wrote:
Hi
Scott,
AMQP
1.0 is a peer-to-peer protocol that essentially supports the
transfer of ownership of a message between two endpoints. It
does that efficiently, with flow control and with a range of
quality of service guarantees. One important thing to note
about AMQP is that it doesn’t make any assumptions about
what is behind either of the endpoints that are
communicating. To that end, it can be used in directly
connected peer-to-peer scenarios, or with router or broker
intermediaries. Saying that another way, it can be used
client-to-client, client-to-intermediary or
intermediary-to-intermediary. When used with a broker, it
doesn’t expect any particular messaging model to be
supported. So one of the advantages of AMQP 1.0 is that is
can be used with messaging middleware that uses different
models. For example, Microsoft use AMQP 1.0 for their Azure
ServiceBus and IoT Hubs services, IBM support it in
WebSphereMQ and it’s supported in the Apache ActiveMQ and
ActiveMQ Artemis message brokers.
Thanks I understand that Dave. But my point was that AMQP basically
implements queues and topics for the model of inter-process
interaction.
I
won’t go in to the details of the protocol right now but, in
a nutshell, AMQP 1.0 supports multiple one-way,
flow-controlled message flows (Links in AMQP parlance) over
a single socket (an AMQP Connection). It’s straight-forward
to implement RPC-style request/response interactions over a
pair of Links.
As one whose implemented RPC over AMQP and other messaging impls
(e.g. [1]), it hasn't been my experience that layering non-trivial
RPC on async messaging is as simple as you implying. Particularly
when one considers service-and-distribution-level issues in addition
to transport-level protocol differences [2].
But I do agree that layers can be added to make available
programming abstractions (e.g. remote services, events to name two)
that are useful for supporting IOT interactions. My follow-up
question really is: what thinking is currently happening WRT this
mapping between IoT communication needs (e.g. provisioning) and
these abstractions (e.g. async/sync, point vs. multipoint, reliable
vs. unreliable, rpc, events, etc).
Scott
[1] https://github.com/ECF/JMS/tree/master/bundles
[2]
https://wiki.eclipse.org/Tutorial:_Using_REST_and_OSGi_Standards_for_Micro_Services
Hope
this helps.
Best
regards,
Dave.
[1]
http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-complete-v1.0-os.pdf
[2]
http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=64955
Hi Dejan and Hudalla,
First, thanks for the explanation. A couple of follow-up
questions below.
On 12/8/2015 6:44 AM, Hudalla Kai (INST/ESY) wrote:
<stuff deleted>
Hi Scott,
my understanding is that purpose of
IoT Connector is to provide a programming model on the
southbound and northbound edges for easy development
of IoT specific applications based on patterns, like
telemetry and command and control. This model will be
based on some “inner” IoT Connector protocol, like for
example AMQP, which will allow the uniform programming
API, hidden messaging infrastructure, security
infrastructure, etc. Additionally, it will allow
multiple implementations based on different
technologies and products.
As I understand it, AMQP is a standardized wire protocol [1],
and essentially implements two concepts: queue and topic.
Does this mean that the IOTConnector model that you mention
will be based directly upon queues and/or topics? Or are you
thinking of something more/other...possibly closer to the IOT
patterns you list above (telemetry, command and control).
To hopefully clarify my question: I can easily see that some
IOT patterns (e.g. provisioning) may 'want' to be based upon
something like remote procedure call (RPC)...e.g. a remote
provisioning service that installs/updates/uninstalls things
on the device with synchronous call-return semantics. For
some types of interactions it's easier to understand
(particularly in terms of timing relationships, security,
etc).
RPC can of course be implemented on queues/asynchronous
messaging, but it's not by default a queue or topic.
So my follow up question is: For the IOTConnector model and
API, are you thinking primariy of queues and topics?...and/or
other models that might be built on those concepts?
Thanksinadvance for any further thoughts.
Scott
[1] https://spring.io/understanding/AMQP
The purpose of ‘Protocol adapter’
here is then to convert the “outer” protocol that
devices use, like LWM2M, MQTT, HTTP, etc. to this
programming model and “inner” network protocol.
This is only my view. If anyone
else have some other views or more ideas and details
on how this should work, I’d be glad to hear them.
On Mon, Dec 7, 2015 at 7:48 PM,
Scott Lewis <slewis@xxxxxxxxxxxxx>
wrote:
I have a technical question.
My apologies if this is well-understood because of
the f2f meetings...which unfortunately I haven't
been able to attend.
I understand the notion of an API to implement for
LWM2M protocol. For any protocol, eventually (by
one's own hand and/or other's) to use that
protocol it's necessary to eventually have a
library/libraries that implement all or parts of
that protocol.
But what exactly is meant by a 'protocol
adapter'? I get that multiple protocols would be
supported, but I think my current lack of clarity
is around 'adapting to *what*?' My current
guesses are:
1) adapting to IoT-relevant API's services (e.g.
remote provisioning, remote 'device-specific
control', etc)
2) adapting to abstract models for communication:
e.g. RPC (sync/async), group/topic-based
messaging, request/response models, events/actor
models, etc).
3) both all?
But as I say, I'm kind of fuzzy about what the
protocol is being adapted to. With the LWM2M
protocol adapter, what API and impl would the
adapter consist of?
Any comments and/or relevant doc pointers
appreciated.
Scott
On 12/7/2015 7:20 AM, Hudalla Kai (INST/ESY)
wrote:
Henryk,
I think that keeping together
the IoT Connector’s Core and one or two
Protocol Adapters would indeed make sense
at least until the first release. During
this time the IoT Connector’s interface
will change all the time and it would be
easier to keep up with these changes if
the Protocol Adapters are part of the same
repo/project. Once we have a stable
release we can still “graduate” the
Protocol Adapters into their own
projects/repos, right?
However, we seem to agree
that it makes sense to include the LWM2M
Protocol Adapter in the IoT Connector
project scope. Let’s wait some days in
order to give others the opportunity to
object before we add it to the project
proposal, ok?
Kai
Hi
Kai,
While
I agree that keeping all the iotsp as
a single project may be too broad
indeed, I would propose to keep at
least connector and protocol adapters
together in a single repository. That
would highly simplify release
management. Maintaining and releasing
all adapters independently will be a
huge burden for us. Keep in mind that
number of protocol adapters may become
quite large eventually.
Everyone,
while I agree that all of this happens
in the context of what we currently
call the "IoT Server Platform", I do
not think that we should have a
project called "IoT Server Platform"
(iotsp). First, because there are more
components that are part of the
overall picture (e.g. software
provisioning, device management, other
protocol adapter) which have meaning
independently from the IoT SP and
second, because I think that we should
try to keep the projects separate from
each other regarding governance which
makes them easier to handle.
I can imagine that we have multiple
projects/repos:
Github.com/eclipse/iot-connector
Github.com/eclipse/hawkbit
Github.com/eclipse/device-management
etc
For the iot-connector project (which
we are currently preparing the
proposal for) we could either have
sub-modules as proposed by Henryk or
we could have additional repos, i.e.
multiple repos for the iot-connector
project (we do the same for
Californium), i.e. something like
Github.com/eclipse/iot-connector.core
Github.com/eclipse/iot-connector.lwm2m
Github.com/eclipse/iot-connector.mqtt
Kai
> -----Original Message-----
> From: iot-sp-bounces@xxxxxxxxxxx
[mailto:iot-sp-bounces@xxxxxxxxxxx]
On
> Behalf Of Greg Autric
> Sent: Monday, December 07, 2015
3:41 PM
> To: iot-sp
> Subject: Re: [iot-sp] LWM2M
protocol adapter prototype
>
> Hi all,
>
> as Henryk said in his last reply
> I think "iotsp" project should be
hosted into Eclipse github repo,
> because "iotsp" should be a
standalone project and has got its own
> lifecyle.
>
> Greg AUTRIC
> JBoss Middleware Consultant
>
> email : gautric __at__ redhat
__dot__ com
> twitter : @gautric_io
>
> Red Hat Global Services
> Red Hat France SARL
sit: http://www.redhat.fr
> Le Linea, 1 rue du General
Leclerc, 92047 Paris La Défense Cedex
Sent
> from webmail
>
> ----- Mail original -----
> De: "Henryk Konsek" <hekonsek@xxxxxxxxx>
> À: "iot-sp" <iot-sp@xxxxxxxxxxx>
> Envoyé: Lundi 7 Décembre 2015
15:14:05
> Objet: Re: [iot-sp] LWM2M
protocol adapter prototype
>
> Hi Ian,
>
> I mean Eclipse project hosted
here [1] of course. :)
>
> Cheers!
>
> [1] https://github.com/eclipse
>
> pon., 7.12.2015 o 15:10
użytkownik Ian Skerrett <
> ian.skerrett@xxxxxxxxxxx
> napisał:
>
>
>
> FWIW, I think it is a great idea
and even essential to have some basic
> adapters in the IoT Connector
project.
>
> Henryk, when you say a new
'github project' do you mean an
Eclipse
> project that is hosted on github
or are you suggesting to do this work
> outside of an official Eclipse
project. I believe Kai is going to
> proposal an official Eclipse IoT
Connector project that would host
> these modules.
>
> Ian
>
>
>
> On 07/12/2015 8:52 AM, Henryk
Konsek wrote:
>
>
>
> Hi Kai,
>
> I propose to start new github
project (let's say called "iotsp").
This
> project could contain following
modules for now:
>
> iotsp
> connector
> core
> mqtt
> lwm2m
>
> So all those three elements (IoT
connector core, lwm2m adapter and mqtt
> adapter) will be part of the same
project, so you can easily build and
> use them together. What do you
think about such layout?
>
> We would like to work on this
outside the Rhiot. I propose to create
> new Eclipse repository for this
purpose. So everything we commit, we
> commit to Eclipse project. No
Rhiot involved. Then, after the SP
code
> is mature enough, we will use it
as a 3rd party jar in Rhiot. This is
> common for Red Hat to work on
community projects now owned by us
(for
> example on Apache projects) and
then using the resulting jars in the
> projects we do own.
>
> Cheers!
>
> pon., 7.12.2015 o 14:39
użytkownik Hudalla Kai (INST/ESY) <
> Kai.Hudalla@xxxxxxxxxxxx
> napisał:
>
>
> Hi Greg,
>
> it's great to see more people
joining the mailing list! I really
like
> the enthusiasm you and Henryk put
on display for the LWM2M Protocol
> Adapter as well because I think
it would be a good first adapter to
> have (along with a generic MQTT
Protocol Adapter).
>
> I was discussing internally with
Steffen Evers whether it would make
> sense to include at least one
protocol adapter in the scope of the
IoT
> Connector. This way we could use
the protocol adapter as the "real
> world" test case for the
southbound interface of the IoT
Connector and
> we would have some reasonable
connectivity solution out-of-the-box
> instead of just having the IoT
Connector with potentially no Protocol
> Adapter being usable at the time
of a first release. What do you guys
> think?
>
> Another thing I would like to
better understand is the context in
which
> you would like to start to work
on the LWM2M Protocol Adapter. Would
> you set it up as part of the
RHIOT project on GitHu b? Or would you
> like to set up a new GitHub repo?
I am asking because (at least for
> Bosch) it would be important to
understand the legal framework the
code
> is published in. Bosch explicitly
decided to join the Eclipse
> Foundation and work on open
source projects under the legal
framework
> of Eclipse only because this
provides a "safe" context for us to
work
> on open source. This might be
totally different for RedHat because
your
> level of maturity regarding open
source development is probably much
> higher. Therefore, it would be
much easier for Bosch to engage in
such
> a project if it were hosted by
Eclipse and we could collaborate on it
> under the Eclipse legal
framework. Any thoughts on this?
>
> Mit freundlichen Grüßen/ Best
regards
>
> Kai Hudalla
>
> Bosch Software Innovations GmbH
> Schöneberger Ufer 89
> 10785 Berlin
> GERMANY
> www.bosch-si.de
>
> Mobile +49 (151)
54336335
> Phone +49 (30) 726
112-145
> kai.hudalla@xxxxxxxxxxxx
>
> Registered office: Berlin,
Register court: Amtsgericht
Charlottenburg,
> HRB 148411 B
> Executives: Dr.-Ing. Rainer
Kallenbach; Michael Hahn
>
>
>
> > -----Original Message-----
> > From: iot-sp-bounces@xxxxxxxxxxx
[mailto: iot-sp-bounces@xxxxxxxxxxx
> ] On
> > Behalf Of Greg Autric
> > Sent: Thursday, December 03,
2015 1:50 AM
> > To: iot-sp
> > Subject: Re: [iot-sp] LWM2M
protocol adapter prototype
> >
> > Hi Henryk,
> >
> > Yes I am in too.
> >
> > keep in touch
> >
> > Greg AUTRIC
> > JBoss Middleware Consultant
> >
> > email : gautric __at__
redhat __dot__ com
> > twitter : @gautric_io
> >
> > Red Hat Global Services
> > Red Hat France SARL sit: http://www.redhat.fr
> > Le Linea, 1 rue du General
Leclerc, 92047 Paris La Défense Cedex
Sent
> > from webmail
> >
> > ----- Mail original -----
> > De: "Henryk Konsek" < hekonsek@xxxxxxxxx
>
> > À: iot-sp@xxxxxxxxxxx
> > Envoyé: Mercredi 2 Décembre
2015 16:57:29
> > Objet: [iot-sp] LWM2M
protocol adapter prototype
> >
> > Hi,
> >
> > I'd love to start working on
a prototype of the LWM2M protocol
> adapter
> > based on Eclipse Leshan. I
guess I'm not the only one as more
people
> > declared a willingness to
work on this topic.
> >
> > Maybe we could set up a
GitHub repository for the project
Server
> > Platform project where we
could start to create the very first
> version
> > of a protocol adapter?
> >
> > Cheers!
> > --
> > Henryk Konsek
> > http://about.me/hekonsek
> >
> >
_______________________________________________
> > iot-sp mailing list
> > iot-sp@xxxxxxxxxxx
> > To change your delivery
options, retrieve your password, or
> unsubscribe
> > from this list, visit https://dev.eclipse.org/mailman/listinfo/iot-sp
> >
_______________________________________________
> > iot-sp mailing list
> > iot-sp@xxxxxxxxxxx
> > To change your delivery
options, retrieve your password, or
> unsubscribe
> > from this list, visit https://dev.eclipse.org/mailman/listinfo/iot-sp
>
_______________________________________________
> iot-sp mailing list
> iot-sp@xxxxxxxxxxx
> To change your delivery options,
retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/iot-sp
> --
> Henryk Konsek
> http://about.me/hekonsek
>
>
>
_______________________________________________
> iot-sp mailing list iot-sp@xxxxxxxxxxx
To change your delivery options,
> retrieve your password, or
unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/iot-sp
>
> --
>
> Ian Skerrett
> VP of Marketing
> Eclipse Foundation
> (m) 613-240-7210
> (o) 613-224-9461 ext 227
> (t) @ianskerrett
>
_______________________________________________
> iot-sp mailing list
> iot-sp@xxxxxxxxxxx
> To change your delivery options,
retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/iot-sp
> --
> Henryk Konsek
> http://about.me/hekonsek
>
>
_______________________________________________
> iot-sp mailing list
> iot-sp@xxxxxxxxxxx
> To change your delivery options,
retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/iot-sp
>
_______________________________________________
> iot-sp mailing list
> iot-sp@xxxxxxxxxxx
> To change your delivery options,
retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/iot-sp
_______________________________________________
iot-sp mailing list
iot-sp@xxxxxxxxxxx
To change your delivery options,
retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/iot-sp
_______________________________________________
iot-sp mailing list
iot-sp@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/iot-sp
_______________________________________________
iot-sp mailing list
iot-sp@xxxxxxxxxxx
To change your delivery options, retrieve your
password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/iot-sp
--
_______________________________________________
iot-sp mailing list
iot-sp@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/iot-sp
_______________________________________________
iot-sp mailing list
iot-sp@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/iot-sp
|
