I'm trying to integrate Proton CEP and Mandrill, an email service, mediated by Orion context broker.
When I was starting to study Orion, I thought that it would be able to communicate directly with CEP, exchanging JSON objects through http. And also that Orion would be able to parse each object to deliver to the correct format understandable by each API.
From the examples and documentation available I was able to understand that another API developed by us should be doing the parsing and mediating the communications between each API.
So I'd like to confirm that this is so and that I'm not missing something. Is Orion indeed unable to customize its outputs?
If confirmed, then I will proceed with development of this mediating API.
Arthur
Edit:
I believe I wasn't clear above about the issue. I hope adding this helps.
Proton CEP recieves through http POST JSON objects, but it only understands the variables if they are in simple format, like {"Name1":"Value1","Name2":"Value2"}, with no arrays or complex struture.
Orion, can comunicate in JSON as well through http, but I can't control the structure of the JSON output. So the result is that CEP wouldn't be able to understand inputs from Orion and process them. The same issue arises with other APIs too. And I'd like to confirm that Orion is indeed unable to custom its output and that this integration needs to be done on our side.
You can find best explanation about connection between CEP and Orion in latest guides.
User guide's Appendix A specifies steps to establish such a communication (subscription(s) and/or simple publish).
Orion only understands/returns XML and JSON, and with this it is able to communicate with most of the GEs in FIWARE. I can't tell you anything about the Proton CEP, sorry.
To make sure you have interoperability between GEs (and especially other components) a "mediating gateway" will solve the problem, of course.
The JSON format that Orion Context Broker sends in notification conforms to the NGSI10 context management specification. Using a predefined JSON (instead of a custom one) is the best way to ensure that interoperability with other NGSI-compliant software works.
Before doing the NGSI-to-Proton adaptation piece yourself, I'd recomend you to check with Proton development team if there is any existing NGSI connector to their system that you can reuse. You can find contact details in Proton page at FIWARE catalogue.
Related
I hope I'll find a reply to a bad (for me) question for which i don't find an answer at the moment.
I have to synchronize information between an enterprise asset management software, based on IBM Maximo, and an external data lake. In order to achieve this target I can develop a custom API gateway useful to receive any update/insert of data in Maximo. Or, I could use FIWARE Context Broker developing a custom data model for my asset management entities (and relationship) in order to store data having benefits in terms of NGSI protocol.
Both FIWARE Context Broker or API Gateway can be extended in order to provide public services to an IoT platform or other systems of third parties. So, why shall I use FIWARE Context Broker or a custom API Gateway? What's your advice and considerations?
I put below an example of a generic architecture
Thank you so much for any reply.
We are evaluating several platforms for integrating a "Smart Energy System".
One important requirement we have to support is multitenancy. From the docs I can see the possibility to start the Orion Context Broker with this option. Orion will ensure the data separation based on the fiware-service request header.
That's fine but how to "secure" this header across the whole software stack (PEP-Proxy, IoT-Agent)?
Which component/device sets this header? Which component ensures that a request with a specific fiware-service header value is authorized to access the data of this tenant?
In my opinion this is a task for Wilma as PEP-Proxy. All traffic to Orion is routed through the PEP-Proxy and the proxy checks if this request is valid. Unfortunately I can not find such a check within the source code nor it is explained in the documentation.
Has someone implemented such an architecture an can help me?
Found another post which answers my question
How to configure access control in Orion NGSI API for tenant isolation using Wilma PEP Proxy and IdM Keyrock?
We will have to implement this kind of authorization for our own.
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,
What is the best technique to push notifications from the cloud to a client? REST does not seem to support this. In particular, I have JSON objects representing world state going to the cloud and want to be able to notify a client when that state changes.
All HTML5 implementations I've seen support full duplex communication via WebSockets.
If you're using Google App Engine you can use the Channel API. https://developers.google.com/appengine/docs/java/channel/
If you're using JBoss you can use the Errai Framework. http://errai.github.io/
I'm sure there are a lot of other options out there. And there's always email.
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.