|
|
|
|
|
|
Back to all documents
 Deciding when to use the OPC Web Client ActiveX Controls or OPCData.NET Components vs. OPC Web Client Web Service
Below is a list of chapters/sections you can jump straight to.
Introduction:
The OPC Web Client consists of the OPCData.NET Components, the OPC Web Client ActiveX Controls and the OPC Web Client Web Service
. The question is which of these two comonents do you use?
This paper will answer these questions by not telling you the answer, because the "right answer" is different
for everybody, but will put forth situations and recommendations and pose them to you as questions for you to ask yourself.
After reading this paper you should have a very good understanding of the differences between the OPCData.NET Components/OPC Web Client ActiveX Controls and the
OPC Web Client Web Service, and you should be able to make an informed decision on which component best suits your needs.
In this document you will see that the OPCData.NET ComponentsOPC Web Client ActiveX Controls, OPC Web Client ActiveX Controls and the OPCData.NET Components
are interchangably used. This is because both tools essentially provide the same output/abilities. The only difference between them is the underlying technology (COM or .NET).
Intended Audience:
- Developers
- Web Site Administrators (web-masters)
Defining the differences between the OPC Web Client ActiveX Controls/OPCData.NET Components and the OPC Web Client Web Service
The OPC Web Client essentially contains a 4th piece of software (the OPCData.NET Components , the OPC Web Client ActiveX Controls and the OPC Web Client Web Service
being 3 of the 4) and that is the OPC Web Client "EasyOPCDa" Process itself. Both the OPC Web Client ActiveX Controls/OPCData.NET Components and the OPC Web Client Web Service both interface to the "EasyOPCDA
" process which is what actually interfaces to the OPC Server(s).
There is a reason why we have both the OPCData.NET Components/OPC Web Client ActiveX Controls and a OPC Web Client Web Service for the OPC Web Client
, this is because both have advantages and disadvantages over each other, although the "end-result" of the applications you can create with these tools will essentially be
the same, it's more "how" you interact with the OPC Server(s) that differs.
Immediate benefits comparisson between the OPC Web Client ActiveX Controls/OPCData.NET Components and the OPC Web Client Web Service
Below is a very basic summary of the immediate and most important benefits/advantages of each component and the situations where they are put to best use:
|
OPC Web Client ActiveX Controls / OPCData.NET Components
|
OPC Web Client Web Service
|
- Best used when the OPC Server is on the same computer as the OPCData.NET Components/OPC Web Client ActiveX Controls because it has less overhead (uses a binary protocol as opposed to XML
(text) protocol) and can move more data in less time.
- Easier to develop with because your development environment can show you the properties, methods and events available to you.
- Does not require a Web Server to host any Services.
|
- Best used when the OPC Server is on a remote computer and where you need an agnostic transport as opposed to DCOM which is limited to Windows-based computers
- Uses XML as the transport so it does not require you to relax your network/firewall security.
- Can be used by any application capable of sending/receiving XML packets.
|
I have deliberately kept the above lists short. I really want to focus hard on the above-mentioned topics as it these subjects that should determine which control you use.
Identifying your needs
Before we can proceed further with this paper, we now need discover what the various needs are as far as the end-user application goes. Some questions:
What type of application do you want to build?
Do you want to build a regular executable? a Web-based system, an NT Service? Other...?
Is the OPC Server on the same computer as the application you plan on developing?
If not, is the OPC Server in the same network?
How do you feel about using DCOM as your data-transport to/from the OPC Server?
How many client applications do you plan on deploying your application to?
Now that we have asked the questions, let's dig deeper into each of them and discuss them. Inside this discussion we will explore how the OPCData.NET Components/
OPC Web Client ActiveX Controls and OPC Web Client Web Service would work, and then finally outline which one of these components would be best suited for that scenario.
Discussion Points - Probing deeper into the requirements
The first question listed in the previous section "What type of application do you want to build" is the question I
will leave till last. I think the other questions are initially more important. Let's now look at the other questions in turn:
Is the OPC Server on the same computer as the application you plan on developing?
Assuming the OPC Server is local
Lets further define this as meaning OPC Server is on the same computer as the developed-application.
In this scenario, your application will have the potential for the best performance in terms of data throughput. This is because issues with networks (such as latency and overall
connectivity) is eliminated.
Comparing the use of the OPCData.NET Components/OPC Web Client ActiveX Controls vs. OPC Web Client Web Service
The OPCData.NET Components/OPC Web Client ActiveX Controls are going to talk to the OPC Web Client Process using a binary protocol.
The OPC Web Client Web Service is going to talk to the
OPC Web Client Process using XML, which is a text-based protocol.
Applications built with OPCData.NET Components/OPC Web Client ActiveX Controls is talking directly to the OPC Web Client process.
Applications consuming the OPC Web Client Web Service
need to transmit their requests to the OPC Web Client Web Service, which in turn connects to the OPC Server to complete the transaction, then the OPC Web Client Web Service must send a transaction back to your application.
Best tool for this Job
Assuming the OPC Server is remote
How do you feel about using DCOM as your data-transport to/from the OPC Server?
Does DCOM scare you and you prefer to avoid it, or have a need to avoid it?
There are good reasons as to why DCOM might scare you into looking for an alternate transport. Thankfully the OPC Web Client
addresses this fear by means of the OPC Web Client Web Service which uses XML.
Reliability:
DCOM is known as a problemmatic protocol which can cause major problems when it loses a
connection to an OPC Server. With a non-negotiable 6-minute hard-coded timeout (thanks Microsoft) your software can be left-hanging while DCOM sits there waiting to timeout.
Security:
DCOM is not firewall friendly. You must open-up several ports on your firewall which not only
reduces your security, but the ports you need to open are the same ports that are typically sought-after by most viruses, worms and hackers.
Assuming the OPC Server is available in your Local Area Network (LAN)
Assuming the OPC Server is available on a remote network (over the internet)
You are happy to use DCOM, or have no choice but to use DCOM
If DCOM doesn't scare you (it shouldn't scare you, it has been used within the industry now
since the mid 90's) and you are happy to go to each computer where your application will run and you are happy to configure the DCOM security (click here for our DCOM Tutorial), then:
Assuming the OPC Server is available in your Local Area Network (LAN)
Assuming the OPC Server is available on a remote network (over the internet)
How many client applications do you plan on deploying your application to?
This question should really be asked along with the following question:
What is the approximate number of Tags that will be in use by each client?
Only one application
For single applications, the importance of this question is not one that should dictate which component should be used. Rather, the previous questions above should be the determining
factor on which component to use in your application.
Between 2 and 5 applications
If your application will be deployed to between 2 and 10 computer then you will need to consider the folowing:
- OPCData.NET Components/OPC Web Client ActiveX Controls deployment
The OPC Web Client process will need to run on each client computer. Therefore if you had one common OPC Server reading 10 tags from one device for example, and let's
say that all the client applications were reading all 10-tags from that device... then your OPC Server would have a total of 10 OPC Client connections. The more clients you
deploy, the more connections will be made to the OPC Server(s).
OPC Web Client Web Service deployment
The OPC Web Client Web Service will run on a Web Server. Because each client application will send/receive XML packets to the OPC Web Client Web Service, only one OPC Web Client
process will be running (on the web-server) which will handle all OPC connectivity. This basically means that 10 OPC Client applications are actually being consolidated by the OPC Web Client
process into one connection to the OPC Server. Therefore, less load occurs on the OPC Server.
5 or more applications
If your system will use more than 10 OPC Clients, then you definitely need to consider the two subjects above "OPCData.NET Components/
OPC Web Client ActiveX Controls deployment" and "OPC Web Client Web Service deployment".
Best tool for this job
Introducting the "Number of Tags" question into this equasion
There is a very good reason as to why the number of tags your client applications use absolutely must be considered.
Going back to the Benefits Comparisson (at the top of this page) we discussed how:
- OPCData.NET Components/OPC Web Client ActiveX Controls uses a binary protocol
- OPC Web Client Web Service uses XML (text-based protocol)
As a general rule, binary protocols are much faster than text-based protocols, so there will be a difference in performance in this respect.
If your application requires either:
- the need to have some tags at a very high rate of speed, i.e. 50ms
- the need to read many tags (> 20) frequently
The more tags you read (whether it is in the speed by which you read the tags or the number of
tags you are trying to read overall) will all consume bandwidth. Bandwidth is something that needs to be considered. Knowing the fact that Binary protocols are faster than Text protocols, the OPCData.NET Components/
OPC Web Client ActiveX Controls look like better choices for more data-intensive applications. On the other hand, if you throw security/DCOM into the equasion then the
OPC Web Client Web Service looks more attractive.
Summary and General Recommendations
As you can tell, this particular issue is difficult to answer without knowing more information
ahead of time, this is why it is so important to plan your system ahead of time.
One application
Between 2 and 5 applications
Small Tag usage
Preference for avoiding DCOM
No preference on the transport
Large Tag usage
Preference for avoiding DCOM
No preference on the transport
Determining the Type of application you wish to create
Now that all of the other questions have been explorered, and now that we have discussed where
each component best fits, it's now time to put what we have discussed into perspective with regards to the type of application you intend to create.
This is an important subject because different types of applications will require very-different approaches in development. For example, creating an
NT Service application on the same computer as the OPC Server will have very different challenges and will follow a completely different development
process than developing a web-based application where the code runs directly within the Browser. Indeed, it is these scenarios we now seek to discuss and determine what is the best component to use.
Executable applications and/or NT Service applications
These types of application in themselves can use either the OPCData.NET Components/OPC Web Client ActiveX Controls or the
OPC Web Client Web Service. Depending on the development language you choose, you might be restricted to using either the OPCData.NET Components/OPC Web Client ActiveX Controls or OPC Web Client Web Service. Development
languages such as VB.NET or C# are more flexible allowing you to choose which component to use.
Generally, you should consider the questions raised previously and determine from there which component is best:
Scripted and/or Web-based applications that run within the Browser or at the Web Server
These types of applications are typically more "light-weight" than their executable
counter-parts, but have the potential to be deployed to more computers, making them more scalable.
Generally, you should consider the following questions (raised above) to determine which component is best for you.
Summary
There are MANY factors involved in determining which component is the best to use for your situation. Whether it is the OPCData.NET Components/OPC Web Client ActiveX Controls or the
OPC Web Client Web Service, the OPC Web Client as a whole has what you need to develop your system and is designed to handle many of the
obstacles that would otherwise greatly reduce your abilities to create some of those applications that we have discussed here.
|
|
|
|
|
