I am investigating how to use the Fiware's Lightweight M2M agent.
I read: https://fiware-iotagent-lwm2m.readthedocs.io/en/latest/deviceProvisioning/index.html and this other helped so much: Setting up LWM2M device communicates with IDAS
But I didn't find how is the message's coap format waited, and where fiware-service and fiware-service-path are placed.
I get with the Lightweight M2M client I can test the client (but it is a kind of blackbox), and I would like understand how is the format for develop my own client/device.
Wikipedia
LwM2M is specified by the OMA. It offers a resource-model and supports two encoding modes TLV and CBOR (at least, the newer spec).
Related
I'm looking for a way to implement basic Publish / Subscribe between applications written in different languages, to exchange events with JSON payloads.
WebSocket seems like the obvious choice for the transport, but you need an (arguably small) layer on top to implement some of the plumbing:
aggreeing on messages representing the pubsub domain "subscribe to a topic", "publish a message"
aggreeing on messages for the infra ("heartbeat", "authentication")
I was expecting to find an obvious standard for this, but there does not seem to be any.
WAMP is often refered to, but in my (short) experience, the implementations of server / clients libraries are not great
STOMP is often refered to, but in my (even shorter) experience, it's even worse
Phoenix Channels are nice, but they're restricted to Phoenix/Elixir world, and not standard (so the messages can be changed at any phoenix version without notice.)
So, is everyone using MQTT/WS (which require another broker components, rather than simple servers ?) Or gRPC ?
Is everyone just re-implementing it from scratch ? (It's one of those things that seems easy enough to do oneselves, but I guess you just end up with an half-baked, poorly-specified, broken version of the thing I'm looking for...)
Or is there something fundamentally broken with the idea of serving streams of data from a server over WS ?
There are two primary classes of WebSocket libraries; those that implement the protocol and leave the rest to the developer, and those that build on top of the protocol with various additional features commonly required by realtime messaging applications, such as restoring lost connections, pub/sub, and channels, authentication, authorization, etc.
The latter variety often requires that their own libraries be used on the client-side, rather than just using the raw WebSocket API provided by the browser. As such, it becomes crucial to make sure you’re happy with how they work and what they’re offering. You may find yourself locked into your chosen solution’s way of doing things once it has been integrated into your architecture, and any issues with reliability, performance, and extensibility may come back to bite you.
ws, faye-websockets, socket.io, μWebSockets and SocketCluster are some good open-source options.
The number of concurrent connections a server can handle is rarely the bottleneck when it comes to server load. Most decent WebSocket servers can support thousands of concurrent connections, but what’s the workload required to process and respond to messages once the WebSocket server process has handled receipt of the actual data?
Typically there will be all kinds of potential concerns, such as reading and writing to and from a database, integration with a game server, allocation and management of resources for each client, and so forth.
As soon as one machine is unable to cope with the workload, you’ll need to start adding additional servers, which means now you’ll need to start thinking about load-balancing, synchronization of messages among clients connected to different servers, generalized access to client state irrespective of connection lifespan or the specific server that the client is connected to – the list goes on and on.
There’s a lot involved when implementing support for the WebSocket protocol, not just in terms of client and server implementation details, but also with respect to support for other transports to ensure robust support for different client environments, as well as broader concerns, such as authentication and authorization, guaranteed message delivery, reliable message ordering, historical message retention, and so forth. A data stream network such as Ably Realtime would be a good option to use in such cases if you'd rather avoid re-inventing the wheel.
There's a nice piece on WebSockets, Pub/Sub, and all issues related to scaling that I'd recommend reading.
Full disclosure: I'm a Developer Advocate for Ably but I hope this genuinely answers your question.
Could anybody explain advantage of using json-rpc over json-api and vice-versa? First and second format are JSON-based, but where I should use one, and where is another?
Note: I may come across a little biased. I am the author of the Json-RPC.net server library.
Json-RPC is a remote procedure call specification. There are multiple libraries you can use to communicate using that protocol. It is not REST based, and is transport agnostic. You can run it over HTTP as is very common, you can also use it over a socket, or any other transport you find appropriate. So it is quite flexible in that regard. You can also do server to client along with client to server requests with it by hosting the RPC server on either the client or the server.
Json-API is a specification for building REST APIs. There are multiple libraries you can use to get started with it. In contrast to Json-Rpc it requires you to host it on an HTTP server. You cannot invoke functions on the client with it. You cannot run it over a non-http transport protocol. Being REST based, it excels at providing information about Resources. If you want an API that is based around the idea of Create, Read, Update, Delete on some collections of resources, then this may be a good choice.
Json-API is going to be better if your API is resource-based, and you want your API to be browsable by a human without setting up documentation for it. Though that human would likely need to be in the software engineering field to make any sense of it.
Json-RPC is going to be better if your API is function based, or you want the flexibility it provides. Json-RPC can still be used to manipulate Resources by creating Create, Read, Update, and Delete functions for your resources, but you don't get the browsability with it not being REST based. It can still be explored (not browsed) by a human by generating documentation based off of the functions you expose.
A popular example of something that uses Json-Rpc is BitCoin.
There are a lot of popular REST-based API's and Json-API is a spec with a bunch of tools to help you do REST right.
--
Note: Neither of those (Json-RPC, or Json-API) are good when you consider for developer time, performance, or efficiently using network resources.
If you care about performance, efficiency, or developer time then take a look at Google's gRPC which is fantastic in those regards, and can still reduce developer time more than using a REST API as client and server code can be generated from a protocol definition file.
I am beginner to MQTT , but what is confusing me is it's basic definition
MQTT is a publish-subscribe based "light weight" messaging protocol'.
Based on my previous understanding on MQ (Message Queue), both MQ and MQTT sounds very same to me. Can any one elaborate what the real difference between MQ and MQTT is and their use case? Thanks!!
MQTT was initially called "Message Queue Telemetry Transport". You can find an in-depth explanation how it evolved here: http://www.hivemq.com/mqtt-essentials-part-1-introducing-mqtt/
MQTT is a protocol, it is open source. A lot of vendors are using this protocol for messaging.
MQ is an over-arching team that just means messaging. There are lot of different protocols, AMQP is one of them as well.
Additionally, IBM had a product called MQ.
MQTT is an OASIS standard protocol that is not only used for MQ messaging but it can also be used for the Internet of Things IOT and M2M (machine to machine) communication.
Here is a slide presentation that you may find useful.
I would to develop an IoT mobility project project using fi-ware.
My intention is to deploy a lot of sensor on the taxi/bus
in the city to control air quality.
I want to use IDAS GEi, but i have some questions:
I must use a linino board as gateway for my sensors.
How can i send observations or receive commands from
linino to IDAS and viceversa? I have found on the web this
tool: figway. I have read figway is used as communication
gateway between raspberryPI and IDAS.
So i have thought to adapt figway for linino. Is it the correct way
to reach my goal? Are there better ways to do that?
Furthermore, i should provide discovery mechanisms and a transparent
interface to control the sensors. For example, i should provide to the user
the possibility to find the sensors, that provide a data measure, in a certain place.
I would to use SWE for that. Is IDAS swe compliant? I have read in the documentation
IDAS uses swe data model, sensorML, O&M but i have not found anything about
SOS/SAS/SPS/WNS services.
Has IDAS discovery mechanisms? Maybe i must use other GE to do that (Configuration Manager?)
Figway is just a python example of how you can make the queries to the Ultralight 2.0 IoT-Agent.
You may port Figway to your new platform if it supports python or, alternatively you can check the HTTP POST requests to code at any other platform/language.
It is really easy, have a look at: http://www.slideshare.net/FI-WARE/fiware-iotidasintroul20v2
Additionally, do not forget that Ultralight2.0/HTTP is one of the technology options that we support for IoT. If your devices are to use other standard such as MQTT/TCP or LWM2M/CoAP/UDP you can check other IoT-Agents (that connect as well to the same Orion contextbroker):
UL2.0 and MQTT are here: https://github.com/telefonicaid/fiware-IoTAgent-Cplusplus
LWM2M is here: https://github.com/telefonicaid/lightweightm2m-iotagent
Also, if you want to use any other standard (or even your own propietary protocol) you may build up your own IoT Agent using the skeleton provided here:
https://github.com/telefonicaid/iotagent-node-lib
Thanks for using IDAS!
Cheers,
Can anyone explain at a beginner-intermediate level the terminology of "bus", "transport" and "endpoint" in the context of an enterprise service bus? I'm a C# developer with a few years experience now, but only just starting working with an ESB.
It seems that the "bus" is effectively a queue to which you can send and receive messages. I'm fine with that. However I'm working on some existing code using NServiceBus and I think if I grokked the "endpoint" and "transport" terminology I'd make a massive leap forward in my understanding.
Let me try to clarify those terms to you:
Bus in context of ESB architecture should not be considered as simple queue for message dispatching. To allow integration of different services, ESB provides much more. Important additional functionalities of ESB:
Routing. Messages can be routed to different services, depending on message content or endpoint specification.
Message Transformations/Mediations between different formats
Transport protocol conversion. ESB should be able to seamlessly integrate applications
that use different transport protocols (JMS, HTTP/S, pure TCP, etc.)
Message enhancement. Messages can be enriched with missing data before further processing.
Security
Management and Monitoring
Those functionalites are provided by services that operate within ESB. Services connect to each other via endpoints - uniform, unique "addresses". Messages dispatched between endpoints are using unified transport (method/protocol that encapsulates message's payload). Application that natively use different transport, need to connect to ESB via suitable adapter - service that will provide necessary transport conversion. This way applications that use ESB are decoupled from each other and don't need to provide conversions themselves.
Of course, those are only very brief descriptions of terms. Remember, Enterprise Service Bus is only catch-term for specific kind of architecture (or concept), but it is not standardized in any way. So specific implementations can be very different from each other.
If you are interested in standardized ESB, you can take a look at JBI (Java Bussiness Integration). There are several open-source implementations of JBI avalable, among them Apache ServiceMix, Mule, OpenESB. Very good introduction to ESB technologies is presented in "Open Source ESBs in Action" book published by Manning.
I would recommend looking at resources related to Enterprise Application Integration (EAI), which revolves around the ESB and various models and patterns used to integrate solutions. Think of it is a GoF for ESB architectures:
http://www.enterpriseintegrationpatterns.com/
and
http://www.enterpriseintegrationpatterns.com/toc.html
All of these patterns would give you an idea of what people use ESB's to achieve and the patterns are useful for providing common pitfalls of do-it-yourself ESB integration. I've learned an immense amount through that book and through people that source from it.