There are a bunch of questions regarding global error handlers and such but none of those address what I need.
Is there any way to add a behavior that will attach to every endpoint or service through .config?
*Specifically what I want to do is add a logger that will capture and log every SOAP request/response. But I would prefer that behavior to be automatically added to every service I have instead of having to manually add it to each.
I looked into behavior extensions and thought that would be the solution but no, you have to add the behavior to every service.*
You may be able to use the <commonBehaviors> section of your machine.config file to define a behavior which would be applied to all services in your machine. Notice that updating the machine.config is really like using a bazooka to solve your problem (and in many scenarios the group policy may forbid you from doing that), so it may not work for all scenarios. You'll also need to make sure that the behavior extension is registered (also in machine.config), and that whatever application you're using with WCF has access to the assembly referenced in the extension (possibly via GAC).
Another alternative would be to use a common library for creating the service hosts (either directly for self-hosted services or via a service host factory for webhosted services), and use that library (which would in turn add the inspector).
Its always good to have a message inspector to get rid of this kind of problem. Message Inspector is an implementation of WCF extension which works nicely to track every incoming request(s) and outgoing response(s) for your service, even if its fails in Message Validation it has an option to trap and work accordingly. More precisely the message inspector can configure using configuration files without making changes in your existing service.
More details about your Message inspector and its implementation can be found Here
Hope this helps !!
Happy Coding :)
I created a Workflow Foundation workflow which will eventually invoke another Workflow Service. I added the call to this service by dragging the appropriate shape from the toolbox onto the designer. The shape was available because I added the Workflow Service as a service reference as recommended.
How can I specify a specific endpoint address for this web service? I can't find a way to programmatically specify the address.
The workflow always uses the address specified in the web.config. But based on certain conditions I want to use different addresses.
Edit
Here is a picture I created to illustrate the problem:
Look for the place where you make a call to the Workflow Service. Somewhere there you define a client. It should look something like this:
client.InvokeService(); // or whatever method you call;
If you want to change address you should change endpoint address before this call, ideally when you define the client:
client.ChannelFactory.Endpoint.Address = new EndpointAddress("http://something.com/service.wsdl");
But keep in mind that this is not recommended practice. If you intend to change it programmatically it's better to get rid of services section in your web.config completely and set properties programmatically when creating client.
What's the use of action/reply action for service operation in WCF. So far, what I've understood is; action is used by WSDL to identify the service operation to which the message from the client belongs and in return reply action is used by service operation to identify the caller to which reply message belong --> Please correct me if I am wrong with this!
Now, I want to understand; what's the real use (apart from handling anonymous messages by using aster ix [*]), I mean this could well be handled internally by WCF instead of exposing it to the developer.
Also, why is action and replyaction required at all? I mean, we already have a name property for the service operation to identify the method and when I call Proxy.SomeMethod() then somemethod is already mapped to the Name property and it should be enough to identify the destination method for the message and similarly the replyaction. Please clarify.
Can I please get a simple real world scenario/or link to that to understand Action/ReplyAction in real life.
Many Thanks.
Actions are part of the various SOAP and WS-* specifcations.
So the first point is that this is not something unique to WCF it is a standard part of the specification you need to support if you want to have interoperable web services. They are used for message routing and other message handling functions.
Second, WCF DOES manage these by default. You only need to specify them yourself if you wish to customise or manage them in some other way. E.g. WCF will automatically generate them into the WSDL for you. WCF will also use them by default when it is selecting which operation to invoke for an incoming message. Again, WCF provides extension points to customise this behavior if you require.
I am looking to extend existing services and add Authorization to every call being made. The problem I have is that I don't know how to do this in the best possible manner. What I need to do is to send the name of the module calling the WCF service. I already send the username and password for the service and now I need to extend that with the name of the module calling the service. This is because we might allow a user to open a module and display data from another module but not from a third.
If we would have used message contracts I would just add a MessageHeader for this and set that header when I create the request. That is unfortunately not an option with DataContracts so I was considering the following two alternatives.
Adding a DataMember in a base class with Order=1000 or something like that. I don't know what will happen if we add another DataMember before that though?
Create the property for the module name and set a header in the transport instead. Not really fond of this one though. It's pretty abstract and hard to follow.
Which one is the least evil or do you have a better suggestion?
EDIT 1: The problem is not how to send a header to the service the problem is how to send a header with a specific value to the server. In the message inspector I can only create generic instances with message.GetBody<DataContract>(); this means I have to know the type which I don't know how to.
EDIT 2: The issue here is that in our application we want to restrict access to a call based on from where the call is made so I need to pass this information. Let's say I make the call to MyService from FindUserModule then I need to add the id of that module in a header so that the AuthorizationManager can check if that user really should be authorized. This is due to service calls being used from many modules.
Handle this as SOAP header in custom message inspector.
In Understanding WCF Services in Silverlight 2, the author, David Betz, explains how to call a web service without adding a service reference in the client application. I have a couple of weeks experience with WCF, so the article was over my head. In particular, although the author gave a lot of code snippets, but does not say what goes where. In the article, he provides two different code snippets for the web.config file, but does not clarify what's going on.
Looking at the source code there are four projects and two web.config files.
So far, I have been using the standard Silverlight project configuration of one project for the web service and one for the Silverlight client.
Firstly, does the procedure described in the article work with the standard two project configuration? I would think it would.
Secondly, does anyone know of a simpler example? I am very interested in this, but would like to either see source code in the default two project setup which is generated when a new Silverlight project is made, or find a step by step description of how to do this (eg, add a class called xxx.cs and add this code..., open web.config and add these lines...)
Many thanks
Mike Thomas
First, a little philosophy...
If you are a consumer of a WCF service that you did not write, adding a service reference to your client is really the only mechanism you have to enable interaction with that WCF service. Otherwise, you have no way of knowing what the service contract looks like, much less its data and message contracts.
However, if you are in control of both the client and the WCF service itself, adding a service reference to the client is a nice convenience, but I've recently been convinced not to use it. For one, it becomes a nuisance after the first few times you change your contract to remember to update your service reference. And in my case, I have several different C# projects that are consuming the WCF service, so I have to remember to update each one of them. Second, creating a service reference duplicates the contract definitions that are already defined in your WCF service. It is important to understand the implications of this.
Let's say your WCF defines the following type.
[DataContract]
public class Person
{
[DataMember] public string FirstName {get; set;}
[DataMember] public string LastName {get; set;}
}
When you add a service reference to your client, the metadata associated with this class is retrieved through the metadata exchange (MEX) endpoint, and an exact replica of this class is created on the client side that your client "compiles" against. So your WCF service has a definition of the Person class, and so does your client, but they are two different, distinct class definitions.
Given this, it would make more sense to abstract the Person class into a separate assembly that is then shared between the WCF service and the client. The added benefit is that when you change the contract definitions within this shared assembly, you no longer have to update the service reference within the client because it is already referencing the shared assembly. Does that make sense?
Now to your question. Personally, I've only used WCF within C# projects, not Silverlight. However, I do not think things are radically different. Given that, I would suggest that you watch the Extreme WCF video at dnrTV. It gives a step-by-step guide for how to bypass the service reference feature.
Hope this helps.
Let me try - I'm not an expert at Silverlight development, so bear with me if I say something that doesn't apply to Silverlight :-)
As Matt Davis mentioned, the "usual" use case is this: you add a service reference to a given service URL. In doing so, Visual Studio (or the command-line tool svcutil.exe) will interrogate the service and grab its metadata - information that describes the service, all the available methods to call, what parameter they expect etc. From this, it will generate a class for you (usually called the "client" or "client proxy"), which you as a client (=service consumer) will use to call the service. You can have this client proxy class generated inside your "normal" Silverlight client project, or you could possibly create your own "service adapter" class library, esp. if you will be sharing that client proxy code amongst several Silverlight projects. How things are structured on the server side of things is totally irrelevant at this point.
As Matt D. also mentioned, if you do it this way, you're getting copies of the service, its methods, and its data, in your client - those are identical in structure to what the server has - but they're not the same type - you on the client side have one type, the server has another (the fields and properties are identical though).
This is important to remember since the whole basic idea of WCF is message-passing - all that connects the client (you) and the server (the other end) are the messages and their structure - what method to call and what values to pass into that method. There's no other link - there's no way a server can "connect" to the client code and check something or whatever. All that gets exchanged is serialized messages (in text or binary form).
If you do control both ends, you can simplify things a bit - you can physically share the service contract (the definition what the service looks like and what methods it has to call into) and the data contract (the description of what data is being passed back and forth) on both the server side as well as the client side. In this case, you won't be adding a service reference, you won't be duplicating the service and data definitions, so things are a bit easier (but it only works if you're in control of both ends).
In this case, best practice would be to package up all that describes the service (the service interface with its methods and the data contracts) into a separate assembly (class library) on the server, which you can then copy to the client side, and reference directly from there (like any old assembly you might have). So in this case, you would typically have at least three projects in your solution:
your actual Silverlight client project
the website or web app hosting your Silverlight control for testing
the service interface assembly, which contains the service and data contracts
So there you have it - I hope I covered all the basics of what's going on, and why you would want to do one or the other thing. If you need additional info, don't hesitate to comment on this posting and let us know!
Marc