This project is read-only.


Topics: Technical Questions
Jun 11, 2009 at 8:46 PM


I´m traing to make a Parameter Inspector with a class that implements  IOperationBehavior,IParameterInspector, the problem is that ServiceModelExtensionElement apply only for service or endpoint behaviors and not for Operation Behavior, so how can I create a Policy that use my custom behavior?.

This policy must apply at Operation level only. I could not find any Operation level Policy example.



Nicolas Sampietro


Jun 17, 2009 at 5:00 PM

Nicolas,  I'd be interested to know more about what you are trying to accomplish.  The MSE handles operations a little different than you may expect partly because of our need to be more dynamic and flexible about what messages an endpoint can receive.  In WCF terms, all messages sent to an MSE endpoint are routed to the UnhandledDispatchOperation operation.  What this means is when you try to implement an IParameterInspector, your IOperationBehavior probably calls dispatchOperation.ParameterInspectors.Add() from  the ApplyDispatchOperation() method.  This method is called for each declared operation in the service contract.  Unfortunately the dispatchOperation you are hooking up to is never used... in ApplyDispatchOperation you could hook into the UnhandledDispatchOperation by instead calling dispatchOperation.Parent.UnhandledDispatchOperation.ParameterInspectors.Add()...(just be sure to only hook up once)

The trouble with this is that when your parameter inspector is invoked, the operationName provided to you in BeforeCall() is "*", though the first element in the inputs array is the full message.  So depending on what you are trying to accomplish, there may be a better approach than using an operation behavior.

As for the policy declaration, as long as you extend the BehaviorExtensionElement class, you can use it in a policy assertion.

In general, if you want a policy to apply at the operation level only, you have a couple options, apply a policy on the OperationVersion or Resource... policies applied here act on the WCF Client channel the MSE creates to invoke the resource.  If you apply a policy on an MSE Endpoint you'd have to manually implement some filtering logic in your assertion to only act on specific messages which we discourage.



Jun 18, 2009 at 6:27 PM

Hey botto, thanks for the response.

a few things :  my class implement IOperationBehavior and use the ApplyClientBehavior method to add the parameter Inspector to the parent UnhandledClientOperation colection of  inspectors. here is the method code:

public void ApplyClientBehavior(OperationDescription operationDescription, ClientOperation clientOperation)

also for some reason my ApplyDispatchBehavior methos is never lunch, ( i know because I put a breake point  in both opeartions and only ApplyClientBehavior is hit). Any idea why ?. You mention a ApplyDispatchOperation() method, but I could not find it, did you mean ApplyDispatchBehavior?.

Although, the ApplyClientBehavior method´s code is executed so the ParameterInspector is added to the collection, the AfterCall or BeforeCall methods are not achieved.

What we are trying to accomplish?,  we what a Policy that enables/disables , parameter logging/inspection at  operation level.  We could do that at endpoint lever , but we need this kind of granularity because the amount of data that could be generated.

Last question :Why did you discourage the filtering login solution in a endpoint policy? it´s because the overhead ?.








Jun 18, 2009 at 7:00 PM

Whena applying behaviors with WCF you must decide if the behavior applies to a WCF client proy that calls a service, or to the service side.  ApplyClientBehavior is used to attach a behavior to the WCF client proxy whereas the ApplyDispatchBehavior (sorry this is the one I ment to reference, not ApplyDispatchOperation) hooks up a behavior on the service side.  Since the MSE is an intermediary you have the option of applying your behaviors to the MSE endpoint (service side) or to the proxy the MSE creates to invoke a service implementation (client proxy).

Depending on where you apply your policy, only one of those two cases will apply.  Since your ApplyClientBehavior() method is being invoked, it sounds like your policy is attached to an OperationVersion, Resource, or SystemInstance in the admin tool since policies applied to these items are attached to the client proxy the MSE creates.  If it is attached properly, there shouldn't be a problem with BeforeCall and AfterCall being invoked.  I've successfully performed this.

An alternative to using a IParameterInspector would be to use an IClientMessageInspector applied via IEndpointBehavior and applied via policy on an OperationVersion, Resource, or SystemInstance.

The concern I was referring to about an endpoint policy is based on the fact that Endpoints don't typically concern themselves with individual operations.  With the MSE, the Broker resolves an incomming message to a specific operation version.  Only then can you effectively have policies apply based on a rationalized message.  If you have a policy that you want applied to only a few operations hosted at an endpoint, you end up hard coding something in your policy to perform the filtering (i.e. you may rely on SoapAction, a specific body element, or something else to identify whether you wanted your policy to apply to that specific message).  Rather than doing this hard coding, it would be better to just apply a policy to the specific OperationVersion or Resource.  This allows for consistent application of policy regardless of how to choose to expose the capability in an endpoint... i.e. if you had an AddIntegers operation exposed in both a basicHttp, wsHttp, and pox endpoints how would you create an endpoint policy that reliably performed it's logic on only the AddIntegers operation at each endpoint?  Add in versioning and it gets even more ugly.




Jun 23, 2009 at 3:12 PM


Finaly the alternative approach works just great. I mean using  IClientMessageInspector applied via IEndpointBehavior.


Thanks you very much!.