One of the things about being on Channel9 and other similar sites is that I always have to know what other developers think before I embark on a big project. Also, since I picked up C# and .NET, something
about the environment always has me pushing to find out what the best practices are before beginning on my own with something I haven’t done before.
Weird. I didn’t used to be like that. I usually solved these problems completely on my own, but now I’m always paranoid that I may not be doing it the best way.
Anyhow, a quick question..
Exporting data from a Web application to be used on other Web sites or desktop and mobile applications is a no-brainer for me, but what about the other way around? What if I have an application that
must share data with an ASP.NET application?
I’m trying to give a desktop server application a Web front-end to allow users to check status remotely, configure it, and pull data from it. My data can be easily represented in simple XML in this
case. SOAP is not important. I don’t necessarily need to pass objects back and forth, just data.
What are my best options? I’m using C# for the desktop server application and C#/ASP.NET for the Web application, although it would be nice to not be limited to just .NET on the Web application side.
Remoting, named pipes, and proprietary UDP and TCP solutions all came to mind. I’m thinking since objects aren’t important and it would be cool to not limit myself to .NET on both sides, remoting might
be out. And I might want a “session-less” solution for efficiency since I’d be fetching data between Web page loads, which rules out TCP.
But, anyway, does anyone have any ideas or has implemented something like this before?
Thanks in advance!
I just realized that the complexity of the logic behind sending and receiving requests for data via UDP in the manner I want to would probably exceed the overhead of TCP in this case, so I guess TCP is back in.
that is an interesting problem. Not sure what the best approach is. Here's a few general comments...
Remoting might be problematic from a security pov. I'm not sure how completely this is wired up in .net 1.1
tcp and udp are doable, but might cause you some grief. You may have to manually implement chunking, and proxy and firewall support may be hand implemented in this case which would be a pain.
Similarily sockets might be viable. .net sockets are pretty cool. again i think chunking and firewalls etc might be a problem...
does your server support in process providers. If so could you expose the desktop server through a web-service, and call that from the asp.net app. that way you could host in iis and get all the security support ( security is going to need some thought in socket
/ tcp case ). If web-services are too high-level, maybe a pure http client that responds to POSTS etc. again hosted in iis.
Not sure where the requirement to support more than .net comes from ...but maybe moving up the stack towards soap and web-services might help this story?
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.