Van Thoai Nguyen's Blog - Chia sẽ những kĩ thuật lập trình .NET

Bài viết này được dịch từ Chapter 25 - INTRODUCING WINDOWS COMMUNICATION FOUNDATION của sách Pro C# 2008 and the NET 3.5 Platform Fourth Edition.



- .NET 3.0 giới thiệu một API mới hỗ trợ chúng ta build các hệ thống distributed gọi là Windows Communication Foundation (WCF). Không như những distributed APIs khác mà có thể bạn từng sử dụng (như DCOM, .NET Remoting, XML web services, …), WCF cung cấp một chuẩn lập trình thống nhất, dễ mở rộng và có thể tương tác được với các công nghệ distributed cũ. Loạt bài này sẽ giới thiệu sự cần thiết của WCF và những vấn đề sẽ giải quyết được bằng WCF, bắt đầu bằng một giới thiệu sơ qua các công nghệ distributed đã có.

A Potpourri of Distributed Computing APIs

- Hệ điều hành Windows đã cung cấp một số APIs để build những hệ thống distributed. Mọi người thường nghĩ rằng “distributed systems” thì phải có ít nhất 2 máy tính, nhưng theo nghĩa rộng thì khái niệm này nói đến 2 application nào đó cần trao đổi dữ liệu với nhau, dù chúng chạy trên cùng một máy tính. Nếu hiểu theo nghĩa này, việc chọn lựa công nghệ để sử dụng sẽ liên quan đến việc trả lời câu hỏi sau đây:

Liệu hệ thống được làm ra sẽ sử dụng “in-house”, hay nó có thể được những người bên ngoài sử dụng?

- Nếu bạn muốn build một hệ thống chỉ để sử dụng nội bộ, rất có khả năng rằng bạn sẽ phải bảo đảm mỗi máy tính trong toàn bộ hệ thống phải chạy cùng một hệ điều hành như nhau, cùng sử dụng một framework (.NET, COM, J2EE, v.v), và bạn sẽ có thể phải tuân theo các chuẩn của hệ thống bảo mật hiện tại khi implement các chứng năng như authentication và authorization. Trong tình huống như vậy, bạn buộc phải chọn đúng một công nghệ distributed API phù hợp với 1 hệ điều hành nào đó, tương thích với 1 framework nào đó.

- Ngược lại, nếu bạn đang build một hệ thống cho cả “nội bộ” lẫn những người ngoài mạng sử dụng, bạn sẽ phải đối mặt với rất nhiều vấn đề. Đầu tiên, bạn không thể buộc-không thể biết người khác phải sử dụng hệ điều hành gì, không thể ép họ dùng framework nào để tương tác với hệ thống của bạn cũng như không thể biết họ sử dụng nền tảng bảo mật nào.

- Hơn nữa, nếu bạn làm việc trong một công ty lớn hoặc trong một môi trường mạng sử dụng rất nhiều hệ điều hành khác nhau cũng như nhiều công nghệ lập trình khác nhau, thì khi đó application “nội bộ” của bạn cũng sẽ gặp vấn đề như trên. Trong những tình huống như vậy, bạn cần phải chọn một công nghệ distributed flexible để bảo đảm cho hệ thống tương lai của mình có thể được sử dụng thuận tiện nhất.

- Dựa trên lời giải đáp cho câu hỏi trên, bước tiếp theo của chúng ta là phải xác định xem chính xác là API nào nên được chọn. Phần dưới đây sẽ giới thiệu sơ lược các công nghệ distributed chính đã được sử dụng bởi những Windows developer. Sau khi xong bài học lịch sử này, bạn sẽ dễ dàng thấy được tính hữu ích của Windows Communication Foundation.

The Role of DCOM

- Trước thời của .NET, Distributed Component Object Model (DCOM) là lựa chọn tối ưu trong cách distrubuted APIs. Một lợi ích của DCOM là nó cho phép tính “không phụ thuộc vị trí” đối với các components. Nghĩa là nó cho phép những phần mềm phía client được lập trình sao cho “địa chỉ vật lý” của các remote objects không bắt buộc phải hard-code. Cho dù các remote object nằm cùng một máy tính hay trên các máy khác ở một network khác thì cũng không ảnh hưởng bởi vì “địa chỉ” thật sự được lưu bên ngoài hệ thống (bên trong registry).

- DCOM đã đạt được một số thành công nhất định đối với các phần mềm Windows. DCOM cũng đã được thử port sang một số hệ điều hành khác nhưng kết quả không mấy sáng lạn, DCOM một mình nó không đưa ra một bộ khung toàn diện để build những giải pháp liên quan đến nhiều hệ điều hành (Windows, Unix, Mac) hay có thể chia sẽ data giữa nhiều nền tảng công nghệ khác nhau (COM, J2EE, CORBA, …)

- Thông thường, DCOM là một lựa chọn khá thích hợp cho các ứng dụng nội bộ bởi vì expose các COM types ra phạm vi ngoài mạng công ty của bạn có thể gặp phải một số vấn đề phức tạp như firewalls. Với sự ra đời của .NET, DCOM nhanh chóng trở nên lạc hậu. Vì vậy, trừ khi bạn phải maintain 1 hệ thống cũ có sử dụng DCOM, còn không ta có thể xem nó như là một công nghệ của quá khứ.

The Role of COM+/Enterprise Services

- DCOM chỉ định nghĩa một cách để thiết lập một kênh giao tiếp giữa hai phần mềm COM. Để bổ sung những yêu cầu khác khi build một giải pháp distrubuted computing toàn diện, Microsoft vào phút cuối đã đưa ra một công nghệ khác là Microsoft Transaction Server (MTS) rồi sau đó đổi tên thành COM+ ở một release sau đó.

- Bất chấp tên gọi, COM+ không chỉ được dùng bởi những COM developer, nó còn được sử dụng bởi những .NET developer. Từ phiên bản đầu tiên của .NET đã có chứa một namespace là System.EnterpriseServices. Nhờ nó, người dùng .NET có thể tạo ra những managed library để có thể install vào môi trường COM+, để có thể truy xuất những COM services. Trong trường hợp nào đi nữa, một “COM+ aware library” khi được install vào “COM+ runtime” sẽ được gọi là một “serviced component”

- COM+ cung cấp một số features mà các serviced component có thể sử dụng, bao gồm transaction management, objet lifetime management, pooling services, role-based security system, không phụ thuộc mô hình event, v.v. Đó chính là những lợi ích chính vào thời điểm đó vì hầu hết các hệ thống distributed system đều cần những tính năng như vậy. Một trong những cái rất thuyết phục của COM+ là khả năng điều chỉnh các setting dễ dàng bằng các administrative tools.

- Trong khi COM+/Enterprise Services vẫn còn được sử dụng, công nghệ này một lần nữa lại là “Windows-only solution” và thực sự chỉ thích hợp với các giải pháp “in-house” hoặc đóng vai trò như một back-end service cho một hệ thống khác, một public website chẳng hạn có thể call 1 serviced components (COM+ objects) ở background.

- WCF không hỗ trợ build những serviced components. Tuy nhiên nó cung cấp một phương pháp để các WCF services giao tiếp với các COM+ objects. Nếu bạn muốn build một serviced components bằng C#, bạn phải dử dụng trực tiếp namespace System.EnterpriseServices.

The Role of MSMQ

- Microsoft Message Queuing (MSMQ) API cho phép developer build những hệ thống distributed cần tính tin cậy cao khi gửi/nhận những dữ liệu trong network. Như chúng ta đều biết, trong bất kì distributed system nào cũng đều có một nguy cơ là các server có thể bị down bất cứ lúc nào, database server offline hay các kết nối mạng bị đứt giữa chừng. Hơn nữa, có một số application cần được thiết kế để có thể lưu giữ những message để rồi có thể truyền đi sau đó (queuing data).

- Lúc đầu, MSMQ được đóng gói như một thư việc cấp thấp C và các COM objects. Khi sử dụng System.Message namespace, .NET developer có thể hook vào MSMQ và build những application có thể giao tiếp với những application mà không có kết nối liên tục. Thêm nữa, COM+ layer có thể kết hợp với các chức năng của MSMQ bằng một kĩ thuật gọi là Queued Components (QC).

- Bất kể bạn dùng kĩ thuật nào để tương tác với MSMQ runtime, cuối cùng bạn cần đảm bảo rằng application mình viết có thể gửi đi những Message đúng nơi đúng lúc. Cũng giống như COM+, MSMQ vẫn còn được sử dụng để build những distributed software trong môi trường Windows.

The Role of .NET Remoting

- Như đã nói ở trên, cùng với sự ra đời của .NET platform, DCOM mau chóng trở nên lỗi thời. Và thay vào đó là một .NET class libraries được đóng gói sẵn trong .NET remoting layer: System.Runtime.Remoting. API này cho phép nhiều máy tính có thể host nhiều remoted objects, tất nhiên chúng phải chạy những ứng dụng .NET.

- .NET remoting API có một số những tính năng rất hữu dụng. Trong đó, tính năng quan trọng nhất chính là khả năng sử dụng file xml config để có thể khai báo những seting quan trọng cho phép client và server có thể giao tiếp với nhau theo nhiều cách. Bằng cách này, sẽ rất dễ dàng để thay đổi tính năng của application chỉ với một vài chỉnh sửa file config và restart application.

- Thực sự rằng API này chỉ có thể sử dụng bởi những application .NET, nhờ đó bạn có thể thừa hưởng được nhiều lợi ích, như là data có thể được mã hóa và nén ở dạng binary, có thể sử dụng ngay các Common Type System (CTS) khi khai báo biến và return values. Thực ra với công nghệ này có thể sử dụng .Net để build những distributed system mà có thể chạy trên nhiều hệ điều hành khác nhau (sử dụng MONO), tương tác với các nền tảng khác như J2EE …

The Role of XML Web Services

- Các distributed APIs ra đời trước đều hỗ trợ rất ít (nếu có) khả năng access đến các chức năng của hệ thống từ một caller chưa biết. Khi bạn cần đưa ra một số services để người khác có thể sử dụng không cần biết người đó sử dụng hệ điều hành gì và công nghệ nào thì XML web services có vẽ như là lựa chọn hợp lý nhất.

- Không như các web application thông dụng, một web service được sử dụng để expose các chứng năng của remote components nhờ vào web protocols. Trong phiên bản đầu của .NET, developer được cung cấp một số chức năng để build và gọi (consuming) XML web services trong namespace System.Web.Services. Thực ra bây giờ người ta chỉ việc sử dụng attribute [WebMethod] cho mỗi public method mà bạn muốn người khác có thể sử dụng. Hơn nữa, Visual Studio 2008 còn cho phép bạn connect đến một remote web service chỉ với vài cái click.

- Web services cho phép developer build những .NET assemblies với những .NET types có thể được gọi thông qua giao thức HTTP đơn giản. Hơn nữa, một web service có thể mã hóa dữ liệu của nó theo chuẩn XML. Công nghệ Web service dựa trên các tiêu chuẩn của ngành phần mềm như HTTP, XML, SOAP thay vì một số kĩ thuật đặc thù như DCOM hay .NET remoting, chúng nâng cao khả năng giao tiếp tối đa giữa các hệ thống khác nhau.

- Tất nhiên không có một distributed API nào là hoàn hảo. Một trở ngại tiềm tàng của web services là vấn đề về performance (sử dụng HTTP và XML), và nó có thể không phải là một lựa chọn tốt để build những ứng dụng “in-house” khi mà TCP-based protocol và dữ liệu ở dạng binary format có thể được sử dụng mà không gặp bất cứ trở ngại nào.



Hình 1: XML web services allow for a very high degree of interoperability

Web Service Standars

- Một vấn đề dễ thấy nhất là có khá nhiều ông lớn như Microsoft, IBM và Sun Microsystems tạo ra các chuẩn Web Services của riêng mình và các chuẩn này không 100% tương thích với nhau. Hiển nhiên đó là một vấn đề rất đau đầu, chúng ta đều biết rằng mục đích của Web service là tạo ra khả năng tương tác cao giữa các hệ thống không phụ thuộc platforms và hệ điều hành.

- Để bảo đảm tính độc lập môi trường của Web Service, những tổ chức như World Wide Web Consortium (W3C; http://www.w3.org) và Web Services Interoperatibility Organization (WS-I: http://www.ws-i.org) đã đứng ra xem xét các đặc tả để vạch ra những điều chi tiết để các software vendor (như IBM, Microsoft, Sun,..) nên build những công nghệ của họ như thế nào để bảo đảm tính tương thích với nhau.

- Tập hợp các đặc tả này được đặt tên theo kiểu prefix WS-, bao gồm các vấn đề về security, attachments, description của web services (Web Service Description Language, hay WSDL), policies, SOAP formats, và một số những vấn đề quan trọng khác.

- Có thể bạn đã biết rằng Microsoft đã hỗ trợ hầu hết các chuẩn trên trong Web Services Enhancements (WSE) 3.0 toolkit, bạn có thể download nó ở website: http://msdn2.microsoft.com/en-us/webservices

- Khi bạn build những WCF service applications, bạn sẽ không cần sử dụng trực tiếp các assemblies của WSE 3.0 toolkit. Ngoài ra, nếu bạn build những WCF service sử dụng HTTP-based binding, mặc định các đặc tả WS-* sẽ có sẵn cho bạn.

Named Pipes, Sockets, and P2P

- Nếu như DCOM, .NET Remoting, web services, COM+ và MSMQ vẫn chưa đủ “challenge” đối với bạn thì bạn có thể sử dụng các APIs giao tiếp khác như pipes, sockets và peer-to-peer (P2P) services. Những APIs cấp thấp này hứa hẹn sẽ có performance cao hơn nhiều đặc biệt đối với những máy LAN nhưng bù lại sử dụng chúng sẽ khá phức tạp.

- Nếu bạn phải build những hệ thống distributed mà các application chạy trên cùng một máy, bạn có thể sử dụng “named pipes” API trong namespace System.IO.Pipes (.NET 3.5). Kĩ thuật này là cách nhanh nhất để truyền data giữa các applications trong cùng một máy tính.

- Cuối cùng, nếu bạn build những applications cần đi sâu chi tiết cách truyền dữ liệu trên network thì sockets và P2P có thể được dùng trong các namespace System.Net.Sockets và System.Net.PeerToPeer.