What is the use and importance of IMetadataExchange in WCF?
I have the following app.config file in which I don't use IMetadataExchange endpoint, but I am still able to create my proxy client. I have read that if I don't use IMetadataExchange endpoint, AddServiceReference will not work because my service does not expose the metadata. How is it working without exposing IMetadataExchange endpoint?
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior name="metaDataBehavior">
<serviceMetadata httpGetEnabled="true"/>
</behavior>
</serviceBehaviors>
</behaviors>
<services>
<service name ="WCFService.Services" behaviorConfiguration="metaDataBehavior">
<host>
<baseAddresses>
<add baseAddress="http://localhost:8090/Services/"/>
</baseAddresses>
</host>
<endpoint address="" binding="basicHttpBinding" contract="WCFService.IMathOperations"/>
</service>
</services>
</system.serviceModel>
</configuration>
ArsenMkrt has the formal answer. Put more simply:
If you don't have it, adding a service reference will not work
You should delete it from production servers, so that a hacker cannot add a service reference
To answer your question more specifically, you have this line on your service:
<service name ="WCFService.Services" behaviorConfiguration="metaDataBehavior">
Which points to this configuration
<behavior name="metaDataBehavior">
<serviceMetadata httpGetEnabled="true"/>
</behavior>
This may be why it still works, although I thought that you needed to specify the MEX endpoint.
IMetadataExchange Interface Exposes methods used to return metadata about a service.
When programming Windows Communication Foundation (WCF) services, it is useful to publish metadata about the service. For example, metadata can be a Web Services Description Language (WSDL) document that describes all of the methods and data types employed by a service. Returning metadata about an WCF service allows consumers of a service to easily create clients for the service.
The difference is:
<serviceMetadata httpGetEnabled="true"/>
allows you to retrieve metadata using the HTTP protocol.
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
allows you to retrieve metadata using the ws-metadata protocol.
Just <serviceMetadata httpGetEnabled="true"/> works, but not all clients can call you (because they can't retrieve metadata to create a proxy).
The standard is to publish both.
See also ServiceMetadataBehavior Class (MSDN).
Without IMetadataExchange, a WCF service exposes the metadata information to the client, but WCF does not guarantee to expose the metadata because WCF default features to exposing the metadata to the client.
Exposing the metadata is done in a well-standardized way through IMetadataExchange. The IMetadataExchange interface follows the industry standard.
Related
Background
I have created ASMX web services in the past and have been able to access the service from the web browser and Ajax GET requests using the address convention: MyService.asmx/MyMethod?Param=xxx
I just got started using WCF and created a new web service in my ASP.NET project. It creates a file with the .svc extension such as MyService.svc.
Current Situation
I am able to consume the service using the WcfTestClient that comes with VS2008. I am also able to create my own WCF Client by either adding a service reference in another project or using the svcutil.exe commandline to generate the proxy and config file.
The Problem
When I try to use the service from a browser using MyService.svc/MyMethod?MyParam=xxx, I get a blank page without any errors.
What I have tried
I have already added a basicHttpBinding to the web.config and made it HttpGetEnabled in the behavior configuration. I also added the [WebGet(UriTemplate = "MyMethod?MyParam={MyParam}")] attribute to my operation contract.
I have already followed the information in this other stack overflow question:
REST / SOAP EndPoints for a WCF Service
However, I either get a blank page or an HTTP 404 Error after following those steps. There's nothing special about the code. I am just taking in a string as a parameter and returning "Hello xxx". This is a basic "Hello WCF World" proof-of-concept type thing.
UPDATE - Here's the relevant code
[ServiceContract]
public interface IMyService
{
[WebGet(UriTemplate = "MyMethod/MyParam={MyParam}")]
[OperationContract]
string MyMethod(string MyParam);
}
Web.Config - system.serviceModel Section
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior name="MyServiceBehavior">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true"/>
</behavior>
</serviceBehaviors>
</behaviors>
<services>
<service behaviorConfiguration="MyServiceBehavior" name="MyService">
<endpoint address=""
binding="wsHttpBinding" contract="IMyService" />
<endpoint address="MyService.svc"
binding="basicHttpBinding" contract="IMyService" />
<endpoint address="mex"
binding="mexHttpBinding" contract="IMetadataExchange"/>
</service>
</services>
</system.serviceModel>
Looking at your web.config serviceModel section, I can see that you need to add a webHttpBinding and associate an endPointBehavior that includes webHttpGet.
Your operation contract is correct. Here's how your system.serviceModel config section should look in order for you to be able to consume the service from a GET HTTP request.
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior name="MyServiceBehavior">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true"/>
</behavior>
</serviceBehaviors>
<endpointBehaviors>
<behavior name="WebBehavior">
<webHttp />
</behavior>
</endpointBehaviors>
</behaviors>
<services>
<service behaviorConfiguration="MyServiceBehavior" name="MyService">
<endpoint address="ws" binding="wsHttpBinding" contract="IMyService"/>
<endpoint address="" behaviorConfiguration="WebBehavior"
binding="webHttpBinding"
contract="IMyService">
</endpoint>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
</service>
</services>
</system.serviceModel>
Be sure to assign a different address to your wsHttpBinding endpoint, otherwise you will get an error saying that you have two endpoints listening on the same URI.
Another option is to leave the address blank in the wsHttpBinding, but assign a different address to the webHttpBinding service. However, that will change your GET address as well.
For example, if you assign the address as "asmx", you would call your service with the address "MyService.svc/asmx/MyMethod?MyParam=xxxx".
The normal WCF requests are always SOAP requests - you won't be able to get this going with just your browser, you'll need the WCF Testclient for that.
There is an add-on for WCF called the WCF REST Starter Kit (which will also be included in WCF 4.0 with .NET 4.0), which allows you to use GET/POST/PUT/DELETE HTTP commands to query WCF services and such. You need to write your services specifically for REST, though - you can't have SOAP and REST on the same service call.
Marc
As marc_s says, the REST Starter Kit can help, but you should also be aware that .NET 3.5 has support for REST services directly in it. It's not quite as complete as what you can do with the starter kit, but it is useful.
The way it works is that you put a [WebGet] attribute on your operations to indicate where in the URL the various parameters should come from:
[WebGet(UriTemplate = "helloworld/{name}")]
string Helloworld(string name);
See this portal for tons of information.
Note, you can have the same service exposed as both SOAP and REST if you specify multiple endpoints/bindings in the configuration.
i am working with wcf service application where svc file is created. now i want to design my service in such a way that people can connect to my service by http url and as well as by tcp url
so i would like to add three endpoint in my config one for wshttp, one for wsDualhttp and another one for tcp. so please someone give me sample config entry with 3 endpoints for wshttp, wsDualhttp and tcp.
in this case do i need to have three different mex endpoint for wshttp, wsDualhttp and tcp.
also tell me 3 url by which i can create proxy classes at client side. thanks
You could have something like this (assuming self-hosting, since only then can you really determine the full service addresses yourself - hosting in IIS, the service address(es) are most determined by where your .svc file lives):
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior name="Default">
<serviceMetadata httpGetEnabled="true"/>
</behavior>
</serviceBehaviors>
</behaviors>
<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="mex"
address="http://YourServer/Services/MyService/mex"
binding="mexHttpBinding"
contract="IMetadataExchange"/>
<endpoint name="Dual"
address="http://YourServer/Services/MyService/Dual"
binding="wsDualHttpBinding"
clientBaseAddress="http://localhost:8001/client/"
contract="YourNamespace.IYourDualService"/>
</service>
</services>
</system.serviceModel>
This would define three endpoints:
a HTTP endpoint at http://YourServer/Services/MyService for your service
a HTTP MEX endpoint at http://YourServer/Services/MyService/mex for the metadata exchange (service discoverability)
a Net.TCP endpoint at net.tcp://YourServer/ServicesTCP/MyService for your service
You could of course also use two base addresses to make things a bit easier in the config:
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior name="Default">
<serviceMetadata httpGetEnabled="true"/>
</behavior>
</serviceBehaviors>
</behaviors>
<services>
<service name="YourNamespace.YourService" behaviorConfiguration="Default">
<host>
<baseAddresses>
<add baseAddress="http://YourServer/Services"/>
<add baseAddress="net.tcp://YourServer/ServicesTCP"/>
</baseAddresses>
</host>
<endpoint name="Default"
address="MyService"
binding="basicHttpBinding"
contract="YourNamespace.IYourService"/>
<endpoint name="TCP"
address="MyService"
binding="netTcpBinding"
contract="YourNamespace.IYourService"/>
<endpoint name="mex"
address="MyService/mex"
binding="mexHttpBinding"
contract="IMetadataExchange"/>
</service>
</services>
</system.serviceModel>
This would configure the equivalent service endpoints.
The wsDualHttpBinding is different in that it requires at least a clientBaseAddress for the callback mechanism (the WCF service will call back your client to send back e.g. status messages) - so it needs some extra tweaks and it cannot really be bolted onto an existing service that works over wsHttpBinding - it needs to be done separately. But basically - it's still pretty much all the same thing....
Update: after reading up on the topic (it's not something I use very often), it does appear that duplex communication is indeed possible also using netTcpBinding, but only if you're self-hosting your service - IIS doesn't support duplex communication over netTcpBinding.
Creating a duplex service does still require extra steps and extra code - so you cannot really have a service that's both non-duplex using basicHttpBinding or wsHttpBinding and duplex at the same time. So it really doesn't make sense to have another endpoint in this example using the wsDualHttpBinding because that service either needs to be really duplex (then you can use wsDualHttpBinding and netTcpBinding) - or it's not duplex - then you can use basicHttpBinding, wsHttpBinding, netTcpBinding and a few more "exotic" bindings (like MSMQ, named pipes etc.)
I'm a newbie to WCF. So here's the thing : I have two systems, one running the wcf service and the other running the client.
I'm able to ping the IP of the service, and also able to see the link when I put it into my browser. (It shows me the service is up and running).
Howver, when I try to run wcftestclient from cmd, it gives me this error :
Error: Cannot obtain Metadata from http://172.16.70.125:8080/Service If this is a Windows (R) Communication Foundation service to which you have access, ...
I've been trying this all day, and its says the same thing.
Could someone please let me know what's wrong and how to fix this?
Thanks,
Thothathri
The WcfTestClient utility depends on the WSDL being available for the service. The WSDL is provided by the Metadata Exchange (or 'mex') endpoint. You are probably missing that endpoint. Look for something like this in your config, or add it if it is missing:
<service ... >
<endpoint ...(your usual endpoint for the service)... />
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
</service>
Has your service exposed a metadata endpoint? Only relevent portions of config included
<services>
<service behaviorConfiguration="metadataBehavior" name="MyService">
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="metadataBehavior">
<serviceMetadata httpGetEnabled="true" />
</behavior>
</serviceBehaviors>
</behaviors>
Do you have metadata exchange enabled on your service? Your service should provide a mex endpoint for metadata in order for WcfTestClient to work AFAIK.
MSDN: How to: Publish Metadata for a Service Using a Configuration File
I created a web service for which I am trying to provide 3 endpoints with different bindings.
1. basicHttpBinding,
2. wsHttpBinding,
3. webHttpBinding
When I make the service reference, I get only the endpoints with the basicHttpBinding and wsHttpBinding bindings created. I don't get webHttpBinding. What could possibly wrong.
Here's the structure of the serviceModel node in web.config.
<system.serviceModel>
<diagnostics>
<messageLogging logEntireMessage="true" logMessagesAtServiceLevel="true" logMessagesAtTransportLevel="true"/>
</diagnostics>
<services>
<service behaviorConfiguration="VersionTolerance.Service1Behavior" name="BookShop.BookShopService">
<endpoint address="sadha" binding="basicHttpBinding" contract="BookShop.IBookShopService" />
<endpoint address="ws" binding="wsHttpBinding" contract="BookShop.IBookShopService" >
</endpoint>
<endpoint address="web" binding="webHttpBinding" behaviorConfiguration="webHttpBehavior"
contract="BookShop.IBookShopService" />
<host>
<baseAddresses>
<add baseAddress="http://localhost:49654/" />
</baseAddresses>
</host>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="VersionTolerance.Service1Behavior">
<!-- To avoid disclosing metadata information, set the value below to false and remove the metadata endpoint above before deployment -->
<serviceMetadata httpGetEnabled="true"/>
<!-- To receive exception details in faults for debugging purposes, set the value below to true. Set to false before deployment to avoid disclosing exception information -->
<serviceDebug includeExceptionDetailInFaults="false"/>
</behavior>
</serviceBehaviors>
<endpointBehaviors>
<behavior name="webHttpBehavior">
<webHttp/>
</behavior>
</endpointBehaviors>
</behaviors>
There's nothing wrong - that's just the way it works!
basicHttpBinding and wsHttpBinding are SOAP bindings that expose metadata about their service - your Visual Studio Add Service Reference can interrogate their endpoints, find out what they're called, what methods they offer, what data types they expect as parameters and what they return.
webHttpBinding is REST - and REST by default doesn't have a concept of metadata - you won't get a service description, list of methods etc. - REST is all about resources - not methods.
So therefore, when you do a Add Service Reference, you get proxy clients for the SOAP endpoints - but not for the REST / webHttpBinding endpoint. Works as designed.
The WCF Data Services - built on top of REST - offer a similar experience to the SOAP bindings, in that you can do an Add Service Reference and get a nice client side proxy and all - and this is done since the OData protocol defines a metadata exchange on top of REST. So if you can turn your REST service into a WCF Data Service, you'd be fine again.
Otherwise, with REST, you just have to "know" (from a documentation page or something) what the resource URI's for your REST service are, and what the HTTP verbs do in your REST context.
I have a WCF service (in 3.0) which is running fine with wsHttpBinding. I want to add netTcpBinding binding also to the same service. But the challenge that I am facing is in adding behaviorConfiguration.
How should I modify the following code to enable the service for both the bindings? Please help…
<service name="Lijo.Samples.WeatherService"
behaviorConfiguration="WeatherServiceBehavior">
<host>
<baseAddresses>
<add baseAddress="http://localhost:8000/ServiceModelSamples/FreeServiceWorld"/>
<add baseAddress="net.tcp://localhost:8052/ServiceModelSamples/FreeServiceWorld"/>
<!-- added new baseaddress for TCP-->
</baseAddresses>
</host>
<endpoint address=""
binding="wsHttpBinding"
contract="Lijo.Samples.IWeather" />
<endpoint address=""
binding="netTcpBinding"
contract="Lijo.Samples.IWeather" />
<!-- added new end point-->
<endpoint address="mex"
binding="mexHttpBinding"
contract="IMetadataExchange" />
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="WeatherServiceBehavior">
<serviceMetadata httpGetEnabled="true"/>
<serviceDebug includeExceptionDetailInFaults="False"/>
</behavior>
</serviceBehaviors>
</behaviors>
Please see the following to see further details
WCF using windows service
Thanks
Lijo
I don't completely understand what your problem or issue is - from what I'm understanding, you're unsure how to apply service behaviors?
Two things you need to consider:
a service behavior can be applied to the entire <service> tag - so these things like metadata support etc. will affect the service per se - regardless of which endpoint you connect to
an endpoint behavior can be applied to an endpoint, so that will affect only those endpoints that this behavior is applied to (and not others)
So in your case, the WeatherServiceBehavior will be applied to the service and thus affect all endpoints (e.g. no matter which endpoint your client connects to, it will have metadata support and debug details turned off).
So again: what exactly is your issue? Where are you "blocked" or what are you trying to do that doesn't work??
You should specify the address of the net tcp endpoint, at the endpoint level, not as a base address.
Also test if first with just nettcp binding to make sure that that works, before you try to configure for both.