services|web|xml| check box | Microsoft COM + Web service: Routing to XML Web services through check boxes
John Noss and Jonathan Hawkins
Microsoft Corporation
November 2001
Summary:COM + WEB Services has new features that you can integrate with Microsoft. NET Remoting and implement the checkbox activation of XML WEB Services Publishing through a SOAP for COM + component. This article introduces a few examples of basic interoperability, configuration, and managed and unmanaged COM + components (XML Web servi on Microsoft Windows. NET Server and Microsoft Windows XP Professional) CES release) deployment.
Directory
- Brief introduction
- Simple known object (WKO) sample
- Simple client-activated object (CAO) example
- Transactional Components Sample
- It's all just beginning.
Brief Introduction
COM + WEB Services has new features that you can integrate with Microsoft. NET Remoting and implement the checkbox activation of XML WEB Services Publishing through a SOAP for COM + component. This article introduces a few examples of basic interoperability, configuration, and managed and unmanaged COM + components (XML Web Ser on Microsoft Windows. NET Server and Microsoft®windows®xp Professional) Deployment of the vices release). The example also introduces several new features that enable clients running Windows XP to access XML Web Services on a remote server.
When developers use. NET Remoting and managed code to refine existing unmanaged COM + server and client code, these features help them to leverage and simplify the migration process. During the testing phase of the. NET Framework, a number of users asked how to configure. NET Remoting for simple, cross-computer activation operations. The solution for COM + WEB services is to automatically configure both the server (Microsoft Windows. NET Server) and the client (Microsoft Windows XP Professional) computers to use the. NET Remoting to Provides SOAP to replace DCOM.
Microsoft Windows XP and the Microsoft. NET Framework are the two most important software releases this year. Both are designed to streamline processes and improve the capabilities of software developers, so it is natural to use both products and leverage their strengths to provide an integrated, easy-to-use solution. COM + WEB service provides an easy way to publish COM + components as XML Web services, as well as new integration features for accessing XML Web services from client computers. You can learn about its easy-to-use features from the following Microsoft Visual Basic scripting Edition (VBScript) examples that determine the current temperature of the Alaska Fairbanks. Run this example on Windows XP (installed. NET Framework) or on Windows. NET Server:
Set soapobj = GetObject ("soap:wsdl=http://www.xmethods.net/sd/temperatureservice.wsdl") wscript.echo "Fairbanks temperature =" & Soapobj.gettemp ("99707")
In the above example, the server is an Apache SOAP server running on Linux, but you can also use any SOAP V1.1 server with a standard WEB service Description Language (WSDL) description feature.
Note: if the "server not Found" error occurs, you will need to manually configure the firewall settings in the Internet options in Control Panel.
One of the advantages of using SOAP as a communication protocol between computers is that it increases the kind of computers that can interoperate.. NET Remoting has the following two basic operational models:
- known objects (WKO): Wko is the most common XML Web Services model supported by the SOAP V1.1. It allows you to work with other computers running SOAP V1.1 compatible stacks. Servers and clients can be non-Windows servers running Apache SOAP and Pocket PCs running Pocketsoap, or windows-based servers and clients. The only requirement is that the description feature that is compatible with the WSDL 1.1 version must be installed on the server in order to generate the appropriate proxy. This agent was generated at run time and no user intervention was used for the first time using a WSDL moniker.
- client-activated object (CAO): The CAO provides a richer development environment, including a stable and persistent connection. Rather than a typical XML Web Services model, it is more like the DCOM model, but requires a version of the. NET framework installed on both the server and the client.
COM + WEB Services can use the Wko and Cao two activation models, and all server applications can provide Wko and Cao endpoints. By combining activation models, XML Web Services, and. NET Remoting, developers can easily combine and match managed and unmanaged clients and servers. The following table shows examples of the scenarios supported by the two activation models.
table 1:wko Model supported ScenariosWko Client Wko Server VB 6.0 or unmanaged C++VB 6.0 or unmanaged C++VB 6.0 or unmanaged C++VB. NET or C#VB 6.0 or unmanaged C++soap V1.1 (described in WSDL) VB 6.0 or unmanaged C + + Microsoft SOAP (ATL server,soap TK) C # or VB. Netsoap V1.1 (described in WSDL) C # or VB. NETVB 6.0 or unmanaged c++c# or VB. NETVB. NET or c#c# or VB. NETMicrosoft Soap (ATL server,soap TK) Microsoft soap Toolkit V2.0VB 6.0 or unmanaged C++microsoft soap Toolkit v2.0c# or VB. Netsoap V1.1VB 6.0 or unmanaged C++soap v1.1c# or VB. NET
table 2:cao Model supported ScenariosCao Client Cao Server C # or VB. NET (early bound) VB 6.0 or unmanaged C++VB 6.0 or unmanaged C++VB 6.0 or unmanaged C++VB 6.0 or unmanaged c++c# or VB. Netc# or VB. net[td]c# or VB. NET
This new COM + Web service applies to the following users:
- COM + users that are currently installed with Microsoft®visual basic®6.0 or unmanaged Microsoft Visual c++®com+ applications that require certain activation actions through a firewall. (using SOAP does not exclude access to the same components on the server through DCOM, which the client computer can select.) For these customers, if you want to use SOAP instead of DCOM, using both the client-agent export and the CAO model requires no changes to the client and server applications. You only need to enable SOAP on the server application, export it as a client agent, and then install the agent on the Windows XP computer that you want to use as the SOAP client.
- A company that is completely migrated to managed code on Windows XP and Windows. NET Server. COM + WEB Services help you set the remote endpoint at both ends of the connection.
- Developers who need to combine and match various services in both scenarios, and developers who write managed server components, or managed client applications with unmanaged server components. In the second case, the developer can take advantage of the COM + Web service to take full advantage of the earlier unmanaged components before replacing them with managed code.
simple Known object (WKO) sample
In addition to providing SOAP support for Linux and Apachein, it is easy to apply COM + Web services to other Microsoft products, such as ATL Server Web services. Simply use Microsoft Visual studio®.net to build, compile, and deploy the default ATL WEB service on the server. The client code that accesses it is as follows (please replace the WEB server name that hosts the ATL server application
MyServer, replace with the name of your ATL Server DLL
Jaltserver）：
The preceding example is a simple description of a new SOAP moniker that is contained in Microsoft Windows XP and Microsoft Windows. NET servers.
Data Publishing
If you only want to provide data instead of using data, simply select a check box, and then enter a value for the IIS virtual root name. To create a complete COM + Web service, follow these steps:
Use Visual Basic 6.0 to create a simple Microsoft Activex®dll and enter the following code:
Function Add (ByVal Value1 as Double, ByVal Value2 as Double) as double Add = Value1 + value2end Function
On the Visual Basic Project Properties page
Generaltab, set the
Unattended ExecutionAnd
retained in Memory, and in
Componenttab, select
Remote Server Files。 Build this DLL using the Visual Basic development environment.
After you create a Visual Basic application, you need to register it as a COM + application. Start the Component Services Administration tool to create a COM + application on Windows XP. (In this example, the application is named Vb6soap.) Import the DLL you created as a component, and then browse to the COM + Application Property page
activationtab, select
Uses SOAP, enter a
SOAP Vroot(for example, Vb6soap), and then click
OK(as shown in Figure 1).
Figure 1:vb6soap COM + Application Properties page
The application is now published as an XML Web Services and can be activated using SOAP. Using Internet Explorer to browse to Http://localhost/VB6Soap/default.aspx, you find a hyperlink on the ASPX page that links to the WSDL generated by your component. The following VBScript activates your component:
If you replace the localhost in the above script with your server name, it can also work on the remote client computer. The referenced page (in this example, VB6Soap.Calc.soap) is a component ProgID that ends with a. Soap suffix.
To access the same endpoint via the SOAP Toolkit (provided with Windows XP Professional and not using. NET Remoting), run the following VBScript:
To simplify the process of publishing SOAP on a server, you can use Microsoft c#™ or Visual Basic. NET, and from
ServicedComponentInherited. The following are examples of managed code for a simple managed component:
Using system;using system.reflection;using system.runtime.interopservices;using system.enterpriseservices; [Assembly:applicationname ("Cssoap")] [Assembly:applicationactivation (Activationoption.server, soapvroot= "Cssoap")] [Assembly:assemblykeyfile ("Cssoap.snk")]namespace cssoap{public interface Icalc {double Value1, double Value2); [ClassInterface (Classinterfacetype.autodual)] [TransactionAttribute (Transactionoption.none)] public class Calc: ServicedComponent, Icalc {public double Add (double Value1, double Value2); {return (Value1 + Value2); } }}
In the example above, it is worth noting that
applicationactivationProperty:
[Assembly:applicationactivation (Activationoption.server, soapvroot= "Cssoap")]
Establish a C # component, install it in the global assembly cache, and then run Regsvcs.exe to register it as a COM + application. The component is then published as an IIS virtual root and a SOAP endpoint. To successfully remotely use
ServicedComponent, you will also need to use the Gacutil.exe or. NET Framework user interface to put this compiled assembly into the global Assembly cache (GAC). To access this SOAP endpoint through WSDL, use the following VBScript:
As a simple example of SOAP interoperability, SOAP Toolkit is provided with Windows XP Professional, and even if the. NET framework is not installed on client computers running Windows XP, the following VBScript can also be used to access COM + SOAP endpoint:
For simplicity, the examples above all use VBScript to access the WEB service. The SOAP WSDL moniker can actually be written using Visual c+, Visual Basic 6.0, Visual Basic. NET, or C #. For example, Visual Basic. NET can also use compiled managed code to access the same object, as shown in the following example:
Imports systemimports System.Runtime.InteropServicesModule wkoclient Sub Main () Dim wsdlmoniker = "Soap:wsdl=http ://localhost/cssoap/cssoap.calc.soap? WSDL "Dim obj as Object obj = Marshal.bindtomoniker (wsdlmoniker) Console.WriteLine (obj. ADD (1,2)) End SubEnd Module
VBScript is used to indicate that both managed and unmanaged clients have access to COM + components that are published as COM + Web services. In large organizations or applications, it is difficult to transform all parts at once, and COM + WEB services allows a subset of applications to be converted to managed code without having to completely rewrite existing applications immediately.
Simple client-activated object (CAO) Example
COM + Web Service Publishing on the server publishes each component as Wko and CAO in two forms, so no additional server configuration is required. The only action to do on the server is to select
Uses SOAPcheck box (located on the COM + Application Property page
activationtab) and in the
SOAP VRootAfter you enter a value in the text box, export the COM + application as an agent. The steps necessary to export the agent application are shown below:
- Right-click the vb6soap COM + application in the Component Services Administration tool and select Export, as shown in Figure 2.
Figure 2: Component Services management tools
- In the COM + Application Export Wizard shown in Figure 3, enter the location and name of the proxy. msi file.
Figure 3:com+ Application Export Wizard
- Installs the agent. msi file on a separate client computer as a pre-generated COM + application.
The agent is configured appropriately at installation to access the correct server and virtual root through SOAP. For client activation, you can use a generic unmanaged COM + activation (for example,CoCreateInstance,CreateObject , and so on) without using a WSDL moniker. After you create an application proxy on the server and install the above Visual Basic Calculator sample on a separate client computer, the following VBScript accesses the server through SOAP:
If the agent does not enable COM + WEB services, the VBScript code above will use DCOM to access the server application.
