I hear that WCF is the new standard for communication across the network and applications in .net. The idea seems to make sense as well, provide standard interfaces for programs to communicate.
Here is my situation, I have a .net app i want to communicate to a ruby application though pipes. On the .net side (server) I would like to use WCF while the ruby side (client) will be chewing gum and duct tape.
I assume both ends don't need to be WCF but what will be involved in making this work. Is there a standard protocol WCF expects incoming requests?
Using the named pipes binding for non WCF clients could be possible, but it wouldn't be easy. You'd need to send the messages in the correct format for WCF to consume.
See this first or last entry on WCF message framing for a hint at the complexity. It's not impossible, but is it worth the effort?
Recommended is the http transport + some type of text or markup encoding, like basicHttpBinding or webHttpBinding.
Depends on your bindings, you can make your WCF a webHttp binding and make it restful (easiest) and you just do gets and posts. Other bindings you will have to use SOAP headers and such to communicate with your WCF, I have not done this myself, but im sure theres info out there on how to do it for non .net applications.
You'll want to keep your contract as simple as possible (in terms of what types you expose). Though I have not tried this myself, I know that this type of functionality is supported (.Net to Java is a common usage) and relatively easy to do.
You don't mention which side (.Net or Ruby) will be the server, but I would expect that this will be much easier to do if you host the service in WCF and consume it from ruby. Going the other way around may be a bit more of a pain because mucking with the internals of WCF can be a bit of a pain.
What sort of "pipes" are you referring to? You cannot use the named pipes bindings with any code that's not .NET.
You'll probably be better off with one of the HTTP bindings, like webHttpBinding or basicHttpBinding.
Related
I'm currently learning the basics of WCF , and I stumbled upon the following flow :
Meaning that my client needs to speak with a Proxy class , that communicates with the WCF server .
Why can't I (the client) speak directly with the server , instead of using a third party for the job ?
There's nothing stopping you from not using a c# WCF proxy client to communicate with a WCF service, you could always do without and use say raw TCP/HTTP/pipes/MSMQ. However, doing so generally requires alot of effort and time - time during which most people would generally prefer to spend reading the Hitchhiker's Guide to the Galaxy.
Heavy?
WCF proxies are actually not as heavy as it may sound. They're not really "3rd party" either. There're generally nothing more than light-weight classes compiled in with your application. They don't run say out-of-process as may happen in certain COM scenarios.
The notion of a "3rd party" proxy is not unique to WCF. DCOM also has the concept of proxies, but unlike WCF, they are created for you behind the scenes and are unable to be avoided. Sometimes, as mentioned, they even run in another process! WCF, or should I say SOAP services (generally), differs from DCOM because the client proxies are not required. They just make the use case of using a SOAP service easier. Luckily that part of Windows had to make way for a hyperspace bypass, so the use of DCOM in contemporary applications is essentially no more.
The client proxies help your life by:
encapsulating and serializing the method call into a request message (usually SOAP)
abstracting you from the underlying transport when the call to the service is made transmitting the request message from the prior step. i.e. using TCP; HTTP; MSMQ etc APIs. Want your TCP WCF service to accept a local named pipe client? Easy just change the config file, no code change is generally required!
deserializing the response message into a user friendly c# object(s)
handles all the tedious; complex and necessary security for you in the form of security tokens; cookies et al
When is WCF not WCF?
So going back to your question again:
Why can't a client speak directly (!) with a WCF server , instead of using a proxy class that does that?
...when you consider that WCF unifies all the comms APIs into a single API; abstracts and encapsulates a SOAP service, then we could say that all WCF clients by definition use WCF proxies to talk to a WCF service.
As soon as a client explicitly uses raw TCP; MSMQ; HTTP; named pipes APIs in code, it essentially stops being a WCF client (remember WCF is all about unified comms) and instead becomes a SOAP client (or perhaps REST). I would even argue that using the IRequestChannel interface with its Request() method, introduces a messaging concept that was not apparent with standard WCF client proxy code (even if it still abstracts transports from the user). By way of comparison, if I add a MSMQ binding to my pure WCF-client-proxy-using-app's WCF config, my code generally doesn't take on an asynchronous messaging model typically associated with MSMQ. That's the nice thing about WCF.
Of course the server, written in WCF, will be quite content in the knowledge that it considers itself "WCF" regardless of whether clients think it is WCF; SOAP or some scary XML payload being shot over TCP in much the same way as the deity that is Pluto, considers itself to be a planet regardless of what classification system happens to be in fashion at the time.
If you want to treat the service as a WCF service - use WCF client proxies (because we generally don't care about the underlying SOAP message being sent about)
If you want to talk to the service directly without proxies, then you should think about the remote service as a SOAP service and so arm yourself with not only low-level comms APIs but also how to construct and process SOAP messages
Are non-Proxy Approaches Recommended?
Whilst you could do without the proxy, it is not recommended because if you wanted to change security, transports, max message lengths, protocols such as JSON, add async methods, you would be required to perform a great deal of code changes to your non-proxy-using-app compared to the proxy approach.
Like the starship Heart of Gold, WCF is "Glad to be of service" but understands should you desire manual helm control.
Gratuitous references to Douglas Adam's fine radio play; TV mini-series and book The Hitchhiker's Guide to the Galaxy. Why not press the Don't Panic button and read it today?
So I'm pretty new to WCF myself, but I'm pretty sure the proxy class is there to give you the types you need your code to reference. When you make a WCF call, you are serializing data, so you need a class to define that. The proxy allows you to write code against it, acting like you know what its methods and data contracts are, but when the code is actually executed, a WCF call is made and serialized messages are sent back and forth.
I have this Windows Service that communicates with TCP/IP.
What I want to know is a method for a Windows Form Application to able to modify the setting of this service, such as remote host address and port to connect, timeout length, and log settings.
I have researched about NamedPipe, WCF Service, and IPC, but I can't decide what matches my scenario the best.
Will be nice to able to change the service settings by doing something like this from the client side.
[Service].SetTimeout(3000);
Any suggestions?
If you want that kind of programmatic control, then WCF is your best bet. With WCF, you get to define the API yourself, e.g., what methods to call, what messages to pass, etc. The WCF framework takes care of exchanging the data for you. And with the WCF config files, changing the back-end data exchange mechanism is trivial. For example, you could replace a NetNamedPipeBinding used for same-machine communication with a NetTcpBinding for cross-machine communication simply by modifying the config file(s). Full disclosure, though, if you haven't done WCF before, my experience was that the barrier to entry was pretty high. Of course, I took my lumps with Visual Studio 2008. It might be much easier in a more recent version. Here's an answer I gave a while back with some tutorials that helped me.
For me personally, I've replaced the early WCF implementation with a TCP-based version over localhost in the project I work on. The front-end application receives constant information from the Windows service when things are "running," and at the time of our decision, WCF streaming was not documented very well. We also saw evidence of problems, although that might simply be because we did it wrong. In any case, I'm very pleased with the solution we've come up with.
I can't speak to named pipes directly, but from what I've read, they're easy to use.
HTH.
currently my WCF Service is using net.pipes to talk on local machine.
Now I want to consume the web service in java on the same machine.
Here I have some questions:
Which binding I have to use to talk on local machine with Java client?
I don't want to go over network and the client must be able to consume the web service.
Do you may have any articles or tipps how to start here? May some hints what I have to take care about?
BasicHttpBinding exposes a SOAP 1.1 wsdl which is probably the most interoperable between JAVA and .NET. If your calls are local then you won't go out to the network.
EDIT
WsHttpBinding supports SOAP 1.2 which is a larger, more complex specification and therefore more open to interpretation by different vendors. So while it may work fine, it will generally be less interoperable.
Specifically there may be differences in the way security is handled on either side (see here for a good explanation).
I would like to have a client application and web application (or service, no UI) and I would like to connect to said web service from within my desktop application and to have two simultaneous network stream, one of them for uploading data and reading them on server and the other one for sending stuff to the client application.
I am not looking for a solution that uses anything more than that like WCF or anything, I just want a way to create connection between web server and my client application and exchange pure binary data. I would implement the protocol myself, I am not looking for any entities or encapsulation like WCF provides.
I don't even know what project type is the best choice here. I thought about empty ASP.NET application maybe that I'd upload on FTP but I have no idea what I should do next to make the application connectible to. I am not asking for complete solution of course, rather some articles that focus on how to make a plain and simple connection between server and client. I want server to be able to immediately update client and vice versa, that's why I am looking for a way to have stream.
Edit: I may as well say that the service is meant to be placed on ASP.NET hosting and I don't know how ports work on these, if there are any restrictions or anything.
"Web service" and "Network stream" are incompatible concepts. Web-services are (ideally) stateless and disconnected - so they work regardless of how the underlying network works. Messages are exchanged only from client-to-server and are encapsulated in HTTP request/response pairs. Hence "web service".
If you want to exchange "pure binary data" (as you put it) then you just need to work with sockets (or use .NET's TcpClient, which wraps up sockets in an easier-to-use API). ASP.NET would be inappropriate for this.
You can technically have an application that uses sockets that runs within an ASP.NET host process but this might not work depending on how security is set-up and it's also bound by the ASP.NET process lifecycle (so it is activated by IIS and can be shut-down or recycled at any time without warning).
You do not want to use ASP.NET Web Services for this (ASMX). That is a legacy technology, and should not be used for new development.
Why do you not want to use WCF? Do you believe it's too complicated? The thing about WCF is that it removes the complication of creating your own protocols.
Also, which version of .NET are you using? WCF get a lot easier to configure with .NET 4.0.
Here is simple duplex example using WCF.
Try it, check if performance you've got is enough, try to use alternative bindings ( like net.tcp). WCF is really neat tool to use. Once become more familiar with it you will love it.
Also check chapter on bindings in WCF from Learning WCF
Have a look at the MVC4 APIController. It works much like stock MVC except that methods return XML or JSON (or anything else you like).
Eg
/api/Users/Get
would could return something like
{
{"Username":"Bob", "Id":3},
{"Username":"Steve", "Id":4}
}
You can also return files and other streams by using special return types. You even get strongly typed, validated input through the use of models.
There's an example here which shows a full CRUD controller and sample AJAX calls from JS which you can replicate in your desktop app
I am working on an media application for which I would like to provide an external API library that would allow another application to communicate with mine an query status information. My application is written in C# and the API DLL will be the same. Initially my thought was to simply use WCF and Named Pipes since it would provide an extremely easy way to code up the whole interface.
However, I realized that doing this would pretty much preclude any other languages or platforms from communicating with the application if I ever wanted to make, for example, an android or Web remote for it.
So, what protocol could I use that would allow a fast and simple interface from within my C# code, but also allow APIs to be written in other platforms.
Basic requirements are:
Local and Remote communication
Low overhead
Procedure Calls
File transfer (to send media)
Pre-Existing C#, open source library would be nice.
I've looked at a lot of the options, used XML-RPC and JSON-RPC before, but would like to know what the community thinks is the best option.
I think using WCF it's the best way to do what you want. It will be simple in maintenance, cover all your requirements and easy to extend. Just don't restrict the access to your API only by net.pipe. I think you should use net.pipe, net.tcp and maybe basic http as primary bindings. I mean several endpoints for each service. So, a client app, no matter what language it is written, will be able to choose what binding to use to access your API server.
For example:
C# client app on the same machine - use net.pipe
PHP client app in web - use basic http
Java client app on another machine - use net.tcp
As an example:
http://www.kevingao.net/wcf-java-interop/java-client-and-wcf-server.html