I need to create a service that will be "called back" by a third party. As a result, I need to conform to their WSDL.
Their WSDL has all of the operations defined with soapAction="", so my service needs to do the same. Unfortunately, I'm getting the error:
The operations A and
B have
the same action (). Every operation
must have a unique action value.
In ASMX web services, there was a mode where the soapAction would not be used, but the name of the request element would be used instead. Is there some way using WCF not only to dispatch on the request element, but also to emit a WSDL with no soapAction?
This is possible in asmx, but out of the box you will find no clean way to do this in WCF because it uses the action to dispatch messages to operations.
I think the hack you need is to set your soapAction to "*", and then write a custom dispatcher.
A potential side effect of this is a bad WSDL, if you need to expose a WSDL you will have to generate/steal it and then use the externalMetadataLocation attribute
Related
i have one doubt in Web Service / WCF
i'm creating the service and it's having 10 methods respectively
test1() , Program1(int age),Describe1(), DisplayAge(string name),,SimilarInterest(),ServiceCall(), Hide(), Difference(), WebService() and Help()
now after hosting this service in asmx only the below methods should display. others should not need to display.
DisplayAge(string name),,SimilarInterest(),ServiceCall() only these three should display when i call the http://URL.asmx?wsdl
the other 7 methods should not need to display in asmx wsdl file .how to do that?
As far as I know, in XML Web Service(ASMX), this should not work if you want the service to be both invoked and not shown in the WSDL. Either using private decorated methods or removing the [WebMethod] attribute causes the method to no longer be invoked. If in WCF we can implement authentication, authorization that individual methods cannot be invoked, or simply not expose metadata. But we cannot hide the specified method (but can be called by the outside world).
https://social.msdn.microsoft.com/Forums/en-US/533e0361-e9e0-400b-a7b2-f098a9ef3e75/how-to-prevent-web-method-from-showing-on-service-description-page?forum=asmxandxml
Feel free to let me know if there is anything I can help with.
I have created a SOAP service.
Now i want to consume it in a c# client application. I added the service using 'Add service reference' and service reference is added to client.
All my service entities are in service. And in current scenerio i can't move them to a common library.
Problem is, my service endpoint is accepting List<Foo> as parameter.
Foo has a method Boo.
In client, when i try to Foo.Boo() i get Cannot resolve symbol Boo error.
Unfortunately only methods on the service itself are exposed via a SOAP web service, methods on objects used as parameters or return values are not. If the method relates to a server-side operation then you could expose it at the service root level taking the instance object as parameter, or if it relates to a client-side operation you could consider adding it as a client-side extension method.
I need to validate the request in all the operation contracts. The request base will have user authentication token which needs to be validated every time.
I need to invoke a method in WCF (basically to validate this request) before all my operation contracts are gets called. Otherwise I have to write the code to validate the request in all the operation contract methods.
Is there any option in WCF for this?
WCF offers several extensibility points. You could check IDispatchMessageInspector.AfterReceiveRequest which allows you to inspect an incoming message before it is dispatched to the operation.
I'm currently working on a WCF service that reaches out to another service to submit information in a few of its operations. The proxy for the second service is generated through the strongly typed ProxyFactory<T> class. I haven't experienced any issues but have heard I should do something like the following when making the call:
using (new OperationContextScope((IContextChannel)_service))
_service.Send(message);
So my question is: when is creating this new OperationContextScope appropriate, and why?
Thanks!
If you are using callbacks or if you want to modify the message or headers then you need to use OperationContextScope. Your service might need to modify outgoing headers while calling that another service.
When you establish OperationContextScope then you can:
Access and modify incoming and outgoing message headers and other properties.
Access the runtime, including dispatchers, the host, channel, and extensions.
Access other types of contexts, such as security, instance, and request contexts.
Access the channel associated with the OperationContext object or (if the channel implements System.ServiceModel.Channels.ISession) the associated channel's session identifier.
The other service which you call, is it a session-based service? Probably you need to look at its sample client code or documentation if available.
I'll be more specific.
Lets say I have a contract defined for my WCF service. And I have two different WCF clients which reference to this service : "ClientA" and "ClientB".
Now , lets say I want to add an operation (method) to my service which only "ClientB" will use , Lets say I added this operation to the contract and "ClientB" updated its reference and we're all happy. Does clientA also need to update it's reference even though it is not using the new operation?
The client only needs to update his reference, if it's going to use the new Operation contract.
Check out this article: Versioning WCF Contracts
No, WCF web references are generated by the IDE very similarly to references to ASMX or other web services, which means that it breaks things down into a method inventory, such that the client calling code operates as though it were invoking a remote API. Therefore, if only new stuff that does not alter the expected existing functionality is added, then old clients do not need to update.