1.1 Kiểm soát thời gian sống của một đối tượng ở xa
V
V
Bạn muốn cấu hình thời gian sống của một đối tượng đơn-nhất hay được-
client-kích-hoạt khi nó không còn được sử dụng.
#
#
Chỉ định các thiết lập mặc định về thời gian sống trong file cấu hình của host;
chép đè phương thức InitializeLifetimeService trong lớp ở xa; hoặc hiện thực
một cơ chế kiểm soát thời gian sống bên client.
Nếu một đối tượng sử dụng chế độ kích hoạt gọi một lần (single-call activation), nó sẽ tự
động bị hủy vào cuối mỗi lời gọi phương thức. Điều này khác với các đối tượng được-
client-kích-hoạt (client-activated) và đơn-nhất (singleton), các đối tượng này có thời gian
sống lâu hơn vì tuân theo “lifetime lease” (tạm dịch là “hợp đồng cho thuê thời gian
sống”). Với các thiết lập mặc định, một đối tượng ở xa sẽ tự động bị hủy nếu nó không
hoạt động trong hai phút, miễn là nó đã tồn tại ít nhất năm phút.
Host, đối tượng ở xa, và client đều có thể thay đổi các thiết lập về thời gian sống.
• Host có thể chỉ định các thiết lập mặc định về thời gian sống trong file cấu hình. Các
thiết lập này sẽ áp dụng cho tất cả các đối tượng ở xa mà nó quản lý.
• Lớp ở xa có thể chép đè phương thức GetLifetimeService để điều chỉnh các thiết lập
lease ban đầu bằng đối tượng ILease.
• Client có thể gọi phương thức MarshalByRefObject.GetLifetimeService với một đối
tượng ở xa cụ thể để thu lấy một thể hiện ILease. Kế tiếp, client có thể gọi phương
thức ILease.Renew để chỉ định lượng thời gian tối thiểu mà đối tượng sẽ sống.
Ví dụ dưới đây sử dụng cách tiếp cận thứ nhất (dùng thẻ <lifetime> trong file cấu hình
của host). Các thiết lập lease áp dụng cho tất cả các đối tượng ở xa do host tạo ra. Sử
dụng M để chỉ phút hay S để chỉ giây. Đối tượng ở xa có thời gian sống ban đầu là 10
phút. Khi client truy xuất đối tượng, thời gian sống của nó tự động được làm mới ít nhất
ba phút.
<configuration>
<system.runtime.remoting>
<application>
<service>
<wellknown
mode = "Singleton"
type="RemoteObjects.RemoteObject, RemoteObjects"
objectUri="RemoteObject" />
</service>
<channels>
<channel ref="tcp" port="9080" />
</channels>
<lifetime leaseTime = "10M"
renewOnCallTime = "3M" />
</application>
</system.runtime.remoting>
</configuration>
Một cách tiếp cận khác là chép đè phương thức InitializeLifetimeService để một đối
tượng ở xa tự kiểm soát thời gian sống của nó. Bạn có thể thêm đoạn mã dưới đây vào
lớp ở xa để nó có thời gian sống mặc định là 10 phút và thời gian làm mới là 5 phút:
public override object InitializeLifetimeService() {
ILease lease = MyBase.InitializeLifetimeService();
// Lease chỉ có thể được cấu hình nếu nó đang ở trạng thái ban đầu.
if (lease.CurrentState == LeaseState.Initial) {
lease.InitialLeaseTime = TimeSpan.FromMinutes(10);
lease.RenewOnCallTime = TimeSpan.FromMinutes(5);
}
return lease;
}
Nếu muốn đối tượng có thời gian sống vô hạn, bạn chỉ cần trả về một tham chiếu null
thay vì là đối tượng ILease. Trường hợp thông thường nhất là bạn muốn tạo một đối
tượng đơn-nhất chạy độc lập (và lâu dài) ngay cả khi client không sử dụng nó.
1.2 Kiểm soát phiên bản của các đối tượng ở xa
V
V
Bạn muốn tạo một host có thể quản lý nhiều phiên bản của một đối tượng.
#
#
Cài đặt tất cả các phiên bản của đối tượng vào GAC, và đăng ký mỗi phiên bản
tại một endpoint URI khác biệt.
.NET Remoting không có sự hỗ trợ nội tại nào cho việc đánh phiên bản. Khi một client
tạo một đối tượng ở xa, host tự động sử dụng phiên bản trong thư mục cục bộ hoặc, trong
trường hợp là một assembly dùng chung, phiên bản mới nhất trong GAC. Để hỗ trợ nhiều
phiên bản, bạn có ba lựa chọn:
• Tạo các ứng dụng host riêng biệt. Mỗi host sẽ có một phiên bản khác nhau của
assembly “đối tượng ở xa” và sẽ đăng ký phiên bản của nó với một URI khác nhau.
Cách này buộc bạn phải chạy nhiều ứng dụng host cùng một lúc và thiết thực nhất
khi bạn đang sử dụng IIS (được mô tả trong mục 12.9).
• Tạo một assembly “đối tượng ở xa” hoàn toàn mới (thay vì thay đổi phiên bản).
Theo đó, bạn có thể đăng ký các lớp trong hai assembly tại các URI khác nhau, sử
dụng cùng host.
• Cài đặt tất cả các phiên bản của assembly “đối tượng ở xa” vào GAC. Theo đó, bạn
có thể tạo một host ánh xạ các URI khác nhau đến các phiên bản cụ thể của
assembly “đối tượng ở xa”.
Tùy chọn cuối cùng là linh hoạt nhất trong trường hợp bạn cần hỗ trợ nhiều phiên bản. Ví
dụ, file cấu hình dưới đây đăng ký hai phiên bản của RemoteObjects tại hai endpoint khác
nhau. Bạn cần ghi rõ số phiên bản và token khóa công khai khi sử dụng các assembly
trong GAC. Bạn có thể tìm thấy thông tin này bằng cách xem assembly trong Windows
Explorer GAC plug-in (vào thư mục C:\Windows\Assembly).
<configuration>
<system.runtime.remoting>
<application>
<service>
<!-- Thông tin type được chia thành ba hàng cho hợp với
biên trang. Trong file cấu hình, thông tin này phải
được đặt trên một hàng. -->
<wellknown mode="SingleCall"
type="RemoteObjects.RemoteObject, RemoteObjects,
Version 1.0.0.1, Culture=neutral,
PublicKeyToken=8b5ed84fd25209e1"
objectUri="RemoteObj" />
<wellknown mode="SingleCall"
type="RemoteObjects.RemoteObject, RemoteObjects,
Version 2.0.0.1, Culture=neutral,
PublicKeyToken=8b5ed84fd25209e1"
objectUri="RemoteObj_2.0" />
</service>
<channels>
<channel ref="tcp server" port="9080" />
</channels>
</application>
</system.runtime.remoting>
</configuration>
File cấu hình của client không phải thay đổi gì hết (trừ việc cập nhật URI, nếu cần).
Client “chọn” phiên bản mà nó muốn sử dụng bằng URI tương ứng.
Hình 12.4 Thư mục C:\Windows\Assembly
1.3 Tạo phương thức một chiều
với dịch vụ Web XML hay Remoting
V
V
Bạn muốn một phương thức web hay một thành phần ở xa thực hiện một tác
vụ kéo dài, và bạn không muốn bắt client phải đợi trong lúc mã lệnh đang thực
thi.
#
#
Tạo một phương thức web một chiều bằng cách áp dụng đặc tính
SoapDocumentMethod hay SoapRpcMethod và thiết lập thuộc tính OneWay
của đặc tính này là true. Tạo một phương thức Remoting một chiều bằng cách
áp dụng đặc tính OneWay thuộc không gian tên
System.Runtime.Remoting.Messaging.
Với các phương thức một chiều, client gửi một thông điệp yêu cầu, và server đáp ứng tức
thì để cho biết rằng phương thức đã bắt đầu quá trình xử lý. Cách làm việc này có các hệ
quả sau:
• Client không cần đợi trong lúc mã lệnh đang thực thi.
• Phương thức không thể trả về thông tin nào cho client (thông qua một giá trị trả về
hay một thông số ByRef).
• Nếu phương thức ném một ngoại lệ chưa-được-thụ-lý, nó sẽ không được truyền về
cho client.
The image part with relationsh ip ID rId 5 was not fo und in the file.
Rõ ràng là các phương thức một chiều không phù hợp khi client cần nhận thông tin từ
server. Tuy nhiên, chúng lại lý tưởng khi cần khởi chạy một kiểu tác vụ nào đó phía
server (chẳng hạn, bắt đầu một công việc xử lý bó).
Để tạo một phương thức web một chiều, bạn cần áp dụng đặc tính SoapDocumentMethod
(thuộc không gian tên System.Web.Services.Protocols) cho phương thức thích hợp và
thiết lập thuộc tính OneWay là true. Ví dụ dưới đây là một dịch vụ Web XML có hai
phương thức, mỗi phương thức đều gây trì hoãn 10 giây. Một trong hai phương thức này
sử dụng đặc tính SoapDocumentMethod (để client không phải đợi 10 giây).
using System;
using System.Web.Services;
using System.Web.Services.Protocols;
public class OneWayTestWebService {
[WebMethod()]
public void DoLongTaskWithWait() {
// (Bắt đầu một tác vụ kéo dài và khiến client phải đợi.)
Delay(10);
}
[WebMethod, SoapDocumentMethod(OneWay=true)]
public void DoLongTaskWithoutWait() {
// (Bắt đầu một tác vụ kéo dài nhưng không khiến client phải đợi.)
Delay(10);
}
private void Delay(int seconds) {
DateTime currentTime = DateTime.Now;
while (DateTime.Now.Subtract(currentTime).TotalSeconds < seconds)
{}
}
}
Ví dụ trên giả định dịch vụ Web XML và client đang sử dụng SOAP document (mặc
định). Nếu đang sử dụng Remote Procedure Call (RPC), bạn hãy sử dụng đặc tính tương
ứng là SoapRpcMethod để đánh dấu phương thức một chiều.
Để tạo một phương thức một chiều trong một thành phần trên Remoting, bạn cần áp dụng
đặc tính OneWay (thuộc không gian tên System.Runtime.Remoting.Messaging) cho