I'm trying to enable a web application I've written in ASP.NET MVC2 to be able to send and receive data to and from Quickbooks on-demand, without a delay/intermediate database/sync operation. (Please take this as an assumption; I understand that it would be a better idea to use the Web Connector and sync every X units of time, but that is outside of the framework of discussion for this question)
It seems that the only way to do this is to write a regular application (it apparently will not work at all from a service), and then have the webapp communicate with that application and send and recieve data through that application.
So my question is what is the ideal way of setting up an intermediate application that will communicate with the web app?
Should I write a regular console application and get data from standard output? Or are there better ways of accomplishing the same goal?
QuickBooks exposes it's API through a COM interface and there are some limitations in how that can be used. An intermediate application that acts as an relay is an appropriate solution.
I would recommend building or using an application that listens over HTTP and proxies requests and responses to QuickBooks. In fact we use exactly the same approach in our product - RSSBus QuickBooks ADO.NET provider. Here are more details of what we do it in our product: http://rssbus.com/kb/help/RQR1-A/pg_qbconnector.rst
Related
I'm starting up a little code project to learn from the process, but I am not sure what's the best way of communicating between the different parts.
First, I have a pure html/js client where the users need to get live updates frequently.
Secondly, I'm considering having a web api application running to provide data.
Thirdly I have a console application running, that needs to communicate with the web api application.
So I'm thinking about using WebSockets all the way from client->web api->console app, but I have trouble making it work. I can make the console app work as a server, but I can't figure out how to make the web api work as a client, so that when it spins up, creates a connection to the console app, and keeps it open for communication, while it delivers data to the clients upon requests.
I tried with different implementations and I have ended up with SignalR, as it seems like that's what people use today :)
Since I have all these problems getting a connection I am wondering if there are better ways of sending data that fulfills my requirements?
If WebSocket (using SignalR) is the way to go, can you provide some links with working examples? I have tried all the top links from Google with no success ^^
Thanks in advance
Your WebAPI project can act as WebSocket server as well. Check this link that uses an IHttpHandler, but you can also do it in a WebAIP's controller how is explained here : Using WebSockets with ASP.NET Web API
The console application should connect as client, using for example ClientWebSocket class.
WebSockets are persistent full duplex connections, so once the client is connected both ends can push information to the other end.
I have the following questions:
I am creating a desktop application (Windows), and I wish the same send solitudes and interact with another application running stored in server (Windows Server), I'm programming in C #.
Is there any way? With some protocol or something related? How?
Thanks.
There's a LOT of ways to do it.
In modern way, use Server: ASP.NET WebApi and desktop application: HttpClient. This is called REST and most popular in these days.
In Windows way, use Server: WCF and desktop application: WebService. Not recommended for simple service.
Oldies but goodies way: use Socket programming.
Many folks might recommend to use REST. Try to find tutorials related on C# and Rest. There's hundreds of good articles so cannot pick one of it in this reply.
I want to build web based facebook like lightweight chat for my site.
Website build on ASP .net on SQL server 2005.
I am interesetd in XMPP commmunication, but not able to find open source XMPP server with supportedlibrary for C# so that I can create client for my site.
Have checked googling butno luck for C# library; all I could found is plugin and jar.
Is it possible to implement chat logic and XMPP server communication in different language, and accessing thisdata through iframe or by other means on my site.
Thanks,
Hitesh.
http://www.ag-software.de/agsxmpp-sdk/
That library seems to be pretty good.
What you'll want to do is follow jgauffin's suggestion, and use an XMPP library on the backend, and then typically you'd add in a comet server for integration with your web frontend (we've actually done exactly this # Frozen Mountain, using WebSync).
If you're building a smaller site and/or don't need the "realtime" aspect, you could probably get away with polling as well, in which case you'd need to store the results from the XMPP library in your own system, and poll that (since XMPP is strictly event driven).
There are many options to send a message since first human! But how about the intelligence on it, automated collaboration in object level or shared objects among the users etc. I suggest you to take a look for the samples in here and feel the difference.
I would like to have a client-server application written in .NET which would do following:
server is running Linux
on the server there is SQL database (mySQL) containing document URLs
What we want:
- server side would regularly crawl all URLs and create a full text index for them
- client side would be able to perform a query into this index using GUI
The client application is written in .NET using C#. Besides of searching in documents it will be able to do a lot of other things which are not described here and which are done client-side very well.
We would like to use C# for the server side as well, but we have no experience in this area. How are things like this usually done?
Clarifying question now based on some answers:
The thing which is most unclear to me is how client-server communication is usually handled. Is client and server usually using sockets, caring about details like IP addresses, ports or NAT traversal? Or are there some common frameworks and patters, which would make this transparent, and make client-server messaging or procedure calling easy? Any examples or good starting points for this? Are there some common techniques how to handle the fact a single server is required to server multiple clients at the same time?
To use c# on Linux you will need to use Mono. This is an open source implementation of the CLR specification.
Next you need to decide on how to communicate between server and client, from the lowest level of just opening a TCP/IP socket and sending bits up and down, to .Net remoting, to WCF, to exposing webservices on the server. I do not know how compleat WCF implementation is on mono, also I think you may have issue with binary remoting between mono and MS .Net .
I would suggest RPC style WebServices offer a very good solution. WebServices also have the advantage of alowing clients from other platforms to connect easily.
EDIT
In response to the clarification of the question.
I would suggest using mono/ASP.NET/WebServices on the server, if you wish to use c# on both server and client.
One assumption I have made is that you can do a client pull model, where every message is initiated by the client. Using another approach could allow the server to push events to the client. Given the client has the ability to pole the server regularly I don't consider this much of a draw back but it may be depending on the type of application you are developing.
Mono allow execution of c# (compiled to IL) on a Linux box. Mono ASP.NET allows you to use the standard ASP.NET and integrate into Apache see http://www.mono-project.com/ASP.NET and finally WebServices allow you to communicate robustly in a strongly typed manner between you client and your server.
Using this approach negates most of the issues raised in your clarification and makes them someone else's problem.
Sockets/SSL - is taken care of by standard .Net runtime on the client and Apache on the server.
IPAddress/ports/NAT traversal - Is all taken care of. DNS look up will get the servers IP. Open socket will allow the server to respond through any firewall and NAT setup.
Multiple Clients - Apache is built to handle multiple clients processing at the same time as is ASP.NET, so you should not encounter any problems there.
As many have already mentioned there are a number of thing that you have mentioned which are going to cause you pain. I'm not going to go into those, instead I will answer your original question about communication.
The current popular choice in this kind of communication is web services. These allow you to make remote calls using the HTTP protocol, and encoding the requests and responses in XML. While this method has its critics I have found it incredibly simple to get up and running, and works fine for nearly all applications.
The .NET framework has built in support for web services which can definitely be called by your client. A brief look at the mono website indicates that it has support for web services also, so writing your server in C# and running it under mono should be fine. Googling for "C# Web Service Tutorial" shows many sites which have information about how to get started, here is a random pick from those results:
http://www.codeguru.com/Csharp/Csharp/cs_webservices/tutorials/article.php/c5477
have a look at Grasshopper:
"With Grasshopper, you can use your favorite development environment from Microsoft® to deploy applications on Java-enabled platforms such as Linux"
Or see here
The ideea is to convert your app to Java and then run it on Tomcat or JBoss.
Another approach: use the Mod_AspDotNet module for Apache, as described here.
This Basic Client/Server Chat Application in C# looks like a kind of example which might be a starting point for me. Relevant .NET classes are TcpClient and TcpListener
I have an application that is built as a Windows Service and a c# library assembly (.dll.) In order to manage and maintain this service, I'd like to add the ability to run a command-line application that tells the last time the service archived files, the next time it's scheduled to do so, the status of the last run, and the location of a file created by the service.
What's the best architecture for writing a service and library that can share data with another application? I'm using .net 2.0.
The way that inter-process communication happens in .net is through remoting (even if both processes are on the same machine). Other responses have suggested alternatives to inter-process communication which would not require remoting.
The best architecture is probably to make your service be a "server" that can report on it's status (and whatever information you want). Using WCF for this like ocdecio suggested would make it pretty simple.
I use WCF for that and create a contract definition for the commands/events I want to support.
Options that spring to mind that I've applied in the past:
Save the information to a database
(if you have one to hand)
Implement a
"status monitor" type thread on the
service that the client can connect
to and query via TCP/IP etc.
A fairly simple approach is to store that information in either a local config / text file which both apps have access to. Or even to place it in a registry key.
+1 for just having the service provide that (and any other data) when it is queried (simple tcp, RPC, web service, or whatever)
I'd make it pretty generic - like
QueryInfo(some identifier)
with a response as some string and a return value or other indicator that the service does not know what you are talking about, cannot get the info, or give back the info