“反向”WCF服务（从客户端定义构建服务器）

Question

.Net provides some wonderful mechanisms for defining a remote service and then "automagically" creating a client to connect to it, hiding away much of the nasty wiring and fuss. But is there a similar route for going the other way?

My most recent task at work is to create a series of services that will communicate with one another for things like authentication and search queries. One requirement is the ability for our core service to call out to other "service nodes", which may or may not be created in house but all need to implement a common interface. I can build a reference implementation of this service, create the WSDL from that, and automatically generate the client side without issue. It seems that the only way to define the service, however, is to basically point someone at the WSDL I create and say "Implement something that looks like that." Seeing as how WSDLs are rarely designed to be read by human beings, this route seems less than attractive.

So is there a way that I'm not aware of to generate a service interface from a WSDL or similar descriptor? Primarily looking at .NET 3.5 here, using C# and WCF. Thanks!

Answer 1

是的 ，您绝对可以从WSDL文件创建WCF服务合同（接口）：使用svcutil.exe 。

Answer 2

If you have a WSDL which describes the methods your client wants to call, plus a XSD (XML Schema) which describes what data elements it will expect to send and receive, you have all it takes to create a service from it. This is called the "Contract First" approach to building WCF services and is fairly popular especially in environments with interoperability requirements (like Java client and .NET services or vice-versa).

Using svcutil.exe , you can generate a service interface class - your service description. This will contain service contract, operation contracts, and data contracts.

svcutil yourMethods.wsdl yourDataSchema.xsd /language:C# /out:YourServiceInterface.cs
(or /language:VB, if you prefer VB.NET)

This will create a YourServiceInterface.cs (or YourServiceInterface.vb ) file, which is the basis for your server code.

From this, you can then create an actual service implementation - your service class that does the real work.

And last but not least, you'll need to decide how to host your service - in IIS or self-hosted in a console app or an NT service or some other means.

Marc