This has been asked a lot, but I'm after more specific answers.
I'm designing/developing a suite of applications that are dependent on communicating with a agent and a manager. They will be communicating commands (from manager to agent) and statistics (agent to manager). At the moment, this suite of applications will only run on the Windows platform, but eventually should scale out to other systems. Some places where this application would be used might not want to install a great load of applications across their systems, and some might not want the manager side sitting there sucking up juice (analysis!) and therefore might want it in the cloud.
So, I know that I can use .Net TCP sockets, which seems to have good raw performance and allows me a great deal of flexibility.
I also know that I could use Windows Communication Foundation, which seems like naturally a better choice.
But, seeing as I'm sending commands and receiving statistics, I could just use Powershell to connect remotely and use the plethora of commands available from what would be the server, ruling out writing a client application full stop.
Bearing in mind that these applications (client especially) should just sit there, be quiet, do their job and not interfere with general operations, which would you suggest to be better?
If you need more clarification I'll be happy to do so!
Thanks.
The way you discribe your application, I would reformulate it as an 'agent' located on clients and a manager located on the server. If it's so the manager sends commands to the agents and the agents respond or store statics available to the manager.
For such an architecture you can imagine using WMI, with a WMI provider on the agent, and wathever you want on the server. Powershell can be used on the server to query your agent. In the near future you can use the same architecture puting your agent on a Linux box with NanoWBEM on the top of WS-Man Protocol (see Standards-based Management in Windows Server “8”) .
They will be communicating commands (from server to client) and
statistics (client to server). At the moment, this suite of
applications will only run on the Windows platform, but eventually
should scale out to other systems.
In your description there is one requirement that is not compatible with Power Shell.
Power Shell works only in Windows world.
WCF service should not consume any resources if they are properly configured. IIS and WAS are able to load services on-demand (upon getting request from client) and unload when it is not necessary.
http://blogs.msdn.com/b/blambert/archive/2009/02/13/enable-iis.aspx
http://msdn.microsoft.com/en-us/library/ms731053.aspx
TCP sockets are the best from performance point of view but unfortunately implementation will require lots of extra DEV and QA work to implement all plumbing that already exists in WCF. When you finish that work you will have one more "bicycle" that is not compatible with industry standards.
My vote is WCF.
Related
I have a project I am working on where I need to create an app and service package for Windows. I would like the service process to run as SYSTEM or LOCALSYSTEM so that credentials are irrelevant. The application frontend will be installed and executable by any user on the machine. Data from the frontend application will be passed to the service - most likely paths to directories selected by users. Once started the service will listen for a command to do some action while accepting the aforementioned paths.
I'm using C# on the .NET platform and I've looked into creating a standalone service and a standalone application separately as well as creating a WCF service library and host application - that's as far as I've gotten.
All of these methods seem overly complex for what I am trying to achieve. What is modern convention when attempting something like this? I'm willing and able to learn the best method for moving forward.
Edit: This was flagged duplicate. I'm not looking for information on HOW to communicate with a Windows service. That's remedial and not at all what I'm asking. I'm looking for validation that I'm on the right track and if I'm not, I'm looking for suggestions. I've been told that I'm on the right track and pointed towards named pipe binding.
Windows Service is certainly an option for hosting WCF, although it kind of is a deployment nightmare. It really depends on your environment and the capability and support of your system admins as I've had many clients where deploying a windows service, as you need admin rights to install and update it, was simply not practical.
Console applications may sound like a terrible idea but the practicality of being able to drop them on a share and run a powershell script to start them is very compelling.
But frankly IIS hosting has the most advantages in my mind as the product is designed for ease of deployment and up time. And you can use any transport binding in IIS that you can use in a Windows Service or Console.
As for the binding itself named pipe is not really a popular option in many enterprise scenarios as it is incompatible with anything but .NET. Although the same can be said for binary which is one of the more performant bindings. The WSHttpBinding is probably the most popular binding in scenarios that require unknown callers. WebHttpBinding is an interesting option as its HTTP/REST based, although that requires further decoration of your operations and honestly if your going that route you should really be using Web API.
I have a windows network (not connected to domain) and I need to provide some automation on each PC at certain time of the day. There are several tasks - launch executables, managing FS, transfering files. All this actions must be implemented via RDP, using C#. What is common approach to achieve this? I don't have experience using RDP within software. So are there .NET classes or free libraries I can use to get RDP functionality in my software. Thank you!
All the tasks you have listed relyed much more on security issues for machines within your network and a user logged-in priveledges a rather than a usage of RPD.
Within a windows domain the tasks like yours are usually delegated to ActiveDirectory administration and policies.
In case of a not Windows Domain Network you will need to use a mechanism that will be presented in following configuration:
a client installed on each particular machine under proper permissions. The client should implement a subscriber pattern.
a server installed on a "commander" machine. the server should inplement a publisher pattern.
There should be a lot of ready solution that should implement the concept of content disribution and starting specific scripts. I think that your investment in such tools research and evaluation will be much more time- and cost- effective rather than writing an app that "uses RPD functionality"
But if there is a reason that prevents usage of 3rd parties, I would go for implementaion of WCF service that will be installed on all clients. This service should be "trained" to do all your suff on client. Server side you will need an appliaction or a service that will publish events for clients or trigger known clients methods.
I want to build some sort of interface that will monitor our real time routing/switching system. I would like to give a lot of visual feedback to be able to monitor its status visually. Our system and clients are not co-located so they would need to connect via TCP/IP.
I would like to be able to service any number of monitoring clients (although this will probably only ever be about 4-6 clients). I thought of using SilverLight but there appears to be one or two tricks involved in getting SilverLight to connect back to an application running on a different port.
I have also thought of using HTML5 canvas and websockets. Another alternative is to just create the clients using normal Window Forms and perhaps WPF. But this means that to monitor the application the client will have to be downloaded before. I would prefer something that is as easily accessible as web app?
What are some of the more common application stacks to achieve this? What should I watch out for?
EDIT:
Just to add: This will be an internal tool only. But we have offices in a couple of locations.
any choice in this direction could be subjective and arguable, surely somebody could suggest any possible web framework or language...
I would consider, however because of your .NET and C# tags, ASP.NET MVC 3, so basically web based plugin-less ( NO Silverlight ) HTML 5 solution.
Consider that StackOverflow is done in same way (MVC, ASP.NET, SQL Server... ) and outperforms as we all know.
the way you grab the underlying events from TCP, so the way you capture and provide the data from TCP, it's another thing from the front end, I would probably write a Windows Service if the traffic is so high and you want to grab and store data anything regardless any active client connection.
There are plenty of real time charting controls out there also for MVC, MS Chart Control. DevExpress, ExtJS integrated ones...
"real time" and Browser is bothering me.
I would indeed go WPF or WinForms. Using the ClickOnce-Deployment you can make this a no-pain for the user and you can roll-out new versions just by redeploying them and having the user restart the application.
In my company this works really fine and we have no problems whatsoever. The only problem with this is, that the app.config is somewhat hard to find and keep current/valid (redeploy) but in your case this won't change per client (or so I guess).
I agree with #Davide - I would go for a WebService that will obtain all routing/switching data in realtime. You will have a web application and on the client side you will have JQuery/AJAX fetching realtime data from the WebService component.
I've seen cool demo's of Web Orb doing something similar to what you want. http://www.themidnightcoders.com/
If you are starting from scratch, it would be good to check out WCF (Windows Communication Foundation). It's great because it can expose your functionality in many ways, using nothing more than modifying a config file.
If you want a Windows client app, you can host it in a Windows Service, or simply include it as a side assembly. For web apps, you can choose between various formats (JSON, XML), channels (HTTP, TCP) and protocols (SOAP, ODP).
If I got it right, there will be a server-side application which will collect information from the devices and expose it to clients as a service. In that case, a WCF application might be hosted in a Windows Service or IIS on a server machine, and expose the data though one or more endpoints (HTTP, TCP).
I am not aware of problems in connecting a SilverLight app to a service, but I would rather go for a HTML5/JavaScript combo instead, for easier deploying and compatibility with a wider range of devices (no plugins needed). ASP.NET MVC should be the best choice for the web app.
We have a multi user product prototype in WPF which works fine as a prototype. Now we want to build the complete product.
In our product we have scenarios where 2 - 3 users might have to use same data. Say one us editing and the other user is viewing the continuos edits. And also whenever a user changes a common itemm updates should go to all the other users on that same item, and they need to refresh their information. And this should happen without polling continuously.
Is there any advantage of going towards web based product development i.e in Silverlight.
There's absolutely no architectural advantage to Silverlight over WPF in this situation. Your main advantages for Silverlight would be 1) smaller deployment 2) cross platform and 3) more integrated in-browser experience.
From the developer's perspective, however, you might actually find WPF better for developing this kind of collaborative application because you have access to a wider array of networking options. Silverlight has limits on what TCP/UDP ports you can access and has no built-in peer to peer networking capabilities like WCF does on the .NET Framework.
In any case, a Silverlight application for all intents and purposes is a client application, not really any more of a web application than WPF except when it comes to deployment.
Peer to Peer (p2p) vs. Client / Server
Your question really comes down to how you want to design your data storage.
P2P: Do you want each copy of the application to keep a full copy of the data and to exchange updates to the data with the other clients? This works well in a LAN environment but gets challenging over the broad Internet. BitTorrent is a good example of an application that does this.
P2P generally has higher performance and fewer costs but is very tricky to pull off. You'll need a p2p network transport like PeerChannel, and most likely a synchronization engine like Sync Framework, and some form of structured local data store like SQLite.
Client / Server: Do you want one master computer (e.g. server) to host all the data and have each client load / update data to the server? This works well in a LAN or Internet environment. Web browsers / web servers are a good example of this.
Client / Server has the overhead that a dedicated always on server computer has to be involved and you have to program two applications, the client side and the server side. Silverlight or WPF work well for the client piece of this design.
If you're up for a challenge, developing a p2p application can be a lot of fun because there are many obstacles to overcome and the end result is generally more efficient. This will essentially require you use WPF to get the libraries/tools support you need. If you need to get something working quickly, you'll find that the tools you have support client / server much better because this is how most applications are written. Here, WPF and Silverlight will both work, but they are only part of the solution -- you'll need a server technology too like SQL Server or ASP.NET or Azure or ...
I'm a desktop application developer who is temporarily working in the web. I'm working with a client that wants me to build an app for use by locations all over the state; however, these locations have very shaky connectivity.
They really want a centralized web app and are suggesting I build a "lean" web app. I don't know what a "lean web app" means: small HTTP requests but lots of them? or large HTTP requests with few of them? I tend to favor chunky vs chatty.. but I've never had to worry about connectivity before.
Do I suggest a desktop app that replicates data when connectivity exists? If not, what's the best way to approach a web app when connectivity is shaky?
EDIT:
I must qualify my question with further information. Assuming the web option, they've disallowed the use of browser runtime technologies and anything that requires installation. Thus, Silverlight is out, Flash is out, Gears is out - only asp.net and javascript is available to me. Having state this, part of my question was whether to use a desktop app; I suppose that can be extended to "thicker technologies".
EDIT #2: Network is homogeneous - every node is Windows. This won't be changing.
You should get a definition of what the client means by "lean" so that you don't have confusion surrounding it. Maybe present them with several options of lean that you think they might mean. One thing I've found is it's no good at all to guess about client requirements. Just get clarification before you waste a bunch of time.
Shaky connectivity definitely favors a desktop application. Web apps are great for users that have always-on Internet connections, and that might be using a variety of different browsers and operating systems.
Your client probably has locations that are all using Windows, so a desktop application is an appropriate choice. One other advantage of web applications is that they make the deployment issue easy to deal with. Auto-update technologies like ClickOnce make the deployment and update of desktop applications almost as easy.
And not to knock Google Gears, but it's relatively new and would have to be considered more risky than a tried-and-true desktop application.
Update: and if you're limited to just javascript on the client side, you definitely do not want to make this a web app. Your application simply will not be available whenever the Internet connection is down. There are ways to save stuff locally in javascript using cookies and user stores and whatnot, but you just don't want to do this.
If connectivity is so bad, I would suggest that you write a WinForm app that downloads information, locally edits it and then uploads it. This way, if your connection goes down, all you have to do is retry until it works.
They seem to be suggesting a plain vanilla web app that doesn't use AJAX or rely on .NET postbacks or do anything that might make it break down horribly if your connection goes away for a bit. Instead, it should be designed so that you can hit Refresh until it works. In other words, they seem to want the closest thing to a WinForm app, only uglier.
You may consider using a framework like Google Gears to help provide functionality during network down time. This allows users to connect to the web page once (with a functioning connection) and then be able to use the web app from then on, even without a connection.
When the network is restored, the framework can sync changes back with the central database.
There is even a tutorial for using Google Gears with the .Net Framework.
Gears with other languages
You mention that connectivity is shaky at these locations, but that the app needs to be centralized. One thing you might consider is using multiple decentralized read database servers and a single centralized write server. Mysql makes this possible and affordable if your app is small.
Have the main database server at the datacenter/central office. Put up small web/db servers at each location, with your app installed. You can even run them off a user computer if the remote location is not too big. Make the local database servers connect to the centralized database server as replication slaves. As changes come in to the centralized database, the slave servers will pull down the data and make it available locally. When the connection is unavailable, your app data is still at least available, if not up to date. When the connection is available, the database handles replicating all relevant data down.
Now all you have to do is make your app use two separate database handles: reading data it uses the local database, writing data it uses the central database.