Does client consuming WCF service require Interface definition?

I have been going through the book "Learning WCF" trying to get my head around creating and using WCF web services. The first part of the book walks the reader through creating and then consuming a simple "Hello World" web service.

The problem I am having is that the client application seems to have no know the structure of the WCF Interface when calling it. How can this be necessary if a web service could be called from any number of programming languages?

I have listed the relevant example code below ...

Here is the code for the Interface

 [ServiceContract(Namespace="http: //www.thatindigogirl.com/samples/2006/06")]
 public interface IHelloIndigoService
 {
  [OperationContract]
  string HelloIndigo();
 }

Here is the code for the Service that hosts the web service

static void Main(string[] args)
{
  using (ServiceHost host = new ServiceHost(typeof(HelloIndigo.HelloIndigoService) ,
    new Uri("http: //localhost: 8000/HelloIndigo")))
  {
    host. AddServiceEndpoint(typeof(HelloIndigo. IHelloIndigoService) ,
      new BasicHttpBinding(), "HelloIndigoService");
    host. Open( );
    Console. WriteLine("Press <ENTER> to terminate the service host") ;
    Console. ReadLine();
  }
}

Here is the code for the client app that consumes the WCF service This is where I get confused. Since this client application could be any language capable of calling a web service why is there a necessity of knowing the definition of the interface?

using System. ServiceModel;
[ServiceContract(Namespace = "http: //www.thatindigogirl.com/samples/2006/06")]
public interface IHelloIndigoService
{
  [OperationContract]
  string HelloIndigo( );
}

static void Main(string[ ] args)
{
 EndpointAddress ep = new
   EndpointAddress("http: //localhost: 8000/HelloIndigo/HelloIndigoService") ;
 IHelloIndigoService proxy = ChannelFactory<IHelloIndigoService>.
   CreateChannel(new BasicHttpBinding(), ep);

 string s = proxy. HelloIndigo();
 Console. WriteLine(s) ;
 Console. WriteLine("Press <ENTER> to terminate Client.") ;
 Console. ReadLine();
}

Am I missing an important point here? Perhaps my understanding of what is needed to consume a web is lacking. My goal is to be able to use WCF to create a .NET service that could be called from any programming language or environment.

Might anyone suggest a good tutorial on creating "cr开发者_StackOverflowoss platform consumable" web services from within .NET? Thanks!

This approach is based on shared interface (the book acutally does not share the interface but instead it uses local copy) and is successfully applied in environment where both client and server are written in .NET. This approach is not usable for interoperability or SOA solutions.

Other approach uses metadata exposed by the service. Metadata are defined as WSDL document plus several XSD documents. These metadata files are way to provide information about your service to both .NET and non .NET developers. The book contains definition of Metadata (mex) endpoint so you will definitely read about that.

Using metadata in .NET means creating service proxy. You can do it automatically using Visual studio's Add service reference or command line utility svcutil.exe. Anyway generated proxy code will probably still contain the interface created from metadata. It is used to create transparent abstraction of the service for the client.

'The interface' doesn't mean a .NET interface file, it means the more general programming interface - a set of objects with properties, and methods with parameters. This is also called the service contract.

The reason that the client and the service need to share (i.e. both know about) the interface is simple when you think about it - if the client doesn't know the interface, how do they know what operations are available and what the expected request/response objects should look like?

Every WCF service is composed of

• A - address
• B - binding
• C - contract

The contract is declared using an interface on the serverside. It declares which methods are available to the client. If you are using a http binding you can invoke a service operation by issuing a http request (using a http client in any library or language - or even a web browser) pointed at the correct address. So the client does not need any interface reference at all. It just needs to follow the ABC of the service.

Here is a nice blog on WCF and Java interopability.

To answer your question on how to develop 'cross platform consumable' web services, consider the REST approach. Making REST-style web services truly makes them independent of the platform that consumes them. Simply put, they use the already well established HTTP protocols everything supports: GET and POST Http methods.

You could then have a Java app simply make POST calls to your WCF services with your own custom XML content in the payload without having to fiddle with more complex stuff like making SOAP wrappers and the like. Check out Rob Bagby's article on REST:

http://www.robbagby.com/rest/rest-in-wcf-part-i-rest-overview/