Web Services in LabVIEW

Applications often require networking interfaces for machine-to-machine communication, remote monitoring, or remote control of an embedded device. The proliferation of the Internet and networking infrastructure simplifies the task of connecting distributed hardware over existing physical networks. NI LabVIEW software offers you a variety of options for establishing communication between software applications. This article explains LabVIEW Web services, a new option in LabVIEW 8.6 added in response to customer requests for a more open and standard way to communicate with VIs over the Web.

Advantages of LabVIEW Web Services

Consider a LabVIEW application deployed across a distributed system. LabVIEW provides features such as shared variables for establishing communication, but many developers need a way to communicate with these applications from devices that do not have LabVIEW using standard Web-based communication. With LabVIEW Web services, you can:

• Communicate with embedded LabVIEW applications from any Web-enabled device
• Establish machine-to-machine communication using standard HTTP protocols
• Remotely monitor and control LabVIEW applications using custom thin clients
• Stream any standard MIME data types, such as text, images, and videos
• Deploy Web service VIs on a Windows or LabVIEW Real-Time target

Figure 1. This screen is an example of a thin-client application developed using Adobe Flex, which can bind data received from a LabVIEW VI to a Web-based user interface.

 

Using Web services, you now can deploy LabVIEW VIs in a distributed application, such as the one described above, for communication over the Web. You can easily configure the LabVIEW Web server to receive requests from thin clients running on any Web-capable device to remotely run and control VIs. However, understand that creating a thin-client interface requires expertise in a text-based language to develop a user interface to interpret and display information.

Web services enable the invocation of a method on a remote target using standard Web-based protocols. A client sends a request to a remote server, which processes the request and replies with a response, which is then interpreted and displayed by the client application. You rely on this communication method for everyday activities such as browsing the Web, checking e-mails, and even reading this article online.

The following bullets are all components of a Web service:

• Server – An application responsible for parsing a request, executing the appropriate method or action, and sending a response to the client
• Client – An application that sends a request to the server and waits to receive a response, which is then interpreted by the client
• Standard protocols – Web-based protocols such as HTTP route data over physical networks from the client to the appropriate server method and then back to the client
• Network – The physical layer, such as Ethernet or IEEE 802.11, over which data is transmitted

With the new LabVIEW Web server, you can deploy VIs as Web services, which you invoke via a request from a client using standard HTTP. Unlike options such as LabVIEW remote panels and shared variables, the clients you build to communicate with a deployed VI do not require the LabVIEW run-time engine, which means you can use any Web-based client technology, including common languages such as HTML, JavaScript, and Adobe Flash.

To understand how communication with a Web service works, consider the experience of browsing an online store. Any time you click on a link or type in a URL, your browser (the client) is sending a request to a remote server, which processes the information and sends a response. Your browser does not need to know anything about the server’s infrastructure or the databases used by the online store; rather, it just interprets the response and displays it to the user.

 

Figure 2. Standard thin-client interfaces can invoke LabVIEW VIs.

 

When communicating with an embedded target, you may find it helpful to relate it to the experience of configuring a router. Routers provide Web client interfaces you can access to configure and set up parameters such as wireless encryption and port forwarding. These stand-alone devices host an onboard server for deploying the interface. You can use LabVIEW in the same manner on embedded devices to deploy a VI as a Web service, which can be communicated from a client such as a Web browser.

This networking method is not ideal for high-speed streaming data applications. The client needs to make a new request any time it wants updated data. Therefore, it is impossible to guarantee how fast data can be returned due to factors such as the quality of the connection, available bandwidth, and the proximity to the server location.

Web-based communication is actually composed of several protocol layers, which range from the physical layer the data is actually sent over to the layers used to encode the message and route it to the appropriate method. LabVIEW abstracts any concern regarding how these layers work, though low-level TCP and UDP VIs are available if you want to develop an application on top of the transport layer.

Figure 3. This diagram demonstrates the standard protocol layers used to communicate from a client application with a LabVIEW Web Service.

The various protocol layers used in Web-based communication are shown in Figure 3. LabVIEW Web services use a RESTful architecture on top of protocols that are ubiquitous across the Web, such as TCP/IP and HTTP, to provide standard, firewall-friendly communication. NI chose a RESTful architecture because it is particularly useful for software that requires lightweight solutions because it involves minimal additional markup.

The Web server in LabVIEW 8.6 has been replaced with a third-party Appweb HTTP Server from Embedthis Software LLC. This new Web server is now used to serve remote panels and Web services. Embedthis is a leading provider of embedded Web servers and was selected based upon its history of providing robust and lightweight solutions ideal for embedded hardware such as NI CompactRIO and Compact FieldPoint.

You can use Web services to provide a Web-based interface for communicating with existing LabVIEW applications. Note that the top-level VI of an application is not typically deployed as a Web service; rather, an additional set of VIs is responsible for communicating with the application and returning data to Web requests, as demonstrated in Figure 4. Information can easily pass between the application context and the Web server context by using shared variables or by writing data to a shared memory location, such as a TDMS file.

Figure 4. Web services can communicate with existing applications via shared variables and shared memory to pass data and configuration parameters to a remote Web interface.

There are several technologies for sending and receiving data between a client application and LabVIEW. The simplest way is to pass data through the connector pane, which yields either standard XML data or plain text. This returned information can easily be parsed by a client that can bind the data to more useful displays, such as tables and graphs. For more advanced communication, a new palette of VIs in LabVIEW 8.6 facilitates the following:

• Data streaming
• Server-side scripting (ESP)
• User sessions (cookies)

You can find detailed information on how to use these advanced methods in the Advanced Reading section below, or you can consult the Example Finder in LabVIEW 8.6.

A Web service VI must be configured, deployed, and managed from the Build Specifications section of the LabVIEW Project Explorer. Right-click on “Build Specifications” and select New»Web Service (RESTful) to get started and configure your VI.

Figure 5. Configure, build, and deploy Web service VIs from the Build Specifications menu.

The settings in the Build Specifications dialog for Web services determine how a remote user calls and interacts with the VI once it has been deployed. The following is an overview of the information and steps required to communicate with a VI that has been deployed as a Web Service.

Figure 6. HTTP directs the request to the correct server, followed by the server and the actual VI to invoke.

1. Physical location of server – HTTP uses URLs to send a request from a client to a specific server interface. The first part of the HTTP address you need to specify in this dialog is the physical location of the Web server. This is commonly specified using an IP address, or domain. If you are accessing the Web server from a client on the same computer as the server, you can type “localhost” to indicate that you intend to communicate with a server that is hosted locally.

2. Name of Web service – Because you can configure multiple services for a single LabVIEW application, the next parameter you need to send in your URL is the service name, which is specified in the dialog window shown in Figure 7.

1. 

   Figure 7. The service name is specified from the Information category of the Build Specification.

3. Mapping to a VI – In the URL mappings dialog, you now can define custom routes for each service that map to VIs or folders containing static content. After selecting the VIs to run as a Web service, enter the URL extension you want to point to each VI.

Figure 8. In the URL mappings dialog, you can customize routes to specific VIs and terminal inputs.

4. Terminal inputs – Inputs can be passed to the invoked VI through the VI’s connector pane. You can map inputs from the URL to the terminal input by adding “:terminal name” at the end of a URL.

To send data to a VI, such as a terminal input, you need to determine how to pass the data. GET and POST are the most commonly used HTTP methods; however, you also have the option of PUT and DELETE using the LabVIEW Web server. GET allows data to be passed in via variables that extend the URL. POST is most commonly used for reading data from an HTML form that contains a large amount of user input.

Static content refers to any document other than a VI that you want to make available to a client communicating with the LabVIEW Web server. In most cases, static content includes a user interface designed to invoke the VI methods and interpret the response. Static content needs to be placed in a destination directory, which is linked by name in the URL mapping dialog.

There are numerous ways to develop a Web user interface that displays content in a visually appealing manner. Since the early days of the Internet, Web pages have relied predominately on HTML and JavaScript, which remain widely used and ideal for simple layouts, user input forms, and static content.  They require minimal overhead, which means that they can be served up easily and quickly over today’s high-speed Web.

Figure 9. The thin-client interface developed in Adobe Flex calls a URL to run the deployed VI, which programmatically generates and streams XML data in response.

Rich user interfaces, such as those shown in Figure 9, can be developed to provide you with dynamic graphics and an application-like feel within a Web page yet still offer lightweight solutions to minimize the amount of data sent from the server. Some of the more common languages for developing these applications include Adobe Flex, Adobe Flash, AJAX, Microsoft Silverlight, and Java applets. These all require unique expertise in the language used to write and script behaviors.

Download an example project containing a thin-client interface developed in Adobe Flex here.

New Web services in LabVIEW 8.6 address the growing need for an open and standard way to interact with LabVIEW applications over the Web. By selecting the Embedthis Web server and the lightweight RESTful protocol, NI is addressing the need for a robust Web server that you can embedded into applications running in LabVIEW Real-Time systems.

View a Webcast on LabVIEW Web services

Web Services Frequently Asked Questions

Learn about security in LabVIEW 8.6 Web services. 

Find out more about server-side scripting with LabVIEW Web services.

Read a W3C white paper on Web services architecture. 

Learn more about features and changes in LabVIEW 8.5 in the LabVIEW 8.6 Web Portal.

Launch LabVIEW online to use the latest features.

Reader Comments | Submit a comment »

Undocumented features and new tools for web services are VERY poor.
Learning how to use these in LabVIEW is poor at best and needs to be done trial and error. NI continues to fall behind new web technologies with this kind of poor roll out of new features.
- Mike King, Advanced Measurements. mike.king@advmeas.com - Nov 6, 2009

In the next release, it would be nice if LabView generated Macromedia/Adobe Flash code automatically for the web based client, just as a stand alone executable is generated today. Flash Actionscript is such a rich langage, that this challenge must be realistic.
- Oct 17, 2009

Web services documentation in LabVIEW is really poor, what happen with the "good the old days" when NI and LabVIEW used to have a nice structured manual for each new topic. I would like a single document that bring me up to speed, with simple steeps or examples to follow up. These days is more like "there is an example, try to figure out what is going on", common NI you can do it better, I've been a NI user for more than 10 years and I am really dissapointed!
- Jul 16, 2009