Soapsuds | The .NET and COM Interoperability Handbook (Integrated .Net)


Team-Fly

	.NET and COM Interoperability Handbook, The By Alan Gordon
	Table of Contents

	Chapter Eleven. .NET Remoting

Soapsuds

If you don't want to have a shared assembly at all, you can also use the soapsuds tool to generate metadata for your .NET remoting clients to use. Soapsuds is a command-line utility that is included with the .NET Framework SDK. It generates metadata that allow a client to call a .NET remoting server, even if the authors of the server did not create a shared library that contains the types that the server exposes. You can run soapsuds against a URL or directly against the assembly that contains the types that will be exposed through .NET remoting. Use the url parameter to generate your metadata from a URL as shown here:

 soapsuds url:[SchemaURL] oa:[AssemblyName]

The URL that you specify is the URL for the schema file for the server, or you can run soapsuds against an assembly using the types parameter as shown here:

 soapsuds type:[type1,assemblyname][;type2,assemblyname]     oa:[AssemblyName]

Here, type1 and type2 are types that you want to generate metadata for, and assemblyname is the name of the assembly that contains these types.

You can run the following command to generate metadata for our server using its URL:

 soapsuds url:http://localhost:8080/company.soap?wsdl     oa:companyassembly.dll

You can also use the following command to generate metadata using the assembly that contains the remotable types:

 soapsuds types:SharedLibrary.Company,SharedLibrary     oa:CompanyServer.dll

You have your choice of two kinds of proxies. The previous commands will create a wrapped proxy, which has the URL of the server embedded into it and can only use SOAP channels. You can call soapsuds with the nowp parameter (as shown in the following) to generate a proxy that will work with any channel and that will work with configuration files:

 Soapsuds url:http://localhost:8080/company.soap?wsdl nowp     oa:companyassembly.dll

Running the soapsuds command generates an assembly that contains metadata for the ICompany interface and the Company and Employee classes. You can now reference the soapsuds-generated assembly from your client and write the same code that you did before.

 using System; using System.Runtime.Remoting; using CompanyServer; namespace CompanyClient {     class Class1     {       [STAThread]       static void Main(string[] args)       {         RemotingConfiguration.Configure("CompanyClient.exe.config");         Company obj=new Company();         Console.WriteLine("Company name=",           obj.CompanyName);       }     } }

Unfortunately, if you attempt to use the Employee class, you get an XML serialization error. You can see the problem by looking at the (cleaned up) definition of the Employee class in the soapsuds-generated assembly:

 class public serializable Employee          extends System.Object {     .field public int32 mID     .field public valuetype System.DateTime mHireDate     .field public string mLastName     .field public string mFirstName     .field public valuetype System.Decimal mSalary     .method public hidebysig specialname rtspecialname             instance void  .ctor() cil managed     {       [...]     } }

Notice that this class looks nothing like the original definition of the Employee class. Soapsuds simply does not work well with marshal- by-value classes.

You can solve this problem by using soapsuds to generate source code instead of an assembly. You can then build your own assembly that contains only the marshal-by-reference types and interfaces, and clients can reference this assembly. You still have to require developers to ship a shared DLL for marshal-by-value classes. You can instruct soapsuds to generate source code by using the -gc parameter to soapsuds. Running the following command generates source code for the server:

 soapsuds url:http://localhost:8080/company.soap?wsdl gc nowp

Soapsuds generates one source file for each namespace that the server contains. You can compile the marshal-by-reference classes and interfaces directly into the client and then put any marshal-by-value classes, which must be present on both the client and server, in a shared assembly that can be referenced from both the client and the server. Keep in mind that my recommendation is still to put your interfaces and marshal-by-value classes in a shared assembly and keep the implementation of your marshal-by-reference classes private to your server. If you use this approach, you do not need soapsuds.


Team-Fly

Top