We have a set of WCF services that use to MSMQ. We use the static web.config file to indicate to the services where the MSMQ host is.
Moving to AWS, we now need to dynamically specify the MSMQ host address. We figure we can pick between 2 options:
1) Write a script to update the web.config files when spinning up the AWS instances.
2) Drop the config files and implement a helper function that will resolve the MSMQ host address at runtime.
Anyone has any insight on what approach would be better or be considered best practice?
Thanks!
We ended up using solution #1.
This was a trivial script to write and now we can use environment variables anywhere in our web.config files (not just to set the MSMQ endpoints).
Keeping the MSMQ config in the web.config files also allows us to change queue technology if/when needed by using other bindings (ex: RabbitMQ) with no changes to the source code.
Related
I want to set up a bunch of rabbitMQ exchanges and queues together with their bindings trough a Octopus deploy step. We're using NServiceBus and we don't want to give the application too much permission hence it can't set up the stuff itself.
Previously we've had a powershell script for setting up virtual host and users and I've been looking at extending this so that we can create the queues, exchanges and bindings too. This script uses RabbitMQ REST API.
The queues and exchanges can be created without any hazzle but the bindings are another matter. I can't find any suitable documentation about setting this up over HTTP. I've read something that this is not the preferred way to do stuff but what options are available to me given octopus scripting?
The code I want to execute is something like this:
http://localhost:15672/api/bindings/TestHost/e/nsb.delay-level-00/q/nsb.delay-level-00
The exchange is named nsb.delay-level-00 and the queue has the same name. Both exists in the rabbitMQ virtual host.
Any ideas?
I found out that, in contrast to creating queues and exchanges, the method call has to be a POST in this scenario.
So, POST http://localhost:15672/api/bindings/TestHost/e/nsb.delay-level-00/q/nsb.delay-level-00 works fine.
I'm new to WCF, so I opened up 2 projects: WCF class library and a host console application.
Now, both projects have app.config to store the WCF service configuration settings.
As it seems to me now, and correct me if I'm wrong, I have redundancy in configuring both projects with WCF settings.
How is it done in real world production software ? Does it use separate *.dll library for WCF services, or is it implemented withing the host project (and by that use a single place configuration of it) ?
Thank you .
EliorCohen's answer is correct, but I wanted to expand on a couple of points.
First, your building a WCF class library - library's don't use configuration files on their own. They use the configuration file of the calling application. This is something that I've seen cause a lot of confusion for developers, especially if they create a new class library and they see an App.config file in the project.
Second, with WCF 4 you can actually host a service without specifying anything in the configuration file. The runtime will add default endpoints based on the URI's supplied when you construct the service host.
You can also use set up default bindings and behaviors that will override the normal defaults - for example, if all of your services would be handling large requests, you might want to define a default binding with larger values (by ommitting the name attribute in the Binding configuration).
WCF is wonderful in that it has a lot of options - but that blessing is also a curse at times, especially when you first start working with it.
For more information on default endpoints and stuff, see A Developer's Introduction to Windows Communication Foundation 4.
Note that you'll still need a configuration file for any client apps.
the wcf project you are building represent an implementation of the service.
the configuration need to be on the host of the service (your host app).
I would like to create a service whose job is to monitor other services that are running within the same process, and then report basic information like health or service dependencies. I'm having trouble figuring out the best way for my monitoring service to access detailed information about the other services without having to have each service publish its metadata or expose some custom endpoint the monitoring service can communicate with. If I load the configuration and read through it I can get most of the way there but this approach has a few weaknesses:
Getting the absolute URI for each endpoint can be difficult,
especially when using IIS hosting or fileless activation.
Any configuration that was done programmatically would not be able to be read by the monitoring service
What I'd like to be able to do is to somehow access the ServiceDescription to get all the information I need about each ServiceHost, without requiring any work on the part of the service designer to give it to me. Is something like this possible?
If you've checked Channs links and are convinced you need to roll your own health monitoring infrastructure, you'll probably need to either derive from ServiceHost or go all out and derive from ServiceHostFactoryBase or possibly do both depending on what you need to implement. They'll give you access to the ServiceDescription instance for each service as it is spun up.
One alternative would be to use WCF's built-in health monitoring and performance monitoring capabilities. This works at the individual service level though.
I would like a recommendation/idea on a method to configure properties for a running Mule service dynamically, i.e. I want the service to pick up the new settings without the need to restart Mule. Typically the kind of properties/settings I would like to change are FTP connector user ID, passwords, service URLs etc.
Any idea would be welcome.
Regards, Ola
Use the URI endpoint format do dynamically address endpoints. In simple cases you may be able to use the message properties in a TemplateEndpointRouter
Otherwise You need to write a component that composes the URI and sends the message to the dynamic endpoint using the MuleEventContext or MuleClient.
See here:
http://www.mulesoft.org/documentation/display/MULE2USER/Outbound+Routers#OutboundRouters-TemplateEndpointRouter
http://www.mulesoft.org/documentation/display/MULE2USER/Using+the+Mule+Client#UsingtheMuleClient-PerforminganEventRequestCall
http://www.mulesoft.org/documentation/display/MULE2USER/Mule+Endpoint+URIs
Mule exposes all service configuration via JMX, but I don't see any obvious way to reconfigure the connectors without a restart. They are internally managing pools of connections.
If there is a limited, you can create connectors for each and reconfigure the routes via jmx attributes.
If it is to be fully dynamic you likely need to implement your own service component to manage the ftp connection. Exposing the connection management, configuration, and restarting via JMX should be pretty straight forward.
In Learning WCF, by Michele Bustamante, there is a section that describes a binding called the NetNamedPipes binding. The book says that this binding can only be used for WCF services that will be called exclusively from the same machine.
Under what circumstances would it make sense to use this? Ordinarily, I would write asynchronous code without using WCF... Why would Microsoft provide something for WCF that can only run on the same machine?
Look at it from the other direction. Once the service is built, you can run in in a variety of binding configurations. If it was a remote machine, you could use the HTTP or TCP bindings. Or, the service happened to be running on the same box, you have those options plus the named pipes option. The named pipes is just another option that is provided just in case you are running locally, but you should be able to switch to a different binding if you are running remote.
Yu could start with everything on the same box because you have less traffic, and use named pipes because it was the shortest path to the service. Then, if load demanded it, you can move the service to another box, and then change it to use TCP or HTTP instead.
You probably won't have a service that exposes only a NetNamedPipe endpoint - that doesn't make a lot of sense. But if you run your WCF service on a server, exposing service endpoints out to the world using the usual bindings, and you need e.g. a management or admin console or something like that, running on that same machine, it can make sense to use the NetNamedPipe binding since it's the fastest around.
Another possible scenario that I learned about is having an error collection service - any error or exception that happens is sent to a service to be logged. Again: that service would probably expose several types of endpoints, but if you have other services running on the same server, using NetNamedPipe binding to connect these two services makes a lot of sense.
I don't think you'll use the NetNamedPipe binding an awful lot in your WCF days - but it can definitely make sense in some cases and be quite useful in such specialized scenarios.