Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Moving DNA applications from COM+ to .NET: Drill down to Serviced Components : Page 2

The question "Is COM dead?" has been hanging around since the release of the .NET PDC Technology preview. Having played with two beta versions of the .NET framework, most of us agree that COM is actually dead as a binary standard. The interface based programming model is still alive though.


advertisement
Serviced Components Registration
Assembly containing serviced classes must go through a registration process to insert the required info into the COM+ catalog and in the registry in order to make them visible to the COM+ runtime. Assemblies are registered using the Regsvcs.exe utility whose basic command line syntax is:

Regsvcs C:\myassembly.dll

In order to provide XCOPY deployment features for serviced components, Microsoft has tried to automate this operation: while binding to a serviced component, the .NET runtime registers the assembly transparently if the registration info can’t be found. Unfortunately this process, that requires Administrator rights, is run under the identity of the caller; hence it will likely fail in a real world scenario.



Serviced Components Instantiation
It’s very important to stress the fact that a .NET serviced component still run into the .NET runtime environment; all such settings just declare the properties of the its associated COM+ context that will run into the unmanaged world. The picture below gives you a clue of the binding process to a serviced .NET component.

As you can see any creation of a serviced component implies a call into the unmanaged world (CoCreateInstance). All such calls are dispatched to the mscoree.dll since all serviced components are implemented into this dll, as far as COM+ is concerned.

Having setup the proper context, mscoree.dll calls into the managed world to create the class and pass it back the obtained proxy to the .NET caller.

This is the VB6 pseudo-code the mscorlib.dll uses to create the managed object while running into the unmanaged world.

Dim crs As New mscoree.CorRuntimeHost crs.Start Dim domain As AppDomain crs.CurrentDomain domain Dim objh As ObjectHandle Set objh = domain.CreateInstanceFrom("c:\myassembly.dll", "vblibrary.Class1") Dim obj As Object Set obj = objh.Unwrap

Once you’ve registered the assembly containing the serviced class, a local .NET client can bind to it as if it was dealing with a standard .NET assembly. In case a serviced class holds expensive resources, you can explicitly release it, instead of relying on the Garbage collector, calling the DisposeObject method that’s inherited from the ServicedComponent class (calling the Dispose method would sort the same effect but requiring an additional context switch).

If you mark your class with the [JustInTimeActivation] attribute you can avoid having the client calling DisposeObject: the .NET runtime automatically release the object when, within a method call, ContextUtil.SetComplete/SetAbort is called (or the method is marked as [AutoComplete])

The same apply when dealing with pooled object: If JITA is used, the object is returned to the pool when the done bit is set to true (Setcomplete/Setabort is called or the method is marked as [AutoComplete]); if it’s not the case you must call DisposeObject explicitly, if you fail to do so, the object is not returned to the pool.

Invoking Serviced Components Remotely
It’s likely that, in most scenarios, a serviced component must be invoked remotely. You have two options to do so: resort to .NET remoting or DCOM.

No special steps are required to invoke the object via .NET remoting: you set up a listening process, declare your preferences in the protocol and formatter to be used and you’re done. There are just a couple of bugs of beta2 you’ve to be aware:

  • You cannot invoke a serviced component via .NET remoting if the component is deployed in a server COM+ application
  • Calling DisposeObject on the object wrapper hold by the client has no effect: you must resort to JITA if you want the object to be deterministically released (or returned to the pool)

Invoking the serviced component via DCOM implies referencing it as if it was a COM component (thus involving .NET interop). You can do this provided you’ve run the COM+ application proxy on the client machine. Unfortunately there is another beta2 bug that prevents you from doing this on Windows 2000, still the process works on Windows XP beta2.

One last consideration: know that transaction flow cannot propagate across .NET remoting calls, consider this fact when you must choose which remoting mechanism adopt.

It’s pretty likely that .NET will provide built-in enterprise services in the future; still, for the while, Microsoft has resorted completely to the good old COM+ framework to provide such services. Provided that the bugs that affect the b2 build will be removed in the V1 release, everyone will certainly appreciate the attribute-oriented approach exposed by the .NET framework





Enrico Sabbadin is a software developer (MCP) that works, since 1995, on distributed and Internet based applications design on the Microsoft platform. He is an author for several Italian programming magazines and for the ASPToday web site, and occasionally speaks at Microsoft MSDN conferences in Italy. Enrico maintains at his own site a MTS FAQ (http://www.sabbasoft.com).
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date