Is there any possibility as a client to get a list of contracts a WCF host exposes?
I would like to query a service and to ask what interfaces it implements.
Take a look at WCF Discovery.
This is not supported by WCF.
You can query the service's WSDL contract, but not the WCF contracts or any Interfaces.
The best you will be able to do is to see what is exposed, and assume that is the interface. You will not be able to see all the different interfaces that the class implements. For example, if you had a service which implemented IFooService, and IDisposable, with IFooService exposed through WCF, you would be able to see all the methods of IFooService from the client.
The WCF Test utility will take a given wsdl and generate a client for it, looking at the source for that might be a good starting point. (you'll have to decompile it with something like reflector)
Another idea, You could programatically invoke svcutil to generate a client for a given wsdl, then invoke msbuild to compile it, and use reflection to load the output assembly. It would be a fairly large amount of work, and I'm not sure what you would do with it. You would have to build a fairly complex UI to inspect and invoke the client.
In general (web) services are being described by XML-based protocols such as WSDL. This is used both for discovery of the services and for describing their operations. Also UDDI is sometimes used but mostly for Enterprise Application Integration (internal use).
So you can have your WCF service produce WSDL information and let your client query that.
Related
I am going to write a WCF service and need help in structuring the project for the below scenario:
Client and Service are going to share data contracts assembly-> http://code-magazine.com/Article.aspx?quickid=0809101
WCF is in turn gonna call multiple services to populate data contract using Automapper.
What are the best practices to structure a WCF project? and how to best wire-up automapper in the middle of WCF project?
I like to structure my WCF solutions like this:
Contracts (class library)
Contains all the service, operations, fault, and data contracts. Can be shared between server and client in a pure .NET-to-.NET scenario
Service implementation (class library)
Contains the code to implement the services, and any support/helper methods needed to achieve this. Nothing else.
Service host(s) (optional - can be Winforms, Console App, NT Service)
Contains service host(s) for debugging/testing, or possibly also for production.
This basically gives me the server-side of things.
On the client side:
Client proxies (class library)
I like to package my client proxies into a separate class library, so that they can be reused by multiple actual client apps. This can be done using svcutil or "Add Service Reference" and manually tweaking the resulting horrible app.config's, or by doing manual implementation of client proxies (when sharing the contracts assembly) using ClientBase<T> or ChannelFactory<T> constructs.
1-n actual clients (any type of app)
Will typically only reference the client proxies assembly, or maybe the contracts assembly, too, if it's being shared. This can be ASP.NET, WPF, Winforms, console app, other services - you name it.
That way; I have a nice and clean layout, I use it consistently over and over again, and I really think this has made my code cleaner and easier to maintain.
This was inspired by Miguel Castro's Extreme WCF screen cast on DotNet Rocks TV with Carl Franklin - highly recommended screen cast !
Could anyone please tell me whether it's possible to reverse engineer (generate interfaces and services) from WSDL.
The reason being, we would like to generate exactly same industry stanadard WSDL.
Any tool to achieve above will be appreciated.
If you mean you want to be able to take a WSDL and run it through some tool to generate a complete service (including the interfaces and the implementation of those interfaces), I don't think there is one.
If you want to generate a proxy to use with a service from its WSDL, you can use the SVCUTIL.EXE tool - ServiceModel Metadata Utility Tool (Svcutil.exe).
I have a WCF deployed on IIS. Now by adding web reference of it i am using it on my app.
So I have two questions:
Is it the best method of consuming WCF.
If the answer of first question is yes then what is the role of svcutil.exc, I mean what is the use of creating wcf proxy class. and if the answer is "No" then why?
It is the easiest solution if you develop with visual studio and have access the remote WCF service.
If you are developing using another IDE, you might want to use SvcUtil to generate your proxies.
If you prefer to have a simple CS file containing the generated client, you might also choose to generate it using SvcUtil.
You may also completely ignore SvcUtil and the Service Reference wizard and use the ChannelFactory class to generate proxies dynamically.
You should use "Add Service Reference" in Visual Studio (not Add Web Reference) for WCF.
It is the easiest way - since you can do it right in Visual Studio. What it does under the covers is basically call svcutil.exe (or you can do that manually, from the command line yourself), and create a service proxy class for use on the client side.
The use of svcutil.exe is many fold - you can create a client proxy class from a running service (or from an existing WSDL/XSD file), you can verify services, you can export metadata from a service for clients to consume, and a great many more options. It's the "Swiss Army Knife" of WCF tools.
WCF uses a concept that all calls to your service must go through a client proxy - this is the place where the entire WCF runtime lives, and where all the WCF extensibility points are located. This proxy converts your call to a method on the client into a serialized message that gets sent across the network to the server for processing, and it also handles "unpacking" the response from the call back into classes and objects on your client side for your use.
Adding a service reference is the quickest and easiest way but not always the best way. If you want performance then using ChannelFactory<T> is the way to go. You should know different ways to create a client side proxy and customisations that you can do.
An excellent resource is WcfGuidanceForWpf. Don't let the WPF in it scare you as it is really an excellent guidance for general WCF as well.
I have two related questions about Web services:
(1) I'm currently writing a set of applications, and it occurred to me that maybe I'm not using the right tool for the job. Here is the spec:
There are many Windows servers behind different VPNs and firewalls.
Each of the servers has a Windows service running, that reports various information about it to a centralized server, via a Web service, both of which I've written, and have access to.
So I'm both the producer and the consumer, and I'm staying on the same platform (.NET). Maybe a web service isn't the way to go? I'm using one purely because it's easy to write and deploy, and I'm the most comfortable with them. Should I really be using WCF for this?
(2) In the web service, I'm creating a State object to represent the state of the server, and sending it as a parameter. However, adding a service reference creates a proxy of the State class. It seems gacky to copy the properties of the State object to the proxy, and then send the proxy. Should I just replace the proxy class with the real class in the auto-generated code (i.e., include a reference to the State class instead)?
By "web services" I assume you mean an ASMX? I would go with WCF is possible, simply because you lose nothing but gain lots of flexibility. You could, for example, switch from XML-over-HTTP to Binary-over-TCP through a simple config change.
I would suggest to use WCF and use the Net.Tcp binding. It should be efficient enough for 300 clients. For the proxy class issue use the /reference option for the svcutil tool when you generate the proxy. This will allow you to share classes between server and client. I would not use this option if interoperability was a concern but since you stated that you develop both the clietn and the service and all in .Net it is a valid use in your case.
Your distinction between "Web Services" and WCF is a false distinction.
ASMX Web Services is the original .NET SOAP Web Service technology, introduced in .NET 1.0. It has been replaced by WCF, which can everything that ASMX can do, plus a whole lot more (including support for the WS-* standards).
Microsoft now considers ASMX Web Services, and the XML Serializer they're based on, to be "legacy technology". See "Microsoft says: ASMX Web Services are a “Legacy Technology”".
With WCF, since you have control of both sides of the operation, and can share the .dll in which the service contract is defined, you can and perhaps should be using ChannelFactory<IYourServiceContractHere> instead of auto-generating those ugly proxy classes with service references.
Here's the first hit I found on this topic: http://blogs.msdn.com/juveriak/archive/2008/02/03/using-channels-vs-proxies-in-wcf.aspx
If it is platform independent, I would certainly recommend WCF.
I've done exactly what your describing to great effect across more than 300 locations. I don't think you made the wrong call.
Another thing you could consider that would work well is using MSMQ. In this case, however, you'll either need to write event triggers (COM) or an event queue processing service.
I use the term network services to refer to things such as NNTP, IMAP, POP3... things which have a defined protocol layered on top of TCP/IP.
I'm having a very difficult time figuring out how I can connect to an existing network service using a WCF client. I haven't found any examples other than ones that are basically using C#-ified socket code.
Can anyone refer me to any examples of using WCF to talk to a legacy service as something other than a glorified socket?
Is WCF even appropriate for this type of requirement?
Thanks.
WCF comes with a set of standard bindings, here is a list of the bindings provided in 3.5:
http://msdn.microsoft.com/en-us/library/ms730879.aspx
If you need to use anything else, WCF is probably not the way to go. Even if you could build your own binding, the cost would outweigh the benefit.
If you have a requirement in your project that everything should use WCF, you could build a WCF facade over your sockets code.
Well, the term "WCF" actually means 2 things:
The framework: "ABC" - Address, binding, contract
Actual use of a combination of the above (for example, a WCF webservice using BasicHttpBinding)
There's not built in bindings for the protocols you mentioned, which is why the examples you'll see looks like "glorified sockets" - That's what they are. That's what a binding is: A level of abstraction built on a basic protocol (typically UDP/IP or TCP/IP).
Now, with all this being said, you need to build / borrow / steal / whatever a binding that is usable with your protocol of choice. This might look like you're just injecting sockets into the WCF framework, and honestly, that's just what it is :)... So what's so great about it?
If you managed to implement your binding to-the-specs, you got yourself a very easily substituted component, which will fit into all WCF applications. Whether you want this behaviour or not, is up to you and your requirements :)
Good luck with it.
Well, WCF at its heart is the unified communication engine offering by Microsoft, based on SOAP - it replaces ASMX web services, WSE, .NET Remoting and more.
As such, it's SOAP based and therefore can talk to anything that talks SOAP - which I doubt is the case for POP3 or other services. So I don't think you can write a WCF client for these services, really.
As for writing these services from scratch and exposing them as WCF services - that might work, since basically the WCF service implementation can do anything, and then present itself to the outside world as a SOAP service - could work, question is: what's the benefit?
Marc