I may be wrong in my ideas but here the plan.
I have an app who has 2 services, with a client who consume these services.
Because I want them to be micro-services, I've planed to build an API Gateway to have only one access point and redirect requests.
I've found some docs for building this and I stumbled into Ocelot to do the job, it seems to fully answer my ideas.
But here the problem, if I want to run multiple instances of my services, I need a service discovery, that Ocelot can do with Consul, but it need in the service to register the service discovery provider in his configuration.
What I wanted to do is to discover services dynamically without configuring a service discovery provider in the services. Is it possible ?
Plus, if I want to run an another instance of the Gateway, the services will not register on this new instance.
Any hints or better solution ?
Related
I have an ASP.NET Core 3.1 application running on a docker container in kubernetes. It consists of two services which send data from the one to the other via Azure Service Bus.
Hot to check on the Service Bus a readiness probe?
I Was trying to find an API on https://learn.microsoft.com/en-us/dotnet/api/microsoft.servicebus?view=azure-dotnet and I did not found any fitting function.
Do you use it? Is it necessary?
There are some endpoints that can be used but are protected behind system/admin keys. But it seems that there is an issue already filed to expose endpoints for Kubernetes You can follow the thread for updates or you can also follow up on this thread.
I know that ASP.net web service supports only HTTP protocol and with WCF you have more options like TCP and Named pipes etc. Can you think of any scenarios in which one might have to consume a WCF service through an ASP.net Web API?
Following would be one of them use case where you want to call wcf service from web API.
If you already have a wcf service running and available which is doing some complex operations and you do not want it to be available directly to your consumers, you can create a web API and call the wcf service to perform the complex tasks and let the consumers to use the web API. In web API you can put extra logic of validation and authorization of the incoming requests.
Wcf being an older technology it would be better to write something new and eventually replace wcf rather than maintaining it.
Also If the current wcf is setup is not available via http protocol then not all the clients can communicate with it. Web API has that edge over wcf service.
How web API would connect to wcf service?
This depends on lot of factors such as network, deployment strategy, security etc.
But following would be one of the examples.
If the wcf service is available on tcp and web API and wcf are running on the same network, then web API can call wcf.
There may be a different answer to this question based on what exact problem you are trying to solve.
My answer is based on what information you have provided and the experience I gained by solving similar issue in real life.
We need to consume SAS webservice in C#. SAS team gave me 2 service names one for development (service_dev) and one for production(service) from the same SAS server. While consuming we need to point dev to dev service and prod to prod service C#.
I have created 2 proxy classes for both the services as the names are different. In the code I am checking if environment is dev, calling dev service and dependent code else prod service and dependent code. The dependent 100 lines code is both in If else condition. This looks ugly and I feel there should be a better way of doing it. Could someone suggest what is the best way to consume same web service hosted with different names?
You should use DI for that. Have the different implementations of your proxy classes in different assemblies and when in production deploy the one that connects to the prod system. This is typically done automatically, during the package step in a CI pipeline.
Is this service running the same code? If so (and you are talking about web services) than they should have the same WSDL and you should only have to reconfigure the URL of one service proxy. (same class)
The URL could then be configured via a config file
We have a Websphere Datapower (WDP) infrastructure providing a central endpoint for Soap based web services for logging and many other stuff.
Clients invoke web services using the WDP endpoint for all Web Services and WDP routes the requests to the matching web service based on Web services namespace.
The scenario of the problem is that we have multiple web services with exactly the same wsdl but with different namespaces so a determined client can notify a determined web service or web services depending on some different conditions.
The reason for this is, when new web services are added, we don't need to compile client code to bind the new web service.
I was thinking in manipulating the XML request namespace on client in order WDP know exactly the endpoint web service .
Also I don't want to have any logic on WDP because dependencies reasons.
Is there a better and elegant way of doing this in .net?
Regards
In the process of building my first AZURE based application using WCF services I have stumbled across a number of examples where people show how one can host a WCF Service inside a Worker Role.
Such as in these articles:
http://www.codeproject.com/Articles/188464/Host-WCF-Services-in-an-Azure-Worker-Role
http://code.msdn.microsoft.com/windowsazure/CSAzureWCFServices-20c7d9c5
Very simple question, can someone please explain what use case would require hosting a WCF service in a worker role? What are the motivation/advantages of doing this?
Hosting a WCF service inside of a WebRole implies that it is hosted within IIS. Some folks prefer to not have the footprint of IIS mess with their ServiceHost and host the service directly. They have more control over how the communication with their service is done without IIS in the middle.
Also, when shrink-wrapping the packaged solution for customers, it is simpler to create an installer package without trying to rely on IIS infrastructure that customers may or may not have properly deployed/configured.
HTH