First I don't know the term of "Proxy Methods" are true way to describe what I need is but let me tell what I really want to know actually :
Suppose I have a class, named Proxy Class containing proxy methods
class ProxyMethods
{
public void CallHelloWorld();
}
actually this is a mirror, actual codes are storing in a web server. So how would this method call the real method that is locating in Web Server without using webservices ?
This way would secure my own code, if a refactoring software refactors the dll located in client's computer, then only thing it would show is that basic method signatures and some connection data which is used to connect the real classes located in Web Server.
So how would I accomplish it ?
Maybe Remoting ?
I'm not sure why you are trying to avoid web services. Performance concerns? Regardless, WCF is the way to go these days. Remoting is nearly totally obsolete. With WCF, it is a config change to go from traditional SOAP over HTTP web service transport to a binary, encrypted transport if you wish. There are so many options to tune the traffic, security, etc. to your needs.
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 a WCF service that will be hosted on a server and a WinForms desktop application.
I would like to implement two-way communication between them and was just after some advice on which is the best way to go about this?
I've done some looking about and the two methods I'm seeing mentioned a lot are either implementing a callback contractor using web sockets.
I'm just after some advice and guidance on which of these methods to take or if there is a better method.
I've used Callback Contract for school project and it served it's purpose nicely. If implemented well, it transfers any kind of data between the server and client. Callback is defined the same way as Contract. It's pretty simple and I advise you to look for some examples on Code Project , like this one Callback example , it's explained with minimum code. Also, in most books, Callback is used as an example for response from server. :)
You tag this question as winforms, so, probably, web sockets less relevant for it.
You can use callbacks (look for Duplex for mode details).
But if you have complex functionality on both sides, and firewalls on clients are not the issue - you can create 2 wcf "services" - one will run on client machine, another one - on server.
This will allow you to be even more flexible (for issue like server restarted, client restarted, ...)
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
I have a client that is pushing for all data access to go over SOAP web services. No, I don't know why; I guess they like to keep their processors warm with all the XML building and parsing. Anyway... I have to move an existing web app programmed using a DataProvider on Oracle to WCF. I haven't written the web service yet. Are their any tools/frameworks/ideas to help create a DataProvider that uses a WCF proxy (or any SOAP client) for data access? Is this even possible?
Hopefully the ASP.NET site has some kind of "Data Access Layer", this will make your job much easier as it will have calls that are easy to proxy, e.g. bool SaveOrder( Order order ), Customer GetCustomerWithOrders( int customerID ) etc.
If instead the ASP.NET is making direct calls to the DataProvider (as I suspect might be the case) then you've got a big job on your hands, since it's a chatty process where you open a connection, do a few things that might require multiple calls to the database, then close it... whereas WCF works best as stateless calls. You can create sessions and try to proxy a DataProvider but I think that would actually make the app more complex and less stable.
I strongly recommend going back to the client and asking "Why do you want to convert to using SOAP and WCF, and what do you hope to gain?".