Advice for setting up an app with web services please?

[Jed_Davidow]

I set up a simple application for a client that interacts/monitors a VISA device with LV 2009.  The architecture is basically a state-machine with a timeout for the VISA calls that retrieve the current status.

The customer has requested that the app also be controlled via the web, and asked me to set up a demo with one or two simple functions.  I have experience suing the LV7 webserver model, but not with web services.

So here's what I did...

1) Added a Queue to my application that would inject actions into the State Machine.

2) Created a simple VI pushes these actions into the Queue, and planned to use this as the Web Service.

And then I followed the examples for the Web Services, thinking that the Web Server was running in the same program space as the development environment, like the LV7 version.  That does not appear to work.

Could someone give me a quick overview on the best way to do this, or point out a KB article?  I have simple WS working, but here's some questions...

1) What's the best way to launch the main application and then allow web service VIs to be called and pass data back and forth?  What's the mechanism for starting the "server" VI so that the web services can connect to it when called?

2) Are Queues best suited to this?  Should I switch to the internet toolkit to keep track of web requests?  This requires simple calls, not a session.

3) In the development environment, is there a way to launch the main application in the GUI and then allow web services to interact with it?  Queues again?  VI server?

4) Same as #3, but what about running as an EXE?

5) Lastly, will upgrading to LV2010 help solve some of these problems?

Thank you!

[Greg_J]

Hi Jed,

Here's a great place to start that describes the basic process of setting up a web service and the common architecture used when deploying your VI as a web service => Web Services in LabVIEW.  You can also check out the LabVIEW Web Services FAQ.  I hope this helps!

- Greg J

[Jed_Davidow]

Thank you for the links, but I am looking for details on how best to transfer data between the web service (which I have running) and an application running under the GUI- those links don't really address my specific needs.

For example, they suggest that I can use a shared variable to pass data back and forth.  But I am trying to pass string commands, which would suggest using a Queue.  Shared variables don't handle FIFOs for strings.

[Logan_H.]

Communication around the network? I'd say use some network published shared variables seen here.

Also, the TCP/IP communication VIs could be used for small packets of information.

Logan H

[Jed_Davidow]

Is there a way to enable FIFOs with the string shared variables?  I am looking at the Messaging VIs in the SMT package, but was hoping for something simpler.

[Logan_H.]

RT FIFOs shouldn't work with strings since they would be of variable length and RT is going to require determinism.

Is there a way to fix your packet size and send in another protocol for strings?

Logan H

[james brunner · Accepted solution]

@ Jed Davidow:

We ran into this difficulty with our web application (LV 2009) as well.  For now we feel the easiest solution is to enable the VI server in your main application (EXE) VI and wrap calls to it's hierarchy from the web services in the Open Application > Open VI > Call By Ref > Close VI > Close Application structure.

Although we try to minimize use of this in the web services, it just makes sense for some shared and globally accessible resources like database references, configuration globals, etc.

I will also point out that there seem to be some instability that we haven't been able to pin down that may (or may not) be attributable to our use of this technique.  The symptom is LabVIEW dropping from memory immediately at some point.

I am currently looking into migrating to LV 2010, and it seems the same constraints between application instances are in place.  I would expect that, but I was hoping for some more streamlined interprocess communication methods with the next LV release.

--

James