I have a WCF service, DummyService. It implements IDummyService and lives on two URIs, http://1.1.1.1/DummyService and http://2.2.2.2/DummyService. I would like to create a routing endpoint such that;
I can hit http://1.1.1.1/RoutingService/DummyService?wsdl and/or http://1.1.1.1/RoutingService/DummyService
This uri appears to just be the dummyservice endpoint, i can build a client proxy, etc.
Any calls get round-robined around
Is there some way to do this without having IRoutingService re-implement DummyService? I want dummyservice to essentially be a plug-in that I can add/remove at runtime.. Can I do this with WCF Routing? Any samples I can reference? I havent been able to find anything on MSDN/Google, but perhaps im asking the wrong way..
This is pretty much exactly what WCF Routing is for.
There is a sample which is part of the WCF/WF samples (info here):
http://msdn.microsoft.com/en-us/library/ee667249%28v=VS.100%29.aspx
Related
We are trying to build a Nservicebus service that can communicated with form and wpf based clients using WCF. I have read that you can inherit from WcfService.
like:
public class ThirdPartyWebSvc : WcfService<ThirdPartyCmd, ThirdPartyCmdResponse>
And then you simple create a endpoint in the app.config and you done like described here. but the problem is that i have to create a endpoint for every command.
I would like to have a single endpoint that excepts any command and returns its response.
public class ThirdPartyWebSvc : WcfService<ICommand, IMessage>
Can someone point me in the right direction? Using Nservicebus for client communication can't be done for us and i don't want to build a proxy like server unless thats the only way to do it.
Thanks
So from what I can gather, you want to expose a WCF service operation which consumers can call to polymorphically pass one of a number of possible commands to, and then have the service route that command to the correct NServiceBus endpoint which then handles the command.
Firstly, in order to achieve this you should forget about using the NserviceBus.WcfService base class, because to use this you must closely follow the guidance in the article you linked in your post.
Instead, you could:
design your service operation contract to accept polymorphic requests by using the ServiceKnownType attribute on your operation definition, adding all possible command types,
host the service using a regular System.ServiceModel.ServiceHost(), and then configure an NserviceBus.IBus in the startup of your hosted WCF service, and
define your UnicastBusConfig config section in your service config file by adding all the command types along with the recipient queue addresses
However, you now have the following drawbacks:
Because of the requirement to be able to pass in implementations of ICommand into the service, you will need to recompile your operation contract each time you need to add a new command type.
You will need to manage a large quantity of routing information in the config file, and if any of the recipient endpoints change, you will need to change your service config.
If your service has availability problems then no more messages to any of your NSB endpoints.
You will need to write code to handle what to do if you do not receive a response message from the NSB endpoints in a timely manner, and this logic may depend on the type of command sent.
I hope you are beginning to see how centralizing this functionality is not a great idea.
All the above problems would go away if you could get your clients to send commands to the bus in the standard way, but without msmq how can you do that?
Well, for a start you could look at using one of the other supported transports.
If none of these work for you and you have to use WCF hosted services, then you must follow the guidance in the linked article. This guidance is there to steer you in the correct direction - multiple WCF services sounds like a pain, until you try to centralize them into a single service - then the pain gets bigger, not less.
OK, I've searched the Internet for the answer to this and haven't found anything... maybe I'm missing the obvious here or just asking the wrong question, but...
How do you call a WF WCF Workflow just by it's URL with parameters? I have a Workflow xmlx, we'll call it DeepThought.xamlx, an operation named TheQuestion and I need to pass the parameter Answer = 42 to it.
I've tried http://localhost:8042/DeepThought.xamlx/TheQuestion?Answer=42 and just about everything else I can think of. I've scoured the Internet and even the wsdl but am either just flat out missing the answer or simply not seeing it.
I assume it's possible, otherwise, what's the point? Clues appreciated.
At least out-of-the-box this is not possible. The standard Receive
activity uses SOAP. I'm sure it's possible to implement a custom Receive but I guess it would be a non-trivial amount of work.
You can also take a look a the following questions. They are REST-related but still may give you some options (a community RESTful endpoint is being mentioned, no idea of its current state though):
RESTful Workflow Service Endpoints in WF4 / WCF
WCF Workflow Service REST interface
I ended up implementing the workflow as a regular activity (non service) inside WCF. This gave me the ability to use their parameters and pass them to the workflow directly. In the end, not too difficult to implement.
I have a simple scenario where i want to output only json to the user.Now should i use a simple httphandler, call it from jquery and get the json or create a WCf service?
I want to use WCf service but don't see any advantage, maybe someone can point few of them and scenarios.
Anything would be suffice. Your thoughts are in correct direction, why to create a wcf service and increase the overload(maintaince, deployment etc).
If you are using Ajax, Look in to PageMethods, which would even free you from creating a separate HTTPHandler and you could call your code behind methods directly in your javascript.
I am assuming you are using asp.net.
I have a WCF Service that exposes two endpoints. One with a WebHttpBinding (acting as a REST service for mobile clients) and one with a NetTcpBinding (used for desktop .NET clients)
Let's say that a client accesses the service method GetData. If there is no data I will return ´null´ (or false or ´0´ depending on what has been called). If the client is a mobile client accessing the WebHttpBinding-endpoint, I would like to change the HttpStatusCode to something other than OK.
Is there a way of doing this and still keeping my service implementation general (not putting any http-specific code there)? I know that I can use IDispatchMessageInspector to intercept the message and change the status code, and only do this for the WebHttpBinding-endpoint, but then I wouldn't really know what to change the status code to...
Is there anyone who has a suggestion as to how I can solve this?
Update:
I'm starting to think that there really is no way to do this in a nice way, since the only place I actually really know what when wrong is in the service implementation.
Edit: the nice way: Seperation of concerns (SoC). The REST implementation only adds REST concerns to the service and inherits the base implementation which does the whole business logic.
Was planning to use Service Routing (on WCF/REST) to do some common tasks before a request hits the actual service. Now that I read more about it, looks like REST is not supported yet on RoutingService and the suggested method is to use System.Web.Routing or ARR.
What needs to happen in the router is a key validation, a header value extraction and versioning.
ARR doesn't look right for this as it just routes and there is no "handler" we have access to. System.Web.Routing looks like a lot of custom implementation which might undermine the efficiency of WCF.
An old school alternative am thinking of is to have the common functionalities in one chain-of-responsibilities implementation and just compose it in every service. This has the disadvantage of being referenced in N number of places for N services. But this increasingly looks like the only alternative if I don't want to mess with the WCF handling of endpoints.
Am looking for advice on a right way to do this, and any samples.
Didn't try, but maybe writing a custom service behavior can solve your problem. Take a look here : Extending WCF with Custom Behaviors.
The idea is to extend the WCF engine with a custom behavior, then attaching your service with this behaviors. This is transparent for the services.
Take a look at HttpMessageHandlers in the new WCF Web Api project htttp://wcf.codeplex.com This mechanisms allows you to do something similar to Rack or WSGI. I have a couple of examples of what you can do with them on my blog http://www.bizcoder.com/index.php/2011/05/22/how-to-get-ahead-with-messagehandlers/