I am new to .net and am trying to use c# as the basis of my .net learning. I have a project where I need a service to connect to mutliple tcpip applications that are a 3rd party application written in vb6. Someone has mentioned using WCF as the base, but i'm not sure how it would make an outbound connection (instead of receiving incoming ones) to a non .net application? Please help
With C# and WCF, you can either create:
a WCF service which will offer up some functionality that other applications can call
or:
a client that connects to some other SOAP or REST service to consume functionality.
So which one is it you're looking for??
Also: WCF is a SOAP or REST based service stack - you cannot use it to connect to low-level TCP calls (socket programming). Your "other" side must understand either SOAP (the web service protocol) or REST (the URL-based lightweight protocol). If you other sides don't speak neither SOAP nor REST, you're out of luck and can't really use WCF for that.
You'll have to deal with socket programming, WCF won't help you here.
Try reading this: http://www.codeproject.com/KB/IP/socketsincsharp.aspx
Related
I am starting a new webservice project which will be consumed by multiple consumer applications done in different technology like ASP, ASP.Net and PHP. I am planning to develop this service as a WCF service. I am new to WCF and I understand WCF is like umbrella tech which has all the features for developing a distributed SOA applications.
I would like to get your advice on whether my choice of opting WCF service over classic asmx service is correct. The consumer applications are existing application done different technologies as I said before. This service is a simple service that creates and updates user information in a centralized DB.
If my decision of choosing WCF is correct, then please let me know if there are any specific things I need to consider so that the existing application can consume my WCF service without any hiccups. In other words, I can provide a asmx service for this which they can consume directly without any issues (and currently they are consuming some of our asmx service. Since the current requirement is new I want it to be done with WCF). Likewise, the consumer should be able to consume my service like they consume asmx service.
I am asking this question because WCF provides additional features like security, etc. and hence the consumers should also follow the practice to communicate with the service.
Any advice is highly appreciated.
You probably want to use BasicHttpBinding in your WCF service and, although I'm not a PHP developer, I understand that PHP 5 has a SOAP library that can be used to create a service proxy based on the WSDL document exposed by the WCF service, assuming metadata exchange is enabled.
Could you please tell what is the difference between a WCF client and a non-WCF client?
When I generate proxy of a WCF service using svcutil and put that in client, what is created - wcf client or non-wcf client?
When should I use WCF client and non-WCF Client?
If you have a WCF service, its services are available to potentially several types of clients - both .NET applications using WCF themselves, or other apps.
Basically, any WCF binding that start with net.... is a .NET specific binding - only other .NET apps with WCF can connect to those services and call their methods.
The bindings with basic.... or ws...... typically are interoperable, e.g. using only industry standards like SOAP and WS-* standards - those can be called from Java, Ruby, PHP - you name it. Any language/system with a SOAP stack can call such a service (provided you get the configuration right on both ends)
The webHttpBinding is another special case - it's exposing it's services over REST - which means anything with a HTTP stack (pretty much every computer system and more and more phones and devices, too) can call its methods.
As long as you are programming your stuff in .NET, always use the WCF client - it's the easiest and the best if it's available. If you need to call your WCF service from a PHP client, of course, then you have to use PHP technology and something that's compatible between the two worlds....
I have a web service that is used by many different clients using many different languages.
I want to switch it to wcf to take advantage of the many different endpoints.
However what has been stopping me is that I am afraid that the clients will have to use a special sdk to connect (if they are using java or php or some other language) that is different then the sdk they use to connect to the existing web service.
Is this true? Or is connecting to WCF the exact same as it is for web services in other languages.
The project I am currently working on has multiple WCF configurations, some are using the default SOAP implementation, and some are using a POX (plain-old-xml) style message.
So the short answer is 'yes' you can configure WCF in such a way to work with just about anything.
However, be warned that as soon as you step outside the default little box that WCF has set up for you, it gets pretty complicated. You end up with a lot of custom message parsing and security handling if you go to a POX message format. Its easier if you stick with SOAP though.
As for needing a 'special SDK' you won't. You can communicate with WCF with simple HTTP POST messages if needed.
I have clients that are using VB.NET apps (using SOAP) and Java apps (using POX) to hit my WCF services.
A basicHttpBinding endpoint in WCF is exactly a standard SOAP endpoint, and your Java or PHP clients will not have to change in any way.
I am learning WCF,one of the benefits of WCF is that you can use WCF even the client and service are not in the same network.Can anyone explain why?
Why using normal asp.net services, .NET remoting or Windows enterprise service client and service have to be in the same network?
Another question is that does the client needs to have a service contract interface and data contract? I assume not ,but how the client understand the type returned from the WCF services?
Edit: Reflecting More comments
A primer on WCF (such as What Is Windows Communication Foundation?) is a good place to start. WCF can use SOAP to implement the contracts way down deep. WCF also uses a variety of communication facilities within windows (and any custom ones you want to create) so talking across machines is built in.
The very essence of contract (IMO) implies that this is present on both sides of the communication. In a pure .net cases I've usually put the contract definitions in separate assemblies and share them. In other places I've used WSDL to be the main contract definition so that the client and service share definitions.
Edit: Answering comments
You can knock up simple examples of communication in WCF easilyy (provided you know the basics of comms on windows including firewalls etc). However doing something custom is not easy but there are many many resources on the web and books to help you get there.
The books i used:
http://www.amazon.com/Programming-WCF-Services-Juval-Lowy/dp/0596526997
http://www.amazon.com/Essential-Windows-Communication-Foundation-WCF/dp/0321440064/ref=pd_bxgy_b_img_c
http://www.amazon.com/Inside-Windows-Communication-Foundation-Developer/dp/0735623066/ref=sr_1_1?ie=UTF8&s=books&qid=1252111759&sr=1-1
Another question on SO with a set of resources is "WCF for the Totally Clueless"
I don't know where you read that a benefit of WCF is that it allows the client and server to be on different networks. They can already be on different networks using .NET Remoting or DCOM (Enterprise Services).
The client does need to know the service contract and any other contracts required in order to use the service. This can be provided through WSDL or the Metadata Exchange Protocol (mex). If using .NET on both sides, then it is possible to share the contract assemblies, but this introduces a coupling between client and service.
Previous Microsoft technologies were designed for some specific needs in particular environment. For example ASMX Web Services were designed to send and receive messages using SOAP over Http only. .NET Remoting specific to Microsoft environment, no interoperability. But WCF is designed to send and receive messages using any format (SOAP as default) over any transport protocol i.e. HTTP, TCP, NamedPipes, MSMQ etc.
And your second question "but how the client understand the type returned from the WCF services?"
Its through proxy, client interacts with proxy which contains all the types etc.
You can find a good concepts and questions here for understanding WCF core concepts.
I am learning wcf but I have trouble understanding the benefits. Is there ever a time I would want to use traditional web services?
I read another thread with these benefits:
Opt in model for members using a certain attribute
Better security
No need to worry about binding (can't understand how this is true)
No need to worry about the xml
I read Programming WCF Services however this was an advanced book a bit like CLR via C#. I am now reading Learning WCF Services and will read Essential WCF (is recommended).
What would happen if I use a normal class to try to talk to a web/service reference? I know this sounds really naive, it's just my lack of experience in web services.
I am coding some WCF services so I am getting exposed to the specifics. They are interacting with a SOAP web service provided by my web host so I can get stats on my site. Is there anything wrong in this approach?
Thanks
WCF is a unified programming model for developing connected systems. What this means is that you use a single framework to develop service-oriented solutions. WCF allows you to keep your service implementation relatively unaware and care free of what's going on under the covers as far as how your service is consumed by clients and communication is handled. This allows you to take your service implementation and expose it in various ways by configuring it differently without touching your service implementation. This is the unified part. Without WCF, you have to get familiar with a framework specific for a particular communication technology such as ASP.NET asmx web service, .NET remoting, MSMQ etc and usually those frameworks impose on your service implementation and creep in such as using WebMethod attribute or having to derive from MarshallByRefObject object etc and you just can not take your service implementation and easily expose it over another communication stack. If I have a service that adds two numbers, why can it not be exposed over http or tcp easily without having to worry about low level details? This is the question in your post regarding binding. Binding allows you take a service and configure it so that it can be exposed over different transports and protocols using different encodings without ever touching your service implementation.
Is there ever a time I would want to use traditional web service?
Web service uses well defined, accepted, and used standards such as HTTP and SOAP. So if you want your service to be consumed by wide range of clients, then you would want to expose your service as a web service. WCF comes with pre-configured bindings out of the box that allows your service to be exposed as a web service easily: basicHttpBinding and wsHttpBinding. You may also want to consider RESTful services which is an architectural style that fits more natural with the HTTP model. WCF supports RESTful services as well
What would happen if I use a normal
class to try to talk to a web/service
reference? I know this sounds really
naive, it's just my lack of experience
in web services.
WCF service can expose the wsdl for a service just like ASP.NET asmx web service does. You can generate a client side proxy by simply adding a service reference to your client project. There is also a command line tool called svcutil that also generates the client side code that allows you to easily communicate with the service. The client side service class basically mirrors the service interface. You create an instance of the client side proxy for the service and then simply call methods on it just like any other .NET object. Under the covers, your method call will get converted to a message and sent over the wire to the server. On the server side, that message will get dispatched to the appropriate service method.
I hope this helps a bit.There are lots of online content such as videos on MSDN and channel 9 that you check out. The more you pound on it and expose yourself to it, the clearer WCF will get I am sure. Also, WCF is THE framework Microsoft recommends to develop connected system in .NET. The other technologies ASP.NET asmx, WSE, and .NET Remoting will most likely still be available going forward but may not be supported and developed further.
There are a number of existing approaches to building distributed applications. These include Web services, .NET Remoting, Message Queuing and COM Services. Windows Communication Foundation unifies these into a single framework for building and consuming services.
Here is a link from MSDN Why Use Windows Communication Foundation?
WCF is really the "new" standard and new generation of web service - and even more generally, communications - protocols and libraries for the .NET world.
Whenever you feel the need to have two systems talk to one another - think WCF. Whether that'll be behind the corporate firewall in your company LAN, whether it's across the internet, by means of a direct call or a delayed message queueing system - WCF is your answer. Mehmet has written a really nice summary of how WCF is the unification of a great many communication standards that existed in the Microsoft world before WCF.
I would think with the "Learning WCF" book, you should be a lot better off than with Programming WCF - that's quite advanced stuff already!
One of the mainstays of WCF is the architecture that you always talk to your service through a proxy - whether that service runs on the same machine using NetNamedPipe binding or halfway around the world in Down Under on a server - no difference, you always go through a proxy. That then also allows WCF to be so extensible - thanks to the proxy always being between the client (your application) and the service, it offers excellent ways of extending the behavior and the inner workings of WCF to your liking and needs.
WCF basically builds on SOAP communications - so interfacing and using existing SOAP services should be no problem at all. With the WCF REST Starter Kit and in the upcoming .NET 4.0 release cycle, WCF will also extend its reach into the REST style web communications, if that's ever going to be a requirement of yours.
All this really shows one of the biggest strenghts of WCF: it's a unified and extremely flexible and extensible communication framework, that can handle just about anything you throw at it. That alone is more than enough reason to learn WCF (which can be dauting at first, I agree!), and you won't regret the effort you put into this endeavor.
Marc
Have you a specific application you are writing for, or just getting your feet wet?
Google protocol buffers, is a very good choice of communications. John Skeet & Marc Gravell have both done C# implementations. See here