I am not able to open the meta data url http://localhost:8082/Tasks/mex, even though
I've added the mexHttpBinding in the config file. Can I view this MEX endpoint in a browser?
The config files look like:
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
Questions:
Is MEX is different from WSDL? If not, then why do we require a MEX endpoint over WSDL?
In the WSDL, I see the WSDL type information is missing. Is it by default? Can I look at the type information in WSDL?
Check out serviceMetadata for more information regarding the WCF configuration file.
To answer your questions though, MEX is a newer W3C standard for the presentation of Service description information; WSDL was the previous method. If you need to allow older clients to access your service description information, you may have to expose that information via WSDL.
The information for exposing your service description information as WSDL (httpGetEnabled) is also in the link provided above.
Also, try using the wcftestclient.exe to access your WCF service. It provides more functionality and information than a browser.
Aakash, Did you add a service behavior with a <serviceMetadata> element? It can be empty, i.e. <serviceMetadata />, but it must be present. The service definition needs to reference the service behaviorConfiguration. Check out the following for examples:
http://www.request-response.com/blog/PermaLink,guid,c9513d28-f580-4a33-b4e8-c15476799a9d.aspx
If you look at that endpoint, you'll see it looks like every other endpoint. There's even a service contract (IMetadataExchange). You can look at System.ServiceModel.Description.IMetadataExchange and see what that contract is all about.
Related
According to my understanding metadata can be explored by using three types of bindings:
mexHttpBinding
mexHttpsBinding
mexTcpBinding
Are all these bindings supported by WcfTestClient.exe ?
UPD
According to my understanding alternative way to get metadata is get WSDL information (old way of posting metadata).
If EcfTestClient.exe supports all these bindings listed above it don't need WSDL. According to my understanding to enable WSDL I need to place <serviceMetadata httpGetEnabled="true" httpsGetEnabled="true" /> in web.config in behaviors. This is not required if metadata is retrieved using mexHttpBinding,mexHttpsBinding,mexTcpBinding bindings. Please, correct me if I'm wrong. In this case WcfTestClient.exe finds metadata.
If I do false for both httpGetEnabled and httpsGetEnabled WcfTestClient.exe can't get service info:
Error: Cannot obtain Metadata from http://localhost:35168/mySrv.svc If this is a Windows (R) Communication Foundation service to which you have access, please check that you have enabled metadata publishing at the specified address.
Looks WcfTestClient.exe is getting information from WSDL and not from bindings mexHttpBinding , mexHttpsBinding , mexTcpBinding?
Well, based on MSDN, WCFTestClient supports all the bindings supported by SvcUtil. Now, if you look at the excerpts from MSDN below:
Svcutil issues the following metadata requests simultaneously to retrieve metadata.
MEX (WS-Transfer) request to the supplied address
MEX request to the supplied address with /mex appended
DISCO request (using the DiscoveryClientProtocol from ASMX) to the supplied address.
Looks like its safe to assume that WcfTestClient supports all three for metadata download.
MSDN WCFTestClient
MSDN SvcUtil
What is the difference between the Service node/section and the Client node/section in the configuration section? Why configure endpoints in one section over the other? Which is best for interoperability?
I'm currently building a service that talks to another service. I have endpoints for my clients and endpoints for the other service. Visual Studio seems to lump all the endpoints into the Client section.
I thought that client node was for your consumption and service node was for producing. But when you create a new wcf service visual studio puts your new service endpoint settings under the client node. I have moved my endpoint between both sections trying to figure out what the difference is.
When should I use service over client?
<system.serviceModel>
<services>
<service> <!--I noticed some tutorials and using wcf config edit tool
puts producer endpoint settings here -->
<endpoint blah settings/>
<endpoint blah settings/>
</service>
</services>
<client> <!--Visual Studio puts both producer and consumer endpoint
settings here -->
<endpoint blah settings />
<endpoint blah settings />
<endpoint blah settings />
</client>
<bindings>.....
</system.serviceModel>
Many settings in the WCF web.config (or app.config for that matter) can be shared for both consumers of a service as well as publishers of a service including:
Bindings
Endpoint Behaviors
Diagnostics
However as you have discovered, some config is specific to a service. A well-written service usually specifies:
It's base address. This is a convenience when defining a service as it allows your to define endpoints using relative addresses. Clients however don't use this particular setting as they need an absolute path. For this reason it makes no sense to specify in the section
Services can also be clients. If the client and server endpoints were all plonked together, WCF would not be able to know which should utilise the base address for one thing
Service behavior
By dividing up config between client and server, WCF is better able to know where to look for endpoints.
Which is best for interoperability?
I don't think that has anything to do with it. WCF is a means to achieve interopability but just by using WCF does not imply you will achieve it. Interopability is established when both parties agree on say a particular service contract; canonical data model; data transformation; message version or many of the other patterns as defined by SOA Patterns.org So there are various patterns you must follow. e.g. If you change a method on service contract but have not updated the clients then you have broken interopability by breaking the schema of the service.
Visual Studio seems to lump all the endpoints into the Client section
If your WCF process is both a consumer and producer of WCF services then it should not be putting all the endpoints under
It's my understanding that MEX and WSDL are two different ways of publishing metadata. In the interest of letting clients choose the one they prefer, I'd like to enable both. But I'm not entirely sure how.
My webconfig simply contains:
<serviceMetadata httpGetEnabled="true" httpsGetEnabled="true" />
and when browsing to it shows that default page, with a link to serviceblahblah?wsdl which suggests I am publishing just the WSDL.
My question is, is this using MEX, if not how can I also publish MEX, and should I be publishing both?
I'm using the basichttpsbinding if that makes any difference.
and when browsing to it shows that default page, with a link to serviceblahblah?wsdl which suggests I am publishing just the WSDL.
No, you are just visiting the WSDL. What else do you expect to see on that URL? ;-)
The httpGetEnabled attribute enables the publishing of WSDL metadata. As shown in the mexHttpBinding documentation and Getting Started, if you want to expose MEX, you also have to expose a MEX endpoint you can then access:
<!-- the mex endpoint is explosed[sic] at
http://localhost/servicemodelsamples/service.svc/mex -->
<endpoint address="mex"
binding="mexHttpBinding"
contract="IMetadataExchange" />
Clients, when discovering your service, will try to call the /mex endpoint first. If not found, they will request the WSDL. You can see this using Fiddler when you click "Add Service Reference" in Visual Studio and input the plain service URL, and I'm sure this behaviour documented somewhere.
I am new in WCF. I know that we have to write endpoint in config file at service end and as well as client end. suppose I have multiple endpoint like
<services>
<service name="YourNamespace.YourService" behaviorConfiguration="Default">
<endpoint name="Default"
address="http://YourServer/Services/MyService"
binding="basicHttpBinding"
contract="YourNamespace.IYourService"/>
<endpoint name="TCP"
address="net.tcp://YourServer/ServicesTCP/MyService"
binding="netTcpBinding"
contract="YourNamespace.IYourService"/>
<endpoint name="Dual"
address="http://YourServer/Services/MyService/Dual"
binding="wsDualHttpBinding"
clientBaseAddress="http://localhost:8001/client/"
contract="YourNamespace.IYourDualService"/>
<endpoint name="mex"
address=""
binding="mexHttpBinding"
contract="IMetadataExchange"/>
</service>
</services>
we know that we can not create proxy at client side with endpoint address like
http://YourServer/Services/MyService/Dual or
net.tcp://YourServer/ServicesTCP/MyService
rather if we need to create proxy at client side then we need to provide mex endpoint address. so I just do not understand what is the use of endpoint address?
When we create proxy at client side and call service then we just do not understand our proxy is using what endpoint address to connect to service?
That is why I just want to know how endpoint address come into role?
I know that we can write separate mex endpoint for tcp in config file as a result we can create proxy with that mex url as a result when client would connect to service then tcp protocol will be used for communication but for other http endpoints one mex endpoint works fine.
My important question is which I really like to know that suppose i have 3 endpoints like basichttp,wshttp,wsdualbidning then one mex endpoint works for all of them to create proxy. so tell me in that case when client connect to service then which endpoint address will be used to connect to that service?
It will be great help if some one discuss this issue with great detail and with sample config entry and as well as sample service code?
UPDATED Part
Tom Redfern said...service endpoints is not required in case of internal use. suppose I have developed a service which is hosted in console apps and other client need to connect to that service. so tell me in this case how client can connect to service without proxy class and call various method of service. I just like to know without proxy how can I connect and call various method of wcf service. please come with some sample code for client side just to show how programmatically I can connect and call various method of wcf service without proxy.
An endpoint needs a way of addressing it. This is both fundamental and reasonable.
Your argument that the client only requires a metadata endpoint address in order to resolve the actual service endpoints only holds true when you are exposing a metadata endpoint (which is by no means required) and when the consumer has no other means to consume the service (perhaps the service is public).
Most services are developed for internal consumption where the ability to bind directly to an endpoint via referencing a shared types assembly (rather than via a service proxy) is commonplace. Knowledge of the endpoint address in these instances is absolutely required.
If you read about the history of UDDI, this was designed as a means to distribute service metadata to consumers who would have no need to know anything else about the service. However, how often do you see a UDDI server? I have seen it used in exactly one company (I have worked in about 20 in total).
I have a WCF web service hosted in IIS7 which is reporting its endpoint URL as the following in its WSDL
http://machinename/virtualdirectory/service.svc
However the actual public URL which clients need to use is actually
http://machinename.mydomain.com/virtualdirectory/service.svc
And so at the moment clients that attempt to use this web service fail unless they manually edit the endpoint URL.
I know that I can fix this by changing the bindings of the site in IIS as per HOWTO: Fix WCF Host Name on IIS however in this case the site is shared with another application which stops working if I do this and so this isn't an option.
Is there another way that I can change the endpoint URL that WCF uses for this one virtual directory?
Although not directly answering my question (how can I set the WSDL endpoint URL in the web.config file) adding the <useRequestHeadersForMetadataAddress /> element to the <serviceBehaviors> section of my web.config file did fix my problems as now the endpoint URL is based on the URL used to access the WSDL, which is always the same as the URL used to call the web service.
Note that in this SO question it indicated that I needed to supply port numbers, note that this wasn't necessary for me - just adding the <useRequestHeadersForMetadataAddress /> element was enough
<serviceBehaviors>
<behavior name="<name>">
<!-- Other options would go here -->
<useRequestHeadersForMetadataAddress />
</behavior>
</serviceBehaviors>
There are a couple of options depending on which version of WCF your service is using. If you're using .NET 4 or higher, look at the accepted answer to this SO question. Otherwise you can either apply the hotfix that question references or if you're really desperate, hack the metadata URL of the httpGetUrl attribut to point to a copy of the WSDL which has been manually edited to contain the desired endpoint URL.