From COM to .NET
by Juval Löwy09/12/2001
The other kind of existing components are COM components that you will access using .NET interoperation (type B in Figure 1). Later in this article I discuss design considerations of these components. Moving into the managed part of your application, identify the three types of components. There are also components that will require providing services to COM objects (type C), usually in the form of subscribing to events, but possibly also to provide services.
Figure 1. Component types in your migration
plan
There are some design considerations with those components as well, outlined later in this article. You will of course have components that you develop natively in .NET (type D). These components will usually be the main draw of .NET for you, and they are likely to take advantage of .NET's new capabilities, such as Web services, ASP.NET, windows forms, and so on. Finally, you may still want to port existing components to .NET (type E). You may want to port your core business logic, or trade secret, to ensure that the heart of your application is in on the new platform. Again, be mindful that porting is not a task for the faint of heart, and it will require considerable understanding of both the way the current components work, and of the new .NET programming model.
Check out O'Reilly's .NET Resource Center for the latest articles and books covering Microsoft's .NET technology. For more .NET resources visit O'Reilly's .NET DevCenter.
Once you have classified your components, you execute the migration plan like any other project. The important benefit of the migration plan is that it allows you to break down the effort involved in moving to .NET, estimate the effort (and the benefits) involved, and to minimize the risk in adopting .NET.
Design for .NET on the COM side
COM components accessed by .NET clients (type B) have to be imported to .NET. The import process creates .NET metadata representing the COM interfaces, in the form of wrapper classes and interfaces. However, the import process cannot convert all the possible COM custom interface signatures. Certain features (like arrays, or server-allocated memory) have no adequate conversion.
To maintain high fidelity between the original COM-interface definitions and the .NET wrapper classes, make sure that your type B components all use OLE-Automation compliant interfaces. Also, do not use S_FALSE as a method returned value. Any HRESULT indicating error should throw an exception on the .NET side, but S_FALSE is ambiguous.
Design for COM on the .NET side
.NET components that provide services to COM clients (type C) have to be exported to COM as COM objects and interfaces. The export process must comply with COM limitations (such as no method overloading or static methods). As a result, avoid the following in your type C components:
- Method overloading
- Public methods that are not part of interfaces
- Public static methods and fields
- Parameterized contractors
- Multiple inheritance of interfaces in interface definition
Again, it's not that you cannot do all of the above; it's just that the resulting exported COM definitions will look mangled and messy.
Use COM+
With all its innovations and advanced concepts, .NET is only a component technology--it provides you with the means to rapidly build binary components. .NET does not have component services, so .NET relies on COM+ to provide it with component services such as instance management, transactions, activity-based synchronization, granular role-based security, disconnected asynchronous queued components, and loosely coupled events. A .NET component that uses COM+ is called a serviced component, and .NET refers to COM+ as Enterprise Services.
Using COM+ allows developers to focus on the business logic instead of component connectivity and plumbing. Developers that use COM+ enjoy a productivity boost, faster time to market and a robust application. In addition, using COM+ implies certain architectural constrains and standards, and .NET serviced components have to comply with those requirements just like traditional COM components. As a result, the likelihood of a good match between your existing COM+ components and .NET serviced component is high.
Remember: A COM+ based architecture means components focus on business logic, and rely on COM+ for all the complicated plumbing and component services. If you choose to implement your business logic in .NET using COM+, it should plug in seamlessly into the existing COM+ architecture.
Use COM+ 1.5 Web Services Support
Web services support is the most exciting new feature of the .NET platform. Web services allow a middle tier component in one Web site to invoke methods on another middle tier component at another Web site, with the same ease as if the two components are on the same site and machine. But .NET Web services come with a price--companies have to invest in learning new languages such as C#, and cope with a new programming model and new class libraries.
To preserve existing investment in COM components and development expertise while providing a migration path to the .NET world, COM+ 1.5 (the next release of COM+, available with Windows XP) can expose any COM+ component that complies with Web services design guidelines as a Web service. All you need to do is specify the virtual directory of the Web service, and COM+ provides the necessary adaptors as a component service.
Each component in a COM+ application is exposed as a separate Web service, identified by the component prog-ID under the virtual directory. COM+ installs the Web services with IIS, and generates the proper Web service configuration and information files. The only requirement is that IIS and .NET be installed on your machine to enable Web services activation mode for your application.
Juval Löwy is a seasoned software architect and the principal of IDesign, a consulting and training company that focuses on component-oriented design using Microsoft COM+ and the .NET platforms. Juval has a passion for component-oriented programming, as well as a unique experience in both COM and .NET as an early adopter. Juval is a regular contributor to the Visual Studio Magazine (formally VBPJ/VCDJ) and to the .NET Magazine. Juval is a frequent speaker at the major software development conferences, and he teaches COM+ and .NET at the Berkeley University Extension. Juval was formally the corporate software architecture manager of KLA-Tencor, a Fortune 500 company, where he designed and developed large-scale frameworks and components used across the corporation. Juval resides in San Jose, California. Contact him at www.componentware.net.
O'Reilly & Associates will soon release (September 2001) COM and .NET Component Services.
Sample Chapter 10, .NET Serviced Components, is available free online.
You can also look at the Full Description of the book.
For more information, or to order the book, click here.
