Advosol提供的軟件組件和工具使得OPC與.NET的整合非常簡單：

• .Net OPC客戶端

　　該客戶端開發(fā)組件允許.Net客戶端應(yīng)用程序訪問OPC服務(wù)器。這些軟件包要比.Net包裝器簡單的多。它們?yōu)楦咝实膽?yīng)用程序開發(fā)提供所需要的一切。所有的OPC定義的功能可以通過一個數(shù)據(jù)正確轉(zhuǎn)換后的類來輕松訪問，附加的軟件層提供了一些更高層次的功能，如在一個.Net樹形結(jié)構(gòu)中瀏覽服務(wù)器支持的項。Visual Studio項目和類生成向?qū)沟檬褂闷饋砗唵慰旖?。在Visual Studio整合的幫助提供上下文相關(guān)的幫助。

• .Net OPC服務(wù)器

 　　.NET服務(wù)器工具箱擁有一個與通用的COM服務(wù)器和一個.NET包裝器相兼容的OPC標準，它允許應(yīng)用程序指定服務(wù)器需要通過VB.Net/C#以一個程序集的方式實現(xiàn)的功能。

現(xiàn)在，怎樣開發(fā)OPC DA服務(wù)器？

　　現(xiàn)在如果您需要開發(fā)一個新的OPC服務(wù)器，那么您需要制定一個基本的決定：是否當(dāng)前的開發(fā)需要在傳統(tǒng)的DCOM技術(shù)或當(dāng)前的.NET和XMLWeb服務(wù)的基礎(chǔ)上完成呢？

　　Advosol提供的這些組件實際上阻止了這些不得不做出這樣的決定。你可以使用Visual Basic 或C#來開發(fā)一個OPC服務(wù)器作為一個.Net程序集，并且以一個OPC DA或XMLDA服務(wù)器來運行它。

　　由于它在OPC服務(wù)器中是一個通用的工具箱，Advosol服務(wù)器工具箱在一個通用的服務(wù)器部分實現(xiàn)了OPC特定功能并且用戶只需要提供與設(shè)備訪問的功能的一個.Net程序集。 該.Net程序集不需要任何COM功能，它是多線程的并且沒有基于ActiveX解決方案的局限性。

現(xiàn)在，怎樣開發(fā)OPC DA客戶端？

　　OPC的DCOM基礎(chǔ)框架已被宣布為傳統(tǒng)技術(shù)，現(xiàn)在微軟新的開發(fā)基礎(chǔ)框架是.Net和web服務(wù)。OPC客戶端應(yīng)用程序的開發(fā)人員如此快速地遵循這一趨勢，而且新的OPC客戶端可能被開發(fā)為.Net應(yīng)用程序。然而目前已安裝的設(shè)備中，大多數(shù)擁有的是基于DCOM的OPC DA V2的服務(wù)器。需要遠程訪問的設(shè)備可能擁有基于web服務(wù)技術(shù)的OPC XM-DA服務(wù)器。這就意味著目前這些客戶端大多數(shù)訪問OPC-DA服務(wù)器，不久將可能訪問XML-DA服務(wù)器。

Advosol offers software components and tools that makes the combination of OPC and .NET real simple：

• .Net OPC Clients

The client development components allow .Net client applications to access OPC servers. These software packages are much more than simple .Net wrapper. They provide everything needed for efficient application development. All OPC defined functions can be called through easy to use classes with all data properly converted. Additional software layers offer a number of higher level functions like browsing the server supported items into a .Net TreeNode structure. Visual Studio project and class generation wizards make usage simple and quick. The Visual Studio integrated help offers context sensitive help.

• .Net OPC Servers

The .NET server toolkits have an OPC standard compliant generic COM server and a .NET wrapper that allows the application specific server functionaly to be implemented with VB.Net/C# as a .NET assembly.
 

How to develop OPC DA Servers today?

If you have to develop a new OPC server today then you have to make a basic decision: Should the development be done on the legacy DCOM technology or the current .NET and XML Web Services base?

Advosol offers components that actually prevent having to make such a decision. You can develop an OPC server as a .Net assembly using Visual Basic or C# and run it as an OPC DA or XML DA server.

As it is common in OPC server toolkits, the Advosol server toolkits implement the OPC specification in a generic server part and the user only has to supply a .Net assembly with the device access functions. This .Net assembly doesn't use any COM features, is multi-threaded and doesn't have the limitations of an ActiveX based solution.

How to develop OPC DA Clients today?

The DCOM base of OPC is declared a legacy technology and Microsoft bases new developments on .Net and web services. Developers of OPC client applications follow this trend rather quickly and new OPC clients are likely developed as .Net applications. Most devices installed today however, have DCOM based OPC DA V2 servers. Devices that need to be accessed remotely are likely to have OPC XML-DA servers based on the web services technology. This means that clients currently mostly access OPC-DA servers but will soon have to be able to access XML-DA servers.