|
Return to Documents list
Writing hybrid applications using OPCData.NET Components and also consuming the OPC Web Client Web Service as a form of communications redundancy.
 Introduction
This paper discusses how you can write an application that essentially uses both the OPCData.NET Components and the OPC Web Client Web Service in the same application.
Because the OPCData.NET Components contain the same interface for both the COM and Web Service
components, you can very quickly and easily create an application that uses one tool to communicate to your OPC Server, and then in the event of a loss of communications switches over to the other component.
For example:
Use the OPC Web Service to read/write data to/from the OPC Server(s).
If/when that communications fails (web-server failed for example) then switch to the COM/DCOM
communications instead cutting-out the web-service and communicating to the OPC Server directly.
Pre-requisites
If you are an OPC Web Client ActiveX Controls developer then this paper is not for you.
This white-paper is specifically oriented towards the Visual Basic.NET or C# developers using the OPCData.NET Components and OPC Web Client Web Service.
Some basic knowledge of the OPC Web Client and .NET technology/development is recommended, but not required. This paper will not discuss Microsoft .NET technology nor development strategies directly.
Common Interface
The OPCData.NET Components make use of a common interface that allows you to write code for use with the OPC Web Client Web Service
or the main back-end engine which would allow you to communicate directly to the OPC Server via COM/DCOM.
This common interface is going to be the key in which the application you create is going to be somewhat agnostic to the form of communications that currently in use.
Step 1 - Defining the Interface
You can define the interface within your .NET application as follows:
The entire namespace is shown above
With the interface defined, you have not actually specified a component/object in which to use it with
Step 2 - Defining the Transport (COM/DCOM or the Web Service)
The interface simply allows us to access the properties/methods that are common between the components. We now need to specify which component we want to use:
Using the COM/DCOM transport allowing your client-application to communicate directly to the OPC Server
The entire namespace is shown above
Using the Web Service:
The entire namespace is shown above
At this point, you can now start coding your OPC Client. The transport will be decided based on which component you used, i.e. .
Step 3 - Determing when communications is lost
Now that your communications is setup and your OPC Client applicaiton is reading/writing to/from the OPC
Server(s) you now need to implement a way in which you will be able to identify and react to when communications is distrupted.
OPC Web Client Web Service
If using the OPC Web Client Web Service then the following exception will be thrown upon trying to make a call to the Web Service:
System.Net.WebException:
The underlying connection was closed. Unable to connect to the remote server.
When this particular exception is thrown, that will be your cue to switch to the alternate COM/DCOM transport via:
OPCData.NET Components
If using the OPCData.NET Components then the following exception will be thrown upon trying to make a call to OPC Web Client process:
or,
When such an exception is thrown, you can simply switch to the alternate Web Service transport via:
A Note on Exceptions
Due to the multitude of reasons why an OPC Server might become unavailable, you should expect to potentially see other exceptions too.
Step 4 - Putting it all together
Now that we have discussed this concept and looked at the specific objects to use, lets put together a simple application to demonstrate this concept.
- Create a new VB.NET or C# Winforms application.
- Reference the OPCData.NET Components within the project
- Add a button to the form, then double-click on the form to open the code-behind it.
- Create the interface to the OPC Web Client object by adding it is a member variable to the form class:
 |
- At this point, we have not defined the actual transport for the OPC Web Client, so lets detect this and set it so within the buttons click event.
- Enter the following code:
If EasyDA Is Nothing Then
EasyDA = New OPCLabs.EasyOPCDANet.EasyDAWS("http://localhost/EasyAccess")
End If
- The above code will automatically choose the OPC Web Client Web Service when no transport is specied.
- The next step is to add some TRY..CATCH blocks because we are going to attempt to read a value of a Tag. So add a TRY...CATCH block below the text previously entered.
- Within the TRY section we will add an IVTQ object to receive the value of the Tag Read.
- Ehter the following code beneath the previous code added:
Try
Dim iVTQ As OPCLabs.EasyOPCDANet.IVTQNet = EasyDA..ReadItem("", "
OPCLabs.KitServer.2", "Simulation.Random")
MessageBox.Show(iVTQ.Value)
Catch ex As Exception
End Try
- The above code will attempt to read the value of a Tag, and will simply display its value within a message box if the read succeeds.
- In the Catch block, we are going to simply switch the OPC Web Client to an alternate transport. We are going to
do this by simply detecting the current transport (the type of object) and then switching to the other. This way we do not need to maintain any flags to accomplish the same thing.
- In the CATCH block, insert the following code:
If TypeOf EasyDA Is EasyDAWS Then
EasyDA = New OPCLabs.EasyOPCDANet.EasyDACOM
Else
EasyDA = New OPCLabs.EasyOPCDANet.EasyDAWS("http://localhost/EasyAccess")
End If
- The above code will simply detect the current data-type of the "EasyDA" object and will simply re-define it to use the alternate object type.
- The resulting code should look as follows:
Conclusion
This paper has shown you how the OPC Web Client can in fact deliver a transport-redundancy ability within
your applications. This ability will allow you to create an application that is not dependant upon one form of transport and is easily/quickly able to adapt to situations by switching to an alternate transport.
The example shown in this paper is very basic, and might not be the best way of using this functionality but
was shown as an easy way of accomplishing this ability. One suggestion might be to create your own class which consumes the OPC Web Client and handles this switch-over automatically so that your client-application
is truly unaware of the underlying transport.
Downloads
|
