When need to authenticate to the backend service instance prior to the webservice call. Prior to using ribbon we have been using a Zuul pre filter to accomplish this. When switching to ribbon the pre filter now only has access to the service name and not the backend URI that will be invoked. How should this be handled ? Is it possible to register a pre-action with the ribbon router ?
thank you
Related
I have trouble understanding the connection between Zuul and Ribbon.
I think I got Zuul clear. It's a reverse proxy I can contact to reach one of my several instances of a service. It will pick the right server using a round-robin algorithm or whatever you configure it to do. It's a traditional load-balancer. To know the instances available it can use a registry like Eureka.
But I've got more trouble with Ribbon. It's sold as a client-side load balancer but what does it mean ? It doesn't need an external server ? Ribbon is embedded in the client the same way an Eureka client is ? If so how does it work ? Do I need Zuul when I use Ribbon, and vice-versa ?
On some articles, I saw that in fact, Zuul uses Ribbon by default for the load balancing part and it got me even more confused. If this is true what does "client-side" mean ? What does Zuul do except routing ?
I hope you can help me.
Client and Server is always relative. Zuul is a client for your service instances and your service instances are servers for Zuul.
When we are using traditional load balancer (server-side load balancer), API caller (client) only knows a single endpoint that is a load balancer and the client doesn't know the list of servers. Load balancer chooses a server from the list.
When we are using client-side load balancer like Ribbon, API caller (client) should know the list of servers and choose one of them from the list. That's why we call it client-side load balancer.
As you know, Ribbon is a client-side load balancer module and is integrated to many http client modules. As an example, Feign and Load-balanced RestTemplate support Ribbon. Namely Feign and Load-balanced RestTemplate can choose a server from the given list or the list from eureka when used with ribbon.
Regarding Zuul, there is a RibbonRoutingFilter that routes your request to an actual service instance. RibbonRoutingFilter is using Ribbon to choose a server from the list that is given from your configuration or from Eureka. So if you want to use Zuul as a load-balanced reverse proxy, Zuul needs Ribbon.
Is it possible to implement REST client ( not browser but ruby client works on arduino device ) to access resource if resource is available via publish subscribe strategy ? (for example: http server(rails application) informed client that resource is now available you can receive/download)
I want to build application for "communication directly between ruby client in arduino board to http server". I don't want to use middle layer like Rabbitmq, zeromq. If it is possible what can be the possible steps to follow ?
It is not possible to use HTTP for pub/sub.
If you don't want to use message queue(anyMQ), try using plain TCP/UDP sockets.
XMPP is not the best choice, it gives too much overhead.
I'm currently hosting 2 webstites (clientportal and admin), in windows azure websites.
I'm going to introduce SignalR right now, to get rid of javascript polling. What I need, is when an admin send a broadcast message on the admin site, all the active client should be receive it. Now, the clien polls the webserver all the time, when an ajax poll receives, the webserver check for new messages in the database.
What would be the best way, to notify the client webserver from the admin webserver? WebApi is ok for this? Or are there any simple way?
From the point of view of Azure Websites and SignalR, it is transparent who is the Client and who is the Admin. This is an implementation detail, and thus, there are many ways to do it.
SignalR is split in two parts: The javascript library, and the .NET library that you use to create your "Hub". One way to accomplish what you are trying to do is to implement the Hub functionality in your Admin back-end using the .NET side of SignalR and ASP.NET Web API; and use the javascript side of SignalR to subscribe and listen for notifications on the Client side.
Another way to do it is to create a third component, just for the SignalR Hub, independent of both the Client and the Admin websites. In this scenario both the Admin and the Client would subscribe to the Hub, but only the Admin would push, and the Client would listen.
You can find many working examples on the internet. This is one of them: http://msdn.microsoft.com/en-us/magazine/hh965663.aspx
I hope this answers your questions.
I want to use Azure service bus in my iOS app to communicate with server i have went through the below link. its pointing to C#.Need suggestions to work on iOS.
http://azure.microsoft.com/en-us/documentation/articles/service-bus-dotnet-how-to-use-relay/#next_steps
You may want to consider using WebHttpRelayBinding for your service so you can hit the Azure endpoint using HTTP / HTTPS.
WCF supports both RESTfull and classic SOAP style messaging but using lightweight json requests in a RESTfull service would be better from a mobile app.
read the following article for details. but you don't need to write custom autostarter if you are using IIS 7.5 or greater with appfabric, since it has autostart functionality in built.
http://msdn.microsoft.com/en-us/library/hh966775.aspx
if you don't need request-response messaging pattern then you can also consider service bus queues for persistence, and your on-premise process can pull and process the messages at its own pace.
I'm designing an API to enable remote clients to execute PowerShell scripts against a remote server.
To execute the commands effectively, the application needs to create a unique runspace for the remote client (so it can initialise the runspace with an appropriate host and command set for that client). Every time the client makes a request, the API will need to ensure the request is executed within the correct runspace.
An (over-simplified) view of the flow might look like this:
Client connects to Web API, POSTs credentials for the backend application
Web API passes these credentials through to the backend app, which uses them to create a RunSpace uniquely configured for that client
Web API and app "agree" on a linked session-runspace ID
Web API either informs client of session-runspace ID or holds it in memory
Client makes request: e.g. "GET http://myapiserver/api/backup-status/"
Web API passes request through to backend app function
Backend app returns results: e.g. "JSON {this is the current status of backup for user/client x}"
Web API passes these results through to remote client
Either timeout or logout request ends 'session' and RunSpace is disposed
(In reality, the PowerShell App might just be a custom controller/model within the Web API, or it could be an IIS snap-in or similar - I'm open to design suggestions here...).
My concern is, in order to create a unique RunSpace for each remote client, I need to give that client a unique "session" ID so the API can pass requests through to the app correctly. This feels like I'm breaking the stateless rule.
In truth, the API is still stateless, just the back-end app is not, but it does need to create a session (RunSpace) for each client and then dispose of the RunSpace after a timeout/end-session request.
QUESTIONS
Should I hack into the Authentication mechanism in ASP.NET MVC to spin-up the RunSpace?
Should I admit defeat and just hack up a session variable?
Is there a better SOA that I should consider? (Web API feels very neat and tidy for this though - particularly if I want to have web, mobile and what-have-you clients)
This feels like I'm breaking the stateless rule.
Your application is stateful - no way around it. You have to maintain a process for each client and the process has to run on one box and client always connecting to the same box. So if you have a single server, no problem. If you have multiple, you have to use sticky session so client always comes back to the same server (load balancers could do that for you).
Should I hack into the Authentication mechanism in ASP.NET MVC to
spin-up the RunSpace?
If you need authentication.
Should I admit defeat and just hack up a session variable?
No variable, just use plain in-memory session. In case more than 1 server, use sticky session as explained above.
Is there a better SOA that I should consider? (Web API feels very neat
and tidy for this though - particularly if I want to have web, mobile
and what-have-you clients)
SOA does not come into this. You have a single service.