Want to understand httpGetEnabled and Mex Endpoint - wcf

i often saw people design their web service with both httpGetEnabled and Mex Endpoint but i do not know like
1) why mex endpoint is require ? what it does ? if we omit mex endpoint then what will occur ? if i omit mex endpoint then any .net application or java application could call my web service? help me the real usage of mex endpoint like when it is required and when not ?
2) what is httpGetEnabled
if i omit httpGetEnabled then any .net application or java application could call my web service?
any .net client can add web reference of my web service if httpGetEnabled is set false of does not exist? what is the default value of httpGetEnabled ?
what httpGetEnabled does ? please explain the usage httpGetEnabled with example or scenario.
thanks

MEX and WSDL are two different schemes to tell potential clients about the structure of your service. So you can choose to either make your service contracts public as "metadata exchance format" (MEX) or in the "web service description language" (WSDL) -- the latter being accessible via HTTP(s).
Thus in order to generate proxies, you need meta data information. When you remove the serviceMetadata-line you say you are not providing meta data in WSDL format.
But the line before, publishing your metadata in MEX, is still active, thus you can generate a proxy from those metadata.
From those follows naturally that when you provide neither WSDL nor MEX formatted information, you cannot generate a proxy.

Related

Various WCF bindings and their endpoints

I have few questions about various WCF bindings and their endpoints support.
1) I just like to know what is service meta data? How a wcf service meta data look like? Can u post a sample of meta data? How it look like?
2) Service meta data can be expose by both MEX and httpGetEnable then when MEX play a key role and when people set httpGetEnable = true ?
3) I am not understanding what is difference between MEX and httpGetEnable endpoint ?
4) Various wcf binding. wcf support various type of bindings as below
basicHttpBinding
wsHttpBinding
WsDualHttpBinding
NetTcpBinding
NetNamedPipeBinding
NetMsmqBinding
WSFederationHttpBinding
NetPeerTcpBinding
MsmqIntegrationBinding
so tell me which bindings are supported by httpGetEnable and what is supported by MEX?
looking for great discussion. thanks
Check the following links You will get informations regarding this,
What was the difference between WSDL & Mex Endpoint in WCF
Understanding httpGetEnabled and Mex binding
Why do i need both mex endpoint and httpGetEnable?
For binding and its full property visit the following link
https://msdn.microsoft.com/en-us/library/ms731172(v=vs.110).aspx

How to secure MEX endpoint WCF

suppose i have developed a WCF service with one mex endpoint. now i like to know how can i secure the mex endpoint means that if anyone know my mex endpoint address then that user may not be able to add my mex endpoint address from their VS IDE to create proxy. if user try to do so then windows auth login dialog comes.
now the question is how then any out side user will be able to call my wcf service. i will distribute my service dll or proxy class related *.cs files or WSDL. so user can add that dll or add those proxy related .cs file or add wsdl to their project to create proxy just to call & consume my service. i am not advance developer so i am not being able to understand how to develop this kind of secure wcf service where user can not add my mex endpoint.
so just guide me with little wcf sample code & config example from where i can understand what i need to to meet my requirement. thanks
This topic looks helpful
https://msdn.microsoft.com/en-us/library/aa395212%28v=vs.110%29.aspx
Initially, one would think one would just change the HTTP to HTTPS but according to the article apparently you lose some degree of freedom in configuration
If you use the mexHttpsBinding your metadata endpoint will be secure, but there is no way to modify the binding settings.

WCF RoutingService failing when mex gets too large

I'm having an issue with a net.tcp WCF windows service int .NET 4.0 where it looks like my mex for a particular endpoint is too large. There is no problem at all connecting directly to the endpoint. I created a WCF RoutingService to allow someone outside our private network to connect to my internal WCF service. Getting the mex information through the RoutingService fails.
My WCF service has about 7 endpoints, and the WCF RoutingService is routing all of them, but only the large one (with 17 methods) is having the problem.
I found this link below which explains how to fix the problem when failing to connect directly to the mex endpoint
http://blogs.msdn.com/b/distributedservices/archive/2009/05/07/too-many-operations-or-methods-in-wcf-service-causes-the-metadataexchange-fail.aspx
But it talks about creating an endpoint in svcutil.exe.config with a contract of IMetadataExchange. The RoutingService endpoint I'm having a problem with is using the contract System.ServiceModel.Routing.IRequestReplyRouter, so I don't know if I need to configure the svcutil.exe.config file slightly differently. I've tried all sorts of combinations but couldn't get anything to work. I'm not even sure where I need to put the svcutil.exe.config file for the RoutingService WCF service to pick it up, or even if it needs one.
Does anybody know of a better solution, or a link which might provide help for when a RoutingService is involved?

WCF wsdl generation missing WsTrust (RequestSecurityToken)

We have a problem in integrating a wcf service in a web service firewall.
Because the wsdl of the service does not contain the operations for ws-trust (requestsecuritytoken, ..).
How can I force WCF to include all details in its wsdl?
Or do I have to construct the wsdl myself?
Details:
Binding: WSFederationHttpBinding
MessageVersion: Soap12
Maybe it's because WCF produces multiple files by default and that is not always supported by things other than WCF clients.
Try this blog post about making WCF producing single wsdl. Maybe it will help.

BizTalk publish net.tcp WCF service

Is anybody familiar with setting up WCF-nettcp adapters for BTS?
When I create a WCF-netTcp adapter for a Receive location, I am unsure how/when BTS will open up port 808 to listen on the address URI specified. It appears to only happen if I restart the entire BizTalk application. If it closes for some reason, I do not see any way of reconfiguring and reopening the port.
Furthermore, since that is only the net.tcp binding, there is no mex endpoint exposed. I believe client applications that wish to use that exposed WCF service needs mex metadata initially. Accessing that endpoint direct from a Visual Studio project would just yield
Metadata contains a reference that cannot be resolved: 'net.tcp://biztalkserver/PostReceiveLocation_TCP/PostReceiveService.svc'.
Metadata contains a reference that cannot be resolved: 'net.tcp://biztalkserver/PostReceiveLocation_TCP/PostReceiveService.svc'.
If the service is defined in the current solution, try building the solution and adding the service reference again.
Cannot tell for such how to properly expose a mex endpoint to the service. the BizTalk WCF Service Publishing Wizard is confusing me; I cannot get it to reference the WCF adapter/Receive location I setup. I find no document that teaches what one ought to do for netTcp services; it is all about Http.
Funny, it took the walkthrough about publshing Net-Msmq WCF service to nudge me thinking how the WCF Service Publishing Wizard really works.
The issue is this: When I manually created the WCF-netTcp Receive location, it has its endpoint URI e.g. net.tcp://biztalkserver/PostReceiveLocation_TCP/PostReceiveService.svc. When selecting the option to publish just an mex endpoint in the WCF Service Publishing Wizard, it will eventually ask for the WCF Service Location, which i confused to be the actual service location. Since it would accept nothing but Http URLs, it appeared to only support Http-based WCF endpoints.
But for that textbox, one is supposed to place the Http URL that for just the mex endpoint, not the actual net.tcp WCF endpoint. That is the location in IIS where the wizard will create the necessary meta-data files. Once finished, that location, hosting a mex endpoint will inform clients of the real service located at the net.tcp endpoint.