Đồ án Về window azure

rữ khác, đó chính là mục đích của dịch vụ Windows Azure Storage. 2.2.1.2 Dịch vụ Storage Ứng dụng có thể làm việc, thao tác dữ liệu theo nhiều cách khác nhau, dịch vụ Windows Azure Storage cung cấp các phương thức lưu trữ và xử lý dữ liệu. Để làm việc với Storage, việc đầu tiên là phải tạo một tài khoản Storage (Storage Account), Windows Azure sẽ cung cấp một khóa bí mật cho tài khoản để kiểm soát các truy nhập vào thông tin trong tài khoản Storage đó, mỗi ứng dụng muốn truy xuất dữ liệu (blobs, table hoặc queue) từ Storage phải cung cấp khóa bí mật để xác thực. Hình 2.5 mô tả các dịch vụ lưu trữ trong Storage service: Blobs, Tables và Queues Hình 2.5: Các dịch vụ Storage Services [3] Blobs Cách thông thường nhất để lưu trữ dữ liệu là sử dụng Blobs (Binary-large-objects). Blobs có thể chứa hình ảnh, âm thanh, video, emails,... Để làm việc với Blobs, lập trình viên phải tạo ít nhất một vùng chứa (containers) trong storage account, mỗi một vùng chứa này sẽ chứa một hoặc nhiều blobs. Blobs có thể rất lớn, kích thước tối đa là 50 gigabytes. Để xác định một blobs cụ thể, ứng dụng sử dụng chuỗi URI có dạng: Trong đó là định danh khi tạo tài khoản Storage, và là tên Container và tên Blob cần truy xuất. Lưu ý là các Container chỉ có thể chứa Blobs, không thể lồng ghép Container khác nên việc tạo cấu trúc phân cấp với Container là không thể. Thay vào đó, có thể dùng ký hiệu “/” trong tên Blob (BlobName) để phân cấp nếu cần. Như đã nói kích thước Blobs có thể lên tới 50GB, nên để việc truyền dữ liệu Blobs hiệu quả, mỗi blobs có thể được chia ra thành nhiều khối (block), nếu việc truyền bị ngắt quãng, có thể truyền lại bắt đầu từ khối được truyền gần nhất thay vì phải truyền lại cả blobs, sau khi tất cả các block được truyền, chúng sẽ được ghép lại thành blobs ban đầu. Có thể quy định thuộc tính private (riêng tư) hoặc public (công cộng) cho Container, với các blobs trong private container, các yêu cầu đọc và ghi cần được xác thực với khóa bí mật tương ứng của Storage Account chứa blobs, trong khi với public container, chỉ thao tác ghi cần cung cấp khóa bí mật, mọi ứng dụng có thể đọc dữ liệu từ public container. Tables Để làm việc với các dữ liệu có cấu trúc, Windows Azure storage cung cấp tables service. Trên thực tế đó không phải là các bảng quan hệ, dữ liệu chứa trong chúng thực tế là tập các thực thể với các thuộc tính. Thay vì sử dụng SQL ứng dụng truy cập các table sử dụng cú pháp định nghĩa bởi ADO.NET Data Services. Mỗi một table chứa một hoặc nhiều thực thể, mỗi thực thể lại có các thuộc tính, các thuộc tính gồm 3 thành phần: Tên thuộc tính (name), kiểu thuộc tính (type) và giá trị thuộc tính (value). Có rất nhiều kiểu thuộc tính được hỗ trợ, gồm Binary, Bool, DateTime, Double, GUID, Int, Int64, String. Mỗi một thuộc tính còn có thể có kiểu khác nhau vào những thời điểm khác nhau tùy thuộc vào giá trị lưu trong nó, hơn nữa cũng không cần thiết tất cả các thuộc tính trong 1 thực thể phải có cùng kiểu. Kích thước tối đa của một thực thể là 1MB và mỗi thực thực được coi là đơn vị dữ liệu, thao tác đọc một thực thể sẽ trả lại giá trị của tất cả các thuộc tính. Ngược lại thao tác ghi sẽ thực hiện ghi lên tất cả các thuộc tính. Windows Azure Tables Storage có nhiều điểm khác biệt với các bảng dữ liệu quan hệ, đầu tiên là chúng thực sự không phải là các bảng thông thường, không thể truy cập sử dụng thuần túy ADO.NET hay truy vấn SQL. Tables Storage không quy định cấu trúc (schema) chặt chẽ như bảng quan hệ, một thuộc tính trong mỗi thực thể có thể có kiểu dữ liệu khác nhau và có thể thay đổi. Một câu hỏi được đặt ra: Tại sao Windows Azure không hỗ trợ mô hình các bảng dữ liệu quan hệ trong Tables và khả năng truy vấn SQL như các hệ RDBMS thông thường? Câu trả lời cũng nằm ở mục tiêu hỗ trợ khả năng mở rộng mạnh mẽ cho ứng dụng. Các bảng quan hệ truyền thống có thể scale-up, phục vụ số lượng lớn người dùng bằng việc chạy DBMS trên các máy chủ cực mạnh. Tuy nhiên để thực sự hỗ trợ số lượng khổng lồ yêu cầu cùng một lúc, không gian lưu trữ cần scale-out chứ không chỉ scale-up, đó là lý do Windows Azure Storage thiết kế mô hình thực thể trong Tables thay vì các bảng dữ liệu quan hệ với chuẩn SQL thông thường. Ứng dụng .NET có thể truy cập vào các tables bằng cách sử dụng ADO.NET Data Services hoặc Language Integrated Query (LINQ), chẳng hạn một yêu cầu HTTP GET để truy vấn tables sẽ có dạng: Ở đây chỉ ra tên bảng cần truy vấn, chứa câu lệnh truy vấn theo chuẩn LINQ. Việc cập nhật dữ liệu vào tables có thể gặp vấn đề: Điều gì xảy ra nếu hai ứng dụng cùng muốn cập nhật dữ liệu vào 1 thực thể trong table, việc cập nhật một thực thể sẽ bao gồm đọc thực thể, thay đổi nội dung thuộc tính, thêm/xóa thuộc tính và ghi lại thực thể vào bảng. Giả sử cả 2 ứng dụng đều cùng đọc thực thể, chỉnh sửa và sau đó ghi lại, điều gì sẽ xảy ra? Câu trả lời là ứng dụng nào thực hiện ghi trước sẽ thành công, còn ứng dụng ghi sau sẽ thất bại. Queues Blob và Table Storage đều sử dụng để lưu trữ và truy xuất dữ liệu. Dạng lưu trữ thứ ba được Windows Azure cung cấp có mục đích hơi khác. Tính năng chính của queue là cung cấp phương thức để Web Role instance kết nối với Worker Role instance. Ví dụ, user submit một yêu cầu tính toán thông qua giao diện web, Web Role instance nhận request này và ghi một message vào queue mô tả công việc cần thực hiện. Worker Role instance có thể đọc message và xác định công việc cần thực thi. Các ứng dụng Windows Azure và các ứng dụng khác đều có thể tham chiếu đến một queue sử dụng URI có dạng: 2.2.1.3 Fabric Toàn bộ ứng dụng và dữ liệu trong Windows Azure Storage đều chứa trong các data center của Microsoft. Trong data center, hệ thống máy móc này được tổ chức thành các fabric. Hình 2.6: Fabric Controller [5] Windows Azure Fabric gồm một nhóm các máy tính, các máy trong nhóm đều được quản lý bởi một phần mềm gọi là fabric controller. Fabric Controller quản lý một nhóm từ 5 – 7 máy tính và sở hữu tất cả tài nguyên trong fabric: máy tính, switches, load balancers, … Fabric controller có khả năng giao tiếp với fabric agent trên các máy, nó cũng giám sát các ứng dụng Windows Azure trong fabric đó. Fabric controller giám sát các ứng dụng thực thi, quản lý operating system, đảm nhiệm các công việc như vá lỗi, cập nhật VM. Nó cũng quyết định ứng dụng sẽ chạy ở nơi nào, lựa chọn server vật lý để tối ưu hóa hệ thống phần cứng. Để làm điều đó fabric controller phụ thuộc vào file cấu hình được upload cùng với mỗi ứng dụng Windows Azure , file này có cấu trúc dạng XML mô tả những thông tin cấu hình mà ứng dụng cần: bao nhiêu Web Role instance, bao nhiêu Worker Role instance, …Khi fabric controller nhận được một ứng dụng mới, nó sẽ sử dụng file cấu hình này để xác định bao nhiêu Web Role và bao nhiêu Worker Role VM cần thiết lập. Một khi VM đã được tạo ra, fabric controller sẽ giám sát VM đó, nếu một ứng dụng yêu cầu 5 Web Role instances và một trong số đó gặp vấn đề trục trặc, Fabric Controller sẽ tự động khởi động lại một instance mới, hoặc nếu máy chủ mà VM chạy gặp vấn đề, fabric controller sẽ khởi động instance mới trên một VM mới (tất nhiên trên máy chủ khác) và thiết lập lại load balancer để trỏ đến máy chủ mới. 2.2.2 SQL Azure SQL Azure cung cấp tập các dịch vụ đám mây hỗ trợ lưu trữ và làm việc với nhiều loại thông tin. Hiện tại, Microsoft đưa ra 2 thành phần chính của SQL Azure: SQL Azure Database và “Huron” Data Sync. Hịnh 2.7: Các dịch vụ bên trong SQL Azure [4] 2.2.2.1 SQL Azure Database SQL Azure Database cung cấp một RDBMS trong “đám mây”. Nó cho phép ứng dụng đám mây và ứng dụng on-premises có thể lưu trữ cơ sở dữ liệu quan hệ hoặc dạng khác trên các server tại Microsoft Data Center. Chi phí sẽ được tính dựa trên những gì sử dụng, thay đổi tùy theo nhu cầu sử dụng. Sử dụng Cloud Database cũng cho phép người dùng không phải bận tâm đến các phần mềm DBMS, đĩa cứng lưu trữ, … Không giống như Windows Azure Storage service, SQL Azure Database xây dựng dựa trên Microsoft SQL Server. SQL Azure Database hỗ trợ cơ sở dữ liệu quan hệ, môi trường SQL Server trong Cloud với Indexes, Views, Store Procedures, Triggers, … Dữ liệu có thể truy cập thông qua ADO.NET và các giao diện truy cập dữ liệu khác của Windows. Trong khi các ứng dụng sử dụng SQL Azure Database hầu như tương tự như sử dụng local DBMS thì công sức quản lý CSDL giảm đi rất nhiều khi sử dụng SQL Azure Database. Người sử dụng SQL Azure Database có thể tập trung vào đối tượng quan tâm chính của họ: Dữ liệu. Hình 2.8: Cơ sở dữ liệu quan hệ SQL Azure Database [4] Ứng dụng sử dụng SQL Azure Database có thể chạy trên Windows Azure, trong Data Center của doanh nghiệp, trên thiết bị di động, … Ứng dụng truy cập dữ liệu thông qua giao thức Tabular Data Stream (TDS). Đó cũng là giao thức được sử dụng đê truy cập dữ liệu trong local SQL Server database. Nhờ đó ứng dụng chạy SQL Azure Database có thể sử dụng client library của SQL Server. Quan trọng nhất có lẽ là ADO.NET, ODBC và các thư viện khác cũng có thể sử dụng. Trong SQL Azure Database, tất cả dữ liệu được nhân bản (replicate) 3 lần, khi ghi dữ liệu (write), toàn bộ các bản sao được cập nhật. Mục đích là cung cấp tính tin cậy dữ liệu ngay cả trong trường hợp hệ thống bị lỗi. Kích thước tối đa của một CSDL trong SQL Azure Database là 10 gigabytes. Ứng dụng cần không gian dữ liệu lớn hơn có thể sử dụng nhiều database. 2.2.2.2 Huron Data Sync Thành phần thứ 2 trong SQL Azure được giới thiệu là “Huron” Data Sync, xây dựng dựa trên Microsoft Sync Framework và SQL Azure Database, công nghệ này cho phép đồng bộ dữ liệu thông qua các on-premises DBMS. Người sử dụng và sở hữu dữ liệu sẽ xác định những gì cần đồng bộ, giải quyết các xung đột như thế nào, … Hình 2.9: Đồng bộ dữ liệu giữa SQL Azure Database và các nguồn CSDL khác [4] 2.2.2.3 Ứng dụng SQL Azure Các ứng dụng có thể sử dụng SQL Azure theo nhiều cách đa dạng: Ứng dụng Windows Azure lưu trữ dữ liệu trong SQL Azure Database, mặc dù Windows Azure có hỗ trợ Storage service, tuy nhiên nó không hỗ trợ mô hình bảng quan hệ. Trong khi đó mô hình bảng quan hệ rất phổ biến, các ứng dụng có thể dễ dàng làm việc với CSDL. Các ứng dụng trong một doanh nghiệp nhỏ hoặc một phần trong doanh nghiệp lớn có thể lưu trữ dữ liệu trên SQL Azure Database thay vì local SQL Server hoặc Access. Ứng dụng có thể tận dụng được những ưu điểm về độ tin cậy và tính sãn sàng của Cloud Storage Một nhà sản xuất có thể đưa dữ liệu lên SQL Azure Database để có thể truy cập từ các ứng dụng của nhà phân phối hoặc từ ứng dụng web để khách hàng truy cập. Tạo bản sao database nhờ ứng dụng “Huron” Data Sync 2.2.3 AppFabric (.NET Service) AppFabric (tên cũ là .NET Services) cung cấp các dịch vụ cơ sở hạ tầng (Infrastructure) trên “đám mây”. AppFabric hỗ trợ các nhà phát triển kết nối các ứng dụng và dịch vụ trong các đám mây hoặc on-premise (tải về). Nó bao gồm các ứng dụng chạy trong môi trường Windows Azure, Windows Server và các nền tảng khác như Java, Ruby, PHP, … AppFabric bao gồm 2 dịch vụ: Service Bus và Access Control. Access Control: Access Control cho phép bạn xây dựng hệ thống xác thực và kiểm tra thẩm quyền cho ứng dụng / dịch vụ web của bạn, giảm thiểu sự phức tạp trong việc tích hợp với rât nhiều các công nghệ xác thực mà khách hàng đang sử dụng. Sử dụng mô hình đơn giản và quen thuộc, Access Control cho phép bạn định nghĩa các quy tắc và yêu cầu, các quy tắc này có thể cấu hình để phù hợp với ứng dụng. Hình 2.10: Access Control quy định quyền truy cập với Users và Applications [9] Service Bus: Service Bus cung cấp kết nối an toàn giữa các dịch vụ và ứng dụng, cho phép chúng có thể vượt qua các rào cản như tường lửa hay giới hạn mạng, nhờ đó giải quyết các khó khăn liên quan đến các ràng buộc trong hệ thống mạng của ứng dụng. Một khi Service Bus thiết lập kết nối giữa các ứng dụng, nó cho phép các ứng dụng có thể liên lạc với nhau một cách mềm dẻo. Nhà phát triển có thể xây dựng giải pháp theo nhiều mô hình truyền thông khác nhau như relay, buffer, bidirectional (2 chiều), publish-subcribe, multicast, streaming hay direct-connect (kết nối trực tiếp). ServiceBus cung cấp cho mỗi dịch vụ 1 địa chỉ URI ổn định có thể truy cập được từ bất kỳ ứng dụng nào được xác thực. Hình 2.11: Service Bus kết nối giữa các ứng dụng cloud và on-premise [9] 2.3. Các mô hình ứng dụng Windows Azure Phần 2.2 đã trình bày các thành phần và dịch vụ mà Windows Azure Platform hỗ trợ, tuy nhiên để có thể tận dụng sức mạnh của nền tảng này, các thành phần đó cần được phối hợp với nhau một cách hiệu quả và hợp lý. Phần này sẽ đưa ra 4 mô hình xây dựng ứng dụng dựa trên nền tảng Windows Azure. Bốn mô hình ứng dụng trên là những mục tiêu cơ bản của Windows Azure CTP, trong tương lai, Windows Azure còn tiếp tục phát triển và cung cấp những giải pháp ngày càng mạnh mẽ hơn. 2.3.1. Ứng dụng web có khả năng mở rộng Giả sử một tổ chức muốn tạo một ứng dụng web, cách thông thường là sẽ là chạy ứng dụng đó trên một máy chủ của tổ chức đó hoặc của một nhà cung cấp host. Tuy nhiên, trong nhiều trường hợp, sử dụng một nền tảng đám mây như Windows Azure sẽ là lựa chọn tốt hơn. Chằng hạn, nếu như ứng dụng web cần phục vụ một số lượng lớn người dùng đồng thời, việc xây dựng ứng dụng trên nền Windows Azure sẽ hỗ trợ thực sự cho ứng dụng có thể tùy chỉnh quy mô, co giãn (scale) ứng dụng và dữ liệu để chịu tải lớn tốt hơn nhiều so với các công nghệ web truyền thống. Hoặc trong trường hợp tải của ứng dụng có sự thay đổi đáng kể, có những khoảng thời gian ứng dụng chỉ chịu tải rất ít, nhưng có những thời điểm tăng cao bất ngờ. Các ứng dụng dạng này có thể tìm thấy chẳng hạn như các trang tin tức hoặc chia sẻ video, khi có những tin nóng hoặc những đoạn video có thể thu hút số lượng người truy cập tăng nhanh chóng mặt, hoặc trong khoảng thời gian 1 ngày, số lượng truy cập của ứng dụng chỉ tập trung vào 1 khoảng thời gian nhất định. Chạy các ứng dụng dạng này theo mô hình truyền thống luôn cần phải có đủ tài nguyên để đối phó trong mọi trường hợp ứng dụng chịu tải bất ngờ, ngay cả những thời điểm ứng dụng chỉ phục vụ khá ít truy cập. Nếu như ứng dụng được xây dựng trong môi trường Windows Azure, người hay tổ chức sở hữu ứng dụng có thể mở rộng hay thu hẹp quy mô ứng dụng bằng cách thay đổi số lượng instance cấp cho ứng dụng tùy theo tình huống, Windows Azure sẽ tính chi phí trên số lượng instance mà ứng dụng dùng đến, nhờ đó tiết kiệm được tài nguyên so với cách host truyền thống. Để tạo ứng dụng web có khả năng mở rộng, nhà phát triển có thể sử dụng Web Role và Tables Storage. Hình 2.12 mô tả một khung ứng dụng cơ bản sử dụng Web role và Tables Hình 2.12: Mô hình ứng dụng web có khả năng mở rộng [5] Trong mô hình trên, ứng dụng có thể được xây dựng dựa trên nền ASP.NET hoặc 1 công nghệ Web khác. Nhà phát triển cũng có thể tạo ứng dụng web có khả năng mở rộng bằng cách sử dụng WCF với dịch vụ mạng (Web Services) RESTful hoặc dịch vụ mạng dựa trên SOAP (SOAP-base). Trong mọi trường hợp, nhà phát triển có thể chỉ định số lương instances ứng dụng sử dụng, Windows Azure Fabric Controller sẽ tạo ra các VM tương ứng. Như đã đề cập ở phần 2.2.1.3 (Fabric), fabric controller sẽ giám sát các instances, đảm bảo ứng dụng luôn có đủ số instance phục vụ cho ứng dụng. Để lưu trữ dữ liệu, ứng dụng sử dụng Windows Azure Storage Tables với khả năng scale-out để lưu trữ số lượng lớn dữ liệu. 2.3.2. Ứng dụng xử lý song song: Một trường hợp ứng dụng khác của Windows Azure là tạo các ứng dụng xử lý song song. Nhiều tổ chức/cơ quan đôi khi cần một số lương lớn các máy tính để xử lý 1 chương trình song song, chẳng hạn như để render các hiệu ứng đặc biệt cho một bộ phim, xử lý nghiệp vụ trong một ngân hàng, …Một giải phát là có thể đầu tư một hệ thống tính toán song song (cluster) gồm nhiều máy với cấu hình mạnh, tuy nhiên chi phí sẽ rất cao. Windows Azure sẽ là giải pháp kinh tế hơn nhiều, gần như một giải pháp siêu máy tính trực tuyến theo yêu cầu (on-demand SuperComputer). Nhà phát triển có thể sử dụng Worker Role để tạo các ứng dụng dạng này, hơn nữa, các ứng dụng song song thường sử dụng đến không gian dữ liệu lớn, Windows Azure có thể đáp ứng bằng Blobs. Hình 2.13 mô tả một khung ứng dụng song song trên nền Windows Azure Hình 2.13: Mô hình ứng dụng song song sử dụng WebRole, nhiều Worker Role instances, queues và blobs [5] Trong mô hình trên, việc tính toán song song được thực hiện bởi một số lượng lớn các Worker Role chạy song song, các Worker Role này sử dụng Blobs để lưu trữ dữ liệu. Để tương tác với ứng dụng, người dùng thống qua 1 WebRole instance, từ giao diện tương tác này, người dùng có thể xác định số lượng Worker Role instance cần thiết, khởi động, tạm dừng 1 số instance, lấy kết quả, … Việc liên lạc giữa WebRole instance và Worker Role instance được thực hiện nhờ “cầu nối” Queues Storage. Các queues này có thể truy cập từ các ứng dụng on-premise, do đó nếu không muốn phụ thuộc vào Web Role instance của Windows Azure, nhà phát triển có thể xây dựng ứng dụng chạy từ máy local để tương tác với các Worker Role instances. Hình 2.14 mô tả một tình huống như vậy Hình 2.14: Mô hình ứng dụng song song kết nối từ ứng dụng cục bộ đến Worker Role [5] Trong mô hình này, việc xử lý song song vẫn được thực hiện trên các Worker Role instances chạy song song, mỗi một instance tương tác với bên ngoài thông qua Queues, tuy nhiên khác với mô hình trước đó, lúc này các công việc trong Queues sẽ được ghi trực tiếp từ ứng dụng on-premises. 2.3.3. Ứng dụng web có khả năng mở rộng với xử lý hậu cảnh Có thể nói rằng ngày nay, rất nhiều ứng dụng đã được phát triển theo mô hình web-based, người sử dụng có thể tương tác thông qua trình duyệt. Việc giao tiếp ứng dụng thông qua trình duyệt có thể nói là đem lại nhiều thuận tiện và linh hoạt, tuy nhiên chúng cũng có những hạn chế. Có rất nhiều tình huống khi ứng dụng web-base cũng cần khởi tạo các công việc chạy ở hậu cảnh (background), độc lập với mô hình request/response của ứng dụng. Chẳng hạn như một ứng dụng Web chia sẻ video, nó có thể phải tiếp nhận rất nhiều yêu cầu từ người dùng thông qua browser trong cùng 1 thời điểm. Một số yêu cầu có thể là upload video mới, mỗi yêu cầu phải được xử lý và lưu video lại để có thể truy cập về sau. Việc để người dùng phải chờ trong khi yêu cầu được hoàn thành có thể không phải là cách hay. Thay vào đó, phần ứng dụng tiếp nhận yêu cầu từ trình duyệt có thể khởi tạo một tiến trình ở hậu cảnh để xử lý công việc. Windows Azure Web Role và Worker Role có thể sử dụng đồng thời để cài đặt mô hình này. Hình 2.15 mô tả khung ứng dụng dạng này Hình 2.15: Mô hình ứng dụng có khả năng mở rộng và xử lý ở hậu cảnh [5] Mô hình này sử dụng các Web Role instance để tiếp nhận các yêu cầu từ người dùng, để hỗ trợ một số lượng lớn người dùng song song, nó có thể dùng Tables Storage để lưu thông tin. Để xử lý hậu cảnh, ứng dụng dựa trên các Worker Role instances, Worker Roles tiếp nhận các công việc dựa trên Queues. Mô hình trên cũng cho một ví dụ tốt về việc phối hợp sử dụng tất cả các thành phần cơ bản của Windows Azure như Web Role intances, Worker Role instances, Blobs, Queues và Tables trong một ứng dụng. 2.3.4. Sử dụng Cloud Storage từ các ứng dụng on-premises hoặc ứng dụng host truyền thống Đôi khi các ứng dụng on-premises hoặc ứng dụng web truyền thống cũng cần lưu một lượng dữ liệu khổng lồ. Một doanh nghiệp có thể muốn lưu trữ toàn bộ các email, một trang web tin tức có thể có nhu cầu lưu trữ khối dữ liệu lớn văn bản, hình ảnh, video, … Một trang web chia sẻ hình ảnh muốn tìm một nhà cung cấp để lưu trữ dữ liệu với dung lượng lớn và độ tin cậy cao. Windows Azure Storage có thể đáp ứng những nhu cầu trên , hình 2.16 mô tả ý tưởng này. Hình 2.16: Mô hình ứng dụng từ máy cục bộ hoặc ứng dụng web truyền thống sử dụng Cloud Storage [5] Trong mô hình trên, các ứng dụng on-premise (chạy trên máy local) hoặc các ứng dụng đang được host trên 1 máy chủ đều có thể truy nhập trực tiếp vào Windows Azure Storage, mặc dù cách truy nhập này có thể chậm hơn so với truy cập bộ nhớ địa phương, nhưng nó sẽ rẻ hơn, khả năng mở rộng cao hơn và đáng tin cậy hơn. 2.4. Triển khai ứng dụng Microsoft Windows Azure Các lập trình viên có thể xây dựng ứng dụng Windows Azure bằng bộ công cụ quen thuộc Visual Studio và gói Windows Azure Development Kit (SDK) bổ sung. Windows Azure Development Kit cung cấp project templates cho Visual Studio để hỗ trợ tạo các thành phần như Web Role, Worker Role. Ngoài ra Microsoft còn cung cấp tool Development Fabric để giả lập môi trường Windows Azure trên máy cục bộ. Development Fabric chạy trên các máy cục bộ sử dụng Visual Studio 2008 (trở lên) và hệ điều hành Windows Server 2008 hoặc Windows Vista trở về sau, nó giả lập môi trường Windows Azure với các tính năng hỗ trợ Web Role, Worker Role, các dịch vụ Storage (Blobs, Tables, Queues). Với Development Fabric, nhà phát triển có thể xây dựng ứng dụng Windows Azure với các project template trong Visual Studio, chạy và kiểm tra ứng dụng với Development Fabric, đóng gói ứng dụng với tính năng Publish trong Visual Studio. Hình 2.17: Development Fabric cung cấp môi trường giả lập Windows Azure trên máy local cho các lập trình viên [5] Các công cụ này đều có thể download tại website chính thức của Windows Azure Ứng dụng Windows Azure sau khi chạy thành công trên môi trường Development Fabric có thể triển khai lên môi trường điện toán đám mây Windows Azure thực. Trước khi đưa ứng dụng lên Windows Azure, bạn cần đóng gói ứng dụng bằng tính năng Publish trong Visual Studio, ứng dụng sẽ được đóng gói thành 2 phần: phần mã nguồn và phần cấu hình (configuration). Microsoft cho phép triển khai các dịch vụ Windows Azure, SQL Azure và App Fabric thông qua portal Các bước triển khai ứng dụng Windows Azure: Đăng nhập Windows Azure Portal với tài khoản Windows LiveID Thiết lập một Hosted Services mới để host ứng dụng của bạn, tên định danh hosted services này sẽ được sử dụng trong domain của ứng dụng khi đưa vào hoạt động. Thiết lập Storage Services nếu ứng dụng có sử dụng storage, sau khi thiết lập Storage Services, bạn sẽ có các end-points đến các dịch vụ Table, Blob, Queue Storage và khóa Primary Key định danh dịch vụ. Upload file đóng gói mã nguồn và file cấu hình ứng dụng lên Hosted Services đã tạo Cấu hình ứng dụng: cấu hình số thể hiện của ứng dụng, Azure Fabric sẽ tạo ra số VM tương ứng với số thể hiện bạn yêu cầu. Nếu ứng dụng sử dụng đến Storage Services, bạn cần chỉ định Primary Key của Storage Services Chạy thử ứng dụng trong môi trường Staging. Sau khi ứng dụng chạy thành công trong môi trường Staging có thể đưa ứng dụng vào chạy thực trong môi trường Production, lúc này ứng dụng của bạn sẽ có domain dạng .cloudapp.net Mức giá hiện tại của các dịch vụ: Tính toán (Compute): Với mỗi một instance, có 4 lựa chọn cho sức mạnh tính toán của VM: Small, Medium, Large, Extra Large Compute Instance Size CPU Memory Instance Storage I/O Performance Small 1.6 GHz 1.75 GB 225 GB Moderate Medium 2 x 1.6 GHz 3.5 GB 490 GB High Large 4 x 1.6 GHz 7 GB 1,000 GB High Extra large 8 x 1.6 GHz 14 GB 2,040 GB High Bảng 2.1: Các mô hình tính toán Windows Azure Mức giá: Small instance (mặc định): $0.12 / giờ Medium instance: $0.24 / giờ Large instance: $0.48 / giờ Extra large instance: $0.96 / giờ Lưu trữ (Storage) = $0.15 / GB / tháng Giao dịch dữ liệu (Storage Transactions) = $0.01 / 10000 giao dịch Truyền dữ liệu = $0.10 in / $0.15 out / GB - ($0.30 in / $0.45 out / GB in Asia)* Phiên bản Web:  Tối đa 1 GB CSDL quan hệ = $9.99 / tháng Phiên bản thương mại:  Tối đa 10 GB CSDL quan hệ = $99.99 / tháng Chuyển dữ liệu = $0.10 in / $0.15 out / GB - ($0.30 in / $0.45 out / GB in Asia)* Access Control Giao dịch Access Control = $1.99/100000 Kết nối qua Service Bus $3.99 / kết nối theo kiểu “pay-as-you-go” $9.95 cho gói 5 kết nối $49.75 cho gói 25 kết nối $199 cho gói 100 kết nối $995 cho gói 500 kết nối Truyền dữ liệu Data transfers = $0.10 in / $0.15 out / GB - ($0.30 in / $0.45 out / GB in Asia)* Nguồn: Microsoft Windows Azure ( Kết chương Chương này cung cấp một cái nhìn tổng quan về các thành phần và công dụng của Windows Azure Platform, có thể tóm tắt lại Windows Azure gồm 3 thành phần chính: + Windows Azure: hệ điều hành đám mây, môi trường thực thi và lưu trữ của các ứng dụng, gồm các thành phần Fabric, Compute, Storage service + SQL Azuze: một Cloud DBMS với SQL Azure Database và “Huron” Data Sync + AppFabric (.NET Services): hỗ trợ cơ sở hạ tầng cloud-based cho các ứng dụng cloud và on-premises, gồm 2 dịch vụ là Access Control và Service Bus. Chương 2 cũng đưa ra bốn mô hình xây dựng ứng dụng trên Windows Azure để tận dụng sức mạnh của nền tảng điện toán đám mây này, đó là các mô hình: Ứng dụng Web có khả năng mở rộng, ứng dụng xử lý song song, ứng dụng Web có khả năng mở rộng và xử lý hậu cảnh, ứng dụng cục bộ (on-premise) hoặc hosted web sử dụng Windows Azure Storage. Nền tảng Windows Azure đang thu hút được nhiều nhà phát triển ứng dụng thiết kế lại các ứng dụng của họ để chạy trên môi trường Windows Azure, trở ngại lớn nhất của Windows Azure lúc này có lẽ nằm ở mức giá, chi phí để duy trì ứng dụng Windows Azure là khá cao và hiện tại phù hợp với những ứng dụng có quy mô lớn, cần tới khả năng mở rộng về cả năng lực xử lý và khả năng lưu trữ. Tuy nhiên Windows Azure vẫn còn tiếp tục phát triển và hướng tới ngày càng đáp ứng được nhiều hơn nhu cầu của các nhà phát triển ứng dụng. CHƯƠNG 3: XÂY DỰNG HỆ THỐNG QUẢN TRỊ NỘI DUNG TRÊN WINDOWS AZURE PLATFORM 3.1. Hệ thống quản trị nội dung (CMS) 3.1.1 Khái niệm hệ thống quản trị nội dung Bạn có một website để lưu các thông tin, từng ngày các thông tin trên đó cần được thay đổi, cập nhật với thời điểm, hấp dẫn hơn, hiệu quả hơn, tuy nhiên việc thay đổi nội dung, hình thức trang web là khá phức tạp và không thuận tiện. Và mặc dù bạn có nhiều công cụ hỗ trợ cho việc thiết kế, cập nhật nội dung, khi nội dung trang web ngày một lớn lên, việc quản lý và cập nhật sẽ mất rất nhiều công sức và thời gian. Hơn nữa, mỗi khi thay đổi nội dung trang web, bạn không thể kiểm soát, theo dõi sự thay đổi thông tin trên trang web, những thông tin cũ sẽ mất đi. Một hệ quản trị nội dung sẽ giúp bạn đơn giản hóa các công việc đó. Một cách đơn giản, hãy tưởng tượng một tờ báo điện tử, phóng viên sẽ tạo một bài báo và được hệ thống quản lý. Bài báo này sẽ được chuyển tới người biên tập để chỉnh sữa, thay đổi ( tuy nhiên phiên bản gốc vẫn được bảo lưu). Có thể có nhiều biên tập viên tham gia vào thay đổi bài viết này. Tất cả các thay đổi đều được ghi nhận và bảo lưu. Sau đó, bài viết này sẽ được chuyển tới tổng biên tập, ông này duyệt và ra lệnh xuất lên web, bài báo này sẽ tự động xuất hiện trên web và tự động mất đi sau một thời gian định trước. Điều quan trọng là người biên tập này không cần phải biết ngôn ngữ HTML để có thể đưa bài báo đó lên web, hệ thống sẽ tự động trình bày và để bài báo đó vào đúng mục thích hợp. Wikipedia định nghĩa: Một CMS hay hệ thống quản lý nội dung là phần mềm để tổ chức và tạo môi trường cộng tác thuận lợi nhằm mục đích xây dựng một hệ thống tài liệu và các loại nội dung khác một cách thống nhất. Trong thực tế có nhiều loại CMS tùy theo loại nội dung mà nó quản lý, phổ biến nhất là các Web CMS nhằm quản lý nội dung trên website. [13] Đối tượng chính được nhắc đến ở đây là nội dung (Content), nội dung trên một website được coi là những chất liệu làm nên trang web đó, có thể chia nội dung thành 2 dạng [7]: Các thông tin (văn bản và hình ảnh, video, files) có thể hiển thị hoặc lưu trữ trên hệ thống Các ứng dụng, phần mềm chạy trên web server và thực hiện chức năng hiển thị thông tin Nội dung ở một website là tài sản có giá trị. Nội dung phải được cập nhật thường xuyên để cho khách thăm quan quay trở lại. Một hệ thống quản lý nội dung sẽ cho phép bạn tập trung vào việc tạo ra nội dung có chất lượng trong khi tự động hoá một số công việc vận hành. Bạn có thể giảm chi phí vận hành, tăng mức độ thường xuyên của việc cập nhật nội dung, và tăng cường chất lượng và số lượng của nội dung được giới thiệu trên Website của bạn. 3.1.2 Một số đặc tính và yêu cầu tiêu biểu của CMS Cung cấp giao diện chuẩn để tạo, sửa, duyệt và triển khai nội dung, tách biệt với phần hiển thị nội dung. Khả năng lưu trữ và quản lý dữ liệu (files, images, video) Quản lý phiên bản, theo dõi và phục hồi bản cũ. Quy trình nghiệp vụ chuẩn để đưa thông tin lên hệ thống (workflow) Khả năng sinh các trang nội dung động (dynamic pages generate) Khả năng cá nhân hóa Quản lý thông tin, quyền hạn người dùng (users) Theo dõi, phân tích, báo cáo hoạt động của website 3.1.3 Lợi ích của CMS Khả năng điều khiển và tính nhất quán: Tất cả thông tin đưa lên hệ thống đều phải tuân theo một quy trình nhất định và được thể hiện theo chuẩn chung. Cho phép cập nhật thông tin nhanh chóng, dễ dàng từ bất cứ đâu: Các thông tin mới có thể được đưa lên hệ thống từ bất kỳ đâu thông qua Internet, với giao diện thân thiện, người quản trị hoặc nhân viên có thể truy cập hệ thống, đăng nhập, đưa thông tin, chỉnh sửa thông tin bằng trình duyệt. Không cần kiến thức chuyên sâu về HTML hay ngôn ngữ lập trình để cập nhật thông tin website Phục vụ nhiều người sử dụng cùng lúc: với kiến trúc client-server, hệ thống CMS cho phép nhiều người cùng truy cập hệ thống, với các quản trị viên, mỗi người có thể độc lập thực hiện công việc của mình tùy theo quyền hạn. Chẳng hạn có thể 1 user đang đưa thông tin mới, 1 user khác có thể biên tập nội dung và 1 người khác đang xem các nội dung đã triển khai. Tăng cường tính cộng tác: Với khả năng quản lý phiên bản và quy trình công việc (workflow), hệ thống CMS cho phép nhiều người có thể làm việc với một nội dung cùng lúc. Chẳng hạn một người có thể tập trung vào nội dung bài viết, một người chuyên về hình ảnh, một người lo phần thể hiện bài viết. Khả năng sử dụng lại các thông tin: Các thông tin đã cũ hoặc không còn phù hợp có thể đưa vào trạng thái “lưu trữ” (archive) - tuy nhiên các thành phần nội dung của nó vẫn có thể dùng lại, việc lưu trữ lại các thông tin cũ (thay vì xóa đi) cũng giúp các quản trị theo dõi hệ thống tốt hơn. Hấp dẫn người đọc: một hệ thống CMS có thể thu hút người xem nhở khả năng cập nhật thông tin nhanh chóng, dễ dàng theo dõi các thông tin mới. Lưu trữ thông tin số lượng lớn: Toàn bộ nội dung được lưu trữ trong các hệ quản trị cơ sở dữ liệu, do đó hệ thống có khả năng lưu trữ rất lớn. 3.2. Mô hình CMS sử dụng Windows Azure Platform 3.2.1. Các yêu cầu cơ bản Phần này sẽ mô tả các yêu cầu cơ bản đặt ra với hệ thống CMS xây dựng trong đồ án. Khả năng quản lý nhóm người dùng với quyền hạn cụ thể (viết bài, sửa bài, duyệt bài, đăng bài), người dùng ở nhóm cao hơn có quyền thực thi các tác vụ của nhóm thấp hơn Cung cấp giao diện đồ họa chuẩn cho các công việc: viết bài, sửa bài, phê duyệt, đăng bài. Khả năng quản lý phiên bản của bài viết, có thể khôi phục lại phiên bản cũ Khả năng chỉnh sửa, xóa bài viết sau khi đã được đăng lên. Khả năng tìm kiếm bài viết Hiển thị bài viết theo các nhóm 3.2.2 Biểu đồ các trường hợp sử dụng (Use Case) Tác động vào hệ thống có 5 nhóm tác nhân, tương ứng với 5 Roles: Author (viết bài), Editor (sửa bài), Approver (phê duyệt), Deployer (đăng bài) và Administrator (quản trị). Người dùng thuộc nhóm Administrator có quyền thực hiện tất cả các chức năng. Trường hợp sử dụng tổng quan: Hình 3.1: Các trường hợp sử dụng tổng quan Trong trường hợp tổng quan, quản trị viên có thể thực hiện các chức năng: Viết bài, Biên tập, Phê duyệt, Triển khai, Quản lý tài khoản. Ở mỗi chức năng, người sử dụng ở các vai trò khác nhau có thể đảm nhận. Các trường hợp sử dụng cụ thể: Viết bài Hình 3.2: Use case Viết bài Biên tập Hình 3.3: Use case Biên tập Người dùng thuộc nhóm Editor có thể thực hiện các chức năng: Xem các bài viết được Author trình lên Chỉnh sửa bài viết được Author trình lên, có thể lưu phiên bản mới Trả lại bài viết cho Author để chỉnh sửa Từ chối biên tập, Editor khác có thể dành quyền biên tập Submit bài viết sau khi biên tập lên để phê duyệt Sau khi submit bài viết lên cho Approver để phê duyệt, Editor không thể thay đổi nội dung bài viết, nếu muốn, phải được Approver trả lại. Phê duyệt Hình 3.4: Use case Phê duyệt Người dùng thuộc nhóm Approver có thể: Xem danh sách và nội dung các bài viết đã được biên tập Trả lại bài viết để biên tập lại Phê duyệt bài viết Triển khai Hình 3.5: Use case Triển khai Người dùng thuộc nhóm Deployer có thể: Xem danh sách và nội dung các bài viết đã qua phê duyệt Trả lại bài viết Triển khai bài viết vào một nhóm bài viết Xem danh sách các bài viết đã triển khai Loại bỏ 1 bài viết đã triển khai, bài viết đó sẽ được đưa về trạng thái lưu trữ để có thể biên tập hoặc xóa bỏ. Lựa chọn cấp độ cho một bài viết đã triển khai Quản lý tài khoản Hình 3.6: Use case Quản lý tài khoản Chức năng quản lý tài khoản cho phép các quản trị viên xem và cập nhật thông tin của các tài khoản, tạo tài khoản người dùng mới hoặc xóa tài khoản. 3.2.3 Mô hình CSDL Bảng Account: Lưu thông tin về các tài khoản của hệ thống STT Tên trường Kiểu dữ liệu Mô tả 1 AccountID INT Khóa chính, mã tài khoản 2 UserName STRING Tên tài khoản 3 Password STRING Mật khẩu đăng nhập 4 Email STRING Địa chỉ email 5 ModifiedDate DATETIME Ngày thay đổi thông tin cuối cùng 6 CreationDate DATETIME Ngày tạo tài khoản Bảng 3.1: Thiết kế bảng Account Bảng AccountProperty: STT Tên trường Kiểu dữ liệu Mô tả 1 AccountID INT Khóa chính, mã tài khoản 2 Property STRING Tên thuộc tính 3 Value STRING Giá trị thuộc tính 4 ModifiedDate DATETIME Ngày thay đổi thông tin cuối cùng 5 CreationDate DATETIME Ngày tạo thuộc tính Bảng 3.2: Thiết kế bảng AccountProperty Bảng Content: Bảng lưu trữ các bài viết trong hệ thống STT Tên trường Kiểu dữ liệu Mô tả 1 ContentID INT Khóa chính, mã bài viết 2 Version INT Khóa chính, phiên bản bài viết 3 Protected BOOLEAN Thuộc tính bảo vệ 4 Headline STRING Tiêu đề bài viết 5 Source STRING Nguồn thông tin 6 Byline INT Tác giả bài viết 7 Teaser STRING Mô tả ngắn gọn bài viết 8 Body STRING Nội dung bài viết 9 TagLine STRING Khẩu hiệu bài viết 10 Status INT Trạng thái bài viết 11 Editor INT Người biên tập 12 Approver INT Người phê duyệt 13 UpdateUserID INT Người cập nhật cuối cùng 14 ModifiedDate DATETIME Thời điểm thay đổi cuối cùng 15 CreationDate DATETIME Thời điểm tạo ra Bảng 3.3: Thiết kế bảng Content Bảng Roles: Bảng lưu các nhóm người dùng, mỗi nhóm sẽ được phân quyền cụ thể, gồm 5 nhóm: Author, Editor, Approver, Deployer, Administrator STT Tên trường Kiểu dữ liệu Mô tả 1 RoleID INT Khóa chính, mã nhóm 2 Role STRING Tên nhóm người dùng Bảng AccountRoles: Mô tả nhóm người dùng cụ thể cho mỗi tài khoản, lưu ý mỗi tài khoản có thể thuộc nhiều nhóm. STT Tên trường Kiểu dữ liệu Mô tả 1 AccountID INT Khóa chính, mã tài khoản 2 Role STRING Khóa chính, nhóm người dùng 3 CreationDate DATETIME Ngày gán Bảng 3.4: Thiết kế bảng AccountRoles Bảng ContentRank: Bảng lưu các cấp độ bài viết – thể hiện tầm quan trọng của bài viết, có 4 cấp độ cho bài viết: Low (Thấp), Average (Trung bình), High (Cao) và Lead (Hàng đầu) STT Tên trường Kiểu dữ liệu Mô tả 1 RankID INT Khóa chính, mã cấp độ 2 Rank STRING Tên cấp độ Bảng 3.5: Thiết kế bảng ContentRank Bảng Domain: Bảng lưu các trang (vùng) thông tin trên trang web, trên các trang thông tin có thể chứa các nhóm bài viết STT Tên trường Kiểu dữ liệu Mô tả 1 DomainID INT Khóa chính, mã trang tin 2 DomainType STRING Kiểu trang thông tin 3 Protected INT Thuộc tính bảo vệ 4 Title STRING Tiêu đề trang 5 Description STRING Mô tả trang 6 ModifiedDate DATETIME Ngày thay đổi thông tin cuối cùng 7 CreationDate DATETIME Ngày tạo trang Bảng 3.6: Thiết kế bảng Domain Bảng Zone: Chứa các nhóm bài viết, các nhóm bài viết này sẽ được thể hiện trên trang tin (Domain), một bài viết có thể được triển khai trên nhiều nhóm bài viết. STT Tên trường Kiểu dữ liệu Mô tả 1 ZoneID INT Khóa chính, mã nhóm tin 2 Protected INT Thuộc tính bảo vệ 3 Title STRING Tiêu đề nhóm tin 4 Description STRING Mô tả nhóm tin 5 DomainID INT Trang tin hiển thị nhóm tin 6 ModifiedDate DATETIME Ngày thay đổi cuối cùng 7 CreationDate DATETIME Ngày tạo nhóm tin Bảng 3.7: Thiết kế bảng Zone Bảng Distribution: phân phối các bài viết tới nhóm bài viết, một bài viết có thể thuộc nhiều nhóm bài viết. STT Tên trường Kiểu dữ liệu Mô tả 1 ContentID INT Khóa chính, mã bài viết 2 Version INT Khóa chính, phiên bản bài viết 3 ZoneID INT Khóa chính, mã nhóm bài viết 4 Ranking INT Cấp độ bài viết 5 ModifiedDate DATETIME Ngày thay đổi thông tin cuối cùng 6 CreationDate DATETIME Ngày tạo phân phối Bảng 3.8: Thiết kế bảng Distribution Lược đồ CSDL Hình 3.7: Lược đồ CSDL 3.3. Xây dựng các thành phần ứng dụng 3.3.1. Mô hình dữ liệu đối tượng sử dụng Table Storage Ở ứng dụng này, ta sẽ sử dụng mô hình dữ liệu Table Storage của Windows Azure để tạo ra cấu trúc bảng dữ liệu (xem chương 2, phần 2.2.1.2 Storage Service), các bảng sẽ được thể hiện thông qua các lớp đối tượng (class) với các trường tương ứng là các thuộc tính của lớp. Cũng tương tự, các hàm (function), thủ tục lưu (stored procedure) sẽ được cài đặt như là các phương thức của lớp. Các lớp này đều thừa kế từ lớp TableServiceEntity định nghĩa trong namespace Microsoft.WindowsAzure.StorageClient. Khi WebRole được khởi tạo, chương trình sẽ dựa trên khai báo của lớp để tạo nên mô hình dữ liệu tương ứng trên Tabl Storage, thao tác này chỉ thực hiện một lần. Ví dụ: // lay the hien doi tuong Storage Account thong qua chuoi ket noi var account = CloudStorageAccount.FromConfigurationSetting("DataConnectionString"); // tao table Accounts tu mo hinh du lieu khai bao trong AccountContext CloudTableClient.CreateTablesFromModel(typeof(AccountContext), account.TableEndpoint.AbsoluteUri, account.Credentials); // khoi tao du lieu cho bang Account ... Sau đây là mô tả các lớp đối tượng và các phương thức tương ứng: Lớp Account: public class Account : Microsoft.WindowsAzure.StorageClient.TableServiceEntity { // primary key: AccountID public int AccountID { get; set; } public string UserName { get; set; } public string Password { get; set; } public string Email { get; set; } public DateTime ModifiedDate { get; set; } public DateTime CreationDate { get; set; } // constructor public AccountContext(string baseAddress, StorageCredentials credentials): base(baseAddress, credentials); public void Insert(string username, string password, string email); // cap nhat thong tin user public void Update(int accountID, string username, string password, string email); // xoa 1 user public void Remove(int accountID); // get Accounts public List GetAccounts(); // tra lai doi tuong Account tu AccountID public Account GetAccountForID(int accountID); public int GetAccountID(string username); // kiem tra co ton tai Account thong qua AccountID public bool Exist(int accountID); // xac thuc tai khoan public bool Authenticated(string username, string password); Lớp AccountProperty public class AccountProperty : Microsoft.WindowsAzure.StorageClient.TableServiceEntity { // primary key: AccountID, Property public int AccountID { get; set; } public string Property { get; set; } public string Value { get; set; } public DateTime ModifiedDate { get; set; } public DateTime CreationDate { get; set; } // tao account property moi public void Insert(int accountID, string property, string value) ; // cap nhat mot account property public void Update(int accountID, string property, string value); // xoa cac account property co cung AccountID = accountID public void Remove(int accountID); // xoa mot account property public void RemoveProperty(int accountID, string property); // lay value cua 1 account property public string GetValue(int accountID, string property); Lớp AccountRole public class AccountRole : Microsoft.WindowsAzure.StorageClient.TableServiceEntity { // primary key: AccountID, Role public int AccountID { get; set; } public string Role { get; set; } public DateTime CreationDate { get; set; } // them moi 1 account role public void Insert(int accountID, string role); // xoa bo account role public void Remove(int accountID); // get all role public List GetAllRole(string role); // get all role cho 1 accID public List GetRolesForID(int accountID); // kiem tra quyen cho 1 user public bool Authorization(ArrayList roles, string username, CloudStorageAccount strAccount); Lớp Content public class Content : Microsoft.WindowsAzure.StorageClient.TableServiceEntity { // primary key: ContentID, Version // foreign key: ByLine --> Account.AccountID // foreign key: UpdateUserID --> Account.AccountID public int ContentID { get; set; } public int Version { get; set; } public int Protected { get; set; } public string Headline { get; set; } public string Source { get; set; } public int Byline { get; set; } public string Teaser { get; set; } public string Body { get; set; } public string TagLine { get; set; } public int Status { get; set; } public int Editor { get; set; } public int Approver { get; set; } public int UpdateUserID { get; set; } public DateTime ModifiedDate { get; set; } public DateTime CreationDate { get; set; } // tao ContentID moi = MAX(ContentID) + 1 public int NextContentID() // them 1 Content moi public void Insert(int contentID, int version, int isProtected, string headline, string source, int byline, string teaser, string body, string tagline, int editor, int approver, int updUserID, int status); // overload public void Insert(string headline, string source, int byline, string teaser, string body, string tagline); // cap nhat thong tin 1 Content public void Update(int contentID, int version, int isProtected, string headline, string source, int byline, string teaser, string body, string tagline, int editor, int approver, int updUserID, int status); // set status bai viet public void SetStatus(int contentID, int version, int status); // set editor public void SetEditor(int contentID, int version, int editor); public void SetApproval(int contentID, int version, int approver); public void SetProtected(int contentID, int version, int isProtected); public List GetHeadlines(); public List GetHeadlinesForAuth(int byLine); public List GetHeadlinesForEdit(int editor); public List GetHeadlinesForApprove(int approver); public List GetContentForID(int cid); public Content GetContentForIDVer(int cid, int ver); public void Remove(int cid, int ver); Lớp ContentRank public class ContentRank : Microsoft.WindowsAzure.StorageClient.TableServiceEntity { // primary key: RankID public int RankID { get; set; } public string Rank { get; set; } public List GetRanks(); public int GetRankID(string rank); Lớp Distribution public class Distribution : Microsoft.WindowsAzure.StorageClient.TableServiceEntity { // primary key: ContentID, Version, ZoneID public int ContentID { get; set; } public int Version { get; set; } public int ZoneID { get; set; } public int Ranking { get; set; } public DateTime ModifiedDate { get; set; } public DateTime CreationDate { get; set; } public void Insert(int contentID, int version, int zoneID, int ranking); public List GetOrdered(int zoneID); public void UpdateRank(int zoneID, int contentID, int version, int ranking); public void Remove(int cid, int ver); Lớp Domain public class Domain : Microsoft.WindowsAzure.StorageClient.TableServiceEntity { // primary key: DomainID public int DomainID { get; set; } public string DomainType { get; set; } public int Protected { get; set; } public string Title { get; set; } public string Description { get; set; } public DateTime ModifiedDate { get; set; } public DateTime Creationdate { get; set; } public List GetAll() public List GetDomainForID(int did) Lớp Role public class Role : Microsoft.WindowsAzure.StorageClient.TableServiceEntity { // primary key: RoleID public int RoleID { get; set; } public string RoleName { get; set; } public List AllRoles() Lớp Zone public class Zone : Microsoft.WindowsAzure.StorageClient.TableServiceEntity { // primary key: ZoneID // foreign key: DomainID --> Domain.DomainID public int ZoneID { get; set; } public int Protected { get; set; } public string Title { get; set; } public string Description { get; set; } public int DomainID { get; set; } public DateTime ModifiedDate { get; set; } public DateTime CreationDate { get; set; } public List GetZonesForDomain(int domainID) public Zone GetZone(int zoneID) public bool isProtected(int zoneID) 3.3.2 Xây dựng các phân hệ Hệ thống bao gồm 5 phân hệ chính: Authoring (Viết bài), Editing (Biên tập), Approving (Phê duyệt), Deploying (Triển khai) và Quản lý tài khoản. Mỗi nhóm người dùng sẽ có thể sử dụng các tính năng của phân hệ với quyền tương ứng. Các phân hệ được thiết kế tương ứng với các trường hợp sử dụng. Phân hệ Authoring Phân hệ Author gồm các form và tính năng: Form tạo bài viết mới với giao diện trực quan Form chỉnh sửa bài viết (trước khi submit) Lưu bài viết theo các phiên bản. Xem danh sách các bài viết của mình Submit bài viết lên nhóm biên tập (editor) Phân hệ Editing Người dùng thuộc nhóm Editor có thể thực hiện các chức năng biên tập trong phân hệ này, bao gồm: Xem danh sách các bài viết được người dùng nhóm Author đưa lên Chỉnh sửa các bài viết Lưu bài viết theo các phiên bản Trả lại bài viết cho tác giả (Author) để chỉnh sửa lịa Từ chối biên tập (Editor khác có thể nhận biên tập) Submit bài viết lên để phê duyệt (approve) Phân hệ Approving Các tính năng trong phân hệ này: Xem danh sách bài viết đã được biên tập Duyệt bài viết lên nhóm Deployer Trả lại bài viết để biên tập lại Phân hệ Deploying Các tính năng trong phân hệ này Xem danh sách bài viết đã được phê duyệt Triển khai bài viết vào một nhóm bài viết (Zone) Xem danh sách bài viết đã được triển khai Đưa 1 bài viết đã được triển khai về trạng thái lưu trữ (archive) Trả lại bài viết để sửa lại Phân hệ quản lý tài khoản: Phân hệ này cho phép Administrator thực hiện các thao tác Xem danh sách tài khoản người dùng Xem thông tin tài khoản người dùng Sửa thông tin tài khoản người dùng Tạo tài khoản mới Xóa tài khoản người dùng Người dùng cũng có thể sử dụng phân hệ này để xem và sửa thông tin cá nhân. Kết chương Như vậy chương này đã đưa ra khái niệm về hệ thống quản trị nội dung cùng với những lợi ích mà nó đem lại, mô tả các yêu cầu cơ bản để xây dựng một hệ thống quản trị nội dung, mô hình hệ quản trị nội dung xây dựng trên môi trường Windows Azure, mô hình các chức năng và dữ liệu. Ở chương tiếp theo, chúng ta sẽ khảo sát kết quả thử nghiệm hệ thống và đánh giá. CHƯƠNG 4: THỬ NGHIỆM VÀ ĐÁNH GIÁ 4.1. Triển khai hệ thống lên Windows Azure Một số hình ảnh của hệ thống và cách sử dụng: Upload ứng dụng lên Hosted Services Hình 4.1: Upload gói mã nguồn (*.cspkg) và file cấu hình (*.cscfg) lên môi trường Staging Deployment của Hosted Service Tạo Storage Services Hình 4.2: Tạo Storage Account, thu được Primary Key Access và Endpoints Cấu hình Hosted Services Hình 4.3: Cấu hình số instances, khai báo Storage Account Key Chạy hệ thống trong môi trường Staging Hình 4.4: Test hệ thống trong môi trường Staging Deploy hệ thống sang môi trường Production Hình 4.5: Deploy hệ thống sang môi trường Production Giao diện bài viết Hình 4.6: Thế hiện nội dung bài viết Giao diện quản trị (Author) Hình 4.7: Phần quản trị: Author xem danh sách bài viết Viết bài Hình 4.8: Author viết bài Biên tập Hình 4.9: Editor biên tập bài viết Phê duyệt Hình 4.10: Phê duyệt bài viết Triển khai bài viết Hình 4.11: Deployer triển khai bài viết Quản lý tài khoản Hình 4.12: Quản lý tài khoản - Danh sách tài khoản Hình 4.13: Quản lý tài khoản – Tạo tài khoản mới 4.2. Đánh giá hệ thống Hệ thống CloudCMS về mặt cơ bản đã đáp ứng được những yêu cầu cho một hệ thống quản trị nội dung, ưu điểm của hệ thống: Giao diện trực quan để thực hiện các công việc: Viết bài, Biên tập, Duyệt bài, Triển khai Tuân thủ chặt chẽ quy trình từ Viết bài cho đến Triển khai Cho phép quản lý bài viết theo phiên bản Khả năng quản lý tài khoản và giới hạn tài khoản người dùng. Sử dụng Windows Azure Storage Service để lưu trữ dữ liệu bài viết, qua đó giảm được chi phí sử dụng SQL Azure và tăng tính linh hoạt cho hệ thống. Tuy nhiên, để có thể triển khai thành một CMS chuyên nghiệp, hiệu quả hệ thống còn một số nhược điểm: Khả năng tùy biến giao diện còn hạn chế Chỉ phù hợp với những trang web quy mô vừa và nhỏ Chi phí tính toán trên Windows Azure còn tương đối cao. Kết chương Như vậy chương này đã giới thiệu quá trình từ triển khai ứng dụng lên môi trường Windows Azure Platform, thử nghiệm quy trình hệ thống với các tính năng Viết bài, Biên tập, Duyệt bài và Triển khai. Hệ thống về cơ bản đã hoạt động ổn định trên môi trường Windows Azure (với tên miền Chương này cũng đưa ra nhận xét, đánh giá về những ưu điểm và nhược điểm của hệ thống. TÀI LIỆU THAM KHẢO Các tài liệu, bài báo khoa học Cloud Computing, A Seminar Report - Maheswaran.M Introduction to Cloud Computing - Sun MicroSystems Architectural Strategies for Cloud Computing - Oracle White Paper Introducing the Windows Azure Platform, v1.2 – Chappell - Microsoft White Paper Introducing Windows Azure - David Chappell - Microsoft White Paper March 09 An Introduction to Windows Azure Platform AppFabric for Developers - Microsoft Real World ASP.NET: Building a Content Management System - Stephen Fraser – Appress 2002 Các trang web IBM Microsoft Windows Azure Homepage Ecomworld www.forrester.com/ www.en.wikipedia.com