What is the importance of this setting httpGetEnabled="false" or httpGetEnabled="true" what will happen if we set httpGetEnabled="false"
suppose if I want any .Net 2.0 client can consume my wcf service which has been developed by .Net 4.0 then how should i develop the wcf service. once i read that if any client need to consume my wcf service then we need to set httpGetEnabled="true" as a result they can consume ny wcf service through wsdl. things was not ver clear so if possible please in more details how wcf service expose through wsdl.
In wcf mex is also there to expose meta data. So I like to know what is the difference between mex & wsdl?
What mex offer more than wsdl? people said mex is configurable but wsdl is not...What does it mean? need details.
If we search Google to see how wsdl envelope looks like then we get ample of link but I found none for how mex envelope look like searching Google. so please help me to visualize how mex meta data structure look like.
If we remove mex endpoint from service config then how other client can consume my service?
other client can consume my service then through wsdl if yes then how ?
what url I need to enter to have the wsdl of any wcf service ? if `httpGetEnabled="false then wsdl will be possible or not.
Here I asked couple of quetion on mex & wsdl. I am new so bit confused about mex & wsdl usage in wcf.
another question is that what is the usage of soap in wcf & relation.
Invoking the service is totally different than exposing metadata. Basically, a service doesn't have to expose metadata (mex or wsdl) to be called by clients.
Metadata are just exposed to allow easier proxy class generation. This allow developpers to 'Add a service referencee' in VS. WCF provides another way to generate a proxy class : using wsdl.exe with a physical wsdl file.
You can also redistribute your service contract through assemblies and use ChannelFactory.
Exposing metadata is useful on dev, because it allows developpers to re-generate proxy class easily after each modification on the contract (Update Service Reference). On Stage/Prod, it depends on your context : it is generally disabled to "hide" service contract.
About wsdl versus mex, there is another recent answer for this.
If we remove mex endpoint from service config then how other client can consume my service? other client can consume my service then through wsdl if yes then how ?
Your clients can invoke your service only if the have a generated proxy class or your service definition. As I said, they can generate this class using metadata when they want or use a physical wsdl file that you have previously sent.
what url I need to enter to have the wsdl of any wcf service ? if `httpGetEnabled="false then wsdl will be possible or not.
HttpGetEnable allow you to expose metadata through HTTP GET method, usually the service’s address with the suffix of ‘?wsdl'. Simply browse the service url and wcf will generate an help page for you.
Related
I'm struggling to find a Layman's definition of the difference between an Application Endpoint and an Infrastructure Endpoint in WCF
MSDN defines the distinction as follows:
application endpoint
An endpoint exposed by the application and that corresponds to a service contract implemented by the application.
infrastructure endpoint
An endpoint that is exposed by the infrastructure to facilitate functionality that is needed or provided by the service that does not relate to a service contract. For example, a service might have an infrastructure endpoint that provides metadata information.
Would an example of the latter be an endpoint that informed a client endpoint how to handle paticular kinds of Bindings? Please could someone provide a less abstract scenario?
An Infrastructure Endpoint says things about the service. E.g. something that implements IMetaDataExchange.
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.
Where as an Application Endpoint does something, e.g what you annotate in WCF with Operation Contract.
if i know the service url then i can click on add reference and add the service url to create proxy at client side to consume it but without creating proxy at client side we can consume and call service with the help of ChannelFactory.
so i like to know when people will go to use ChannelFactory to create proxy at runtime and what is the advantage?
if i want that if other people know my service url then also they will not be able to add my service as add service reference....how to enable this feature? i want other people will not be able to create proxy at their end if they know my service url....is it possible. i want that people always has to call ny service using ChannelFactory. please discuss this issue in details. thanks
If you have any clients who are not .NET (like Java or PHP, for example), ChannelFactory won't work for them as that is specific to .NET and WCF. In that case, you'll either have to publish the metadata or send the client a WSDL so they can create the proxy via whatever means their language of choice uses (I don't know much about Java, PHP, etc so I can't say much more than that definitively).
As for using ChannelFactory, I assume you're talking about ChannelFactory<T>, as ChannelFactory itself is an abstract class and can't be instantiated. Using the channel factory gives a greater degree of control (as others have indicated) - for ChannelFactory<T> the client will need the service contract (interface, not the implementation), so either using a common assembly shared by everyone or providing the interface to the clients are the two easiest ways to achieve this.
You can disable publishing metadata (the WSDL) by turning httpGetEnabled to "false" in your config file in the <serviceMetadata> tag:
<system.serviceModel>
<behaviors>
<serviceBehavior>
<behavior name="MyServiceBehavior">
<serviceMetadata httpGetEnabled="false" />
</behavior>
</serviceBehavior>
</behaviors>
</system.serviceModel>
You would then reference this behavior by setting the endpoint element's behaviorConfiguration attribute to "MyServiceBehavior".
You should also remove any mex endpoints as (based on my understanding) that's a newer way for web services to expose their metadata. If the metadata is not exposed, then clients cannot construct the proxy via the WSDL and will have to do so by some other method. .NET clients specifically will not be able to use Add Service Reference.
Finally, if you're concerned about access to your service, you should really implement some sort of authentication scheme. If you just simply want to disable publishing (exposing) metadata then setting httpGetEnabled to false and removing any mex endpoints should do the trick.
I've used the ChannelFactory instead of the autogenerated proxies to use the same object model on the server side and on the client.
Also here Sharing Interfaces Between a WCF Service and Client (marked w/ ServiceContract) some problems with autogenerated proxies are discussed.
As for the hiding metadata, the answer is probably here How to hide wsdl information on WCF?
I usually create two assemblies, one with the service metadata (Interfaces [service contracts] and data objects [datacontracts]) and one with the actual service implementation.
Usually i self-host wcf services and skips the DataExchange endpoint-service needed for clients that dont have the meta data (to create proxy's). Clients receive my meta data dll and write their own proxies or uses a custom library together with the metadata dll to create a proxy. Both approaches uses the channelfactory to create the proxy.
If a service is used in a LAN environment I typically setup a discovery service so that clients can find the service url(s) for a specific service interface (custom library code).
Maybe Im just old-school but I like to have control over the process. Versioning concerns etcetera. Another reason, when there is more than one way to use a technology, I focus on the one that can learn me the most about it.
Maybe you should use IIS and service pages (SVC) and auto-proxy creation in Visual Studio if you want to quickly test a service or isn't comfortable with the WCF programming model. Use Channelfactory if you write your own service libraries and need more fine-grained communication control (common service discovery strategy, common configurations/common binding settings, common security settings, hooking into events in the communication stack to run custom code, etcetera).
Why serviceBehavior part is not generated on client side automatically after ServiceReference tool in Visual Studio as endpointBehavior?
Wsdl.exe or "Add Service Reference..." generate proxy classes, datacontracts & config based upon exposed metadata. Commons ways to expose metadata is by using a mex endpoint or exposing a wsdl.
Basically, Behaviors are simply not exposed. That's why you can't generate the same endpoint behaviors on client side.
What is important here, is that many behaviors are "local settings only" (for a service OR for a client ). It does not tell to clients how to call the service, but how the service should run.
I want to architecture our software so that we can expose our API logic using WCF (SOAP and REST).
Im confused as to whether I have to use ASMX files if I want to do SOAP services, or whether .svc file can still do SOAP service?
Yes you can. You have to expose a SOAP end-point for your WCF service. This MSDN post has an example.
Your svc file can provide the restful interface you are requesting. You just have to do a little configuring within your web configuration file, and decorate the svc class with the attributes to describe the behavior of our restful url.
here is a great article going over the steps:
http://www.dotnetfunda.com/articles/show/779/simple-5-steps-to-expose-wcf-services-using-rest-style
With a reference to my previous question, I would like to know how would I extract information of a WCF service from a client application to know what methods/types are exposed if the service exposes only one endpoint that uses webHttpBinding?
Just to summarize, in my previous question, I came to know that an endpoint using webHttpBinding does not get exposed in the generated WSDL because it would be a JSON endpoint and is just not compatible.
WebHttpBinding is a REST-based binding - REST does not expose metadata like WSDL/XSD contrary to SOAP.
There's no way to extract the metadata from a REST endpoint at this time. There are some efforts under way to establish a similar construct for REST called WADL (Web Application Description Language) - but that's nowhere near standardized yet.
For now, with REST endpoints, you have to either figure it out yourself, or you need to have some documentation provided by the service provider on e.g. a static HTML page or something.
.NET 4 does provide some level of an automatically generated help page - see this blog post or the MSDN docs for more info. But it's still nowhere near as formalized and machine-interpretable as WSDL/XSD.
I wonder why the REST samples tell you to expose a MEX endpoint at all. It is not needed and here is how to cleanly remove it:
Remove MEX endpoint from the service section of the config file.
Remove service metadata enabled line in the service behaviour section of the config file.
Edit the Visual Studio project (assuming it's a WCF service library) and remove the line:
<StartArguments>/client:"WcfTestClient.exe"</StartArguments>
If you have other non-rest services you will want to leave the last 2 parts present. You must remove the WCF Client when disabling MEX otherwise it will complain during debugging if it cannot enumerate any services in the project (regardless whether they have any useful metadata or not).