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.
Related
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'd like to have a page or a section of information that only is relevant to a specific API. Is that possible in the new portal?
In this case it has to do with information about event data that is sent out (to webhooks) when new items are created and that are then available in operations for the API. If it's not possible to have i an "API-specific" page, where would you put something like this?
I believe in this case you are trying to add some sort of static page or documentation to explain the functionality about a specific API. You may refer to this. As mentioned in the thread, you can try with swagger but in APIM portal it might not work immediately. Microsoft product team has confirmed that they working on improving support for OpenAPIv3. The ETA is about end of September.
However, you may also check the self-hosted gateway feature
The self-hosted gateway feature expands API Management support for hybrid and multi-cloud environments and enables organizations to efficiently and securely manage APIs hosted on-premises and across clouds from a single API Management service in Azure.
Official Documentation
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.
Me and my team will be working on APIGEE which is an API development platform to expose some services in our application. I am going through their documentation and also trying to understand the need of APIGEE or any other API development platform like Mashery. One very good article on the need of API proxy as been very well explained in the given link, http://apievangelist.com/2011/06/11/the-battle-for-your-api-proxy/
One question that i am confused about is What is the difference between APIGEE and any ESB like ALSB or Mule. We know Apigee too supports message transformation via policies and protocols like http/https/soap.
Can anyone please tell me the differences between the two? Does Esb support more protocols like SMTP/JMS etc.
Any information is most welcome
Though API management definition is still evolving but API management is defined as transforming APIs to reach to your target audience [ here is a good description - http://searchcloudapplications.techtarget.com/definition/API-management].
This technology has it's root in SOA but different from ESB.
ESB is more for system-to-system integration but API tends to be securely exposing your internal systems in a managed fashion to wider audience - we call them "developers".
ESB tends to be equipped with many adapters and strong message oriented middleware for supporting different interaction patterns. It is also generally couple with business process management software to automate internal processes by integrating multiple services or systems.
API management also does some integrations and orchestrations but focus is more simplifying the interfaces to easier consumption of the services - that's why it is always come with developer on-boarding capabilities, security , caching , api design , oauth etc.
Apigee gateway service [ API management platform ] has support for limited JMS and SMTP functionality serving our diverse customer base and our technology stack is capable of building other protocol support.
Many API management products [ including Apigee gateway ] also include API analytics to help you getting insight of API program and API traffic.
Nowadays, APIGEE and Mule are direct competitors in the API management offering realm. In the case of Mule, there was a great transformation on the company, towards API-ification of all systems. Current Mule runtime is integrated with strong API management capabilities including analytics (functionalities from the former Mulesoft's API Gateway product, which was merged into the Mule runtime since v3.8.0), as well the usual ESB capabilities. Further info is available at Mule dev doc site.
API Management & ESB are two different capabilities which may have little overlap in terms of exposing the integrations themselves as API's which Mulesoft does.
Apigee also supports few ESB capabilities but it's not as exhaustive as Mulesoft. Ofcourse ESB is bigger scope & if you don't need that capability & just need API management with Full API lifecyle Mulesoft & APIGee both serves that need.
Personally I am a big fan of Mulesoft's API policies which comes out of box & it's an exhaustive list.
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.