Earlier, I posted the interoperability between .net and Java web service. I will continue on how to access secured Java web service from legacy apps created with VB6 COM objects or classic Active Server Pages. Since we have already solved the interoperability issues between .net and securied Java web service, the next challenge is to register the .net proxy as COM object so it is accessible from VB6 and ASP pages.

Not all the .net classes can be registered as COM object. ASP can only work with COM objects that supports OLE automation so the it can work with even more limited .net classes. Proxy classes derived from WSE2 Microsoft.Web.Services2.WebServicesClientProtocol cannot be registered with dual interface. Fortunately, it is possible to define explicit interface for COM clients. The Visual Studio refactor feature made it pretty easy to create an explicit interface. After creating the interface, mark the class itself with [ClassInterface(ClassInterfaceType.None)] attribute. It is important that the explicit interface must be public. Another important step is do not forget to set ComVisible(true) in AssemblyInfo.cs.

The next step is to register the .net assembly as COM using "regasm myassembly.dll" or unregister with "regasm /u myassembly.dll". If we do private assembly deployment (that is, not registering the assembly into the global assembly catch with gacutil", the dll and the config files need to be copied into the directory of the exe that hosts the assembly. That means, for VB6 development, they need to go into the directory where VB6 resides. Furthermore, we need to rename myassembly.dll.config into HostExeName.exe.config.

With this technique, we can access fairly complicated, securied web services from our legacy apps.