I would like to set the MSMQ message label using the NetMsmqBinding. I understand it’s easy when using the MsmqIntegrationBinding, but I would like to continue to use the NetMsmqBinding (even call private methods, if possible)
I thought this was an interesting question. Unfortunately, from everything I've seen, it looks like you can't access the Label property on an outgoing MSMQ message using NetMsmqBinding.
Here are some of the links I came across:
http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/3389679b-a130-4e83-bb4c-1b522c216227/
http://blogs.msdn.com/skaufman/archive/2007/12/17/msmq-label-property-and-wcf.aspx
I couldn't find anything that explained exactly why, but the reasoning makes sense - the NetMsmqBinding does not expose anything specific to System.Messaging, so that the binding itself can be easily swapped out for another binding without any code changes. Like you said, the MsmqIntegrationBinding is tightly coupled to System.Messaging concepts, so you get access to all the System.Messaging stuff at the expense of interchangability with other bindings. If setting the Label is important, the easiest route will probably be to just use msmqIntegrationBinding.
George: No answer, but I'm curious to know how you plan to use the MSMQ label together with NetMsmqBinding.
The reason I ask is that NetMsmqBinding was really created to support the scenario in which both the sending and receiving endpoints are both WCF applications, so at that point you might as well just stick any out-of-band data you need in the message headers...
Use OperationContext.Current.IncomingMessageProperties.Values
Related
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.
We are migrating set of WSE services to WCF platform.
The new WCF services are called over secured HTTP. (https)
I want to invoke an operation contract of one WCF service from another. Both the services are mostly hosted in the same IIS, but they can be on separate IIS server.
Do I need to take care of some things (which i obviously do not know at present) in this scenario?
Is there any special calling mechanism in this case?
Does calling mechanism change when call is synchronous and when it is asynchronous?
Can you suggest some type of binding which is readily available in this case?
1.) If the services are on the same box, use named pipes, unless you have any compelling reason not to, to communicate with each other. While WCF proper doesn't care about what you're doing as long as the address, binding and contract all match up (see what I did there?), .NET will when it comes to making network connections. The fewer you use, the better. (see http://msdn.microsoft.com/en-us/library/fb6y0fyc.aspx for more details)
2.) As stated in #1, if they're talking on the same box, use named pipes unless there's a good reason not to.
3.) Can you provide a little more detail on what you mean by this or what you're planning on doing? A lot of this is built out for you, so assuming you're familiar with implementing async methods and using async callbacks, the short answer is yes, it's different than calling an operation synchronously, but that's to be expected. Or do you mean IsOneWay = true? If that's the case, the calling mechanism is the same but there can be a number of other gotchas (e.g. faults)
4.) Named Pipes on the same box, BasicHttp otherwise (unless you need any of the additional features from WS).
but they can be on separate IIS server
In this case, you either can't use Windows authentication (if you were using it) or you have to set up some special delegates stuff on the domain to make it work. Windows Authentication won't "hop" between different servers. Here's some info on that, there's a lot of reading out there on the subject.
If they stay on the same server or you're not using Windows authentication, then it shouldn't be a problem.
Does calling mechanism change when call is synchronous and when it is
asynchronous?
Shouldn't matter, it's all the same on the service end. I will say that if the client calls X and X calls Y, X might as well call Y synchronously because it can't return to the client until Y is done anyway. (If X calls Y and Z, then X making async calls may make more sense.)
Can you suggest some type of binding which is readily available in
this case?
If you were using WSE before, then BasicHttpBinding is going to be the one closest to what you were doing and will look pretty familiar in what it outputs. It's also the simplest one to work with.
There shouldn't be anything special needed just because a WCF service method calls another WCF service. A WCF service doesn't "care" what other application types are calling its methods so long as they use the correct service contract, data contract, endpoint, and binding settings.
Just make sure that both service methods return promptly, and don't cause execution to block for long periods of time.
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/
Is it possible to create a "generic" as in "adaptable" routing service, which will NOT have any public methods to call. Instead, you'd be able to call any command, which would then be mapped in the service and will pass it to appropriate end point with simple message transformation where required.
It may be hard to understand and idea might seem a bit crazy (it came from a colleague of mine), but it's clearer if you look at the example:
similar to what's described in this article, only difference is that our service should not have a "SubmitTimeSheet" public method, in fact it should have no public methods to call. We'd have to "intercept" an incoming call on a much lower level before it returns "Method Not Found" error.
Is this at all possible? The reason for this is obvious: possibility of adding new clients without having to change the code. All we'd have to do is to add a new mapping entry in some sort of config file or even database, e.g.
<Client address="newClientAddress" method="DoAnything" transformation="NewClientDoAnything.xslt" endPoint="endPointClientAddress" endPointMethod="endPointClientDoAnything" />
Check out WCF 4 routing - supports content based routing, xpath transforms and much more.
http://blogs.msdn.com/b/routingrules/
They have already done it in Nirvana. But it is very expensive.
This is not possible in WCF unless you define your contract as a very loose, fit-for-all contract which takes a message and returns a message. By doing this, you will los all the goodness (although not huge goodness in WCF) of WCF.