regarding mex endpoints in wcf - wcf

here is one sample of mex endpoints
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
but i have seen people write mex endpoints like
<endpoint address="net.tcp://localhost:1645/ChatServer/mex"
binding="mexTcpBinding"
contract="IMetadataExchange"/>
so tell me why and when one should write mex endpoint like above one.
just compare my two endpoints and see the difference that first one address attribute has
the word called "mex" but second one has url.
so my question is "when people has to give a url to address attribute of mex endpoints?".
Another question is "Does mex address url always should have /mex word at the end of url?".
if i give url like net.tcp://localhost:1645/ChatServer/ or net.tcp://localhost:1645/ChatServer without mex word then service will not be discoverable?
what is the significiant of /mex word??

the first one will expose metadata over http and second one will do it over the TCP . It is used to support the platforms, WCF is made for supporting multiple platform.
you can make any url to expose metadata. it is not necessary to follow the convention above.
mex is just more good practice to make it metadata just same like url+mex .
here is an url which will give an overview
http://www.danrigsby.com/blog/index.php/2008/05/27/wcf-metadata/

Related

Asp.NET Core 2.2 WCF Warning: Policy

I'm trying to add wsdl using WCF. But at first I get an warning like this;
enter image description here
Here is the details:
The following Policy Assertions were not Imported:
XPath://wsdl:definitions[#targetNamespace='urn:sap-com:document:sap:soap:functions:mc-style']/wsdl:binding[#name='zz_binding_SOAP12']
Assertions:
<saptrnbnd:OptimizedXMLTransfer xmlns:saptrnbnd='http://www.sap.com/webas/710/soap/features/transportbinding/'>..</saptrnbnd:OptimizedXMLTransfer>
<sapattahnd:Enabled xmlns:sapattahnd='http://www.sap.com/710/features/attachment/'>..</sapattahnd:Enabled>
The following Policy Assertions were not Imported:
XPath://wsdl:definitions[#targetNamespace='urn:sap-com:document:sap:soap:functions:mc-style']/wsdl:binding[#name='zz_binding']
Assertions:
<saptrnbnd:OptimizedXMLTransfer xmlns:saptrnbnd='http://www.sap.com/webas/710/soap/features/transportbinding/'>..</saptrnbnd:OptimizedXMLTransfer>
<sapattahnd:Enabled xmlns:sapattahnd='http://www.sap.com/710/features/attachment/'>..</sapattahnd:Enabled>
The optional WSDL extension element 'Policy' from namespace 'http://schemas.xmlsoap.org/ws/2004/09/policy' was not handled.
XPath: //wsdl:definitions[#targetNamespace='urn:sap-com:document:sap:soap:functions:mc-style']/wsdl:portType[#name='zz_test_web_structure']/wsdl:operation[#name='ZzTestWebService']
The optional WSDL extension element 'Policy' from namespace 'http://schemas.xmlsoap.org/ws/2004/09/policy' was not handled.
XPath: //wsdl:definitions[#targetNamespace='urn:sap-com:document:sap:soap:functions:mc-style']/wsdl:portType[#name='zz_test_web_structure']
I still can't run the wcf service after adding it. Does anyone know about this?
Microsoft WCF Web Service Reference Provider tool based on the Mex service endpoint, namely metadata exchange service endpoint instead of the Web service definition language(WSDL page).
<services>
<service name="WcfService1.Service1">
<endpoint address="" binding="basicHttpBinding" contract="WcfService1.IService1" bindingConfiguration="mybinding"></endpoint>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"></endpoint>
</service>
</services>
Or,
Binding mexbinding = MetadataExchangeBindings.CreateMexHttpBinding();
sh.AddServiceEndpoint(typeof(IMetadataExchange), mexbinding, "mex");
If you prefer to generate a client proxy class by using WSDL, you could try the SVCUtil.exe tool.
https://learn.microsoft.com/en-us/dotnet/framework/wcf/servicemodel-metadata-utility-tool-svcutil-exe
All the above ways can generate a client proxy class.
https://learn.microsoft.com/en-us/dotnet/framework/wcf/accessing-services-using-a-wcf-client
Besides, In WCF4.5 there is a new feature called SingleWSDL, which contains the whole WSDL with the related schema. It could be consumed perfectly by a third-party system.
What is the difference between ?wsdl and ?singleWsdl parameters
https://learn.microsoft.com/en-us/dotnet/framework/wcf/whats-new
Feel free to let me know if there is anything I can help with.

Few basic query regarding entries in config file for WCF service end as a wcf starter

i am very new in WCF world. i just download a code and saw the wcf service config file but confusion is occuring in my mind regarding entries in config file for WCF service due to my lack of knowledge.i go through some online article but still i have confusion.
here are my question
1) <service name="WCFService.Service"
when service name is required? can i omit the service name and if yes then what kind of problem may occur?
2) can i set any name to service name like abc.xyz or is there is some rule for assigning service name?
3) what is the use of base address? if one omit the base address then what can be problem.
when base address is required.according to below config entries there are two base addresses...why two base address is required. when people give more base addresses? just see the below 2 base address and tell me why people give two base address why not one...is there any specific reason?
4) there are two endpoints one is tcp and another is mex.
if i omit mex base address then service will not be discoverable? if yes that means no one can create proxy from VS IDE or svcutil....am i right.
5) if mex endpoint will be remove then how one can interact with the service....there must be some other way out. if so then tell me how one can interact with service as a client end.
6)
just see the above mex endpoint and tell me can we write mex endpoint url anything like
**net.tcp://localhost:1645/MyServer/mex** instead of ChatServer ??
actually wcf service hosted in win form project whose name is ChatServer. is this the reason that url becomes net.tcp://localhost:1645/ChatServer/mex?
i have seen many time people write mex end point like and here no url assign to address tag of mex endpoint....why?
when i should write the mex endpoint like above...please explain with example.
7) what is the meaning of /mex....net.tcp://localhost:1645/ChatServer/mex
/mex is mandatory and mex is fixed word?
8) now see tcp endpoint
tcp endpoint address has no url rather tcp the word has been assign to address property...why?
can't we assign any valid url to address filed of tcp endpoint??
9) the address field of tcp endpoint will always have the fixed word called "tcp" is it rule or convention.
10) if i need to add another endpoint called wsdualhttp binding then what i need to write in config file
11) suppose some one developing service which will be hosted in IIS but client can be another asp.net web apps and win apps then what he/she need to do?
then what url client should use to create proxy from VS ide? can anyone come with sample config entries.
12) how to write config file if i want that people can create proxy of my service using two url like....one is as sample net.tcp://localhost:1645/ChatServer/mex and another one
is http://localhost:1645/ChatServer/message.svc
i know my question are very basic but still i am not being able to sort these question.
also guide me how could i have strong knowledge for creating config file entries boldly.
is there any tool which will create right config entries for my service....i am is there any automated apps which will do it on behalf developer. thanks
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.serviceModel>
<services>
<service name="WCFService.Service" behaviorConfiguration="behaviorConfig">
<host>
<baseAddresses>
<add baseAddress="net.tcp://localhost:1645/ChatServer/"/>
<add baseAddress="http://localhost:1648/ChatServer/"/>
</baseAddresses>
</host>
<endpoint address="tcp"
binding="netTcpBinding"
bindingConfiguration="tcpBinding"
contract="ChatService.IChat"/>
<endpoint address="net.tcp://localhost:1645/ChatServer/mex"
binding="mexTcpBinding"
contract="IMetadataExchange"/>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="behaviorConfig">
<serviceMetadata httpGetEnabled="true" httpGetUrl=""/>
<serviceDebug includeExceptionDetailInFaults="true"/>
<serviceThrottling maxConcurrentCalls="100" maxConcurrentSessions="100"/>
</behavior>
</serviceBehaviors>
</behaviors>
<bindings>
<netTcpBinding>
<binding name="tcpBinding"
maxBufferSize="67108864"
maxReceivedMessageSize="67108864"
maxBufferPoolSize="67108864"
transferMode="Buffered"
closeTimeout="00:00:10"
openTimeout="00:00:10"
receiveTimeout="00:20:00"
sendTimeout="00:01:00"
maxConnections="100">
<security mode="None">
</security>
<readerQuotas maxArrayLength="67108864"
maxBytesPerRead="67108864"
maxStringContentLength="67108864"/>
<reliableSession enabled="true" inactivityTimeout="00:20:00"/>
</binding>
</netTcpBinding>
</bindings>
</system.serviceModel>
</configuration>
MY Edited part start here
3) what common part you are talking about. what common part u have seen in my complete config file...please explain with example.
you said....If you omit base address, you need to specify common part multiple times every time. Multiple base address are required if endpoints are specified for multiple transport protocol
can u please make me understand with example what u have said for omit base address becoz the things not clear to me after reading ur answer for points 3
4) if i disable mex endpoints then how can i create wsdl with svcutil? if i give my service dll then client can decode the code and get my full source code.can u tell me more elaborately what u trying to say for the points 4
12) if i expose two url for consuming my service then asp.net client can create service proxy using tcp url like net.tcp://localhost:1645/ChatServer/mex ??
is there will be any problem for web client for using tcp binding. because tcp is state full but web is stateless...that is why i am asking is there will be any problem for web client for using tcp binding url net.tcp://localhost:1645/ChatServer/mex
13) in my example the mex endpoint look like
but many people create mex end point like
so tell me what is the difference between two mex end point....also tell me when one should go for 1ts mex endpoint and when people go for second mex endpoint
14) in my case if i would write mex end like
and tcp endpoint like
then what would be the result. my service would be discoverable or not.
what address i shoudl use to create service proxy in that case.
if possible please answer my question with mini sample for easy understanding because i am very new in WCF....thanks
Your answers one by one
Service name is always required. If you omit it in the configuration file, runtime error will occur related to malformed configuration file (with error indicating invalid service name). If you omit it from the code, it will form compile time error.
No. Service name should be corresponding to the type that is implementing the service (along with namespace). Check this answer for detail.
If multiple end points are defined (like service endpoint, and mex endpoint) with some common part, then common part can be specified in base address tag. Only differential part is then required in endpoint address attribute (usually "" for service endpoint and "mex" for mex endpoint) If you omit base address, you need to specify common part multiple times every time. Multiple base address are required if endpoints are specified for multiple transport protocol (ie different base address for http and net.tcp).
Example is here with and without baseaddress.
Common part is "net.tcp://localhost:1645/ChatServer"
If you omit mex endpoint, you need to provide the contract information offline to client. As you have mentioned service will not be discoverable. Thus you need to supply the service/data contract information (as WSDL/ library/ source file ) somehow to client application.
To create client, all you need is contracts and configuration. If mex is available, this information is gathered from mex endpoint. If mex is not available, this information must be made available offline. Example (sending contracts library and configuration by email).
Way out is to provide contract information offline (as mentioned in step 4)
Yes, but not recommended to avoid ambiguity.
No, "mex" is not fixed. It can be anything (as long as URL is valid). "mex" is just unsaid protocol/standard.
Endpoint address = baseAddress + address attribute.
In this case address (of tcp endpoint) = "net.tcp://localhost:1645/ChatServer/" + "tcp"
It is no convention. It could be anyting (as long as URL is valid).
Refer to the link for wsdualhttpbinding configuration. However not that since transport protocol is http, you need to provide full address. baseAddress will not be picked up. This is due to protocol mapping.
Client app (be it ASP.NET/console/win app/WPF/ any other) need to add WCF client configuration and proxy.
If is upto client to decide, which URL they want to use (provided they have access and they are aware). If you want to do it on server side, you may use Routing service feature (available in WCF 4.0 onwards).
I am not sure how web client uses tcp clients (Does security policy allows this?). What ever is the case, exposing two endpoints from server side has no issues on how client will access the endpoints.
13/14 code snippet not visible due to formatting issue.

In WCF app.config, why does the base address require the prefix http:// or net.tcp?

I'm watching a webcast on WCF, and it has two endpoints defined in the app.config, one netTcpBinding and one mexHttpBinding.
It also has two base addresses, net.tcp://localhost:9000 and http://localhost:8000.
I'm wondering how it associates those base addresses with the endpoints. Since your endpoint specifies tcp or http, why are the base addresses prefixed with net.tcp and http?
If WCF uses net.tcp base addresses with netTcpBinding endpoints, what happens if you have two tcp endpoints that listen on 9000 and 9001, what would you put into the config to stop the conflict?
I'm wondering how it associates those base addresses with the
endpoints.
Per protocol.
When you define service endpoints, you can give relative or absolute addresses for the endpoints, if you give an absolute endpoint address then the base addresses will not be used to generated the actual endpoint address, however if you give a relative address
in your endpoint then a combination of your base address and relative address will be used to generated the final endpoint address.
A relative endpoint address is like this for example:
<endpoint address="/hostHttp" binding="wsHttpBinding" contract="IMyService" />
<endpoint address="/hostNetTcp" binding="netTcpBinding" contract="IMyService" />
Now WCF will generate the actual endpoint address using your base address that you defined per protocol:
<baseAddresses>
<add baseAddress="http://localhost:8550/MyServiceHost/Service"/>
<add baseAddress="net.tcp://localhost:8551/MyServiceHost/Service"/>
</baseAddresses>
So your HTTP endpoint address will ultimately be:
http://localhost:8550/MyServiceHost/Service/hostHttp
and your netTcp endpoint:
net.tcp://localhost:8551/MyServiceHost/Service/hostNetTcp
Now if you have another protocol defined, and you haven't defined an absolute address in your endpoint, WCF will look for the base address defined for that particular protocol, and generate an endpoint using the base address.
If WCF uses net.tcp base addresses with netTcpBinding endpoints, what
happens if you have two tcp endpoints that listen on 9000 and 9001,
what would you put into the config to stop the conflict?
I think it would be best to give absolute adresses in ypour endpoints in this instance:
<endpoint address="net.tcp://localhost:9000/MyServiceHost/Service"
binding="netTcpBinding"
contract="IMyService" />
<endpoint address="net.tcp://localhost:9001/MyServiceHost/Service"
binding="netTcpBinding"
contract="IMyService" />
As mentioned previously when you provide absolute addresses then your base addresses won't be consulted in generating an endpoint address.
You may want to have a look at this.
Regarding multiple base addresses. How it chooses the right one, im not sure, but "You can also have multiple base addresses for a service, but each service is allowed only one base address for each transport" as you have observed, more info here.
You cannot have two base address of the same type.
I maybe misunderstanding slightly but if you want to amend (and I dont know why you would!) that it associates a net.tcp address with nettcpbinding - you can do so in the protocolmapping section of your config file
as highlighted here

WCF IIS hosted service multiple Service Contracts implemented by a single service - how do I share uri between endpoints via config

I have a set of Service Contracts which split up my service interface into chunks of related functionality. I am currently implementing all contracts using a single service class (may want to split these later but for now the single service class suffices).
I am trying to use configure the endpoints using a config file (as opposed to via code). The problem is I get a ServiceActivationException because the two endpoints (one for each service contract) are trying to listen on the same uri. The exception details say that to achieve this the two endpoints must share the binding object, which makes sense but I can't figure out how to do this via config (I haven't tried doing this via code as I am hosting in IIS but I can imagine it being a simple exercise to configure in code).
The following is the config I am currently using (this is still dev so I'm not currently worried about security concerns etc. that some of these settings may expose):
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
<services>
<service name="CDC.WebPortal.MidTier.MidTierAccessService"
behaviorConfiguration="MidTierServiceBehaviour" >
<endpoint address=""
binding="webHttpBinding"
bindingConfiguration="RestBindingConfiguration"
contract="****************************.IProductService" />
<endpoint address=""
binding="webHttpBinding"
bindingConfiguration="RestBindingConfiguration"
contract="****************************.ICategoryService" />
<endpoint address="mex" binding="mexHttpBinding"
contract="IMetadataExchange" />
</service>
</services>
<bindings>
<webHttpBinding>
<binding name="RestBindingConfiguration"
maxReceivedMessageSize="104857600">
<readerQuotas maxStringContentLength="104857600"/>
</binding>
</webHttpBinding>
</bindings>
<behaviors>
<serviceBehaviors>
<behavior name="MidTierServiceBehaviour">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="false" />
</behavior>
</serviceBehaviors>
</behaviors>
So my question is how do I share this binding between the two endpoints?
Comments in this SO question suggest I may not be able to do this, but I don't beleive that is correct.
UPDATE 1 According to this MS publication what I'm doing should be ok...
UPDATE2 Here is the svc file content if it helps:
<%# ServiceHost Language="VB" Debug="true"
Service="*********************.MidTierAccessService"
Factory="Microsoft.ServiceModel.Web.WebServiceHost2Factory" %>
UPDATE 3 Here is the exception detail:
A binding instance has already been associated to listen URI '********************'. If
two endpoints want to share the same ListenUri, they must also share the same binding
object instance. The two conflicting endpoints were either specified in
AddServiceEndpoint() calls, in a config file, or a combination of AddServiceEndpoint()
and config.
UPDATE 4 Ok I missed this before, stating "You will need to use relative addresses when exposing more than one endpoint for a particular .svc service". The cause of this is something to do with the IIS virtual directory determining the base address of the service, can anyone explain this in a little more detail, i.e. why IIS needs relative addressing for each contract.
To my knowledge, and I have been doing extensive work with WCF in the last month, you can not share the same exact URI for more than one endpoint. In WCF, a "service" is not defined by the implementation of a contract, but by the contract itself (which also follows WSDL and standard SOA practices.) Endpoints allow you to expose a single service via multiple protocols (and therefor different addresses), but you can not share different services on the same exact address. Logically that wouldn't work.
Assume the following scenario (which is what you are trying to accomplish):
IProductService exposed # http://localhost/service
ICategoryService exposed # http://localhost/service
IMetadataExchange exposed # http://localhost/service/mex
It is easy enough to access the MEX endpoint...it has a unique URI. However, how do you access either of IProductService or ICategoryService? There is nothing that allows you to differentiate the two other than a URI. WCF has nothing that will allow it to route between messages that are supposed to go to IProductservice, and those that are supposed to go to ICategoryService. Since both use the same URI, you do indeed have a conflict. Every service CONTRACT must be exposed via a unique URI. Every endpoint that utilizes the same exact binding must use a distinct address.
There is a way to achieve what you need. The problem is message routing. WCF does not natively support message routing OOB, however it does provide the ability to implement your own message router. (Or, if you are willing to use beta tech, .NET 4.0 comes with a message router out of the box, based on the articles linked below, but with improved configurability.) Michele Bustamante, a veritable sorceress of WCF, has provided a complete implementation and article describing message routing at the following links:
http://msdn.microsoft.com/en-us/magazine/cc500646.aspx
http://msdn.microsoft.com/en-us/magazine/cc546553.aspx
The general idea is that you set up a single service that listens on a single URI. This service uses wildcard dispatch to a single service operation, which then determines which unique URI to route each message to. You can make the determination any way you wish, however the simplest is via the request Action, assuming each action on your two interfaces, IProductService and ICategoryService, are globally unique. You will end up with more services, however...the router itself is a distinct WCF service that would need to be hosted just like any other.

WCF WebInvoke problem getting WSDL

i got a webservicedefinition like this:
[OperationContract]
[FaultContract(typeof(Exception))]
[WebInvoke(ResponseFormat = WebMessageFormat.Xml,
BodyStyle = WebMessageBodyStyle.Wrapped,
RequestFormat = WebMessageFormat.Xml)]
SearchResponse SearchXML(SearchRequest req);
and a Service config like this:
<service name="SearchEngine.SearchService" behaviorConfiguration="HTTPGetBehavior">
<endpoint address="SearchEngine.SearchService" behaviorConfiguration="ajaxBehavior" binding="webHttpBinding" contract="SearchEngine.ISearchInterface" />
<endpoint contract="IMetadataExchange" binding="mexHttpBinding" address="mex" />
<host>
<baseAddresses>
<add baseAddress="http://localhost:8800/SearchService" />
</baseAddresses>
</host>
</service>
and i want to get the WSDL file, which should be possible with a HTTP-GET request like this:
http://localhost:8800/SearchService?wsdl
But all iam getting is a "method not allowed message by the wcf-service"
What am i doing wrong? I want the WSDL information to show the structure of request and response to an external client ( so that he can prepare his function calls )
Thanks
Well, if I read the binding correctly, you're using the "webHttpBinding" which is a REST interface.
REST does not have anything like the WSDL file - that's a SOAP thing.
REST is considered easier to use and simpler to understand - but it doesn't have the amount of metadata that a typical SOAP web service will have.
So basically, if you stick with REST (webHttpBinding), you can't have a WSDL - you have to find another way to communicate your service methods exposed and the possible parameters they expect.
There seem to be efforts under way to come up with something similar to a WSDL for REST called Web Application Description Language (WADL) but I don't know how far that effort has come, and as far as I know, the WCF REST starter kit doesn't support any of that just yet.
Check out some links for WADL:
Sun Web Application Description Language Spec
WADL REST API description language getting some attention
Do we need WADL?
Does REST need a WSDL?
Marc