webMethods and Microsoft .Net

webMethods 6.1 has opened an interface to Microsoft .Net. This makes it very easier to make calls to components that are very hard to create from Java Runtime. This also allows easier IS client creation from MS.Net. I would not take the client creation as the feature because, anyways it was easier earlier, using InterOps, though by having managed interface, it is now faster than earlier.

webMethods does not allow calling Global Assembly Cache
webMethods can call any service, so the new .Net services can call the .Net assembly classes. The assembly name has to be hard coded in the .Net properties of the service. This makes it further difficult in migration activities. After a considerable research, I could make out that the assembly path can be relative to INTEGRATION_SERVER folder also than using absolute path.

webMethods creates a service for each method selected for interfacing
When creating a .Net service and we need to select assembly, it marks out the classes and their respective methods in the assembly. All selected methods are create a .Net service in the specified folder. So for example, when an assembly has two classses with same procedures/methods with same name, they create a conflict in namespace, so either they have to be in a different logical folder or they have to manually created. This also makes the integration server runtime little heavier I believe, as each method will create a service and then it will be statically loaded in memory when server starts. So it is recommended to create the .Net services for the methods need to be called. I would always avoid calling the .Net service directly, as that will make my application hard to reengineer in case of .Net CLR has performance problems when called from wM.

Every assembly load has a CPU spike
So far I have seen every assembly load, means appdomain load, has a considerable CPU spike. This spike is due to creation of reflection object loading on the CLR. As long as the class lifetime is managed properly, we are cool from infrastucture point of view, other wise .Net usage has to be revisited for the consideration.