ASP.NET Web Service hay .NET Remoting

Tóm tắt: Hiểu được cấu trúc cơ sở của phương thức quản trị từ xa Microsoft .NET Remoting và các dịch vụ Microsoft ASP.NET Web services có thể giúp bạn có được hoạt động truyền thông tiến trình chéo. Hai công nghệ này hoạt động như thế nào và lựa chọn chúng phù hợp cho ứng dụng của bạn ra sao là nội dung chính của bài hôm nay.

Tổng quan

Qua thời gian, việc xây dựng ứng dụng như là một tập hợp thành phần phân phối vào mạng chung và làm việc với nhau như là một phần trong chương trình tổng thể ngày càng trở nên phổ biến. Hình thức này thường được gọi là kỹ thuật "đối tượng-thành phần", như Distributed Component Object Model (DCOM) của Microsoft, Common Object Request Broker Architecture (CORBA) của Object Management Group, Remote Method Invocation (RMI) của Sun. Chúng cung cấp cấu trúc mềm dẻo, tin cậy để nắm bắt kịp thời sự phát triển cần thiết của các ứng dụng.

Mặc dù công nghệ dựa trên kiểu thành phần này hoạt động tốt trong môi trường Intranet, nhưng với Internet lại xuất hiện hai vấn đề đáng kể. Đầu tiên là chúng không thực hiện theo phương thức từng phần. Tất cả hoạt động xử lý dựa trên các đối tượng (object) nhưng lại không đưa ra từng chi tiết cụ thể như quản lý chu kỳ hoạt động, hỗ trợ xây dựng và hỗ trợ mức kế thừa. Thứ hai, quan trọng hơn là quá tập trung vào hình thức truyền thông kiểu RPC điển hình dẫn đến việc xây dựng các hệ thống kết hợp chặt chẽ quanh các viện dẫn mở của phương thức đối tượng.

Trái lại, các ứng dụng Web dựa trên cơ sở trình duyệt lại được kết hợp lỏng và thực hiện theo từng thành phần rõ rệt. Chúng liên lạc bằng cách dùng giao thức HTTP để chuyển đổi dữ liệu kiểu MIME sang nhiều kiểu định dạng khác nhau. Các Web service thích ứng với mô hình lập trình Web truyền thống để dùng được cho tất cả các loại ứng dụng, không chỉ kiểu cơ sở trình duyệt. Chúng trao đổi thông điệp SOAP bằng cách dùng HTTP và nhiều giao thức Internet khác. Do các Web service được xây dựng dựa trên tiêu chuẩn công nghệ như HTTP, XML, SOAP và WSDL nên khi muốn đưa tính năng ứng dụng lên Internet, chúng còn phải phụ thuộc vào ngôn ngữ, platform và thiết bị lập trình.

Cấu trúc cơ sở Web service ASP.NET cung cấp một API đơn giản cho các dịch vụ Web dựa trên cách thức ánh xạ thông tin SOAP vào các viện dẫn phương thức. Quá trình hoàn thiện bằng cách cung cấp mô hình lập trình rất đơn giản dựa trên hình thức ánh xạ các trao đổi thông tin SOAP vào từng viện dẫn phương thức riêng. Các client của ASP.NET Web services không cần phải biết đến platform, mô hình đối tượng hay ngôn ngữ lập trình dùng để xây dựng chúng. Chính các service cũng không cần biết gì về client đang gửi thông tin đến cho mình. Chỉ có một đòi hỏi duy nhất là cả hai bên phải thống nhất kiểu định dạng thông tin SOAP được tạo ra và sử dụng, như định nghĩa biểu thức rút gọn của Web service kiểu WSDL và XML Schema (XSD).

.NET Framework hỗ trợ hai mô hình lập trình phân phối riêng biệt: Web service và các đối tượng phân phối, là nguyên nhân thường gây ra nhầm lẫn cho các nhà phát triển. Khi nào nên để hệ thống sử dụng ASP.NET Web service và khi nào nên dùng .NET Remoting? Muốn có câu trả lời cho câu hỏi này, trước hết bạn cần phải hiểu cơ chế hoạt động của cả hai công nghệ này như thế nào.

Nối tiếp và Metadata

Tất cả hoạt động phân phối truyền thông suy cho cùng cũng chỉ thực hiện hai nhiệm vụ: sắp xếp các phiên của kiểu dữ liệu lập trình vào phần thông tin có thể sẽ được gửi qua mạng và cung cấp bản bản mô tả thông tin đó. Trước đây, quá trình này được thực hiện bằng cách dùng một số dạng thức nối tiếp hoặc sắp xếp theo thứ tự, sau này sử dụng các dạng metadata. Điểm khác nhau cơ bản giữa ASP.NET Web services và .NET Remoting là cách thức chúng sắp xếp thứ tự dữ liệu vào phần thông tin như thế nào và kiểu định dạng chúng chọn cho metadata ra sao.

ASP.NET Web Services, XmlSerializer và XSD

ASP.NET Web Services dựa trên lớp System.Xml.Serialization.XmlSerializer để sắp xếp dữ liệu vào phần thông tin SOAP hoặc lấy dữ liệu từ đó ra trong thời gian chạy. Với metadata, chúng tạo các định nghĩa WSDL và XSD mô tả phần thông tin chứa những gì. Dựa trên các WSDL và XSD thuần nhất giúp metadata của ASP.NET Web Services có khả năng di động. Chúng mô tả cấu trúc dữ liệu theo cách khiến các toolkit Web service trên nhiều platform khác và nhiều mô hình lập trình khác vẫn có thể hiểu được. Trong một số trường hợp còn liên quan ràng buộc tới nhiều kiểu lấy ra từ một Web service. XmlSerializer chỉ sắp xếp thứ tự những thứ được mô tả trong XSD. XmlSerializer không sắp xếp phần đồ hoạ đối tượng và hỗ trợ hạn chế cho các kiểu lưu trữ.

Mặc dù các giới hạn này dường như không đáng kể trước đối tượng phân phối theo lớp, nhưng chúng giúp đảm bảo thống nhất thao tác giữa các phần với framework Web service khác - mục đích cơ bản của mô hình Web service kết hợp lỏng. Phần hỗ trợ cho thao tác giữa các phần được tăng cường với tập hợp phong phú các thuộc tính tuỳ chọn, cho phép bạn chú thích kiểu dữ liệu để điều khiển cách thức XmlSerializer sắp xếp thứ tự. Kết quả, bạn có quyền điều khiển rất hữu ích qua hình thức của XML tạo ra khi một đối tượng được sắp xếp thứ tự. Thêm vào đó, một Web service trên nền ASP.NET có thể được biến đổi để mô tả các thông tin của nó theo thuật ngữ XSD literal (nguyên bản) hoặc các nguyên tắc mã hoá SOAP. XSD literal được đặt mặc định và sau này sẽ được tiêu chuẩn hoá. Chức năng hỗ trợ mã hoá SOAP được sắp xếp cho tất cả các phần với toolkit đang sẵn có. Điều này rất có lợi, nhất là khi bạn cần phải liên lạc với một Web service hoặc client tồn tại, sử dụng kiểu tin tức xác định trước.

.NET Remoting, IFormatter và Common Language Runtime (Bộ thực thi ngôn ngữ chung)

.NET Remoting dựa trên các hình thức thực thi kiểu kín của giao diện IFormatter dùng theo cơ chế System.Runtime.Serialization để sắp xếp thứ tự dữ liệu đến và đi từ các phần thông tin trao đổi. Có hai bộ định dạng tiêu chuẩn: System.Runtime.Serialization.Formatters.Binary.BinaryFormatter và System.Runtime.Serialization.Formatters.Soap.SoapFormatter. BinaryFormatter và SoapFormatter, giống như tên gọi, sắp xếp thứ tự các kiểu lần lượt theo định dạng mã nhị phân và SOAP.

Với metadata, .NET Remoting dựa trên các bộ phận của Bộ thực thi ngôn ngữ chung (Common Language Runtime), bao gồm tất cả thông tin liên quan đến kiểu dữ liệu thực thi và cách xuất nó ra qua hình thức ánh xạ lại. Dựa trên các bộ phận ghép của metadata, việc duy trì độ tin cậy của toàn bộ thời gian chạy kiểu hệ thống trở nên dễ dàng hơn. Kết quả là khi .NET Remoting sắp xếp thứ tự dữ liệu xong, nó sẽ có toàn bộ thành viên, kể cả public (thành viên chung) và private (thành viên riêng) của một lớp; điều khiển các phần đồ hoạ đối tượng một cách chính xác và hỗ trợ tất cả các kiểu lưu trữ (như System.Collections.Hashtable). Tuy nhiên, dựa trên metadata thời gian chạy cũng giới hạn khả năng của hệ thống .NET Remoting. Một client phải hiểu cấu trúc .NET để liên lạc với điểm cuối .NET Remoting. Thêm vào đó, với các bộ định dạng kín, tầng .NET Remoting hỗ trợ các kênh kín sẽ trìu trượng hoá chi tiết mô tả phần thông tin được gửi như thế nào. Có hai kênh tiêu chuẩn, một cho TCP thô và một cho HTTP. Thông tin có thể được gửi qua một trong hai kênh, phụ thuộc vào kiểu định dạng.

Remoting và Web Service

Sự hiện diện của bộ định dạng SOAP và một kênh HTTP đặt ra câu hỏi: .NET Remoting có thể dùng để xây dựng các Web service được không? Câu trả lời là có và không. Stack công nghệ Web service tiêu chuẩn không chỉ dựa trên thông tin cơ sở SOAP mà còn theo các mô tả trên nền WSDL và XSD của thông tin đó. Quá trình hoàn thành Remoting có thể thực sự tạo ra các định nghĩa WSDL mô tả thông tin sản xuất và sử dụng điểm cuối. Tuy nhiên nhiều vấn đề phát sinh tăng lên (sẽ bàn kỹ hơn ở phần dưới).

Đầu tiên, các file WSDL được tạo luôn mô tả thông tin trong thuật ngữ theo nguyên tắc mã hoá SOAP thay vì XSD literal. Ngày nay, đây không phải là vấn đề. Nhưng người ta trông chờ sẽ ngày càng có nhiều công cụ tập trung toàn bộ vào chương trình này.

Thứ hai, các file WSDL được tạo gồm phần mở rộng là .NET Remoting-cụ thể. Ví dụ, dưới đây là một lớp đơn giản sử dụng .NET Remoting để giải thích hoạt động của nó.

Nếu bạn tạo WSDL từ lớp này, thông tin ghép gồm các chi tiết của .NET Remoting cụ thể, như bên dưới:

Các phần tử mở rộng này là hợp lệ vì WSDL đặc tả các hỗ trợ mở rộng. Bất kỳ toolkit Web service hoạt động tốt nào không hiểu chúng thì đơn giản là sẽ lờ chúng đi. Dẫu vậy, có một số thứ toolkit Web service không được phép lờ. Ví dụ như một điểm cuối Remoting trả ra dữ liệu kiểu tập hợp Microsoft® ADO.NET System.Data.DataSet.

Dưới đây là định nghĩa WSDL được tạo ra cho thông tin ra của phương thức này:

Thông thường, một thông tin WSDL cho biết các kiểu được định nghĩa trong một namespace cụ thể dùng XML Schema. Tuy nhiên trong trường hợp này namespace tiền tố ns3 áp dụng cho kiểu DataSet không được định nghĩa trong XSD. Thay vào đó nó được định nghĩa ẩn qua thời gian chạy. Tiền tố ns3 trong ví dụ này thể hiện một namespace XML xác định bởi địa chỉ URL:

http://schemas.microsoft.com/clr/nsassem/System.Data/System.Data%2C%20Version%3D1.0.3300.0%2C%20Culture%3Dneutral%2C%20PublicKeyToken%3Db77a5c561934e089

Người dùng của kiểu định nghĩa WSDL trên thường được ngụ ý để hiểu ý nghĩa quan trọng của URI "nổi tiếng" này, một tên dài gồm bốn phần của thời gian chạy cụ thể gắn trong .NET Framework. Kiểu WSDL này rất thích hợp cho các client triển khai .NET Remoting vì họ có thể tạo ra proxy ghép với thông tin chính xác cho quá trình sắp xếp thứ tự. Tuy nhiên, các toolkit Web service khác (gồm cả ASP.NET) lại không hiểu được địa chỉ URI này và chờ đợi tìm ra định nghĩa khung cho kiểu DataSet. WSDL này trở nên vô ích.

Vì thế lại xuất hiện thêm câu hỏi, bạn có thể dùng .NET Remoting để xây dựng các Web service được không? Có, nói một cách nghiêm túc, bạn có thể. Nhưng những ai không dùng .NET Remoting có thể sử dụng chúng? Câu trả lời là có thể, nếu bạn cẩn thận giảm dần điểm cuối xuống chỉ còn các kiểu dữ liệu và kiểu ngữ nghĩa cơ bản nhất. Cụ thể, nếu bạn muốn thao tác với các toolkit Web service khác, bạn cần phải giới hạn tham số cho các kiểu dựng sẵn đơn giản và các kiểu dữ liệu riêng của bạn (không được dùng các kiểu .NET Framework như DataSet), và tránh các đối tượng, các sự kiện client được kích hoạt. Nói tóm lại nếu bạn quan tâm tới phương thức này, bạn cần phải tự giới hạn mình giống như tập hợp tính năng các Web service ASP.NET hỗ trợ.

Nếu vẫn chưa tốt hơn, hãy dùng ASP.NET Web Service, vì ASP.NET Web Service chính xác được thiết kế là nhằm mục đích này.

Thiết kế ứng dụng phân phối: ASP.NET Web Service đấu .NET Remoting

ASP.NET Web Services chú trọng hơn hệ thống kiểu XML Schema và cung cấp mô hình lập trình đơn giản phân phối chéo tới từng platform. .NET Remoting lại chú trọng đến hệ thống kiểu thời gian chạy và cung cấp mô hình lập trình tổng hợp hơn với hình thức bị giới hạn nhiều hơn. Điểm khác nhau cơ bản trong hai công nghệ này là xác định yếu tố chính trong mục đích sử dụng. Ngoài ra còn có một số lượng lớn các yếu tố thiết kế khác như các giao thức truyền vận, chương trình host, bảo mật, thực thi, quản lý trạng thái và hỗ trợ giao tác để xem xét,…

Các giao thức truyền vận và chương trình host

Về mặt kỹ thuật, SOAP không quản lý HTTP như là một giao thức truyền vận. Nhưng client chỉ có thể truy cập các Web service sử dụng ASP.NET qua HTTP, bởi vì nó chỉ hỗ trợ giao thức truyền vận ASP.NET. Các dịch vụ (service) được viện dẫn qua IIS và thực thi trong chương trình nhóm làm việc ASP.NET (aspnet_wp.exe).

.NET Remoting chung cấp cho bạn phương thức mềm dẻo để quản lý các đối tượng từ xa thuộc bất kỳ kiểu ứng dụng nào, như Windows Form, chương trình quản lý Windows Service, ứng dụng console hay chương trình nhóm ASP.NET. Như đã nói ở trên, .NET Remoting cung cấp hai kênh truyền vận: TCP và HTTP. Cả hai kênh cung cấp liên lạc giữa các chương trình gửi và nhận riêng sử dụng socket.

Cũng có thể tích hợp kênh HTTP với IIS và chương trình nhóm ASP.NET bởi một số lý do quan trọng sau. Thứ nhất, chỉ có một cách để tự động khởi động một điểm cuối .NET Remoting khi một client yêu cầu đến. Quá trình hoàn thành .Net Remoting không sử dụng kiểu DCOM Service Control Manager (SCM) để khởi động các server từ xa. Bạn chỉ có thể lấy được các đối tượng từ xa trong chương trình riêng khi chương trình đó đang chạy. Đồng thời phải đảm bảo chúng là dòng an toàn, ví dụ như dòng A không thể kích hoạt một đối tượng sau khi dòng B bắt đầu kết thúc tiến trình. Nếu sử dụng các đối tượng từ xa của ASP.NET, bạn có thể thấy chương trình nhóm Aspnet_wp.exe vừa có chức năng tự động khởi động, vừa là dòng an toàn. Thứ hai, như được mô tả trong phần tiếp theo, khả năng tích hợp với IIS là cách bạn có thể bảo đảm an toàn lời gọi .Net Remoting chương trình chéo.

Cả cấu trúc cơ sở của ASP.NET Web Services và .Net Remoting đều có khả năng mở rộng. Bạn có thể lọc thông tin bên trong và bên ngoài đường bao, điều khiển các khía cạnh của kiểu sắp xếp thứ tự và metadata chung. Với .Net Remoting bạn cũng có triển khai các bộ định dạng và kênh riêng.

Bảo mật

Từ khi ASP.NET Web Services sử dụng trên HTTP, chúng được tích hợp với cơ sở hạ tầng bảo mật Internet. ASP.NET thúc đẩy các thành phần bảo mật kết hợp với IIS, cung cấp công cụ hỗ trợ mạnh cho các khung thẩm định tiêu chuẩn HTTP như Basic, Digest, thẩm định chứng chỉ số và thậm chí cả .NET Passport của Microsoft. (Bạn có thể dùng bộ thẩm định Windows Integrated, nhưng chỉ cho các client trong một domain tin cậy). Một cải tiến nâng cao khi dùng các khung thẩm định HTTP là không đòi hỏi phải thay đổi mã trong Web service, IIS thực hiện thẩm định trước khi ASP.NET Web Services được gọi. ASP.NET cũng cung cấp phần hỗ trợ cho chương trình thẩm định trên nền .NET Passport và nhiều khung thẩm định tuỳ biến khác. Các thành phần hỗ trợ ASP.NET truy cập điều khiển dựa trên các đường dẫn URL đích và bằng cách tích hợp chúng với cấu trúc cơ sở Bảo mật truy cập mã .NET (CAS). SSL có thể được dùng để đảm bảo kênh truyền thông riêng qua dây.

Mặc dù các kỹ thuật mức truyền vận tiêu chuẩn bảo đảm an toàn cho các Web service khá hiệu quả, nhưng chúng cũng chỉ dừng ở đó. Trong nhiều môi trường tổng hợp như các Web service đa dịch vụ trong các hệ thống tên miền (domain) tin cậy khác, bạn phải xây dựng nhiều giải pháp đặt biệt tuỳ biến. Microsoft và nhiều hãng khác vẫn đang tiếp tục làm việc trên một tập hợp các chi tiết kỹ thuật bảo mật xây dựng trên thành phần mở rộng của thông tin SOAP để cung cấp các khả năng bảo mật mức thông tin. Một trong các công nghệ đó là XML Web Services Security Language (WS-Security), được định nghĩa như là một framework cho hoạt động truyền tải đáng tin cậy mức thông tin, toàn vẹn thông tin và bảo mật thông tin.

Như đã được chú ý trong phần trước, quá trình hoàn thành .Net Remoting không đảm bảo an toàn cho các viện dẫn chương trình chéo trong trường hợp chung. Một điểm cuối .Net Remoting đưa vào trong IIS với ASP.NET có thể thúc đẩy tất cả thành phần bảo mật giống nhau sẵn sàng cho các Web service ASP.NET, bao gồm hỗ trợ an toàn truyền thông qua hàng rào dùng SSL. Nếu bạn đang dùng kênh TCP hoặc HTTP cho các chương trình thay vì aspnet_wp.exe, bạn phải tự mình thẩm định, cấp phép và quản lý cơ chế bảo mật.

Một khái niệm bảo mật truyền thống là khả năng thực thi mã từ môi trường phần nào đáng tin cậy mà không phải thay đổi cơ chế bảo mật mặc định. Các proxy client ASP.NET Web Service làm việc trong những môi trường như thế. Nhưng proxy của .Net Remoting thì không. Để dùng proxy .Net Remoting từ môi trường phần nào đáng tin cậy, bạn cần phải có quyền sắp xếp thứ tự đặc biệt không cung cấp mã tải từ mạng Intranet hay Internet mặc định. Nếu bạn muốn dùng .Net Remoting client từ bên trong môi trường phần nào đáng tin cậy, bạn phải chỉnh sửa cơ chế bảo mật mặc định về load mã từ các khu vực này. Trong nhiều trường hợp, khi bạn đang kết nối tới các hệ thống từ client chạy trong sandbox (giống như download ứng dụng Windows Forms chẳng hạn), sử dụng ASP.NET Web Services sẽ đơn giản hơn vì bạn không cần phải thay đổi cơ chế bảo mật mặc định của nó.

Quản lý trạng thái

Mô hình ASP.NET Web Services sử dụng cấu trúc dịch vụ không trạng thái làm mặc định. Nó không tương quan với đa lời gọi từ cùng một người dùng. Thêm vào đó, mỗi lần một client viện dẫn một Web service ASP.NET, đối tượng mới sẽ được tạo để phục vụ cho yêu cầu. Đối tượng này được bỏ đi sau khi lời gọi phương thức hoàn thành. Để duy trì trạng thái giữa các yêu cầu, bạn có thể dùng cùng kỹ thuật như các trang ASP.NET (VD: các gói thuộc tính "Session and Application") hoặc có thể tự triển khai giải pháp riêng của mình.

.Net Remoting hỗ trợ khá nhiều tuỳ chọn quản lý trạng thái, có thể hoặc không tương đương với nhiều lời gọi từ một người dùng, tuỳ thuộc vào giản đồ thời gian sống của đối tượng bạn chọn. Các đối tượng SingCall không có trạng thái (giống như các đối tượng dùng để viện dẫn ASP.NET Web Services), các đối tượng Singleton chia sẻ trạng thái cho tất cả client và các đối tượng kích hoạt client duy trì trạng thái trên từng client cơ sở (với tất cả độ đàn hồi và tin cậy có thể).

Thực thi

Trong thuật ngữ "thực thi thô", .Net Remoting hoàn chỉnh cung cấp khả năng truyền thông nhanh nhất khi bạn dùng kênh TCP và bộ định dạng nhị phân. Trong hầu hết các bài kiểm tra được đưa ra để so sánh thực thi quan hệ của ASP.NET Web Services và .Net Remoting thì các dịch vụ Web của ASP.NET thực hiện tốt hơn các điểm cuối .Net Remoting sử dụng bộ định dạng SOAP với kênh HTTP hoặc TCP. Thú vị hơn ASP.NET và các điểm cuối .Net Remoting dùng bộ định dạng nhị phân và kênh HTTP tương tự nhau trong thực thi.

Các dịch vụ doanh nghiệp

Một Web Service ASP.NET hoặc một đối tượng lấy ra từ .Net Remoting có thể dùng các giao tác cục bộ để làm việc kết hợp trước một cơ sở dữ liệu đơn. Nếu cần làm việc trước nhiều tài nguyên, nó có thể dùng .Net Enterprise Services (a.k.a COM+) khai báo giao tác (một giao tác phân phối DTC được quản lý bằng chương trình COM+). Cũng cần lưu ý rằng chỉ một trong hai, hoặc ASP.NET Web services , hoặc .Net Remoting hỗ trợ truyền giao tác khai báo. Vì thế một trong hai loại điểm cuối không thể kế thừa giao tác khai báo qua lời gọi chương trình chéo.

Điều này không thực sự cần thiết. Nhìn chung, một giao tác khai báo thường đắt hơn một giao tác cục bộ. Cho dù bạn có truyền nó qua ranh giới chương trình, nó vẫn đắt hơn. Nếu bạn vẫn cần chức năng này, giải pháp dễ dàng là triển khai một lớp bắt nguồn từ System.EnterpriseServices.ServicedComponent trong một ứng dụng server .NET Enterprise Services. Những lời gọi chéo chương trình tới các đối tượng của kiểu này sẽ được điều khiển bằng DCOM để đảm bảo quá trình truyền ngữ cảnh giao tác diễn ra phù hợp. Giải pháp khó hơn là dùng các API mức thấp hơn để truyền giao tác phần phối thủ công.

Bạn cũng cần lưu ý rằng mô hình giao tác được phân phối theo lớp nhìn chung không phù hợp cho các Web service kết hợp lỏng. Mô hình dựa trên các giao tác bù, là các giao tác khôi phục lại nhiều hoạt động bị bỏ qua của các giao tác khác thì tốt hơn vì chúng có ít ràng buộc riêng nghiêm ngặt hơn. Có sự thống nhất chung giữa các hãng cung cấp dịch vụ Web service, trong đó có Microsoft là cần sử dụng nhiều mô hình giao tác mềm dẻo trong không gian Web service, và có nhiều hoạt động đang diễn ra liên tục trong không gian này. Hiện nay vẫn chưa có phương thức tiêu chuẩn cho các giao tác Web service nên bạn có thể triển khai khung bù riêng của mình, sử dụng các giao tác khai báo hoặc cục bộ một cách thích hợp.

Chọn kiểu cấu trúc

Nếu bạn đang thiết kế một ứng dụng phân phối xây dựng trên .NET, bạn phải xem xét tới tất cả các vấn đề đã được nói ở trên và vẽ khái quát sơ đồ cấu trúc hệ thống đó ra. Nhìn chung nó thường dễ dàng hơn bạn tưởng. Một số trường hợp đòi hỏi phải có cách thức chỉnh sửa đặc biệt, cần phải có những kỹ thuật riêng. Ở đây chúng tôi cung cấp một số trường hợp giả định chung, thường đơn giản hơn cho bạn.

Đầu tiên là sử dụng ASP.NET Web Services mặc định. Chúng đơn giản hơn trong triển khai và sử dụng. Chúng cung cấp cách thức lớn nhất có thể cho các platform client. Mã proxy client của ASP.NET Web Services có thể được viện dẫn từ mã chạy trong một sanbox theo cơ chế bảo mật mặc định.

Nếu bạn cần mô hình đối tượng được phân phối truyền thống hơn với độ tin cậy hoàn toàn kiểu CLR, bạn không cần thực hiện các phần với platform khác mà điều khiển cấu hình của cả client và server, xem như .Net Remoting. Nếu bạn chọn .Net Remoting, tốt hơn nên kết hợp kênh HTTP với IIS và ASP.NET. Nếu không bạn sẽ phải xây dựng chương trình quản lý chu kỳ hoạt động chương trình và cấu trúc cơ sở bảo mật riêng. Muốn được như thế, .Net Remoting đòi hỏi phải có một .NET client. Bạn nên dùng bộ định dạng nhị phân thay vì bộ định dạng SOAP. Thao tác giữa các phần không phải là một vấn đề và khả năng thực thi sẽ được chú ý tốt hơn.

Cuối cùng, sử dụng Enterprise Services (COM+) khi bạn cần đến các giao tác khai báo. Nếu bạn sử dụng ServicedComponents, hãy triển khai chúng trong các ứng dụng thư viện mặc định để thực thi tốt hơn. Triển khai chúng trong các ứng dụng server nếu chúng cần chạy trên các máy từ xa. (Bạn cũng có thể xem xét đến các ứng dụng COM+ server nếu cần thực thi mã với mã thông báo bảo mật chương trình khác, hơn là chỉ dùng bằng aspnet_wp.exe, ngay cả khi dùng trên cùng một máy).

Dưới đây là ba cấu trúc phổ biến theo các phương thức trên:

Hình 1. Kiến trúc 3 tầng đơn giản

Hình 1 mô tả cấu trúc 3 tầng đơn giản với một khu Web server hỗ trợ nhiều client khác nhau. Tất cả mã server thực thi trong chương trình nhóm ASP.NET, aspnet_wp.exe. Ba kiểu client khác nhau truy cập server bằng cách dùng HTTP. Các client dựa trên cơ sở trình duyệt sử dụng trang web ASP.NET; các client giàu (như các ứng dụng Windows Forms, 6 ứng dụng Microsoft® Visual Basic®) và các Web service khác dùng ASP.NET Web Services; các client .NET giàu (như các ứng dụng Windows Forms) và Web service dùng ASP.NET Web Services hoặc .Net Remoting với kênh HTTP và bộ định dạng nhị phân (giả định là nó không nằm trong sandbox) như mong đợi.

Hình 2. Kiến trúc nhiều tầng sử dụng ASP.NET

Một số ứng dụng rất lớn dùng các kiểu máy thứ hai để hoạt động offload từ tần ngoài của Web servers. Cấu trúc này được mô tả trên hình 2. Chú ý rằng trong trường hợp này, tầng thứ hai cũng sử dụng chức năng qua ASP.NET.

Hình 3. Kiến trúc nhiều tầng sử dụng Enterprise Services (COM+)

Hình 3 mô tả dạn khác của kiến trúc nhiều tầng. Tầng thứ hai khai thác tính năng ServicedComponents triển khai trong COM+.

Tất nhiên đây không phải là toàn bộ kiến trúc .NET Framework hỗ trợ. Nhưng chúng cung cấp cái nền tảng cơ sở giúp bạn phát triển và xây dựng hệ thống cho riêng mình.

Kết luận

Mặc dù cả cấu trúc cơ sở .Net Remoting và ASP.NET Web Services đều cho phép hình thức truyền thông tiến trình chéo. Nhưng mỗi loại lại được thiết kế khác nhau, tuỳ thuộc vào hướng sử dụng mà chúng nhắm tới. ASP.NET Web Services cung cấp mô hình lập trình đơn giản với phạm vi rộng. .Net Remoting cung cấp mô hình lập trình tổng hợp hơn nhưng phạm vi bị hạn chế nhiều. Điều quan trọng là bạn phải hiểu được cách hoạt động của cả hai công nghệ này để lựa chọn phương thức phù hợp nhất cho ứng dụng của mình. Một trong hai trường hợp có thể dùng IIS và ASP.NET để quản lý chu kỳ hoạt động chương trình và cung cấp mức bảo mật chung trong một số trường hợp.