A little while ago, I did a small post about the advent of the new ASP.NET controls available in the Measurement Studio package.
A very good question was raised...When should you use ASP.NET? Let's look at the answer to that question...
The purpose of ASP.NET is to create a user interface for a web browser. Sounds simple, eh? I wish. To try to keep it simple, I'm going to assume that you do want remote access to your system and/or data, and that you're trying to decide between LabVIEW's remote front panels and going with ASP.NET.
When you get involved in creating a "web interface", there are a lot of questions you have to ask yourself. Let me throw a few of them down here...
- Time and money to get it working.
- Is it accessible to the Internet (outside the company firewall)?
- How many clients are going to attach?
- How "live" does the data have to be (continual updates? refresh? click to update?)
- Can you force the clients to install a runtime engine?
- What clients to support (IE? Firefox? Opera? Cell Phones? PDAs?)
Let's look at those in turn.
Time and money to get it working
I'm starting with this, because, until you can answer this, you don't want to get carried away with delusions of grandeur. Remember that you have a job to do and unless you're a full time web developer, this probably isn't it.
The main advantage of the LabVIEW remote front panels is that it's fast to develop content rich applications - all in LabVIEW. You don't need to learn another language, worry about deployment, installing and configuring web servers, etc. It has its limitations, but there are trade-offs to everything. Remember, engineering is the science of balancing mutually exclusive objectives.
Is it accessible to the Internet?
This is mainly a question of security - how secure is the web server? how many clients can you handle? Do you need them to log in (authentication)? Do you need to restrict what people can do based on who they are (authorization)?
[As a quick side note, and another LV and .NET plug, if you do need authorization, I recommend checking out the Authorization Manager (AzMan) from Microsoft. Free role-based security manager with plugins for LDAP and ActiveDirectory...very nice. I'm going to write up some examples and posts about it when I can get the time]
Generally, if you're going to make something available out on the WWW, you should stick with an enterprise-class web server, such as Microsoft's IIS or Apache. Since we're talking about ASP.NET here, then you should look at using IIS.
How many clients are going to attach?
Simple question...who are your clients? Are you talking about a handful of people you work with? A few hundred in your division? Your entire company? All of your customers?
It's also a question of how many you expect to attach at once. Even if there are hundreds that need access, if it's likely that only a few will ever be connected at the same time, you're looking a just a few clients.
Generally, if you're talking about a few clients connected at the same time, the remote front panel is a great solution. If you're talking about dozens or hundreds of people at the same time, you're looking at ASP.NET. Truth be told, if you're looking at that many, you're also looking at professional hosting (internal or external) because you'll need load balancers and web farms.
As a quick side-note, for this and the last issue - realize that as you increase the accessibility of the application, you increase the involvement of your IT department. Security issues at this level become very serious - this isn't a weekend kinda project.
How "live" does the data have to be?
This is a key one. There's a big difference between retrieving some data from an XML file or SQL database and showing live vibration data from a spinning rotor. What exactly does your client need to see?
Generally, the rule of thumb here is that the more responsive you need the user interface, the more you want to stick with remote front panels. The more the data is one-shot, the better the Measurement Studio ASP.NET controls can be.
Can you force the clients to install a runtime engine?
This often comes up as a show-stopper to the remote front panels, as it requires the LV RTE to be installed on the client machine. But I'll point out that this is a requirement for a lot of items - Flash, Adobe PDF, Java Applets, etc. I'm not saying this issue is "all in your head", but really think about whether this is a problem or not (especially considering the cost of developing the web interface) before calling this a showstopper.
What clients to support?
Where the RTE does can become a showstopper is on the client browsers. If your clients are running on a support LV platform (i.e, Desktop Windows, Mac, Linux), then you can install the RTE. But if you need to be able to see the display from your Windows CE PDA or from the latest cell phone, then realize you'll need pure (and fairly simple) HTML only - thus requiring ASP.NET.
Summary
So, when do you need ASP.NET? As you might have guessed: when it's the right choice for the job. If you ever want to discuss your application and brainstorm how to make it "web-able", please feel free to drop me a line. I'd love to help out.
Brian,
Thanks for the article. I'm looking for a little more info about the "using LV to serve up info on the web". If you are not the person to ask, please point me to the right one. Simply put, we have some x-y plots (traces)for instruments in our lab, with data stored in a custom in-house format. More and more people are asking for the ability to view this data. We have a viewer, but are hesitant to let lots of people install it for fear of the support monster that could grow into. Right now, we have about 10 users, but it could grow to 50, and I could see myself being more and more consumed with being the helpdesk for this app. So I thought, what about making it an app on the server, and letting users connect in via a browser. Then there is only one app installation to worry about, and people can see traces in their browser through the remote front panels thing. Installing a local copy of the RTE is not a problem. This brings up two questions. One, the prof dev system gives a 5 connection license, but only for itself, not for a built app. What's up with that? Does NI really expect that my dev machine will be serving out to others? I want to build an app running on a separate machine, and let it serve, but it looks like I have to buy additional connection licenses. Two, how do I make it so multiple connections can each view a trace of their choice? That is, so user A can view trace 103, user B view trace 107, etc. Do I use multiple copies of the app, each with a different name, running on the server? That doesn't seem right. Does the app call up multiple copies using vi server calls and vi templates? I'm at a loss here but I'm sure this is not a unique application.
Thanks,
Alvin.
Posted by: Alvin Moore | May 16, 2006 at 08:45 AM
Alvin,
This kind of application you mention is exactly what Remote Front Panels are perfect for. It keeps effort to a minimum because the VI you use locally is the same thing you use for remote access - no need to create a seperate web application.
#1 Licensing: As a developer, I just can't keep up with all the varieties and flavors. I do know that you need to obtain connection licences for a built application. My suggestion is to talk to your sales rep about numbers and cost.
#2 I have have good news and bad news on this front. The bad news is that LV 8 does not support different concurrent views of a VI from the same RFP application. The good news is that LV Europa (the next release) is going to support that. All you need to do is have the VI you're remoting marked as re-entrant (and of course, working as a re-entrant VI). Then each connection gets its own copy of the VI.
Right now only a single VI instance is remoted and your clients have to request control of the VI.
Posted by: Brian Tyler | May 17, 2006 at 10:25 AM