Mashup và một số vấn đề liên quan đến widget

11 Chương 2 Mashup và một số vấn đề liên quan đến widget Tóm tắt:  Nội dung chương này cung cấp định nghĩa, sự phân loại, kiến trúc ứng dụng Mashup nhằm làm rõ vai trò của widget được sử dụng khi tổng hợp Mashup. Các vấn đề liên quan đến việc biểu diễn widget, khả năng phối hợp widget cũng được trình bày ở chương này. 2.1 Mashup 2.1.1 Khái niệm về Mashup Mashup là khái niệm ra đời từ trào lưu Web 2.0. Cho đến giờ, định nghĩa về Mashup vẫn còn là vấn đề tranh cãi và hiện tại vẫn chưa có định nghĩa thống nhất chung về Mashup [28]. Theo Wikipedia, Mashup là một ứng dụng Web được tạo ra bằng cách kết hợp dữ liệu từ nhiều nguồn khác nhau. Tuy nhiên, định nghĩa này chưa đầy đủ vì thành phần tham gia kết hợp không chỉ là dữ liệu mà còn là xử lý hay giao diện thể hiện [28]. Giusy Di Lorenzo xem Mashup là một hướng tiếp cận phát triển ứng dụng dựa trên sự tổng hợp dịch vụ đã có sẵn để tạo ra dịch vụ mới [19]. Dịch vụ ở đây có thể là dịch vụ nghiệp vụ, dịch vụ dữ liệu, dịch vụ giao diện (UI Services). Agnes Koschmider đã cung cấp một định nghĩa tổng quát và đầy đủ hơn về Mashup: Mashup là một ứng dụng web được tạo ra bằng cách kết hợp các tài nguyên trong các website khác (third-party Website) để tạo ra tài nguyên mới [28]. Định nghĩa này đã tổng quát hóa các thành phần được dùng để Mashup, một cách cụ thể, các tài nguyên này có thể là nội dung (data), xử lý (application functionality) hoặc giao diện (presentation). Các tài nguyên có thể được cung cấp với nhiều dạng khác nhau (RSS, Atom, HTML, Web API…). 12 Một trong những ứng dụng đầu tiên và kinh điển về Mashup là website www.Housingmaps.com (Hình 2-1). Ứng dụng này được phát triển vào 04/2005 bởi Paul Rademacher, một lập trình viên độc lập và hiện là lập nhân viên của Google. Housingmaps.com kết hợp dữ liệu về nhà ở, căn hộ, phòng cho thuê… từ website rao vặt Craigslist ( và hiển thị trực quan lên Google Map. Hình 2-1: Ứng dụng Mashup đầu tiên: Housingmaps.com Housingmaps.com thể hiện rõ đặc trưng của Web 2.0 là cá nhân hóa thông tin theo nhu cầu sử dụng. Khi phát triển Housingmaps.com, Paul Rademacher đã sử dụng kỹ thuật Crawler để rút trích các thông tin cần thiết trên Craigslist; sau đó tùy biến lại các đoạn mã javascript của Google để thể hiện lên bản đồ (thời điểm Housingmaps.com xây dựng, Google chưa công bố Google Map API [57]). Một số ví dụ khác về Mashup chẳng hạn, một nhà lập trình có thể tạo website chia sẻ ảnh và video của riêng mình khi kết hợp hai dịch vụ YouTube và Flickr, hoặc trộn dữ liệu về tình trạng giao thông với Google Maps để lập bản đồ các điểm thường xuyên tắc đường trong khu vực… Tóm lại, Mashup đã trao cho người dùng cuối khả năng tự xây dựng các ứng dụng tình huống (situational application) giải quyết tức thời và nhanh chóng các yêu cầu nghiệp vụ phát sinh chỉ liên quan đến cá nhân họ (individual & ad-hoc business problem - Volker Hoyer [30]). 13 Volker Hoyer đã trình bày tổng quan các đặc trưng tiêu biểu của ứng dụng Mashup [50], bao gồm:  Thời gian phát triển ứng dụng: Mashup có thể được xây dựng trong một khoảng thời gian rất ngắn: vài ngày, vài giờ, thậm chí vài phút.  Chu kỳ sống: ứng dụng thường chỉ được sử dụng trong một khoảng thời gian ngắn.  Loại ứng dụng: ứng dụng có chức năng đơn giản, phục vụ cho một số trường hợp sử dụng hoặc tình huống cụ thể (situational application).  Yêu cầu chức năng: các yêu cầu thường thay đổi nhanh chóng và liên tục, ứng dụng có thể dễ dàng điều chỉnh đáp ứng sự thay đổi này .  Yêu cầu phi chức năng: các yêu cầu về khả năng chịu tải (scalability), bảo trì (maintainability) rất ít được đặt nặng.  Quy trình phát triển: không dựa trên một quy trình hay một phương pháp luận phát triển cụ thể nào. Tất cả chủ yếu dựa trên các giải pháp, công cụ được cung cấp sẵn để tạo ra các ứng dụng vừa đủ sử dụng (good enough application) và đáp ứng ngay nhu cầu tình huống của người dùng.  Quản lý ứng dụng: các ứng dụng được phát triển riêng rẽ, rời rạc, chủ yếu dựa vào sở thích cá nhân người sử dụng và ít chịu sự quản lý.  Mức độ tích hợp: sử dụng các giải pháp tích hợp các thành phần thể hiện hay giao diện người dùng (presentation integration).  Người phát triển ứng dụng: chủ yếu là người dùng cuối với sự hỗ trợ đầy đủ của các công cụ.  Người dùng mục tiêu của ứng dụng: chủ yếu là cá nhân đơn lẻ hoặc nhóm người dùng nhỏ. Tính đến ngày 1/5/2010, www.programmableWeb.com là website cung cấp Web API, Mashup lớn nhất hiện nay, với khoảng 4783 ứng dụng Mashup (xem thống kê trong Hình 2-2). Trung bình mỗi ngày có thêm khoảng 2 đến 3 ứng dụng Web Mashup mới được tổng hợp. Kết quả thống kê từ Hình 2-2 cho thấy loại ứng dụng Mashup phổ biến nhất hiện nay là bản đồ (35%), tiếp theo là các ứng dụng Mashup ảnh (10%), video (9%) .. 14 Hình 2-2: Bảng thống kê các dạng ứng dụng Mashup dựa trên mức độ phổ biến (ProgrammableWeb.com) 2.1.2 Phân loại Mashup Agnes Koschmider đã cung cấp các tiêu chí phân loại Mashup dựa trên 4 khía cạnh [28]:  WHAT: loại thông tin tổng hợp Mashup, bao gồm Mashup trên dữ liệu (Data Mashup), Mashup thành phần thể hiện (Presentation Mashup), Mashup chức năng xử lý (Functionality Mashup).  WHERE: phân hệ (client, server) mà tại đó việc tích hợp được thực hiện.  HOW: các thức xây dựng Mashup.  FOR WHOM: Mashup tạo ra phục vụ cho đối tượng người dùng nào. Chi tiết về mỗi loại Mashup sẽ được trình bày trong phụ lục A. 2.1.3 Công cụ xây dựng Mashup Hiện nay, đã có khá nhiều công cụ hỗ trợ tạo Mashup (Mashup Framework), chẳng hạn như Microsoft Popfly dành cho người không chuyên dựa trên nền tảng Silverlight, người dùng thông thường có thể tạo lập các dịch vụ online tương đối phức tạp nhưng lại không cần am hiểu về HTML, XTML, CSS, AJAX... Tất cả những gì người dùng phải làm là kéo - thả nội dung từ nguồn này sang nguồn kia. Yahoo Pipes là một trong những công cụ mashup đầu tiên trên thế giới. Do đó, nó hướng đến những người có đôi chút kiến thức về kỹ thuật. 15 Agnes Koschmider đã thống kê một số công cụ Mashup và phân loại dựa trên chức năng mà mỗi công cụ cung cấp [28]. Các công cụ được ông chọn để khảo sát, phân tích chủ yếu là các công cụ tiêu biểu được phát triển bởi các nhà phát triển lớn; kết quả khảo sát được trình bày trong Bảng 2-1. P re se nt at io n D at a F un ct io na lit y E xt ra ct io n F lo w C on su m er E nt er pr is e Apatar x x x Data Mashup x x x x Dapper x x x DERI Pipes x x x Grazr x x x IBM Infosphere Mashup Hub x x x Intel Mash Maker x x x JackBe Presto x x x x Microsoft Popfly x x x x OpenKapow x x x x Procession x x x x RssBus x x x x Serena Mashup Suite x x x x TIBCO PageBus x x x Yahoo Pipes x x x Bảng 2-1: Bảng thống kê và phân loại Mashup Framework dựa theo chức năng Kết quả khảo sát từ Bảng 2-1 cũng cho thấy hiện nay các công cụ hỗ trợ phát triển Mashup với giao diện thể hiện đối với người dùng cuối (Presentation Mashup) vẫn còn hạn chế. Phần lớn công cụ tập trung hỗ trợ các kỹ thuật thu thập và tổng hợp dữ liệu phục vụ Mashup (Data Mashup). 16 2.1.4 Kiến trúc công cụ xây dựng Mashup Widget Assembly Layer Query Widget Pie Chart Widget Map Widget Web Clipping Widget Event Bus Widget Layer Query Widget Pie Chart Widget Map Widget Web Clipping Widget Data Mashup Layer Data Mashup Source Access Layer SOAP Adaptor Semi-structured HTML Web Page Adaptor Other Data Source Adaptors (REST, DB, files …) Web Clipping Adaptor SOAP Services Web Application Web Application Hình 2-3: Mô hình Kiến trúc Mashup Framework [5] Trong mô hình biểu diễn kiến trúc trong Hình 2-3, Javier López đã phân chia các thành phần trong hệ thống dựa trên vai trò hoạt động, có 4 thành phần chính:  Source Access Layer: là tầng truy cập dữ liệu dựa trên các API mà Web Resources cung cấp. Ví dụ : Web Service, HTML...  Data Mashup Layer: dữ liệu do tầng Source Access Layer cung cấp có thể không theo định dạng phù hợp cho việc sử dụng. Do đó, nó có thể được xử lý tiếp qua một quy trình biến đổi nhằm tạo ra dữ liệu kết quả với định dạng mong muốn và phù hợp với xử lý của các thành phần khác.  Widget Layer: là tầng cung cấp các Widget có vai trò hiển thị nội dung dữ liệu từ các tầng bên dưới cung cấp.  Widget Assembly Layer: cung cấp giao diện đồ họa cho phép kết hợp (wiring) các widget với nhau để tạo ra một ứng dụng web hoàn chỉnh. 17 Hình 2-4: Hai tiến trình chính khi tổng hợp Mashup: Piping và Wiring [35] Trong Hình 2-4, Volker Hoyer đã trình bày 2 tiến trình chủ yếu khi phát triển ứng dụng Mashup [35], bao gồm:  Piping: là tiến trình xử lý, tổng hợp thông tin và nạp nội dung kết quả lên widget.  Wiring: là quá trình phối hợp hoạt động, truyền dữ liệu giữa các widget để tạo giao diện ứng dụng theo nhu cầu. 2.1.5 Các bài toán cần nghiên cứu khi phát triển ứng dụng Mashup Từ mô hình các thành phần trong kiến trúc Mashup Framework (Hình 2-3), để xây dựng ứng dụng Mashup, ta cần giải quyết các vấn đề được trình bày trong phần dưới đây. 2.1.5.1 Rút trích thông tin trên Web (Web Data Extraction) Đặc trưng của Mashup là thông tin có thể lấy từ nhiều nguồn khác nhau với nhiều định dạng khác nhau, chẳng hạn Web Feed (đối với các thông tin được cập nhật thường xuyên: Blog, tin tức), dữ liệu dạng bảng (tập tin CSV – Comma Seperated Value, bảng tính – Spreadsheet), dữ liệu XHTML, hoặc nội dung đa phương tiện (ảnh, video…). 18 Để đơn giản hóa việc truy cập dữ liệu, nhà phát triển website sẽ cung cấp thông tin thông qua Web API (Giusy Di Lorenzo [29]). Web API giúp cho quá trình truy cập và sử dụng dữ liệu thuận tiện, che giấu sự phức tạp trong cách thức tổ chức lưu trữ dữ liệu bên dưới. Web API thường cung cấp dữ liệu thông qua các giao thức chuẩn: REST/SOAP Web Services, Ajax (Asynchronous Javascript + XML), XML RPC (Remote Procedure Call). Tuy nhiên, thách thức lớn hiện nay là phần lớn nội dung đều được lấy dưới dạng Web Feeds (RSS, Atom), phần lớn các ứng dụng chưa hỗ trợ Web API cung cấp thông tin. Do đó, một số kỹ thuật đã được đề xuất để khắc phục: web page clipping (I-know [8], Internet Scrapbook [9], C3W [10]), rút trích dữ liệu dựa theo cấu trúc HTML (typed data - Marmite [11], Mash Maker [7]), phát sinh web services để rút trích nội dung từ các web application chưa hỗ trợ API: Hao Han [2], Pollock [12], H2W [13], Kapow Web Data Services (www.strikeiron.com). Các kỹ thuật này còn được gọi là Mashup Enabler. Hình 2-5: Vai trò của Mashup Enabler trong các hệ thống Mashup 1 1 Kapowtech JavaOne 2007 ( 19 Mashup Enabler có vai trò đóng gói (wrapping) dữ liệu từ các nguồn bên ngoài (HTML, Web Service, ...) và cung cấp cho thành phần thể hiện (Widget) dưới dạng microformat (RSS, ATOM) hay Web Service. Chúng tôi đã khảo sát và phân loại các nguồn dữ liệu có thể được dùng để tổng hợp Mashup. Chi tiết về các nguồn dữ liệu kèm theo ví dụ được trình bày trong Bảng 2-2. Nguồn dữ liệu Ví dụ Web Feed RSS Atom Web Service SOAP RESTful WCF … File Text CSV Spreadsheet (Excel) … Relational Database Access MySQL DB2 Oracle … Nested Data XML JSON … Web Clipping HTML Markup (Fragment of Html, CSS, Javascript, ..) Bảng 2-2: Các nguồn dữ liệu được dùng khi tổng hợp Mashup 2.1.5.2 Tích hợp dữ liệu từ nhiều nguồn khác nhau Vấn đề này có thể tận dụng thành tựu từ các hướng tiếp cận trong lĩnh vực tích hợp dữ liệu (Data Integration), một ngành nghiên cứu trưởng thành và phát triển. Giusy Di Lorenzo và các cộng sự đã thực hiện cuộc khảo sát các công cụ Mashup tiêu biểu nhất hiện nay (Damia, Yahoo Pipes, Popfly, Google Mashup Editor, Apatar, Intel Mash Maker …). Trên cơ sở đó, ông đã trình bày, phân tích toàn diện các vấn đề, khía cạnh khác nhau liên quan đến quá trình tích hợp dữ liệu phục vụ Mashup [29]. Chi tiết về các vấn đề liên quan đến quá trình tích hợp dữ liệu được trình bày trong Phụ lục B. Khảo sát cũng cho thấy phần lớn Mashup Framework hiện nay đều kết hợp dữ liệu dựa trên mô hình data-flow (Yahoo! Pipes, Apatar, JackBe Presto, Serena Mashup Suite, IBM Damia[31], SpiderCharlotte [21]...). 20 2.1.5.3 Thể hiện nội dung lên các thành phần thể hiện (widget) Widget là thành phần có vai trò thể hiện dữ liệu tổng hợp được đến người dùng, đồng thời cung cấp một số cơ chế để người dùng tương tác, phối hợp hoạt động giữa các widget (Javier López[5], Rama Gurram[19], Volker Hoyer[35]). Để xây dựng widget, ta có thể dựa vào sự hỗ trợ của các widget Platform đã mô tả trong Bảng 1-1. Ngoài việc cung cấp đặc tả, Platform còn cung cấp hệ thống các API cần thiết (chẳng hạn API hỗ trợ các xử lý bất đồng bộ - Ajax) giúp cho việc phát triển widget thuận lợi và dễ dàng hơn. 2.1.5.4 Biểu diễn sự phối hợp hoạt động, tương tác giữa các widget Dựa trên việc khảo sát các công trình và Framework đề xuất hỗ trợ tổng hợp widget hiện nay: Javier López[5], Jin Yu[14][24], Rama Gurram[19], Rui Guo[22], Sohei Ikeda[25], IBM iWidget [26], Google Gadget[37], OpenAjax widget[38], ta nhận thấy tương tác giữa các widget chủ yếu dựa trên sự kiện (event) với mục tiêu đồng bộ hóa nội dung thể hiện giữa các widget trên toàn giao diện Mashup (Mashup Canvas). Chẳng hạn khi người dùng chọn 1 dòng trong danh sách địa chỉ trên widget A, widget B sẽ hiển thị vị trí được chọn tương ứng lên bản đồ. Một số đề xuất cung cấp đặc tả widget kèm theo biểu diễn phối hợp bao gồm: Sohei Ikeda[25], Jin Yu[14], IBM iWidget [26]), các đề xuất còn lại chủ yếu cung cấp thư viện hỗ trợ phối hợp (Rui Guo[22], Google Gadget[27], OpenAjax widget [38]). 2.1.5.5 Cơ chế liên lạc trên hệ khách giữa các widget Mashup là kết quả của sự phối hợp giữa nhiều widget với nhau trên Mashup. Quá trình tương tác chủ yếu xảy ra tại trình duyệt, trong đó mỗi widget chịu trách nhiệm thể hiện thông tin từ những nguồn khác nhau. Điều này dẫn đến khả năng một số widget từ những nguồn không đáng tin cậy có thể truy cập các thông tin nhạy cảm hoặc thay đổi nội dung trong widget khác. Kỹ thuật tấn công thường được sử dụng là Frame Phishing. Kỹ thuật này sử dụng mã 21 kịch bản script để thay đổi thuộc tính src của một iframe (mỗi iframe được xem như một cửa sổ trình duyệt) và điều hướng nó đến các website giả mạo (phishing site). Để hạn chế kiểu tấn công này, các trình duyệt sử dụng chính sách bảo mật Same Origin Policy (SOP): nội dung tài liệu (DOM document) hoặc mã script trong nguồn này không thể truy cập nội dung tài liệu hoặc mã script từ nguồn khác [34]. SOP sẽ hạn chế khả năng liên lạc giữa các widget do mỗi widget đều thể hiện nội dung từ các nguồn khác nhau. Hiện nay, nhiều kỹ thuật đã được đề xuất hỗ trợ vượt qua hạn chế của SOP, chẳng hạn sử dụng thẻ Module [45], Subspace[46], URL fragment identifier [27][47], MashupOS [43][44], OpenAjax widget [38]… 2.2 Các thành phần trong đặc tả widget và sự phối hợp widget 2.2.1 Công nghệ phát triển widget Widget là thành phần thể hiện giao diện, do đó nó có thể được xây dựng dựa trên các chuẩn Web: HTML, CSS (mô tả giao diện) và Javascript (xử lý), hoặc các công nghệ Plug-in trình duyệt: Flash, Silverlight, JavaFX… Nếu được xây dựng dựa trên các chuẩn Web, widget có thể tận dụng được sức mạnh, khả năng và sự đa dạng của rất nhiều thư viện Javascript có sẵn hiện nay (Google Map, Yahoo UI, Dojo, JQuery, Prototype, jMaki…). Việc mở rộng widget để bổ sung khả năng tương tác như các ứng dụng RIA (Rich Internet Application) cũng không gặp nhiều khó khăn vì đa số các công nghệ hiện nay đều cung cấp các kỹ thuật chuyên biệt để tương tác với Javascript. Chẳng hạn Silverlight cung cấp HTML Bridge, Flash cung cấp ExternalInterface API… để tương tác với các thành phần trong nội dung trình duyệt. 22 2.2.2 Mô hình biểu diễn widget Dựa trên khảo sát mô hình đặc tả widget trong các widget Platform hiện nay (Bảng 1-1), mô hình biểu diễn widget (widget Model) bao gồm các thành phần: thông tin mô tả widget, tham số cấu hình, ngôn ngữ thể hiện, giao thức truy cập dữ liệu riêng tư, mã kịch bản xử lý trên hệ khác, kiểu định dạng thể hiện, nội dung widget. Sau đây, chúng tôi sẽ trình bày chi tiết ý nghĩa, công dụng của các thành phần này. 2.2.2.1 Thông tin mô tả widget Thành phần thông tin mô tả widget (widget Description) khai báo các mô tả chung về widget, chẳng hạn: widget Name, unique ID, Author, Author Email, Description, Version, Key, Tags, Screenshot, Thumbnail.. Thông tin này được sử dụng bởi các công cụ Mashup Framework phục vụ cho việc quản lý, phân loại widget, hoặc cung cấp cho người dùng widget các mô tả, chỉ dẫn trong quá trình sử dụng. 2.2.2.2 Tham số cấu hình Thành phần tham số cấu hình (User Preference hay User Configuration Parameter) định nghĩa các tham số cấu hình hoạt động của widget. Các tham số này thường được cung cấp cho người dùng, được lưu trữ và nạp lại qua mỗi lần sử dụng. Tùy theo công dụng, mỗi dạng widget sẽ cung cấp các tham số cấu hình khác nhau.  Ví dụ: widget hỗ trợ đọc Web Feed có tham số là Feed URL xác định địa chỉ RSS hoặc Atom cần truy cập. widget thể hiện dữ liệu có hỗ trợ cơ chế phân trang có 2 tham số cấu hình là Feed URL, Page Size xác định địa chỉ RSS và số phần tử hiển thị trên mỗi trang. Đa số các nhà cung cấp widget (widget Platform) đều tự đưa ra đặc tả tham số cấu hình của riêng nó (Netvibes, Google Gadget, Springwidget, Yourminis, IBM iWidget, W3C…) do HTML không cung cấp các thẻ mô tả thành phần này. 23  Ví dụ: widget hiển thị nội dung Web Feed theo đặc tả Netvibes có tham số cấu hình được mô tả như sau: <preference name=“url” type=“text” label=“URL” defaultValue=> <preference name=“limit” type=“range” label=“Number of items to display” defaultValue=“10” step=“1” min=“1” max=“25”/> Giao diện kết quả từ biểu diễn trên được minh họa trong Hình 2-6. Trong đặc tả này, mỗi thẻ preference định nghĩa một tham số và tùy thuộc vào giá trị thuộc tính type sẽ kết xuất giao diện nhập liệu tương ứng. Danh sách các kiểu dữ liệu mà tham số cấu hình sử dụng theo đặc tả Netvibes được trình bày trong Bảng 2-3. Hình 2-6: Giao diện User Preferences kết quả với đặc tả trong ví dụ trên (Nguồn: Netvibes.com) Giá trị thuộc tính type Mô tả text Kết xuất là một TextBox Boolean Kết xuất là một CheckBox Hidden Không kết xuất, dùng để truyền các tham số ẩn hoặc khởi tạo giá trị Range Kết xuất là một HTML ListBox, trong đó mỗi phần tử (thẻ ) là một con số. List Kết xuất là một HTML ListBox Password Kết xuất là một TextBox để nhập Password Bảng 2-3: Các kiểu dữ liệu tham số cấu hình được hỗ trợ bởi Netvibes 24 Các nhà cung cấp widget khác chẳng hạn Google, cũng cung cấp đặc tả biểu diễn thành phần tham số cấu hình hoạt động. Tuy nhiên, đa số đều mô tả tham số dựa trên kiểu dữ liệu cơ sở (chuỗi, số, kiểu luận lý…) và khi sử dụng sẽ nhờ đến Framework Engine chuyển đổi thành giao diện đồ họa cung cấp cho người dùng. 2.2.2.3 Ngôn ngữ thể hiện Một số widget Platform bổ sung một số biểu diễn cho phép tạo widget đa ngôn ngữ: Google Gadget1, Yahoo widget, W3C 2, OpenAjax widget… Cơ chế thực hiện đa ngôn ngữ của Google Gadget được thực hiện như sau: Các chuỗi nội dung cần đa ngôn ngữ trong widget sẽ được phân tách khỏi nội dung và khai báo trong các tập tin _.xml.  Ví dụ: Nội dung tập tin khai báo các chuỗi thể hiện tiếng Anh được mô tả như sau: Hello World. Color Red Green Blue Gray Nội dung tập tin khai báo các chuỗi thể hiện tiếng Tây Ban Nha: Hola Mundo. Color Rojo Verde Azul Gris Mỗi chuỗi trong các tập tin được tạo từ 2 thành phần: khóa định danh cho chuỗi (thuộc tính name) được dùng chung trong nhiều tập tin ngôn ngữ và chuỗi đã được 1 2 25 phiên dịch theo địa phương. Sau khi tạo xong các tập