A Short Overview to Web Services in COM+ 1.5
The major change in the .NET platform is supporting the Web services. They
allocate a middle-tier component in one Web site to call methods on a further
middle-tier component at another Web site, as simply as if the two components
were on the same site and computer. But .NET Web services comes with a cost
because companies have to spend time and money in learning new languages for
example C#, and handle with a new programming model and new class libraries.
In most organizations, this is a nontrivial cost.
In COM components and development expertise to preserve existing investment
while providing a migration path to .NET, COM+ 1.5 can expose any COM+ component
as a Web service as long as the component complies with Web services design
guidelines. The application Activation tab lets you configure SOAP activation
for your application. All you need to do is specify the virtual directory of
the Web service associated with this application, and COM+ provides the necessary
adaptors as a component service. COM+ installs the Web service with IIS, and
generates the proper Web service configuration and information files. You should
note that IIS must be installed on your computer to enable SOAP activation mode
for your application.
Relationship between COM+ 1.5 and .NET
Developers used several tools like Microsoft Visual Studio 6.0 to develop COM+ components and establish the components in COM+ applications to use COM+ services. Today with Microsoft Visual Studio .NET, managed classes are built and then installed in COM+ applications, in order to get such COM+ services as transactions, object pooling, and activity semantics. Using Visual Studio .NET and the .NET Framework gives several rewards more than Visual Studio 6.0 through better tools, the common language runtime, and a much easier coding syntax. Each managed class can be hosted in a coexisting COM+ context; thus, managed classes can take full advantage of all the COM+ services. In the .NET Framework, these classes are known as serviced components. Any managed class can be modified to use COM+ services. The Microsoft.ComServices namespace provides various custom attributes and classes to assist the developer in accessing these services from managed code.
The Microsoft .NET Framework now provides equal access to COM+ services in a consistent and logical manner, and for all languages. Moreover, a number of innovative parts of the .NET Framework, such as ASP .NET, ADO .NET, and Messaging, integrate deeply with .NET component services, making use of services such as transactions and object pooling. This integration provides for a consistent architecture and programming model. The Microsoft.ComServices namespace provides various custom attributes and classes that, together with the ServicedComponent class, provides the programming model to add services to managed classes.
Using COM+ Services in .NET
In fact it should be called “using COM+ technologies under .NET Framework”. COM+ services have large quantity of enterprise functionality that would be very complicated and time consuming to duplicate. Even if COM+ services were originally designed for use with COM+ components, it would be nice if .NET components could also use them. The problem is that compiled .NET components (assemblies) and compiled COM components stay on different structural standards; COM components conforms to COM’s binary model and .NET components conforms to the structures outlined in the CLS (Common Language Specification). In order to make .NET components make use of services originally designed for components that fit a different model there are two basic challenges that need to be met. .NET components need to be able to access the objects in the COM+ services object model so that they can refer to them in code.
Developers can develop specific components that manipulate COM+ services exclusively in managed code or in any combination of managed and unmanaged code. The services will spring between the components because the context of each component is hosted in COM+ where the context flows appropriately from one component to another. The common language runtime and COM+ services are working together to automatically generate type library information and perform registration so that the managed class appears in the COM+ catalog. However, only COM+ services the context information, while the actual implementation and execution is performed within the runtime. In the following code, the class Account derives from the class System.ServicedComponent. Deriving from ServicedComponent ensures that the contexts of Account objects are hosted in COM+. Further modifications that are required for this class are highlighted in the code.
The Transaction attribute marks the class as requiring a transaction, which is equivalent to using the COM+ Explorer to set the transaction support on a COM+ component. The AutoComplete attribute is used to specify that the runtime must automatically call the SetAbort function for the transaction if an exception is thrown during the execution of the method; otherwise, a SetComplete function is called. Various assembly level attributes are also used to capture COM+ application level registration details.
#using <mscorlib.dll>
using System;
using Microsoft::ComServices;
using System::Runtime::CompilerServices;
namespace ATMComponent
{
[Transaction(TransactionOption.Required)]
public class ATMAccount : ServicedComponent
{
[AutoComplete]
bool SendIt(int accountNum, double amountOfAcc)
{
// do something
}
}
// - Registrations Part -
// COM+ Application Name to add the Component
[assembly: ApplicationName("ATMComponent")]
// You need to add a Strong Name for Assembly
[assembly: AssemblyKeyFileAttribute("ATMComponent.snk")]
}
Comments