Using Web Services in LabVIEW
Overview
Web Services have emerged as the next generation of Web-based technology for exchanging information between applications across the Internet. This document describes what Web Services are and how they can be incorporated in the LabVIEW environment. Note: Calling Web Services from LabVIEW 8.20 and earlier, requires Microsoft Windows and the .NET Framework 1.1 Service Pack 1 or later.
Table of Contents
What are Web Services?
According to the World Wide Web Consortium (W3C) a Web Service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface that is described in a format such as WSDL (Web Services Description Language). Other systems interact with the Web Service in a manner prescribed by its interface, using messages which may be enclosed in a SOAP (Simple Object Access Protocol) envelope. Web Services represent black-box functionality that can be reused across the Internet without any required knowledge of their implementation.
Both Web sites and applications can make use of Web Services. Essentially, a Web Service resembles a set of functions exported to the Internet through a Web server. A designer of a Web site or an application has the capability of invoking these functions and making use of the Web Service. Web Services are gaining popularity due to the many benefits they offer:
- Code Reuse – Building applications is simplified using off-the-shelf Web Service components.
- Platform Independence – Because access to Web Services uses standard Internet technologies, the consumers of a Web Service can utilize any platform.
- Language Independence – Any programming language can act as a Web Service consumer without knowledge of the implementation details of the Web Service.
- Distributed Computing – Web Service components can be used to easily build distributed applications that span firewalls.
The power of Web Services lies in their ability to provide added functionality to standard Web or application design tools. For example, a standard process control application might alert operators of unsafe conditions using alarms. By incorporating a Web Service to place phone calls when an alarm condition exists, this control application now has the ability to reach beyond operator interaction to actually dial an emergency number for help.
Web Services augment existing programming toolsets. As more programmers adopt Web Services as a programming tool, these services become increasingly prevalent in Web and application design.
Communicating with Web Services
Any Web Service is accessible using popular Web protocols, data formats, and message formats, such as Hypertext Transfer Protocol (HTTP), Extensible Markup Language (XML), and Simple Object Access Protocol (SOAP). HTTP is utilized to send and receive messages between the Web Service and the consumer of the service. XML is used to describe and represent the data exchanged. SOAP defines the messages and their bindings to HTTP. Using the SOAP protocol, a client can send and receive messages that are well understood by both the Web Service and the consumer. However, the consumer needs to know which messages to send and receive. A description of the interface to the Web Service is necessary for this transaction. Web Service Description Language (WSDL) is an XML-based contract language jointly developed by Microsoft and IBM. A Web Service publishes its interface in WSDL at a specific URL. A consumer then can read the WSDL specification from the URL and create SOAP messages to communicate with the Web Service.
Finding a Web Service
Stock quote tickers, currency converters, language translators, and package trackers only represent a small subset of some commonly available Web Services. Much like a local vendor advertises in the phone book, vendors of Web Services publish their services in well-known Web directories. Searching in Google for "Web Services Directory" yields several results containing these listings. A few popular directories also are linked below. A directory may list Web Services by categories and allow users to search for services using keywords.
After finding a Web Service of interest, a user must take note of the URL of the WSDL specification. Often, the Web Service directory description will clearly label the URL of the WSDL specification along with the service’s functionality. This URL is necessary when creating a Web Service-based application in LabVIEW.
See Also:
XMethods
Microsoft UDDI Business Registry
Leveraging Web-Service Technology
Communicating with a Web Service using SOAP messages is analogous to writing code in an assembly language; it is efficient but hard to write, debug, and maintain. A user can simplify the task greatly with a higher level of abstraction by using the Import Web Service Wizard in LabVIEW.
In LabVIEW 8.20, the Web Services Import Wizard introduces an abstraction layer between the Web Service and a VI called a .NET assembly wrapper. This layer does the work of packaging, sending, and receiving SOAP messages. The result is a drop-and-go version of the Web Service functionality.

Figure 1 - Leveraging .NET to communicate with Web Services
Under the hood of the Web Services Import Wizard, services are leveraged using a .NET assembly, which is a unit of deployment in .NET. While the extension for the .NET assembly is .DLL, it is not a standard dynamic link library that can be called using a Call Library Function Node in LabVIEW. Rather, it is built to run on the Common Language Runtime (CLR) supported by the .NET framework. A .NET assembly exports a class-based interface with properties and methods. Using .NET client support in LabVIEW, a user can create an instance of a class from a .NET assembly using the Constructor Node and can access its properties and methods using property and invoke nodes, respectively.
In LabVIEW 7.1 or earlier, refer to Chapter 19 of the LabVIEW User Manual (linked below) for more information about using .NET in LabVIEW. In LabVIEW 8.0 or later, refer to the Using .NET with LabVIEW topic in the LabVIEW Help (linked below).
This level of detail about the .NET assembly wrapper is rarely needed for most applications. Utilization of the .NET assembly wrapper is simplified in LabVIEW 8.20 using the easy-to-follow Web Services Import Wizard. The Web Services Import Wizard automatically wraps VIs around this functionality as demonstrated by Figure 7. The example in the following section demonstrates the ease of using of the Web Services Import Wizard.
See Also:
LabVIEW User Manual
LabVIEW Help: Using .NET with LabVIEW
Creating a Web Service-Based Application in LabVIEW 8.20
LabVIEW 8.20 allows the user to easily import a Web Service and utilize the functions of the service through standard subVIs in LabVIEW. Follow the steps detailed above for finding a Web Service and its associated WSDL URL. Using LabVIEW 8.20, the following steps outline how this information is used for a Web Service-based application:
Step 1: Locate and copy the WSDL URL of a desired Web Service.
Step 2: Launch the Web Service Import Wizard in LabVIEW.
Step 3: Paste the WSDL URL in the Web Service Import Wizard.
Step 4: Select the desired methods of the Web Service.
Step 5: Utilize the Web Service VIs on the block diagram.
The following example demonstrates how to call a Web Service called Phone Notify from LabVIEW. This Web Service calls a specified phone number and reads a specified text aloud. Refer to www.cdyne.com fFor product information about the Phone Notify Web Service.
Step 1: Locate and copy the WSDL URL of the Phone Notify Web Service
- Visit www.xmethods.net and view the full list of Web Services.
- Search for “Phone Notify” and select the link.
- Copy the WSDL URL (Figure 2).
Step 2: Launch the Web Service Import Wizard in LabVIEW
- Launch LabVIEW.
- Select Tools»Import»Web Service… (Figure 3) to launch the Web Service Import Wizard.

Figure 3 - Launching the Web Service Import Wizard in LabVIEW 8.20
Step 3: Paste the WSDL URL in the Web Service Import Wizard
- Paste the WSDL URL into the Web Service Description URL field and click the Next button. The Web Service is now automatically validated – LabVIEW checks the URL to verify that it is a valid WSDL specification.
- In the Name (.lvlib) field, specify the name of a new Project Library to contain the Web Service.

Figure 4 - Specifying the Web Service project library
Step 4: Select the desired methods of the Web Service
Methods are the various functions that this Web Service can provide. Available methods are listed in the window of the Web Services Import Wizard.
- Ensure that each method that you want to import into the project library has a checkmark next to its name (Figure 5).
- Click the Generate button to proceed with the Wizard and open the imported project library.
- Click the Finish button to exit the Wizard and launch the project library (Figure 6).

Figure 5 - Selecting the Web Service methods

Figure 6 - Opening the imported Web Service project library
Step 5: Utilize the Web Service VIs on the block diagram
When the Web Service Import Wizard completes, the generated project library is accessible.

Figure 7 - Exploring the generated Web Service project library
- From the Project Explorer Window, drag the Open Web Service.vi and the Close Web Service.vi onto the block diagram. These VIs are necessary to properly establish and close the connection to the Web Service.
- Drag the NotifyPhoneEnglishBasic.vi icon onto the block diagram. Note: this can be any desired method of the Web Service.
- Specify the LicenseKey, the PhoneNumberToDial and TextToSay and wire the VIs as shown in Figure 8.
- Notice in Figure 8 that the VIs encapsulate low level .NET calls for easier implementation (red squares).
- Run the VI. The Phone Notify Web Service calls the specified phone number and reads the text.

Figure 8 - Utilizing the Web Service in a LabVIEW application
As shown by the previous example, calling a Web Service method from LabVIEW is a simple process when using the Web Service Import Wizard.
Don’t have LabVIEW 8.20?
LabVIEW 8.20 greatly simplifies the process of calling a Web Service from LabVIEW. However, if you want to call Web Services with a version of LabVIEW prior to 8.20, refer to the following document:
Using Web Services in LabVIEW 7.x or 8.0
Reader Comments | Submit a comment »
XML-RPC Support
I agree that XML-RPC support is something
that needs to be supported in the next
release. I can't think of another major
development language that doesnt natively
support, or have external libraries
supporting, XML-RPC.
- Jul 22, 2008
Using Web Services
Is it possible to consume Web Services
developped in Java and deployed with
Tomcat/Axis ?
- Perret Bruno, INRA. perret@grignon.inra.fr - Sep 17, 2007
client versus server
The article describes how to find web
services and create a client application.
Although I like the article, it wasn't
initially clear to me that it was for
client-side only. The article doesn't mention
whether there is any way of creating a web
service with Labview.
- Aart-Jan van Zadelhoff, University of California, Davis. ajvanzadelhoff@gmail.com - Jul 22, 2005
does not work if vi on a network drive
Hi there,
You will receive a 1172 error code if the
vi is located on a network drive. The Dll
can be located either locally or on the
network for the vi to work (although a it's
a good practise to have the vi and dll in
the same directory). But you must have the
vi on a local drive.
- darren.lockyer@pwrm.com - May 3, 2005
XML/RPC vs .Net
Can you give a similar level of support for XML/RPC
based services, or Java Services or systems which are
not using .Net?
- Glen Speckert, SpeckTech. speckert@specktech.com - Aug 12, 2003
Legal
This tutorial (this "tutorial") was developed by National Instruments ("NI"). Although technical support of this tutorial may be made available by National Instruments, the content in this tutorial may not be completely tested and verified, and NI does not guarantee its quality in any way or that NI will continue to support this content with each new revision of related products and drivers. THIS TUTORIAL IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND AND SUBJECT TO CERTAIN RESTRICTIONS AS MORE SPECIFICALLY SET FORTH IN NI.COM'S TERMS OF USE (http://ni.com/legal/termsofuse/unitedstates/us/).

