Giới thiệu
Ngày nay, các ứng dụng không còn đơn thuần chỉ gồm một module, khi thực thi thì chỉ cần chạy trong một process mà là một tập hợp nhiều thành phần (component) phức tạp. Các thành phần đó không chỉ phân cách với nhau bằng ranh giới giữa các process mà còn có thể phân cách với nhau qua ranh giới máy – mạng – máy.
Tiến trình di chuyển một đối tượng vượt qua một ranh giới (process, máy, …) được gọi là Remoting.
Tiến trình chuẩn bị để một đối tượng thực hiện remoting được gọi là Marshaling.
Giả sử đối tượng A nằm trên máy X muốn sử dụng dịch vụ của đối tượng B nằm trên máy Y. Để phục vụ đối tượng A, đối tượng B chuyển cho A một đối tượng proxy. Những yêu cầu từ đối tượng A sẽ được proxy chuyển về cho B, những kết quả trả lời của B được gởi đến proxy, proxy sẽ gởi lại cho đối tượng A. Giữa đối tượng A và đối tượng B có nhiều đối tượng sink, công việc của các đối tượng sink là áp đặt an ninh lên kênh liên lạc giữa 2 đối tượng. Các thông điệp được chuyển tải giữa A và B trên một đối tượng channel. Đối tượng channel lại yêu cầu sự giúp đỡ của đối tượng formatter. Công việc của formatter là định dạng lại thông điệp để 2 phía có thể hiểu nhau (ví dụ chuyển mã hóa endian của dãy byte).
Application Domains
Trong hệ điều hành Windows, một process là một ứng dụng (application) đang chạy. Mỗi một ứng dụng chạy trong một process riêng của nó. Nếu trên máy hiện có Word, Excel, Visual Studio thì tương ứng trên máy đang có 3 process.
Bên trong mỗi process, .NET chia nhỏ ra thành các phần nhỏ hơn gọi là miền ứng dụng (Application Domains – appdomains). Có thể xem mỗi miền ứng dụng là một process “nhẹ cân”, miền ứng dụng hành xử y như là một process nhưng điểm khác biệt là nó sử dụng ít tài nguyên hơn process.
Các miền ứng dụng trong một process có thể khởi động (started) hay bị treo (halted) độc lập với nhau. Miền ứng dụng cung cấp khả năng chịu lỗi (fault tolerance); nếu khởi động một đối tượng trong một miền ứng dụng khác với miền ứng dụng chính và đối tượng vừa khởi động gây lỗi, nó chỉ làm crash miền ứng dụng của nó chứ không làm crash toàn bộ ứng dụng.
Mỗi process lúc bắt đầu thực thi có một miền ứng dụng ban đầu (initial appdomain) và có thể tạo thêm nhiều miền ứng dụng khác nếu lập trình viên muốn. Thông thường, ứng dụng chỉ cần một miền ứng dụng là đủ. Tuy nhiên, trong những ứng dụng lớn cần sử dụng những thư viện do người khác viết mà thư viện đó không được tin cậy lắm thì cần tạo ra một miền ứng dụng khác dùng để chứa thư viện không tin cập đó, tách thư viện đó khỏi miền ứng dụng chính để cô lập lỗi, nếu lỗi xảy ra thì không làm crash ứng dụng.
Miền ứng dụng khác với thread. Một thread luôn chạy bên trong một miền ứng dụng. Trong một miền ứng dụng có thể tồn tại nhiều thread.
Marshalling cho phép vượt qua biên của Application Domains
Marshaling là quá trình chuẩn bị một đối tượng để di chuyển qua một ranh giới nào đó. Marshaling có thể được tiến hành theo 2 cách: bằng giá trị (by value) và bằng tham chiếu (by reference).
- Khi một đối tượng được marshaling bằng giá trị, một bản sao(copy) của đối tượng được tạo ra và truyền đến nơi nhận. Những thay đổi trên bản sao này không làm thay đổi đối tượng gốc ban đầu.
- Khi một đối tượng được marshaling bằng tham chiếu, một đối tượng đặc biệt gọi là proxy được gởi đến nơi nhận. Những thay đổi, những lời gọi hàm trên đối tượng proxy sẽ được chuyển về cho đối tượng ban đầu xử lý.
Marshalling và Proxy
Khi marshaling đối tượng bằng tham chiếu, .NET CLR cung cấp cho đối tượng đang thực hiện lời gọi từ xa một đối tượng proxy “trong suốt” (transparent proxy).
Công việc của đối tượng transparent proxy là nhận tất cả những thông tin gì liên quan đến việc gọi hàm (giá trị trả về, thông số nhập, …) từ trong stack rồi đóng gói vào một đối tượng riêng mà đối tượng đó đã cài đặt giao diện IMessage. Sau đó đối tượng Imessage đó được trao cho đối tượng RealProxy.
RealProxy là một lớp cơ sở trừu tượng (abstract base class) mà từ đó các đối tượng proxy thừa kế. Lập trình viên có thể tự tạo ra các đối tượng proxy mới thừa kế từ RealProxy. Đối tượng proxy mặc định của hệ thống sẽ trao IMessage cho một chuỗi các đối tượng sink. Số lượng các sink phụ thuộc vào số lượng chính sách bảo an (policy) mà nhà quản trị muốn duy trì, tuy nhiên đối tượng sink cuối cùng là đối tượng đặt IMessage vào Channel.
Channel được chia ra thành channel phía client và channel phía server, công việc chính của channel là di chuyển thông điệp (message) vượt qua một ranh giới (boundary). Channel chịu trách nhiệm tìm hiểu nghi thức truyền thông (transport protocol). Định dạng thật sự của thông điệp di chuyển qua ranh giới được quản lý bởi formatter. Khung ứng dụng (framework) .NET cung cấp 2 formatter:
- Simple Object Access Protocol (SOAP) dùng cho HTTP channel
- Binary dùng cho TCP/IP channel
Lập trình viên cũng có thể tạo đối tượng formatter riêng và nếu muốn cũng có thể tạo ra channel riêng.
Một khi message vượt qua ranh giới, nó được nhận bởi channel và formatter phía server. Channel phía server sẽ tái tạo lại đối tượng IMessage, sau đó channel phía server trao đối tượng IMessage cho một hay nhiều đối tượng sink phía server. Đối tượng sink cuối cùng trong chuỗi sink là một đối tượng StackBuilder, công việc của StackBuilder là nhận IMessage rồi tái tạo lại stack frame để có thể thực hiện lời gọi hàm.
Chỉ định phương pháp truyền tham số cho Marshaling
Một đối tượng bình thường hoàn toàn không có khả năng marshaling.
Để marshaling một đối tượng bằng giá trị (by value), chỉ cần thiết lập attribute Serializable lúc định nghĩa đối tượng.
[Serializable] public class Book {}
Để marshaling một đối tượng bằng tham chiếu (by reference), đối tượng đó cần thừa kế từ MarshalByRefObject.
public class BookDal : MarshalByRefObject {}
Context
Miền ứng dụng (appdomain) đến lượt nó lại được chia ra thành các context. Context có thể xem như một ranh giới mà các đối tượng bên trong context có cùng quy tắc sử dụng (usage rules). Các quy tắc sử dụng như: đồng bộ hóa giao dịch (synchronization transaction), …
Đối tượng loại Context-Bound và Context-Agile
Nếu các đối tượng là Context-Bound, chúng tồn tại trong một context riêng, khi giao tiếp lẫn nhau, các thông điệp của chúng được marshaling để vượt qua biên context.
Nếu các đối tượng là Context-Agile, chúng hoạt động bên trong context của đối tượng yêu cầu (calling). Do đó, khi một đối tượng A triệu gọi phương thức của đối tượng B, phương thức của B được thực thi bên trong context của A. Vì vậy việc marshaling là không cần thiết.
Giả sử đối tượng A cần giao tiếp với cơ sở dữ liệu, giả sử đối tượng A có thiết lập về giao dịch (transaction). Do đó A cần tạo một context. Tất cả các phương thức của A sẽ được thực thi trong context của transaction.
Giả sử đối tượng C triệu gọi một phương thức Z của B, phương thức Z có thực hiện thay đổi cơ sở dữ liệu, do B thuộc loại Context-Agile nên Z được thực thi trong context của C. Vì vậy những thay đổi mà Z thực hiện lên cơ sở dữ liệu sẽ không thể được roll-back.
Nếu B thuộc loại Context-Bound, khi A tạo ra B, context của B sẽ được thừa kế từ context của A. Khi C triệu gọi phương thức Z của B, lời triệu gọi đó được marshaling từ context của C đến context của B rồi được thực hiện trong context của B (thừa kế từ A). Do đó phương thức Z thực thi trong sự bảo vệ của transaction. Những thay đổi mà Z thực hiện lên cơ sở dữ liệu có thể được rooll-back.
Một đối tượng có thể có 3 lựa chọn về Context:
- Context-Agile.
- Context-Bound không chỉ định attribute. Thực hiện bằng cách thừa kế từ ContextBoundObject. Phương thức của đối tượng thuộc loại này thực thi trong Context thừa kế từ Context của đối tượng tạo ra nó.
- Context-Bound có chỉ định attribute Context. Các phương thức hoạt động trong Context do nó tạo riêng.
Marshaling vượt qua ranh giới Context
Khi truy cập đối tượng Context-Agile trong cùng miền ứng dụng thì không cần proxy. Khi một đối tượng A trong một context truy cập một đối tượng Context-Bound B trong một context khác, đối tượng A đó truy cập đối tượng B thông qua proxy của B.
Đối tượng được marshaling khác nhau vượt qua ranh giới context phụ thuộc vào cách nó được tạo ra:
- Đối tượng bình thường không có marshaling; bên trong miền ứng dụng các đối tượng thuộc loại context-agile.
- Đối tượng có đánh dấu attribute Serializable thì thuộc loại context-agile và được marshaling bởi giá trị (by value) vượt qua ranh giới miền ứng dụng.
- Đối tượng thừa kế từ MarshalByRefObject thì thuộc loại context-agile và được marshaling bởi tham chiếu (by reference) vượt qua ranh giới miền ứng dụng.
- Đối tượng thừa kế từ ContextBoundObject được marshaling bởi tham chiếu vượt qua ranh gới miền ứng dụng và ranh giới context.
Remoting
Cùng với việc marshaling đối tượng vượt qua ranh giới context và miền ứng dụng, đối tượng có thể được marshaling vượt qua ranh giới process và thậm chí qua ranh giới máy – mạng – máy. Khi một đối tượng được marshaling vượt qua ranh giới process hay máy – mạng – máy, nó được gọi là Remoted.
Tìm hiểu các kiểu dữ liệu phía Server
Có 2 kiểu đối tượng phía server phục vụ cho việc Remoting trong .NET: well-known và client activated. Kênh liên lạc với đối tượng well-known được thiết lập mỗi khi client gởi thông điệp (message). Kênh liên lạc đó không được giữ thường trực như trong trường hợp của đối tượng client activated.
đối tượng well-known chia thành 2 loại nhỏ: singleton và single-call.
- Đối tượng well-known kiểu singleton: tất cả các thông điệp từ client gởi đến đối tượng được phân phối (dispatch) cho một đối tượng đang chạy trên server. Đối tượng này được tạo ra khi server khởi động và nằm chờ trên server để phục vụ cho bất kỳ client nào. Vì vậy đối tượng loại này phải có default constructor (phương thức khởi dựng không tham số).
- Đối tượng well-known kiểu single-call: mỗi thông điệp mới từ client gởi đi được giải quyết bởi một đối tượng mới trên server. Mô hình này thường dùng để cân bằng tải hệ thống.
Đối tượng client activated thường được sử dụng bởi các lập trình viên có công việc chính là tạo ra các server riêng phục vụ cho việc lập trình, đối tượng client activated duy trì kết nối với client cho đến khi nào toàn bộ yêu cầu của client được đáp ứng.
Xây dựng Server
Trong Visual Studio, tạo một project mới kiểu Windows Form Application.
Thêm vào project này một class mới tên: StudentDal (Project – Add Class)
public class StudentDal : MarshalByRefObject
Tạo channel và đăng ký
TcpChannel channel = null; private void btnStart_Click(object sender, EventArgs e) { channel = new TcpChannel(12345); // ... }
Đăng ký channel với .NET Channel Services
ChannelServices.RegisterChannel(channel, false);
Đăng ký đối tượng (cần cung cấp endpoint cho hàm đăng ký; endpoint chính là tên liên kết với đối tượng)
Type type = typeof(StudentDal);
Khởi tạo Server kiểu Singleton
string url = "StudentDal"; WellKnownObjectMode mode = WellKnownObjectMode.Singleton; RemotingConfiguration.RegisterWellKnownServiceType(type, url, mode);
Xây dựng Client
Client kết nối với dịch vụ từ xa, trao cho hàm kết nối kiểu đối tượng mà nó cần cộng với URI của lớp cài đặt dịch vụ
string url = "tcp://127.0.0.1:12345/StudentDal"; Type type = typeof(StudentDal); RemotingConfiguration.RegisterWellKnownClientType(type, url);
Kế tiếp, chúng ta có thể tạo đối tượng và thực hiện tác vụ
dal = new StudentDal(); dataGridView1.DataSource = dal.GetStudents();
Sử dụng SingleCall
Để thấy được sự khác biệt giữa Singleton và SingleCall, chúng ta thay đổi lại phần đăng ký đối tượng remote trong Server như sau:
string url = "StudentDal"; WellKnownObjectMode mode = WellKnownObjectMode.Singleton; RemotingConfiguration.RegisterWellKnownServiceType(type, url, mode);
Thành
string url = "StudentDal"; WellKnownObjectMode mode = WellKnownObjectMode.SingleCall; RemotingConfiguration.RegisterWellKnownServiceType(type, url, mode);
Tìm hiểu RegisterWellKnownServiceType
Khi gọi phương thức RegisterWellKnownServiceType, điều gì đã xảy ra ?
Xin nhớ lại rằng bạn đã tạo một đối tượng Type cho lớp StudentDal
Type type = typeof(StudentDal);
Sau đó bạn gọi RegisterWellKnownServiceType(), trao cho phương thức đó đối tượng Type, endpoint và Singleton. Điều đó báo cho CLR biết phải tạo một thể hiện của StudentDal và liên kết endpoint với thể hiện đó.
Chúng ta có thể tự làm lại quá trình này bằng cách thay đổi như sau:
channel = new TcpChannel(12345); ChannelServices.RegisterChannel(channel, false); StudentDal dal = new StudentDal(); string url = "StudentDal"; RemotingServices.Marshal(dal, url); lblStatus.Text = "Server is started";
Tìm hiểu EndPoint
Chuyện gì xảy ra khi bạn đăng ký endpoint? Rõ ràng là server liên kết endpoint với đối tượng bạn vừa tạo, và khi client kết nối, server sử dụng chỉ mục trong một bảng để có thể trả về đối tượng proxy tương ứng với đối tượng yêu cầu.
Bạn có thể không cung cấp endpoint, thay vào đó bạn ghi các thông tin về đối tượng StudentDal rồi gởi về client. Client “phục chế” lại đối tượng proxy để có thể dùng liên lạc với StudentDal trên server.
Để có thể hiểu làm cách nào bạn có thể gọi một đối tượng mà không biết endpoint, thay vì gọi Marshal() với một endpoint, hãy trao một đối tượng:
ObjRef objRef = RemotingServices.Marshal(dal);
Hàm Marshal() trả về một đối tượng ObjRef. Đối tượng ObjRef chứa tất cả thông tin cần thiết để kích hoạt và liên lạc với đối tượng ở xa. Khi bạn cung cấp một endpoint, server tạo một bảng và liên kết endpoint với một ObjRef để khi client có yêu cầu, server có thể tạo một proxy cung cấp cho client. ObjRef chứa tất cả thông tin cần thiết cho client để client có thể tạo một proxy. ObjRef có khả năng Serializable.
Chúc các bạn thành công. Các bạn có thể download chương trình mẫu bên dưới.
Source code tham khảo:
[sociallocker id=”444″]Download[/sociallocker]