XMLDA.NET White Paper
Copyright 2004-07 by Advosol Inc.
This paper was written in 2004 and was updated in April 2007 to include the features of XMLDA.NET V4 as well as information about the current operating system environments and the emerging OPC UA specification.
The .NET platform required for XML DA is now widely used and OPC server and client applications are being developed on the .NET platform. However, still most applications are built as DCOM based OPC DA server/clients, using .NET wrappers. Despite the many difficulties with DCOM configuration the transition to web services based designs is slow.
With most OPC talk being about the announced OPC Unified Architecture you may find it difficult to decide on how to approach new OPC projects.
This paper tries to shed some light on the related factors. It focuses on the development of OPC clients and explains different approaches and products.
Advosol Inc. started in 2002 with the development of .Net and XML-DA based client and server components and toolkits and offers high quality, matured products. These products will be explained in regards of what they do and why we decided for a particular implementation.
Current OPC Situation
OPC DA (Data Access) is broadly accepted for process data access applications and OPC-DA V2 servers are available for almost any equipment. OPC-DA is based on DCOM and this foundation is becoming a legacy technology. Microsoft will keep supporting DCOM but focuses new developments on web services. .NET3 combines the different Microsoft communication technologies (except DCOM) into one component, the Windows Communication Foundation (WCF).
The OPC standard currently most widely used is OPC-DA V2.05. OPC DA V3 offers some additional features but most client applications don't use these in order to be able to work with the many installed OPC DA V2 servers. The OPC AE (Alarms&Events) and OPC HDA (Historical Data) specifications are used to a much less extent than OPC DA. Other OPC specifications such as OPC DX, Commands and Batch are hardly used at all.
The XML DA specification defines a data access interface in the form of web service SOAP messages. XML DA is designed to provide the Data Access functionality on a web service base and is the only web services based OPC specification released so far.
OPC UA is created as a very general specification that covers all previous OPC specifications and can be implemented with web services communication but also on other communication stacks.
The designer of .Net based OPC application has the choice of using OPC DA, XML DA, or wait for OPC UA.
Application Design
New client applications are likely implemented as .NET applications. Since most installed OPC servers are DCOM based OPC DA servers, the client application needs some form of a .NET wrapper in order to be able to access these servers. The .NET wrapper can be implemented in widely different ways:
- .NET OPC DA Interface wrapper
There is no specification for a OPC DA .Net interface. Different wrapper products provide different user interfaces, either close to the OCP DA specification or quite different based on vendor preferences. The Advosol OPCDA.NET Client Component has a layered structure with the classes that implement the OPC DA interface and helper classes for simplified use.
These wrappers support only access to OPC DA servers. The OPC DA interface is not well suited to access XML DA or UA servers. Use this approach if you need to be able to use all OPC DA V2/V3 features.
- XML DA to OPC DA wrappers
Such wrappers enable XML DA clients to access OPC DA servers. Clients can be implemented on the rather simple XML DA interface with only eight methods. The wrapper can be:
- Built into the client application
The Advosol XMLDA.NET Client Component has the same interface as the .Net XML DA proxies created from the XML DA WSDL file.
XML DA servers can be accessed without overhead. For access to OPC DA server the calls are wrapped to OPC DA calls without going through an XML serialization. OPC DA server access is as efficient as with an OPC DA interface .Net wrapper.
- A Wrapper XML DA service at the OPC DA server location
Clients may access OPC DA servers at a remote location. The wrapper is actually an XML DA service that interfaces an OPC DA server. Any XML DA client can access the OPC DA server through this wrapper. The Advosol XDAGW-SS server-side Gateway is such a wrapper server.
- OPC UA to OPC DA wrapper
The OPC Foundation is planning an OPC DA wrapper that makes OPC DA servers accessible as an UA server.
Since UA clients are rather complex this approach is only advisable if the application actually needs to access UA servers.
Differences between OPC DA, XML DA and OPC UA
OPC DA and XML DA address the same interface functionality but they base on different communication technologies, giving them quite different characteristics that must be understood. OPC UA is designed to handle the sane features and much more.
| OPC-DA |
XML-DA |
OPC UA |
DCOM based
|
Web services based |
Defined as an interface that can be accessed as a web service or through an UA specific communication stack.
|
(D)COM is a mechanism to call procedures in a shared server. It defines two interfaces. The low level interface is used in the OPC Custom interface and is the preferred choice for C++ applications. The ActiveX layer is used in the OPC Automation interface and is implemented as a generic wrapper layer. OPC servers do only implement the custom interface and are accessed from ActiveX applications through the generic wrapper layer.
|
XML-DA is based on XML and SOAP (Simple Object Access Protocol). SOAP is a remote procedure call mechanism that transfers data as XML over HTTP communication channels. Different transports such as TCP or secured HTTP can be configured if client and server are running on .NET3.
The SOAP server’s capabilities are described in a WSDL (Web Service Definition Language) document. It defines the supported methods with their arguments and data types as they are transferred in XML form.
The methods available to the programmer to implement web services or clients depend on the tools used. This will be further explained below.
|
The OPC UA .NET implementation bases on .NET3 (WCF) and communicates through a secure HTTP transport or a UA specific binary TCP protocol.
OPC UA for .NET3 defines the available web service methods in a WSDL file. An additional set of methods are defined to manage the communiation. |
(D)COM calls are quite fast, especially InProc and local servers. The OPC-DA specification accordingly defines a large number of relatively simple functions (over 60). Access to remote server through DCOM is slower but still acceptably fast. DCOM uses a binary data transfer that is fast but limited to a local network because it does not pass firewalls well.
|
Web service calls involve XML serialization and possibly slow long distance Internet connections and may be slow. The XML-DA specification accordingly defines few (only 8) rather complex methods to achieve good performance. A call involving 1000 bytes of data is not much slower than on with only 10 bytes.
|
OPC UA uses either a secure (encrypted) HTTP communication with serialized XML data or a UA specific binary protocol over a TCP connection. |
| DCOM works with permanent connections and supports a data callback mechanism that allows the server to transfer unsolicited data. |
Web services are connectionless and stateless. Each server call is self contained and independent of previous calls. The exception is only the OPC XML-DA subscription mechanism that allows the client to subscribe to a number of items and then poll these items with the server buffering value changes.
Server initiated callbacks are not possible; the client has always to poll the server for new data.
|
OPC UA uses sessions to define the communication characteristics. Within the session there is a stateless web service access. The session times out if there is no communication. |
DCOM is not well suited for communications through firewalls and cannot be encrypted.
Proprietary tunneling solutions address this issue.
|
XML DA uses the well established SOAP protocol that is supported on practically all platforms. Inter-platform communication is simple. Using secure communication is simple between .NET3 server/clients is a matter of simple configuration. On other platforms the configuration may be more sophisticated even with .NET3 using only accepted web server extension standards.
|
OPC UA actually specifies an inner interface layer that is accessed through a communication stack such as the .NET3 web service layer. Clients and servers can only communicate when the implement a compatible communication stack. |
OPC-DA and XML-DA Coexistence
The large number of installed OPC-DA servers will have to be accessed for a long time period. Clients are more quickly converted to .Net or new applications developed as .Net desktop or web applications. Wrapper and gateway software is therefore required:
- To access OPC -DA servers from a .Net client application
- To access a remote OPC-DA server as an XML-DA server
- To access an XML -DA server from an existent OPC-DA client
A server is either implemented as an OPC-DA server or as an XML-DA web service. Sooner or later it will get hard to decide for server developers which one to choose. The Server Toolkits offered by Advosol enable the server developer to develop a customization assembly that can be used with the generic OPC-DA and XML-DA toolkit server.
OPC client applications will need to be able to access OPC-DA and XML-DA servers. This can be achieved using:
- A client internal .NET wrapper that supports access both types of servers
- External gateways, either to access XML-DA servers from an OPC-DA client or vice versa. An external gateway located at the OPC-DA server’s location is required to make the server accessible from a remote client
Gateway software for XML-DA to OPC-DA or OPC-DA to XML-DA conversion is available from Advosol and other vendors.
The gateway products are quite similar; they have to implement a standardized interface on both ends. The differences are in the used base (.Net or other web services tools), configuration options and error handling and reporting features.
OPC Client internal support for both standards can be achieved in two different ways.
- Define a .Net interface that is a combination of OPC-DA and XML-DA and wraps the OPC-DA procedure calls to XML-DA. The OPC Foundation has developed such sample code.
- Use the XML-DA interface and wrap the XML-DA procedure calls to OPC-DA. The client is developed as an XML-DA client but uses a wrapper that can access OPC-DA servers.
We think that the XML-DA interface is a much better approach for the following reasons:
- The wrapper layer should be optimized for the new standard and allow the legacy support to be dropped at a later stage without leaving many legacy features in the wrapper and the client application.
- XML-DA is connectionless and stateless. It is easy to implement that on the DCOM OPC-DA interface by just ignoring the features offered by a permanent connection. It is however rather complex to emulate the OPC-DA connection features on XML-DA.
- XML-DA has only few rather complex methods. The wrapper can easily implement these methods by calling a number of OPC-DA methods. Implementing the many OPC-DA methods on the few XML-DA function is difficult and likely inefficient.
For these reasons Advosol decided to offer two .Net wrapper products instead of a combined one.
- OPCDA.NET is a top performance .Net wrapper for access to OPC-DA servers only. The interface is similar to the OPC-DA custom interface and supports all mandatory and optional functions
- XMLDA.NET has an XML-DA interface and supports access to OPC-DA and XML-DA servers
Read the page How to develop OPC clients today for more information about different development approaches.
The XMLDA.NET Client Component
XMLDA.NET is a Advosol product that allows OPC clients to be developed as XML-DA clients and access either XML-DA or OPC-DA servers. It offers high performance access to both types of OPC servers and can easily be converted to a pure XML-DA client. Only the assembly reference needs to be changed.
The XMLDA.NET wrapper assembly is used. |
The .Net generated XML-DA web service stub is used. |
To explain how this is achieved I need to describe how web services are implemented.
Implementation of Web Services
The OPC XML-DA specification defines the services in the WSDL (Web Service Definition Language) document. SOAP and web services tools convert the WSDL specification into objects and methods. Each tool does generate a different set of methods and even web services tools generate different parameter passing definitions. Since all these tools convert from and to the same XML messages this doesn’t cause compatibility issues. Only some more work is required if a client or server is ported to another environment.
XMLDA.NET is provided in a version for .NET2 and one for .NET3.
The .NET3 version can use the BasicHTTP binding for compatibility with .NET2 or servers on other web services platforms. With .NET3 based servers the communication can be configured to use any of the .NET3 supported bindings and transports.
The .Net web services tools implement web service handling as follows:
|
.Net desktop or web application
A stub code assembly is created from the WSDL file. This assembly defines all data types declared in the WSDL file and a method for each declared procedure.
The stub code handles the XML serialization to produce the WSDL defined XML messages and to de-serialize the reply.
The SOAP XML messages are transferred over a communication such as HTTP.
The web server de-serializes the SOAP XML messages and calls the XML-DA web service.
The .Net web service tool generates web service skeleton code. The generated methods are identical to the methods created in the client stub code.
The server developer has to implement the methods according the functionality defined in the XML-DA specification.
The web service is a .Net assembly that is loaded by the web server when a client accesses this web service. |
Web service tool generated Stub Code |
Communication Link
( Internet, … ) |
Web server with SOAP support |
|
Since the assembly interface for the client side stub code and the web service are identical, the client application can reference the web service assembly in place of the stub code and access the web service assembly directly, without any XML handling.
This is not of much general importance because .Net assemblies cannot be shared. However XMLDA.NET uses it to embed an XML-DA server with the functionality of an OPC-DA wrapper into the client application.
|
The XML DA client application references the XMLDA.NET assembly in place of a XML-DA web reference.
XMLDA.NET is an XML-DA web service with an embedded XML-DA client and an OPC-DA wrapper.
Depending on the URL the client call is forwarded to the specified XML-DA web service or wrapped to OPC-DA server calls.
Multiple OPC-DA and XML-DA servers can be accessed by the client application.
|
XML-DA web server as
OPC-DA
wrapper |
|
The forwarding of XML-DA service request causes minimal overhead and OPC-DA servers can be accessed without any XML serialization. The OPC-DA wrapper uses hand-coded calls to the OPC-DA custom interface for top performance.
XML-DA subscriptions create an OPC-DA group and a data change call back handler. Data changes are buffered within the wrapper. The client subscription poll is extremely fast because it only has to read the buffered values within the .Net assembly. No COM calls are necessary at this time.
Helper Classes
XMLDA.NET also offers an additional layer of helper classes that enhance and simplify the XML-DA interface and make the client development much quicker. These classes are implemented on top of the XML-DA layer, insuring that the application always can use all XML-DA defined methods if the higher layer does not support a feature required in a particular application.
| BrowseTree |
The server is browsed into a TreeNode structure in a single method call.
XML-DA defines better browse functions than OPC-DA but still is restricted to browsing a single hierarchy level in one browse call.
In Windows Forms application the BrowseTree class displays the branches/items directly in a Windows TreeView control or in a TreeView/ListView combination.
|
| ListBuilder |
The ListBuilder Tool and Class create the request lists needed in XML-DA server calls. The tool creates an XML file and the class loads the definitions from the XML file instead of initializing the data structures within the client code.
|
| DataBind |
Server items can be associated with properties of user classes or Windows controls and the DataBind class handles the update, eliminating the need for user poll or callback handlers. In ASP.NET applications DataBind is used in combination with the ASP.NET DataBind feature.
By using DataBind in combination with the ListBuilder, complex applications can be realized with only a few lines of application code.
|
See the product specification for more details.
Sample Windows Application
The simple Windows desktop application shown here displays the current values of three items and updates the displayed values when the server executes a DataChange callback. There is no need for a user callback handler. Only the shown application code is required. A boolean value is displayed in a checkBox, an integer value is shown in a progressBar and an item with an array of doubles value is displayed in a row of a listView. Either OPC-DA or XML-DA servers can be accessed. Only the server URL needs to be changed. |
 | |
Dim OpcSrv As XmlServer = Nothing
Private Sub btnStart_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) _
Handles btnStart.Click
If Not OpcSrv Is Nothing Then
Return
End If
tbStatus.Text = ""
ListView1.Items.Clear()
ListView1.Items.Add("")
ListView1.Items.Add("")
Try
OpcSrv = New XmlServer(Me.cbOPCServers.Text)
Dim sbl As ArrayList = New ArrayList
Dim subscr As DataBindSubscription()
ReDim subscr(2)
subscr(0) = New DataBindSubscription("SimulatedData.Signal", Me.CheckBox1)
subscr(1) = New DataBindSubscription("SimulatedData.Ramp", Me.ProgressBar1)
subscr(2) = New DataBindSubscription("Dynamic.Analog Types.Double[]", _
Me.ListView1.Items(1).SubItems)
Dim err As OPCError()
OpcSrv.DataBindSubscribe(Me, subscr, 1000, Nothing, err)
tbStatus.Text = "Started"
Catch ex As Exception
tbStatus.Text = ex.Message
OpcSrv = Nothing
End Try
End Sub
Private Sub btnDisconnect_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnStop.Click
If Not OpcSrv Is Nothing Then
Dim err As OPCError()
OpcSrv.DataBindCancel(Nothing, Nothing, err)
OpcSrv = Nothing
tbStatus.Text = "Stopped"
End If
End Sub |
Help Documentation, Wizards and Samples
XMLDA.NET comes with Help2 documentation that plugs into Visual Studio’s help system and provides context sensitive help.
Visual Studio project and class templates create an XML-DA client project with small functional sample code or add a class with XML-DA client functionality to an existing application.
A number of VB and C# desktop client applications and ASP.NET web applications are provided. These range from very simple applications to samples that use all XML-DA defined methods and can be used to get a better understanding or as the base for a user application.
XMLDA.NET in ASP.NET applications
XMLDA.NET is well suited for use in ASP.NET web applications for the following reasons:
- ASP.NET applications are .Net applications that require some wrapper layer to be able to access OPC-DA servers. XMLDA.NET is such a wrapper and it has an integrated buffer for data changes. This is important because ASP.NET applications can only be polled from the user. Callbacks to the user browser from the server side are not possible.
- The ASP.NET application can be used from a browser on a user computer located anywhere. The ASP.NET application can therefore be installed on a web server that is networked with the OPC-DA servers. The OPC-DA servers can be accessed locally through the XMLDA.NET internal wrapper without XML serialization. Desktop client application to the contrary run on the user computer and can access remote OPC-DA servers only through an XML-DA gateway located at the OPC-DA server.
- Access to remote OPC-DA servers is possible by having an XML-DA gateway at the OPC-DA server’s location. It is accessed from the ASP.NET client application as an XML-DA server.
- XML-DA servers, when such become available, can be accessed without a wrapper layer.
- The XMLDA.NET DataBind subscriptions can be used in combination with the ASP.NET DataBind feature.
Sample ASP.NET Application
The simple ASP.NET application creates DataBind subscriptions according the definitions in an XML file.
The page is periodically refreshed and uses the ASP.NET DataBind feature to display new item values. |
 | |
<%@ Page language="c#" AutoEventWireup="true" %>
<%@ Import Namespace="System.Net" %>
<%@ Import Namespace="xmldanet" %>
<%@ Import Namespace="xmldanet.xmlda" %>
<%@ Register TagPrefix="xmldanet" Namespace="xmldanet" Assembly="XmlDANet" %>
<script runat="server" lang="c#">
//static string OpcURL = "http://localhost/OpcXmlGateway/OpcDaGateway.asmx" ;
static string OpcURL = "OCSTK.DA.Sim.32" ;
static XmlServer OpcSrv ; private void Page_Load(object sender, System.EventArgs e)
{
if( ! IsPostBack )
{
chkStopped.Checked = false ;
OpcSrv = new XmlServer( OpcURL );
OPCError[] err ;
DataBindSubscription[] subscr ;
OpcSrv.DataBindFromXmlFile( this, "AspDemo1.xml", "Demo1",
null, 1000, null, out subscr, out err );
}
if( OpcSrv == null )
chkStopped.Checked = true ;
DataBind();
}
//------------------------------------------------------
// method used in DataBind definitons
private object GetOpcItemValue( string SubscrID )
{
if( OpcSrv == null )
return "" ;
return OpcSrv.GetBindValue( SubscrID );
}
//------------------------------------------------------
private void btnRefresh_Click(object sender, System.EventArgs e)
{
// only postback handling is required
}
//-----------------------------------------------------
private void chkStopped_CheckedChanged(object sender, System.EventArgs e)
{
if( OpcSrv != null )
{
OPCError[] err ;
OpcSrv.DataBindCancel( null, null, out err );
OpcSrv = null ;
}
}
</script> <HTML>
<HEAD>
<title>XMLDA.NET Demo</title>
<meta content="Microsoft Visual Studio .NET 7.1" name="GENERATOR">
<meta content="C#" name="CODE_LANGUAGE">
<meta content="JavaScript" name="vs_defaultClientScript">
<meta content="http://schemas.microsoft.com/intellisense/ie5" name="vs_targetSchema">
<script language="javascript" id="clientEventHandlersJS">
<!--
var timer;
function window_onload()
{
timer = window.setInterval ("refresh()", 1000 );
}
function refresh()
{
if( Form1.chkStopped.checked )
window.clearInterval(timer);
else
Form1.btnRefresh.click();
}
-->
</script>
</HEAD>
<body MS_POSITIONING="GridLayout" language="javascript" onload="return window_onload()">
<form id="Form1" method="post" runat="server">
<asp:button id="btnRefresh" style="Z-INDEX: 101; LEFT: 144px; POSITION: absolute; TOP: 184px"
runat="server" Height="32px" Width="96px" Text=" " BackColor="White" BorderColor="White"
BorderStyle="None" OnClick="btnRefresh_Click"></asp:button>
<asp:CheckBox id="chkStopped" style="Z-INDEX: 111; LEFT: 24px; POSITION: absolute; TOP: 184px"
runat="server" Text="Stopped" Width="104px" Height="24px" AutoPostBack="True"
OnCheckedChanged="chkStopped_CheckedChanged"></asp:CheckBox>
<asp:Label id="Label10" style="Z-INDEX: 110; LEFT: 304px; POSITION: absolute; TOP: 192px" runat="server"
Width="120px" Height="24px">
<font face="Verdana" size="2">IntArr[]</font></asp:Label>
<asp:Label id="Label9" style="Z-INDEX: 109; LEFT: 200px; POSITION: absolute; TOP: 136px" runat="server"
Width="120px" Height="24px">
<font face="Verdana" size="2">Random</font></asp:Label>
<asp:Label id="Label8" style="Z-INDEX: 108; LEFT: 200px; POSITION: absolute; TOP: 104px" runat="server"
Width="120px" Height="24px">
<font face="Verdana" size="2">Step</font></asp:Label><asp:textbox id=tbRandom
style="Z-INDEX: 104; LEFT: 24px; POSITION: absolute; TOP: 136px" runat="server"
Height="24px" Width="168px" Text='<%# GetOpcItemValue("Random") %>'></asp:textbox>
<asp:textbox id=tbRamp style="Z-INDEX: 103; LEFT: 24px; POSITION: absolute; TOP: 64px"
runat="server" Height="24px" Width="168px" Text='<%# GetOpcItemValue("Ramp") %>'></asp:textbox>
<asp:textbox id=tbStep style="Z-INDEX: 102; LEFT: 24px; POSITION: absolute; TOP: 96px"
runat="server" Height="24px" Width="168px" Text='<%# GetOpcItemValue("Step") %>'></asp:textbox>
<asp:ListBox id=ListBox1 style="Z-INDEX: 105; LEFT: 296px; POSITION: absolute; TOP: 64px"
runat="server" Height="129px" Width="177px"
DataSource='<%# GetOpcItemValue("IntArr") %>'>
</asp:ListBox>
<asp:Label id="Label6" style="Z-INDEX: 106; LEFT: 24px; POSITION: absolute; TOP: 16px" runat="server"
Width="392px" Height="48px">
<font face="Verdana" size="4">XMLDA.NET DataBind Sample</font></asp:Label>
<asp:Label id="Label7" style="Z-INDEX: 107; LEFT: 200px; POSITION: absolute; TOP: 72px" runat="server"
Width="120px" Height="24px">
<font face="Verdana" size="2">Ramp</font></asp:Label>
</form>
</body>
</HTML> |
Benchmarks
The following benchmark data was measured in a C# .Net Windows Form application.
One item is read from OPC-DA and XML-DA servers using different wrappers and gateways.
The absolute times depend on the computer and could be 5 times faster on a top end PC. Interesting is mainly the relative performance of the different access methods.
|
|
Client with
OPCDA.NET Wrapper |
XML-DA Client with XMLDA.NET |
XML-DA web services client |
|
read |
read |
poll |
read |
poll |
| OPC-DA Server |
0.58 |
10 ms |
0.07 ms |
|
|
| XML-DA Gateway to local OPC-DA Server |
|
45 ms |
35ms |
45 ms |
35 ms |
| local XML-DA Server |
|
35 ms |
35 ms |
35 ms |
35 ms |
XML-DA Gateway to OPC-DAServer
via Internet access from client in USA to server in Europe |
|
1.2 s |
1.2 s |
1.2 s |
1.2 s | Notes:
1) OPCDA.NET clients create a group and add items only once and then call the read function repeatedly. XML-DA clients make independent read calls and the wrapper has to create a group and add items for each read call.
2) The large difference between read and poll times for XML-DA clients with XMLDA.NET is because a read connects to the OPC-DA server and reads the values from the server. For subscriptions the OPC-DA callback handler transfers the values into the XMLDA.NET subscription buffers and the poll only has to read the subscription buffer, no COM access is required.
3) The XML-DA server handles poll and read similarly and the processing time is mainly for the XML serialization respectively the Internet communication.
Additional related Advosol Products
- OPCDA.NET high performance wrapper for access to OPC-DA servers from .Net client applications
- OPCAE.NET high performance wrapper for access to OPC A&E servers from .Net client applications
- OPCHDA.NET high performance wrapper for access to OPC HDA servers from .Net client applications
- XDAGW-SS Gateway for access to OPC-DA servers from XML-DA clients
- XDAGW-CS Gateway for access to XML-DA servers from OPC-DA clients
- DANSrv OPC-DA server toolkit with application customization plug-in as a .Net assembly
- XDASrv XML DA Server Toolkit that is customized with the same .Net plug-in assembly as the DANSrv OPC DA toolkit server..
|
XMLDA.NET White Paper