C# ПІДРУЧНИКИ / c# / Hungry Minds - C# Bible

using System;

using System.Data.SqlClient; using System.EnterpriseServices;

[Transaction(TransactionOption.Required)] public class ExAirMain : ServicedComponent

{

public void Process()

{

/* call methods to add Food info and Ticket info */

AddFood process1 = new AddFood(); AddAirline process2 = new AddAirline(); process1.Add();

process2.Add();

}

}

[Transaction(TransactionOption.Supported)]

[AutoComplete]

public class AddFood : ServicedComponent

{

public void Add()

{

SQLConnection cnn = new SQLConnection("FoodSupplierConnection");

SQLCommand cmd = new SQLCommand(); cnn.Open();

cmd.ActiveConnection = cnn;

cmd.CommandText = ""; // Insert statement to DB cmd.ExecuteNonQuery();

cnn.Close();

}

}

[Transaction(TransactionOption.Supported)]

[AutoComplete]

public class AddAirline : ServicedComponent

{

public void Add()

{

SQLConnection cnn = new SQLConnection("AirlineConnection"); SQLCommand cmd = new SQLCommand(); cnn.Open();

cmd.ActiveConnection = cnn;

cmd.CommandText = "" // Insert statement to DB cmd.ExecuteNonQuery();

cnn.Close();

}

}

}

Accessing Object Context

The System.EnterpriseServices namespace includes a class called ContextUtil, which can be used by C# classes to access an object's COM+ runtime context. In Visual Basic 6, you

to determine the caller's COM+ role. If the caller's role is the ClientRole role, then the object's transaction is committed with a call to SetComplete(). If the caller's role is a role other than the ClientRole role, then the object's transaction is rolled back with a call to SetAbort().

Listing 35-4: Accessing COM+ Context Through the ContextUtil Class

using System.Reflection;

using System.EnterpriseServices;

[assembly:AssemblyKeyFile("keyfile.snk")] [assembly:AssemblyVersion("1.0.*")]

[ObjectPooling(5, 10)] [Transaction(TransactionOption.Required)] [SecurityRole("ClientRole")]

public class PooledClass : ServicedComponent

{

public PooledClass()

{

}

~PooledClass()

{

}

public override bool CanBePooled()

{

return true;

}

public override void Activate()

{

}

public override void Deactivate()

{

}

public void DoWork()

{

bool IsInRole;

IsInRole = ContextUtil.IsCallerInRole("ClientRole"); if(IsInRole == true)

ContextUtil.SetComplete(); else

ContextUtil.SetAbort();

}

}

Summary

Exposing your C# class as a COM+ application takes very little effort and is certainly easier than implementing the same functionality using earlier versions of Visual Studio 6.0. COM+ applications written using Visual C++ 6.0 needed much more code to complete the same tasks, and some COM+ features (such as object pooling) were not even available to COM+ components written in Visual Basic 6.0.

Developing COM+ components using C# involves only four simple concepts:

•Derive your class from ServicedComponent

•Add attributes to describe your application's settings

•Use the regsvcs tool to build a COM+ application for your public classes

•Call methods and properties on the ContextUtil class to access the COM+ context at runtime.

Microsoft dropped hints about this COM+ programming model as far back as 1997. Back then, they described a model based on attributed programming, in which COM components could be described with attributes and the runtime would take over details such as class factories and IUnknown-style reference counting. It is now clear that the .NET model of COM+ component development is the fulfillment of that original vision.

Chapter 36: Working with .NET Remoting

In This Chapter

The .NET Framework provides several mechanisms that enable you to write applications that do not exist in the same application domain, server process, or machine. Based on the requirements of your application, such as the capability of non-.NET servers to access your data, you can choose any of the different types of object communication methods. In this chapter, you learn about .NET remoting. Using remoting, you can marshal objects and method calls across process boundaries and effectively pass data between applications.

In earlier chapters, you learned that ASP.NET and XML Web services were also excellent ways to pass objects and data between process boundaries, but depending on your application infrastructure, those services may not be the best option available. Remoting fills in any of the gaps that were left open by these services. In this chapter, you learn how to implement remoting, how to create the client and server objects in a remoting framework, and how to effectively pass data using remoting across process boundaries.

Introducing Remoting

.NET remoting enables applications to communicate between objects that reside on different servers, different processes, or different application domains. Before the .NET Framework was introduced, you could pass objects across process boundaries by using distributed COM, or DCOM. DCOM worked well, but it had limitations, such as the types of data that could be passed, and security context passed between the client caller and server activation. Moreover, it was based on COM, which meant that although you could communicate across machine boundaries, all machines had to be running a Microsoft operating system. This isn't a critical limitation, but it limited your options regarding what you could do with your existing infrastructure. In .NET, remoting takes care of these issues, and expands upon what DCOM offered as a viable method to remotely communicate between objects.

With remoting, you implement a server, or host application, and a client application. On the host or client, the application can be any of the .NET application templates that are available, including console applications, Windows services applications, ASP.NET applications,

create the host application that accepts client requests for the methods in the assembly. In the following steps, you build the assembly that implements the methods to be called:

1.Create a new C# Class Library application and call it HostObject. For simplicity, I have created a directory on my C drive called cSharpRemoting, and have added three subfolders named Host, HostObject, and Client. You might see where we are going with this. The HostObject Class Library application should be created in the cSharpRemoting\HostObject directory. This makes is easier for you to run the console applications you create later.

2.After you create the HostObject class library application, you add a public method that accepts a parameter, called customerID, and returns the name of the customer from the Northwind database from SQL Server based on the customerID passed in. Your completed class for the HostObject application should look something like the one shown in Listing 36-1.

Listing 36-1: Creating the Host Object Application

using System; using System.Data;

using System.Data.SqlClient;

namespace HostObject

{

public class Class1: MarshalByRefObject

{

public string thisCustomer;

public Class1()

{

Console.WriteLine("HostObject has been activated");

}

public string ReturnName(string customerID)

{

// Create connection, command object to SQL

string cnStr = "Initial Catalog=Northwind;Data" + "Source=localhost;Integrated Security=SSPI;";

SqlConnection cn = new SqlConnection(cnStr);

string strSQL =

("Select CompanyName from Customers " +

" where CustomerID = '" + customerID + "'");

SqlCommand cmd = cn.CreateCommand();

cmd.CommandText = strSQL;

cn.Open();

SqlDataReader rdr = cmd.ExecuteReader (CommandBehavior.CloseConnection);

while (rdr.Read())

{

thisCustomer = rdr.GetString(0);

}

Console.WriteLine(thisCustomer + " was returned to the client");

return thisCustomer;

}

}

}

The preceding code performs a simple query to SQL Server to grab the CompanyName field in the Customers database based on the parameter customerID, which is passed into the method. As you can see, this code is no different from any other class library that you would create in C#. The next step is to create the host application that services the client requests for this class library.

Creating the Remoting Server

To create the application that will host the HostObject assembly, which is where you actually start to use some of the remoting features created in Listing 36-1, you need to create a console application called Host in the C:\cSharpRemoting\Host directory. This host application is the actual remoting server that uses the features of the System.Runtime.Remoting namespace.

Before you start any coding, several key features of remoting need to be described. The namespace that contains the remoting functionality is the System.Runtime. Remoting namespace, whose classes are described in Table 36-1. Although you do not use all of these classes when writing remoting applications, several of the classes are extremely important to inplementing a remoting infrastrucure; namely, the ObjRef class, RemotingConfiguration class, the RemotingServices class, and the WellKnownObjectMode enumeration. You learn more about each of these in detail later in this section as you write the code for your host application.

Table 36-1: System.Runtime.Remoting Classes