I have a method with custom attribute in my service. I want to read the attributes of the calling method on the server side and check if it has that attribute. How can I accomplish this?
Thanks.
You cannot - the server side cannot go back to the client and read attribute in its code. After all - these could be on different machine, potentially even using different programming languages and system. How is a Java server going to read your .NET client attribute?
Check out figure showing the WCF archicture: on the left, you have the client, on the right, the server, and all that's holding the two together is the messages being exchanged. They have no other link.
What you could do is send along a custom header from the client to the server - then, your server - no matter what it is - can read that custom header in the message and act accordingly.
Messages are being passed between client and server - that's all the connection the two sides have. Anything in the message (and its headers) can be examined by the server - anything else cannot be checked.
Marc
I resolved this by simply implementing IParameterInspector instead. As the documentation states, parameter inspector works on operation level.
Related
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 have two different servers on which two similar WCF services are running. Both services are exactly same (clone). I have to consume both services in a single orchestration because I have to communicate them with each other. (I am using "Add generated Items" to add service reference). I want to get data from one service method named "Get" and send it to others "Send" method. After deploying project I get error that "Cannot locate document specification because multiple schemas matched the message type #####".
I have read a solution of creating custom pipeline with a specific document schema but that didn't worked.
How I can handle this situation?
If the services really are identical, then you don't need to use the wizard to import the schema twice - just import the first service's WSDL to create the schemas and port types, and then create a new send port* and change the bindings accordingly to point to the second service (i.e. notably the service URL).
This situation also typically happens if your WCF Services use MessageContracts which accepts or returns the same message payload for more than one service call (as opposed to DataContract, where you should get typically 'uniquified' root element names of the form xmlns#MyMethod and xmlns#MyMethodResponse).
In this case (i.e. common MessageContracts), in addition to basvo's answer, you can also get around this issue as follows:
Import all artifacts for all consumed WCF services into your BTS project in Visual Studio.
Retain the first 'instance' of each request (or response schema), and then in Orchestration view in VS, go through each of the second and subsequent port types and delete the duplicated request or response messages ("operation message") on the Port type. (Under each Port Type, you should see the request, the response and also any fault message types)
You then need to 'edit' each of the message types that you've deleted, and then manually go and change it to the original instance of the schema that you've retained.
You may also need to delete or worse, hack, the duplicated message types out of the imported .xsd files.
This is a pain however if your web service changes and you need to 'refresh' your imported schemas again - it would be a nice feature if the Import Wizard detected duplicate schemas and offered to merge them in this way for you.
*
Update - just to clarify, reuse the same logical send port in your orch design, but create a new Send Port in the deployed BTS server / cluster, subscribing the send port to the required messages / link the second Orch to the send port (depending on whether you are using Direct binding or not), and obviously change the binding to the second URL.
The problem is that you now have more than one schema in your BizTalk application which has the same namespace and root element.
You need to set the DocumentSpecNames property on both the XMLReceivePipeline of your "get service" and the XMLTransmitPipeline of your "send service" to tell BizTalk which one to use.
The basic format of this value is ... Schemaname+Rootname,Assembly
Example:
Company.Schemas.Messages+GetReply,Company.Schemas,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
As these services are same so just adding service reference for any one of these will add the required schemas.Just create separate send ports for each service in BizTalk MMC and to connect the logical port created in orchestration to correct send port while configuring the orchestration.
This solution Worked.....
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.
We are using an authentication string (guid) for client identification in our wcf services
and for database lookups.
We dont want to add this to every messagecontract.
Is there a way to do this in wcf?
Regards,
Rune
The best and typical way is to add this to a header in your WCF message - and that would be perfect in a message contract.
Why do you not want to add it to the message contract??
WCF typically encourages a "per-call" methodology - you send all necessary info with your call, each and every call that is. It is discouraged to have any kind of "state" that lingers around between calls.
So again: why not just include your authentication string as a header in every message? That's the preferred way of doing things these days.
UPDATE:
Check out Nicholas Allen's blog post on Adding Headers to a Call. Besides adding them to the message contract, you could also check out the Message Inspector sample he links to, which creates a message inspector that automagically adds those header entries to each outgoing call. No code clutter, no mess, nothing - just works.
I've got some WCF services (hosted in IIS 6) which use the Enterprise Library (4.0) Validation Application Block. If a client submits a message which fails validation (i.e. gets thrown back in a ValidationFault exception), I'd quite like to be able to log the message XML somewhere (using code, no IIS logs). All the validation happens before the service implementation code kicks in.
I'm sure it's possible to set up some class to get run before the service implementation (presumably this is how the Validation Application Block works), but I can't remember how, or work out exactly what to search for.
Is it possible to create a class and associated configuration that will give me access to either the whole SOAP request message, or at least the message body?
Take a look at using the Policy Injection Application Block...
I'm currently developing an application in which I intercept (using PIAB) all requests incoming to the server and based on the type of request I apply different validation behavior using the VAB.
Here's an article about integrating PIAB with WCF:
http://msdn.microsoft.com/en-us/magazine/cc136759.aspx
You can create different inteception mechanisms such as attributes applied to exposed operations.
You could log the whole WCF Message:
http://msdn.microsoft.com/en-us/library/ms730064.aspx
Or you could combine it with Enterprise Library Logging Application Block.
I found a blog post which seems to do what I want - you create a class that implements IDispatchMessageInspector. In the AfterReceiveRequest method, you have access to the whole incoming message, so can log away. This occurs after authentication, so you also have access to the user name - handy for logging. You can create supporting classes that let you assign this behaviour to services via attributes and/or configuration.
IDispatchMessageInspector also gives you a BeforeSendReply method, so you could log (or alter) your response message.
Now when customers attempt to literally hand-craft SOAP request messages (not even using some kind of DOM object) to our services, we have easy-to-access proof that they are sending rubbish!