What is the purpose of IMetadataExchange endpoint. Some places i found that if i dont define this endpoint, adding service reference will not work OR creating proxy using svcutil wont work. But both of this working without having IMetadataExchange defined.
If we have other endpoint with httpGetEnabled = true, we are able to create proxy from client.
Also, some article says that we should delete IMetadataExchange before moving code to production and it should development period only so that other client cant see metadata. Doesnt this stop the behaviour of service having self describing itself?
And if I have defined this IMetadataExchange endpoint, how can i see that on browser. Address whoch i have provided for this endpoint is not pulling any metadata in browser.
Service metadata can be served two ways:
Regular WSDL served over HTTP/HTTPS, which is what that http[s]GetEnabled=true enables.
WS-MetadataExchange (MEX) which uses SOAP (and not just a plain GET request over HTTP) and supports a few more advanced scenarios (in theory, at least). That's what the IMetadataExchange endpoint enables.
Related
I'm working on an implementation of ICommunicationClient and accompanying stuff for HTTP protocol communication which should be compatible with SF reverse proxy. The most subtle part for me is retry policy. According to Azure docs for 404 errors reverse proxy relies on X-Service-Fabric header to be returned from web service when deciding if it should retry.
ASP.NET Core provides middleware for integration with a reverse proxy which adds X-Service-Fabric header to every 404 response.
Assume we have the scenario when ServicePartitionClient cached the endpoint for a stateless service listening on port 3001. At some point, this service may be moved to another node. On the first node, the Service Fabric runtime allocates a different service with its own endpoints but using the same middleware and listening on the same 3001 port.
When a client tries to call the original service at its old (cached) address it will receive 404 response containing the X-Service-Fabric header. According to reverse proxy policies it shouldn't retry, but for me, it seems like the client will stay connected to the wrong service forever and won't attempt to re-resolve the endpoint.
I can't find any information about this case in the documentation, did I miss something here? Is it safe to rely on this standard middleware and don't do retry attempts on 404 errors with X-Service-Fabric: ResourceNotFound header?
In the described case the communication client will be invalidated by staying connected to the wrong service. It is recommended by Microsoft to use unique URL prefixes for services with dynamically-assigned port to handle those scenarios.
In ASP.NET Core programmers can leverage ServiceFabricMiddleware which checks URL prefixes and returns 410 Gone if they don't match. Then HTTP implementation of ICommunicationClient can retry with re-resolving endpoint only for 410 responses and don't perform any retries on 404 response with X-Service-Fabric: ResourceNotFound header if reverse proxy integration is enabled.
In your given scenario, when your Client encounters a 404, the X-Service-Fabric:ResourceNotFound header isn't the only attribute your code could examine when deciding whether or not to retry some operation.
To simplistically address your concern that your client won't be able to tell the difference between a "friendly" node and a "newly arrived" node, and since you're already working with http headers, you could add a custom HTTP header to outgoing responses to identify that a request comes from your application.
When the client receives a 404, you can simply check for the presence of your custom header to answer the question of whether or not it's a "legit" retry. Of course, adding a custom HTTP header just for the sake of this validation check may be more of a global solution to a local problem. Ed: goes without saying that this should not be used to make security decisions by the application
A more elegant and complex means of accomplishing the same would be to deduce the same result using a different combination of HTTP headers and response attributes (e.g., see if some other headers are expected/unexpected), but this could also be a hyper-local solution to the problem.
By default AppFabric adds WorkflowControllEndpoit with NetNamedPipeBinding.
In my environment I need to manage workflows from another server which means that I cannot use net.pipe.
How do I add a WorkflowControllEndpoint on HttpBinding?
Please note that I allow users to dynamicly add workflows so I'm looking for a way to add endpoint to all workflows hosted by AppFabric. tag in web.config is not good for me.
Attempt 1:
Using behaviour to add endpoint. I've had problems adding WorkflowControllEndpoint. I've add following to behavior
var host = (WorkflowServiceHost)serviceHostBase;
host.AddServiceEndpoint(new WorkflowControlEndpoint(new
WSHttpBinding(), new EndpointAddress(host.BaseAddresses[0] +
"/Control")));
that compiles and runs but when I make request to this endpoint I'm getting
Content Type application/soap+xml; charset=utf-8 was not supported by service http://localhost/WorkflowServices/xx.xamlx/Control. The client and service bindings may be mismatched.
I guess that's because endpoint wasn't added and it goes to a default endpoint which doesn't accept Soap
Attempt 2
Disabling net.pipe - That forces AppFabric to bind to WSHttpBinding for WorkflowControllEndpoint but then I get wornings in Persistence window like
workflow persistence is not fully functional because the net.pipe
What functionality do I loose ?
I am trying to add a SOAP web service in the VS.NET 2010 interface, but I get that the server refused the connection. The people in charge of the service tell me it is working. I asked if they had a wsdl file, but supposedly they have none.
Is the problem caused by their lack of wsdl, or can I assume there is a problem on my side?
If they are not willing to expose their service metadata on the service then see if they will give you access to the assemblies containing the service contract, operations, and data contracts. Then you can create a proxy to the service without needing any metadata.
// Create service proxy on the fly
var factory = new ChannelFactory<IMyServiceContract>("NameOfMyClientEndpointInConfigFile");
var proxy = factory.CreateChannel();
// Create data contract
var requestDataContract = new MyDataContract();
// Call service operation.
var responseDataContract = proxy.MyServiceOperation(requestDataContract);
It also helps if you have access to the service-side config file so you can copy the endpoint details out of there into your client config.
It looks like their service is not exposing metadata. Try and browse to the wsdl url and see if you get back anything. http://server/blah/blah?wsdl
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
it looks like I am not able to succesfully move my WCF proxy code into a separate DLL (as opposed to an EXE as I can see in all the examples I have run into).
The reason I am trying to do this is that I would like my proxy code to be invoked by different clients (possibly unmanaged code), which might not know anything about WCF but just need to access to the services (through a Facade exposed by the proxy maybe?).
Whenever I move the following code that creates a new proxy to a different VS project within the same solution, I get the dreaded "Could not find default endpoint element that references contract 'localhost.IRemoteCommandService' in the ServiceModel client configuration section" exception.
localhost.RemoteCommandServiceClient proxy =
new localhost.RemoteCommandServiceClient();
The same code works smoothly whenever used within a Main method in the same project where the proxy code is (auto-generated from Visual Studio).
Any idea? I hope that the client code of my proxy does not need to have the service model XML configuration as the proxy, because that would defeat the purpose I am moving the WCF proxy code into a DLL in the first place.
Thanks,
Stefano
The endpoints are indeed normally specified in the configuration file. You must look at the serviceModel data in the config file, and copy it into your calling app.config - or you need to use the more verbose way of creating the proxies in your code (i.e. specifying the address, binding, configuration etc through code to the constructors).
If you don't want to have to endpoint configuration on the client, you'll have to embed it into your proxy dll by specifying everything in code.
Another option would be to use a dynamic proxy, like this one, which would allow you to not have the serviceModel in your client apps.