08-18-2008 06:56 PM
08-19-2008 12:46 PM
Hi John,
The answer to your questions are as follows:
1) Yes. You can deploy a web-service on a computer that does not have LabVIEW but you need the Run-time Engine. There is only two versions of the RTE available, and you would need the Full version of the RTE. In fact, you can also deploy a web service from a Real-Time target such as a CompactRIO.
2) The Web-service needs to be deployed manually and once it does it will run in the background. But it is not like a Windows service that runs automatically on start-up.
3) You can create a VI that does anything you want and if you can get that information into a standard MIME type, you can stream that through a web service. In your specific case, yes, you can get a screenshot and convert it to a JPG which is standard MIME and stream it over a web service.
4) As far as security settings, Webservices operate on port 80 like other HTTP communication. If you have a firewall, you need to make sure you open that port.
5) Web services are standard protocol and they post information in XML format. Any webpage editor can work with them. I have seen applications developed in Flash and in Javascript and they both work well.
6) Web services can inherently handle multiple requests but there is a limitation as to how many. I think the limitation also has to do with the webserver you use.
08-19-2008 01:00 PM
Thanks for the info. I have a few follow up questions:
Concerning #2 below, it sounds like you need to run the installer to deploy the web service (which I assumed) but that it does run in the background. What is not clear to me still is will the web service be running as soon as the machine boots or do I need to log into the machine and then launch some app to get the web service to run each time?
You say it is not like a windows service so I think that I would be required to start the service manually each time I logged into the machine and that the service would be running under the current user's login, not some sort of admin login, correct?
Can I build a launcher VI that can be called like a windows service that can in turn launch the web service?
Concerning #3, if the web service is running under the current user's account, I assume I can grab their screen image using some .net calls, but if it is running under a different (admin) account, then I might not have access, correct?
Concerning #6, I am not clear on the limitation due to the web server. I thought the web server was part of the web service RTE and was chosen and provided by NI. Are you saying that the web service will actually use a different web server that I supply? Will it run inside of IIS on a windows machine? If you are supplying the web server, then why would you not know what the limitations are? Are you referring to the hardware that I deploy this on?
thanks again for the help! I am looking forward to making some really powerful remote management features with this new capability, once I sort out all the details.
-John
08-19-2008 02:30 PM
Hi John, hopefully I can help clarify a little bit.
Regarding your first two questions, on the Windows desktop, web services are normally "run" from the built-in web server in LabVIEW, so LabVIEW must be running on the server machine in order for the web service to be running and available. It is possible to manually build and deploy a web service to a system that doesn't have the complete LabVIEW IDE installed; it is done via the built application mechanism. Once you have the built application constructed, it is up to you to manually deploy it to the desired system and decide when and how to start it. We have a LabVIEW Web Services FAQ posted that hopefully will address this use case for you. Please see LabVIEW Web Services FAQ, check out #12.
Regarding #5, LabVIEW Web Services can output almost anything you want. Terminal output mode offers three fixed formatting options for returning values from the output terminals on your web method VI, but you can use the VIs on the web services palette to output almost anything. It wasn't clear from your question what use case you were trying to address. We don't have a particular HTML editor to recommend, there are many many available out there, both commercially and open source. However, if your goal is to return simple values from your VI but to pretty them up in a custom HTML page, you might consider using our ESP scripting feature which is ideal for generating HTML documents with values embedded in them from your application logic. Look at item #10 on the FAQ I linked, it also links a scripting syntax reference manual. You have to write the HTML one way or another still.
Regarding #6, your web service is indeed served up from LabVIEW's built-in web server. The basic web server configuration is done via Tools >> Options >> Web Server: Configuration. The web server has a pool of worker threads that are used to handle incoming request, by default there are 10 threads so up to 10 concurrent requests can be handled. You can have one or more web services deployed, so this thread pool is shared across all web services. Each web service has one or more web method VIs that run when a request is processed. If the web method VI is marked reentrant, than multiple requests can be handled concurrently (and your application logic should account for that fact). If the web method is not marked reentrant, than only one request at a time can call the VI and subsequent request threads will block waiting to be able to call your VI.
Daren W.
NI, LabVIEW R&D
08-19-2008 06:24 PM
Thanks Daren! That definitely helps.
I read through #12 on the FAQ. The process seems a bit complex. Is there any plans to make this simpler in the future? Do you have an example that demonstrates this? I tend to get a bit concerned when the directions mention things like copying and moving DLLs around on a target machine after installing something. Is there any way to get the installer to do this for me?
thanks again,
-John
08-20-2008 10:26 AM
02-12-2009 02:14 PM
darenw wrote:The web server has a pool of worker threads that are used to handle incoming request, by default there are 10 threads so up to 10 concurrent requests can be handled
Hi Daren,
Is it possible to increase the number of web server worker threads, using a config token in LabVIEW.ini?
Thanks,
-Jim
02-12-2009 02:53 PM
Hi Jim,
There is a separate configuration file that is used for the web server. By default it is named niwebserver.conf and is located in the same directory as the LabVIEW ini file.
The appropriate config token to control the number of threads is 'ThreadLimit n'. Where 'n' is the number of threads. Keep in mind, when custom modifying the web server config file that any changes you make will be overwritten the next time the settings are changed in the web server Tools->Options page. To make them persist you should follow the directions in the FAQ Daren linked to above for getting LabVIEW to use a separate custom web server config file.
Incidentally- There are many configuration options that can be used with the web server that we decided did not need to be exposed through Tools->Options. The third party documentation for the web server configuration file can be found here. The ThreadLimit directive in particular is documented here. Keep in mind that this is the current documentation for the Appweb server and LabVIEW's build may not conform to this documentation exactly.
Nathan
02-12-2009 03:30 PM
Hey Nathan,
Thanks for the info and link to the AppWeb docs. This is very good to know.
Is it possible to enable SSL by tweaking the conf file and dynamically loading the SSL module (e.g., libsslModule.dll) that can be downloaded from Mbedthis AppWeb?
I see that libespModule.dll is already under the ./resource folder of LabVIEW. Could I just copy libsslModule.dll, libopenSslModule.dll, and ssleay32.dll there, too?
If this is too complicated, don't worry about it. But, if there's a simple solution, it would be great to know.
Thanks,
-Jim
02-12-2009 03:50 PM
Jim,
Unfortunately, in 8.6, SSL is not possible in the web server. It requires more than just including the module in the correct directory. There are various technical and legal hurdles that we have to jump through before that feature is available. We're working on it.
Thanks,
Nathan