Advanced Web Service Framework

Introduction

Ever have a need to launch, monitor, and manage an application running on a remote NI Real-Time device or Windows computer? For instance, if you need to launch a data logging process expected to run 24/7 and then check in from anywhere to get status or even change operating parameters, then the MGI Web Service Actor Framework provides a great starting point. This framework allows the developer to create Web Services that launch on call and then continue to run on the server. The running service can be accessed by any web client using the HTTP protocol. Web Services in LabVIEW support authentication and secure communication using SSL, so the developer can protect systems from unauthorized access, aka snooping. Leveraging the LabVIEW Actor Framework provides a reliable method for running asynchronous processes. The combination of Web Services and Actors makes a robust solution for “start and stay running” remote processes.

Using MGI’s Web Service Actor Framework

The WSA Framework is provided as a VI package. When you install the package, you get the following things:

WebServiceActor and WSAClient abstract classes are installed in user.lib along with a documentation file.

Web Service Actor and Web Service Actor Client project templates are installed and available from the Create Project dialog.

WSAExample and WSAClientExample are added to examples and can be found from the NI Example Finder.

The project templates give you everything you need to create a web service and to consume that web service from LabVIEW. To create and configure a web service, follow these steps:

Create a Web Service Actor project from the Getting Started window or File | Create Project….

Set the project name, save location, and icon overlay in the dialog.

In the project tree, expand the .lvlib and .lvclass and open GetName.vi.

Replace “SetServiceNameHere” with the desired web service name. Don’t use spaces. Make this the default value for the control and save the VI.

Expand the Build Specifications and open the properties for the build spec.

Change the name of the build spec and enter the service name. You can also change the destination directory for the build if you want and add a description. OK your changes.

In the MessageMethods virtual folder, edit Initiate.vi and Iterate.vi to perform the initial and periodic functions of your web service.

You can pass parameters to Initiate.vi if you add data members to the Initiate message class and modify the StartService web service method to set those parameters.

If you make no changes, the web service posts a time stamp every 100ms. You can look at the example service for additional ideas, but the example was not built using the template, so there are some minor differences in how it works.

Create a Web Service Actor Client project from the Getting Started window or File | Create Project….

Set the project name, save location, and icon overlay in the dialog.

In the project tree, expand the .lvclass and open Define Connection.vi.

Set the strings for the web service you’d like to connect to, make their values defaults, save and close.

Open Reading Loop.vi. If you have created a service without modifying the template and deployed it, run this VI to read the data the service is outputting. Since the client runs every 250ms and the service loops every 100ms, this VI will alternate between displaying 2 or 3 timestamps each iteration. If you have modified the web service template, you can use Reading Loop.vi as a starting point or delete it.

Technical Details

LabVIEW provides built-in support for web services both as a client and as a server, but they are not a matched pair for producing and consuming a web service within LabVIEW. On the client side, the Import Web Service Wizard makes it easy to use a web service that has a WSDL URL, which would otherwise be a difficult task. On the server side, LabVIEW implements a RESTful architecture which is simpler to use as a client. To consume a LabVIEW web service within LabVIEW, your starting point is the http protocol VI’s. That’s fairly low level support, so MGI decided to build an additional tool.

We wanted to provide a stateless solution so that the client does not need to maintain any state about the server process (no cookies) and the server does not need any secondary management (shared variables or functional globals) to maintain the link to the process. To support this design, the MGI Web Service Actor wraps the LabVIEW Actor Framework Self Enqueuer in a named queue and puts responses from the actor on named queues. Any client can access the running process (a data logger, for example) and get status, download history, and manage settings because the client can access the service by queue name. The named queues are created as part of the Web Service Actor’s Pre Launch Init method and are guaranteed to have a lifetime that matches the lifetime of the actor. All queue creation and management is provided by the framework and requires no extra implementation by the user.