You may use the DWService APIs to integrate any or all of the DWService Apps where it mostly make sense for you.
In this scenario you have built a remote support Web app in order to assist employees or third-party users with their Mac or PC.
On this application you can make use of several external APIs. For instance, you can implement a chat box to discuss with the user, a button to initiate an audio or a video call as well as the DWService APIs to access their desktop in order to remotely troubleshoot a problem on their machine.
In this scenario you are a company providing a web app to manage files and documents hosted on several cloud-storage services.
You may want to make use of the DWService APIs in order to integrate the File App and display it next to another cloud storage solution. This would enable users to easily drag and drop documents located on a remote server to a third-party cloud storage provider like Dropbox, OneDrive or Box for instance.
If you decide to make use of the DWService APIs, you will have to integrate them within your existing user management system. Since the Web application will be hosted on your side, existing DWService users accessing their remote machines from dwservice.net domain won't be able to reach your web application. DWService APIs are flexible enough to be integrated in any kind of user management system.
For instance if you have deployed Zimbra within your company and already manage a group of users, you may write a plugin to map their credentials to create a DWS account for each of them. Similarly, you may integrate the DWService APIs within Microsoft Windows Single Sign-On mechanism so they are automatically logged in your app that makes use of DWService APIs.
When setting up your application with DWService APIs you have the ability to configure user permissions. For a specific application, some users may be limited to only access the DWService Screen and the DWService File apps while others can be granted access to the Resource App. It is up to you to choose and moderate your users.
An agent is the software installed on the remote machine. It enables an active connection in order to communicate with the applications that you choose to activate namely : the Screen app, the File app, the Resource app, the Shell app, the Text editor app and the Log Watch app.
A channel is an active connection to an agent. However, a connection is not linked to a specific agent. Depending on your use case, you may have several connections and just a few agents or the other way round.
In this scenario you are either:
If you need to assist 200 people. You have to get 200 agents but only 5 channels.
This way all IT experts can connect to the computers that are being supervised and offer their help to the 200 people.
In this scenario you are a company with a central server that needs to be accessible through a custom Web application by a team of 10 IT administrators.
All 10 IT administrators need to be able to access the central server in case an incident occurs.
Therefore, you will only need 1 agent for your custom web application that is installed on the server but 10 channels so that all IT administrators can access it.
In this scenario you are a company with 100 employees. All of them have a desktop workstation. You bought 100 laptops so they can work remotely from home or while travelling and access their workstation.
You can develop a specific extranet application enabling your employee to access company news and professional email messages and calendar. Within this Web app you can make use of the DWService APIs so they can access the screen of their workstation as well as the files on their respective machines.
You will need 100 agents (one per workstation) and 100 channels so each can access their workstation.