There's an IIB HTTP SOAP service exposed to multiple channels - the service has 4 operations and one of them is being consumed very frequently by a particular channel (less than 1 transaction per second).
Is there any way within IBM Integration Bus (broker or service level) to limit number of HTTP requests per channel (IP address) to 1 or n transactions per second?
You could implement it manually using the standard facilities of IIB, but rate-limiting is an API management feature and best implemented using out-of-the-box features of IBM API Connect. It works well with IIB, btw.
As already suggested above, this kind of logic should be done outside of IIB if you need it globaly.
On IIB level, you can configure many things, like the maximum amount of connection, but there's no logic to have this kind of pool for each users.
The best solution, in my opinion, is to use a network component specialized in this kind of logic. On my side, I've decided to implement this rule on the load balancer I have in front of my IIB server. A proxy could probably also do it.
For your specific case, if it is the only case where you need this logic, you can also consider creating different entry point for each application. If this is SOAP, and that the users currently calls /kimbertService/, you can consider having multiple SOAP Input node, with the following routes instead : /kimbertService/App1, /kimbertService/App2, /kimbertService/App3, and then you'll be sure that App1 will never block App2 ...
IIB has a feature of throttling by limiting the number of messages processed through a given message flow per second.
For example, to set the maximumRateMsgsPerSec property for a message flow included in an application, you can use the following sample code:
mqsiapplybaroverride –b BARfile -k applicationName -m sampleFlow#maximumRateMsgsPerSec=100
You can also do it through workload management policies by using the IIB web user interface.
Below is the link:
https://www.ibm.com/support/knowledgecenter/en/SSMKHH_9.0.0/com.ibm.etools.mft.doc/bj58270_.htm
A WORK-A-ROUND SOLUTION
The ideal solution, as others have mentioned, would be to have a API management gateway sitting in front of IIB to manage your API.
Now, a work-around solution could be following:
1) Have your main service flow duplicated, making them two different message flows. These two are your back-end flows performing the same thing but on one of them you can enable throttling.
2) Build a new router IIB flow which takes HTTP requests from consumers. This flow identifies the requester and routes it to the back-end flows accordingly.
Hope this helps.
Related
As per the KAA references, I understand that once should only use the Notification feature, When it required to send data from server (External apps) to endpoints and Events are only used when there is a need for endpoint to endpoint communication (kind of device binding requirement)
So, To achieve request/response functionality using KAA. I need to implement any hybrid solutions like as below.
1) In my server, I can run one KAA SDK instance and use the event feature for request to the endpoint and response from the endpoint.
OR
2) From my server, I use the notification REST API for request and get the response back through the data logger feature using any in-build appender by configuring "LogUploadStrategy" as to uploads every log record as soon as it is created.
Notes For Point 1
As per Andrew, Solutions Architect of Kaa IoT platform
"You can always embed an SDK to a standalone application and host in
on the same server where kaa-node is present. This application may
receive REST API calls and forward them to particular endpoints via
Kaa events feature. However, this is useful for test purposes. I
would not recommend this solution in production because it is hard to
scale and has potential security issues"
Notes For Point 2
It satisfies the KAA reference document as well as Andrew's suggestion for request only but how can i achieve the response.
Questions For Point 1
1) What causes to scale the application and what type of security issues it faces even through it uses RSA 2048 encryption for communication?
2) Can we embed more then one SDK in standalone application and host in on the same server where kaa-node is present.
Questions For Point 2
3) if device sends the notification response along with the telemetry data, can it increase the latency and any other performance issue.
Common Questions
4) Which one is the better approach to achieve request/response functionality?
Any help or suggestion is really appreciated.
1) What causes to scale the application and what type of security issues it faces even though it uses RSA 2048 encryption for communication?
It makes the EP on the server side as a single point of failure and does not allow load balancing.
About security issues, Andrew meant: This application may receive REST API calls and this forces one to provide additional security for this REST API calls and better use your first hybrid solutions using solely event feature.
2) Can we embed more then one SDK in standalone application and host in on the same server where kaa-node is present.
No, you can't use more than one SDK in one application, but you can run a couple of instance on one machine in different directories
in order to prevent collisions of autogenerated security keys and other files.
3) if device sends the notification response along with the telemetry data, can it increase the latency and any other performance issue.
Of course, you will face some delays if start sending very frequently and big portions of data on both sides. If you have a lot of devices that sends in total a big amount of telemetry data, you can increase performance on the server side by start-up KAA in the cluster mode or add new nodes for processing requests.
4) Which one is the better approach to achieve request/response functionality?
The second hybrid solution – data collection and notification features. This doesn't cause any problem with scale and you can easily launch Kaa server in cluster mode.
Like most web development, I have multiple environments:
Local development
Cloud staging
Cloud production
Cloud-based web debugging services like RequestBin or Runscope which allow you to inspect http requests
etc.
During development and testing I would like to have inbound http requests (whether they are from users, 3rd party webhooks, etc.) hit multiple endpoints at the same time. Naturally I don't have control of the origination of those inbound requests.
How might I achieve for example, receiving a 3rd party webhook in both my production environment and development environment at the same time?
Update: Let me follow up with the broader question - Perhaps my feeling that this functionality is a requirement is misplaced. The reason I am looking for this functionality is because it would vastly simplify configuration (for example, I would have to set up multiple instances of a 3rd party webhook in order to go to my multiple environments). How are others handling this overall situation?
There is no way to do this "natively" as this would be in direct violation of numerous protocols and standards. That said depending on how you want to handle the responses, you can create a router (software function, not networking device) that accepts the requests, issues new requests to each environment, aggregates those responses, and finally returns that to the client.
If I understood you correctly, maybe what you are looking for, is a Topic system with publishers (producers) and subscribers (consumers). If it's what you need, maybe AWS SNS can be a good option for that, it's free for 1M requests, and with it, you can configure your environments as subscribers then make the requests to a SNS topic, which will fanout them to the subscribers.
If you only want to log the requests, you can also use PutsReq as a proxy. Making the requests to PutsReq, and "re-passing" them to the real target.
// sample response builder
// https://github.com/phstc/putsreq#forwardto
request.forwardTo = 'http://production.com/api';
A little background.
Very big monolithic Django application. All components use the same database. We need to separate services so we can independently upgrade some parts of the system without affecting the rest.
We use RabbitMQ as a broker to Celery.
Right now we have two options:
HTTP Services using a REST interface.
JSONRPC over AMQP to a event loop service
My team is leaning towards HTTP because that's what they are familiar with but I think the advantages of using RPC over AMQP far outweigh it.
AMQP provides us with the capabilities to easily add in load balancing, and high availability, with guaranteed message deliveries.
Whereas with HTTP we have to create client HTTP wrappers to work with the REST interfaces, we have to put in a load balancer and set up that infrastructure in order to have HA etc.
With AMQP I can just spawn another instance of the service, it will connect to the same queue as the other instances and bam, HA and load balancing.
Am I missing something with my thoughts on AMQP?
At first,
REST, RPC - architecture patterns, AMQP - wire-level and HTTP - application protocol which run on top of TCP/IP
AMQP is a specific protocol when HTTP - general-purpose protocol, thus, HTTP has damn high overhead comparing to AMQP
AMQP nature is asynchronous where HTTP nature is synchronous
both REST and RPC use data serialization, which format is up to you and it depends of infrastructure. If you are using python everywhere I think you can use python native serialization - pickle which should be faster than JSON or any other formats.
both HTTP+REST and AMQP+RPC can run in heterogeneous and/or distributed environment
So if you are choosing what to use: HTTP+REST or AMQP+RPC, the answer is really subject of infrastructure complexity and resource usage. Without any specific requirements both solution will work fine, but i would rather make some abstraction to be able switch between them transparently.
You told that your team familiar with HTTP but not with AMQP. If development time is an important time you got an answer.
If you want to build HA infrastructure with minimal complexity I guess AMQP protocol is what you want.
I had an experience with both of them and advantages of RESTful services are:
they well-mapped on web interface
people are familiar with them
easy to debug (due to general purpose of HTTP)
easy provide API to third-party services.
Advantages of AMQP-based solution:
damn fast
flexible
cost-effective (in resources usage meaning)
Note, that you can provide RESTful API to third-party services on top of your AMQP-based API while REST is not a protocol but rather paradigm, but you should think about it building your AQMP RPC api. I have done it in this way to provide API to external third-party services and provide access to API on those part of infrastructure which run on old codebase or where it is not possible to add AMQP support.
If I am right your question is about how to better organize communication between different parts of your software, not how to provide an API to end-users.
If you have a high-load project RabbitMQ is damn good piece of software and you can easily add any number of workers which run on different machines. Also it has mirroring and clustering out of the box. And one more thing, RabbitMQ is build on top of Erlang OTP, which is high-reliable,stable platform ... (bla-bla-bla), it is good not only for marketing but for engineers too. I had an issue with RabbitMQ only once when nginx logs took all disc space on the same partition where RabbitMQ run.
UPD (May 2018):
Saurabh Bhoomkar posted a link to the MQ vs. HTTP article written by Arnold Shoon on June 7th, 2012, here's a copy of it:
I was going through my old files and came across my notes on MQ and thought I’d share some reasons to use MQ vs. HTTP:
If your consumer processes at a fixed rate (i.e. can’t handle floods to the HTTP server [bursts]) then using MQ provides the flexibility for the service to buffer the other requests vs. bogging it down.
Time independent processing and messaging exchange patterns — if the thread is performing a fire-and-forget, then MQ is better suited for that pattern vs. HTTP.
Long-lived processes are better suited for MQ as you can send a request and have a seperate thread listening for responses (note WS-Addressing allows HTTP to process in this manner but requires both endpoints to support that capability).
Loose coupling where one process can continue to do work even if the other process is not available vs. HTTP having to retry.
Request prioritization where more important messages can jump to the front of the queue.
XA transactions – MQ is fully XA compliant – HTTP is not.
Fault tolerance – MQ messages survive server or network failures – HTTP does not.
MQ provides for ‘assured’ delivery of messages once and only once, http does not.
MQ provides the ability to do message segmentation and message grouping for large messages – HTTP does not have that ability as it treats each transaction seperately.
MQ provides a pub/sub interface where-as HTTP is point-to-point.
UPD (Dec 2018):
As noticed by #Kevin in comments below, it's questionable that RabbitMQ scales better then RESTful servies. My original answer was based on simply adding more workers, which is just a part of scaling and as long as single AMQP broker capacity not exceeded, it is true, though after that it requires more advanced techniques like Highly Available (Mirrored) Queues which makes both HTTP and AMQP-based services have some non-trivial complexity to scale at infrastructure level.
After careful thinking I also removed that maintaining AMQP broker (RabbitMQ) is simpler than any HTTP server: original answer was written in Jun 2013 and a lot of changed since that time, but the main change was that I get more insight in both of approaches, so the best I can say now that "your mileage may vary".
Also note, that comparing both HTTP and AMQP is apple to oranges to some extent, so please, do not interpret this answer as the ultimate guidance to base your decision on but rather take it as one of sources or as a reference for your further researches to find out what exact solution will match your particular case.
The irony of the solution OP had to accept is, AMQP or other MQ solutions are often used to insulate callers from the inherent unreliability of HTTP-only services -- to provide some level of timeout & retry logic and message persistence so the caller doesn't have to implement its own HTTP insulation code. A very thin HTTP gateway or adapter layer over a reliable AMQP core, with option to go straight to AMQP using a more reliable client protocol like JSONRPC would often be the best solution for this scenario.
Your thoughts on AMQP are spot on!
Furthermore, since you are transitioning from a monolithic to a more distributed architecture, then adopting AMQP for communication between the services is more ideal for your use case. Here is why…
Communication via a REST interface and by extension HTTP is synchronous in nature — this synchronous nature of HTTP makes it a not-so-great option as the pattern of communication in a distributed architecture like the one you talk about. Why?
Imagine you have two services, service A and service B in that your Django application that communicate via REST API calls. This API calls usually play out this way: service A makes an http request to service B, waits idly for the response, and only proceeds to the next task after getting a response from service B. In essence, service A is blocked until it receives a response from service B.
This is problematic because one of the goals with microservices is to build small autonomous services that would always be available even if one or more services are down– No single point of failure. The fact that service A connects directly to service B and in fact, waits for some response, introduces a level of coupling that detracts from the intended autonomy of each service.
AMQP on the other hand is asynchronous in nature — this asynchronous nature of AMQP makes it great for use in your scenario and other like it.
If you go down the AMQP route, instead of service A making requests to service B directly, you can introduce an AMQP based MQ between these two services. Service A will add requests to the Message Queue. Service B then picks up the request and processes it at its own pace.
This approach decouples the two services and, by extension, makes them autonomous. This is true because:
If service B fails unexpectedly, service A will keep accepting requests and adding them to the queue as though nothing happened. The requests would always be in the queue for service B to process them when it’s back online.
If service A experiences a spike in traffic, service B won’t even notice because it only picks up requests from the Message Queues at its own pace
This approach also has the added benefit of being easy to scale— you can add more queues or create copies of service B to process more requests.
Lastly, service A does not have to wait for a response from service B, the end users don’t also have to wait for long— this leads to improved performance and, by extension, a better user experience.
Just in case you are considering moving from HTTP to AMQP in your distributed architecture and you are just not sure how to go about it, you can checkout this 7 parts beginner guide on message queues and microservices. It shows you how to use a message queue in a distributed architecture by walking you through a demo project.
I am working on a application, which is proposed to be a set of webapps (being called agent), running on tomcat 7, configured on different nodes. I have been tasked, to make these webapps(agent) discover each other automatically. The idea is, that each webapp(say agent X) , once up, will communicate a 'request pattern' to all the other webapps. Other webapps(say agents A, B, C) in turn will store this information ('request pattern') and will use these to route any matching request to agent X using http call.
I am looking for some option where in each webapp will have some component listening on particular port, and the agent X while registering itself will send a multicast request to all the nodes on that particular port.
I think apache camel might be useful here.. but I am not sure.
It will be great if some body can tell the technical viability of this approach, or any other suggestions.
My first thought was that you could use apache httpd and the mod_proxy_loadbalancer to balance all requests over the available nodes. You can define different balancers for any kind of agents. Requests will be send to the balancer and the balancer will route it to any available node.
This is more of a messaging than a routing problem. Add Camel if you need complex routing or adapting to legacy protocols.
This looks like a classic publish and subscribe use case. You can do it with any messaging technology. Look at JMS - ActiveMQ is what Camel uses, or AMQP - I've used RabbitMQ very successfully for this, both use the "topic" paradigm for this, a quick search found this as an example: http://jmsexample.zcage.com/index2.html. Or Jabber.
Julian
I've read of an ESB being used as a SOA approach. What are some other approaches?
This is a very broad question, you may want to focus is.
If you are asking regarding approaches that are instead of ESB, then you may consider using direct access to services, instead of using a service bus.
This approach is often used with a directory or lookup service like UDDI to look up service end point location.
When using an ESB, you send the message to the ESB, who 's responsible to route it to the service provider.
When using direct access the client should know in advance the address of the service provider, and he sends the message directly to him.
When using a lookup service, you first query the address of the service provider (like using DNS to lookup IP addresses), and using this address you send the message to the service provider.
Beyond addressing and routing, the ESB may provide other functions that you loose (or have to implement in other way) if you use the direct access approach.
multi cast routing - sending the request to more then one service provider
context based routing - deciding to which service provider we should send the request, based on the content of the request
central logging
central policy enforcement
load balancing \ fault tolerance
format or protocol translation
buffering and asynchronous service invocation
First.... ask yourself which SOA philosophy are you adhering to. If you are in the IBM camp, then there are 4 different products that provide ESB functionality. Each product is optimized for a different scenarios but basically each one does similar functions.
Think.... SOA == a car. IBM is one manufacturer. Different products == different type of cars for different type of drivers.