I want to send data from intranet web application that is running on server to a window application running on local machine??
which would be the best way to perform this task?
i am comfortable with wcf services.
can anyone please post any link to get some hint regarding this ..thanks.
Have a look at ZeroMQ (if you're on .NET, look at NetMQ).
Related
I'm developing a distributed Java application that implements state machines in a master -> slave/s configuration.
I would like the master to be able to communicate with each slave asynchronously. To my novice eye, Javelin Websockets looks like a nice lightweight solution to implementing SSL connections for it.
I'm currently struggling a little with it as all of the examples I've found so far are for Javascript in a web page talking to a server. Which isn't really what I'm trying to achieve. I want a persistent connection where each Java application can asynchronously send messages either way.
Before I end up wasting time I was wondering if anyone could tell me if what I want to do is possible, and if so, are they able to point me at any code examples that use a Java application on each end, rather than a web page talking to a backend?
Thanks for any help.
Brad
Yes, two Java applications can talk over Javalin WebSockets. From the perspective of a web server it doesn't matter if the WebSocket client is Java based or JavaScript/Browser based. Javalin itself uses https://github.com/TooTallNate/Java-WebSocket for WebSocket integration testing.
I need to find the most efficient way to communicate from an asp.net web server and a windows C++ application. The windows application does not have any permission to access the database of the asp.net web server.
When the user presses a button, that action with some bytes should be received by the C++ application.
In return, after processing the data on the C++ application, it will send back the result to the web server.
The only way I can think of at the moment is as following:
The asp.net web server will have two web service methods:
the C++ application will call that web service for a method for an interval. if there is a change, then the C++ application will process.
after the C++ application finished its process, it will call a method on that web service to inform about the result.
Any other ways to solve this kind of communication?
Thanks in advance.
If the C++ Application is also on Windows, named pipes would be a good solution. They can be configured to be durable so they can queue messages if either side is not ready to receive the message and they are quite easy to use. They basically look like files that you can read or write from and the data appears on the other side of the "pipe".
Take a look at the documentation (C++) here: http://msdn.microsoft.com/en-us/library/aa365781(v=VS.85).aspx
On the ASP.NET side you would use .NET API's. Here's a nice example to get you started: http://msdn.microsoft.com/en-us/library/bb546085.aspx (This example includes both client and server code.)
Named pipes would be a great solution if the C++ application is located in the same physical server as the ASP.NET application. In that case the OS would be just moving memory between processes for you so it could be very quick.
Additionally, I would configure the C++ Application as a Windows Service so it's always available and can be restarted when the server it's running on is restarted. If keeping it running is very important you could integrate Performance Counters and then have your ops team monitor the counters to make sure it is operating within expected thresholds.
The C++ application can also make a simple GET or POST request with enough information that the webserver can handle in case you don't want to expose a webservice.
You could use network sockets. It's been a long time since I have done anything with them so I can't be much help. Research Winsock (aka Windows Sockets API).
You could use WCF services and connect to them using your C++ client. You will have to research consuming WCF services from C++ client.
As #parapura suggested you could use simple HTTPRequest get & post methods. You could create your own http handler for these request to customize the response.
As you suggested you could use simple web services.
First of all thanks for taking the time to read my question. Here is what I am trying to accomplish followed by what I have so far on this.
What I want to do is create a Windows application (or server of sorts) that would listen for requests from an ASP.NET application. The windows application would be installed and would listen for messages from ASP.NET application and then do some processing. The flow is like this:
A user downloads the desktop application and registers their IP address on my web site. After downloading the desktop app, the ASP.NET application can then send requests to that particular desktop client for further processing. I think further processing is independent of the resolution in this case that's why i have skipped over details on what processing would be done. But if you think it is important, please let me know and I will add those details as well.
I have looked into creating a TCP server that would listen for requests. Because the user has already registered their IP address on my web site, my web site assigns them a unique identifier and stores the ID alongwith IP address in database. Now, the ASP.NET site can send requests to that desktop application.
I have looked into creating a TCP server for this purpose. While researching I also came across PNRP and it seems something like what I am trying to do.
Can you guys recommend some solutions or where I should be looking at for this scenario? Should I create a simple TCPLISTENER or may be go with PNRP approach? Or something else?
The basic requirement is for a web application to be able to communicate with a desktop application. The web application would be servicing numerous users and each user would have a desktop application installed. Which user for which desktop client question would be addressed by the web application that would maintain a database of unique user id's and their corresponding IP Address.
Thanks in advance for your help.
You could use .NET remoting or a web-service in the desktop app. Use WCF or WSE for the latter. You can use COM to add windows firwall rules.
Whatever you do, take firewalling/NAT into account. It might be easier for the client application to poll the server (initiate the connection) otherwise you open a can of worms by trying to have a remotely-accessible server in your user's computer without having to do some very manual configurations on the user's networking equipment.
Once you have that part sorted out, what I used in your situation was .NET Remoting. At the time WCF had not come out and when it did it was to crippled for my needs. TCP IP sockets were too raw (I had to write too much code) and so Remoting solved my problem ideally (a hand full lines of code to set up the connection, and everything was automatic from there on).
EDIT: I use an excellent third party library that makes Remoting even more flexible (flexible enough that I am still waiting for WCF to catch up with the featureset so that I stop using Remoting, and no luck yet!). Check out http://www.genuinechannels.com/ to see all the features they have. It includes making calls from server to client, and that sounds exactly like what you need to do. Check it out.
I'd like to know if/how would it be possible to connect Adobe Air application to Java VM Debug Interface? I have some objects residing on server side and don't want to change the code there and server already allows to do remote debugging.
Here's the information about JPDA:
http://www.j2ee.me/j2se/1.3/docs/guide/jpda/architecture.html
Greatly appreciate for your advice in advance.
Be very careful about opening the remote debugging interface to the Internet. That could be a huge security problem.
Security considerations aside, only a single debugger process can attach to the JVM at the same time.
You should really look at some of the more regular remoting protocols, such as SOAP or REST over HTTP(S) to talk to your server. This is not more work (probably less) than trying to shoe-horn JPDA into something it was not meant to do.
I am building an ASP.NET website which will collect data from a user and submit it to a 3rd party webservice. The webservice is somewhat unreliable and for this reason there is a backup service.
If a call to the primary service fails (timeout or some other error) then I need to flip a bit in a static class which will trip the system to use the secondary service.
At this point, I need to start polling the primary service (with dummy data) to see if it is back up (at which point I will receive an OK code in return). At this point I need to flip the bit back so that the website starts using the primary service again.
I've had a read of this Should I use a Windows Service or an ASP.NET Background Thread? and I think that separating out the code into a Windows Service would be the cleanest method of performing the polling, but then how would I communicate with the web appication.
One thought I've had is to expose a webservice that the Windows Service could use to communicate into the webapp but this seems both messy and over-kill.
I'd appreciate your thoughts and experiences performing similar tasks.
Thanks
I think the Windows service is the way to go, definitely.
As for the communication between the service and your web site, the best answer depends on the size and scale of your solution. If you are building something that needs to be reliable, I'd suggest you implement some sort of queue between your ASP.NET site and your Windows service. You have a lot of options here too, depending on budget and ability: BizTalk, MSMQ, and SQL Server queues (SSIS). Alternatively if you are looking for something smaller scale, I'd recommend you just stick it into a database table somewhere.
I would avoid using files on the file system because you will encounter issues with file locks and multithreading. I would also avoid directly communicating with the service because you risk losing the in-memory queue if the service fails for any reason.
Edited to add:
If reliability isn't a concern here, you could use a WPF named-pipes hosted service for communication between your website and your Windows service. This avoids much of the overheads normally involved in classic Web Services and is surprisingly quick. The only down-side is that self-hosting a WPF service is tricky and can be difficult to keep the service up.