Trong chu kỳ sống của một ứng dụng Ajax, server có 2 vai trò chính và nó khá tách biệt nhau. Đầu tiên, nó phải chuyển ứng dụng tới trình duyệt, Vì vậy chúng ta giả thiết rằng việc chuyển nội dung ban đầu là số liệu thống kê rõ ràng, ta viết ứng dụng nh− là một chuỗi các file .html;css; và .js. Trong thực tế có rất nhiều điều cần phải nói tới vấn đề này.
Vai trò thứ 2 của server là nói chuyện với client, điền đầy các hàng đợi và cung cấp dữ liệu theo yêu cầu. Do HTTP chỉ là cơ cấu truyền có sẵn, ta sẽ giới hạn ở tr−ờng hợp client bắt đầu một đoạn hội thoại. Server chỉ có chức năng trả lời. Trong phần tr−ớc ta đã nói đến sự cần thiết cho một ứng dụng Ajax để duy trì một mô hình cả ở 2 phía client và server (cho những truy cập tới tài nguyên, ví dụ nh− là cơ sở dữ liệu). Việc duy trì các mô hình đồng bộ với thể hiện khác là một thách thức lớn, và vì thế client không thể tự mình giải quyết đ−ợc. Ta sẽ xem xét cách thức viết dữ liệu cho server trong phần sau, mô tả giải pháp để giải quyết vấn đề này dựa trên một trong những mô hình mà ta đã đề cập trong phần tr−ớc. Ta có thể chuyển ứng dụng client và nói chuyện với client theo nhiều cách khác nhau.
II. M∙ ch−ơng trình phía server
Trong một ứng dụng web hội thoại , phía server có xu h−ớng phức tạp hoá, điều khiển và giám sát hoạt động ng−ời dùng thông qua ứng dụng và duy trì trạng thái hội thoại. ứng dụng đ−ợc thiết kế cho một ngôn ngữ riêng và tập các hội thoại sẽ quyết định xem nó có thể làm gì và không thể làm gì. Các ngôn ngữ có thể bị bó gọn trong các kiến trúc cụ thể nào đó, hay các hệ thống vận hành hoặc các phần cứng. Chọn lựa môi tr−ờng lập trình là một vấn đề rất quan trọng.
2.1 Các ngôn ngữ ứng dụng thông dụng
Ch−ơng trình phía server đ−ợc quyết định bởi ngôn ngữ điều khiển. Hiện nay các ngôn ngữ thông dụng nhất là PHP, Java và ASP với ASP.NET và Ruby. Ajax chủ yếu là kỹ thuật phía client và có thể t−ơng thích với bất cứ ngôn ngữ nào kể trên. Trong một chừng mực nào đó, một số cách làm việc với
Ajax là rất quan trọng khi xem xét ngôn ngữ phía server, giúp cho việc port các ứng dụng Ajax từ một server sang một server khác đ−ợc dễ dàng.
Với Ajax, các web framework là quan trọng hơn so với ngôn ngữ ứng dụng. Các web framework với các giả thiết về cách thức ứng dụng đ−ợc xây dựng và nơi các đáp ứng khoá. Hầu hết các framework đều đ−ợc thiết kế để xây dựng các ứng dụng web truyền thống, và các giả thiết về chu trình của chúng là khá khác biệt so với những gì có ở một ứng dụng Ajax, có thể là vấn đề ở các vị trí. Sau đây chúng ta sẽ xem xét các nguyên tắc cơ bản của các kiến trúc web để làm cơ sở cho những thảo luận sau này.
2.2. Các kiến trúc N-tier
Khái niệm cốt lõi trong các ứng dụng phân tán đó là những gì đ−ợc gọi là tier. Một tier th−ờng thể hiện một tập các đáp ứng cho một ứng dụng, tuy nhiên nó cũng mô tả một hệ thống con mà có thể đ−ợc loại bỏ trong một tiến trình hoặc một loại náy cụ thể. Cần phân biệt giữa các vai trò của MVC, Model, View và các Controller không phải là các tier bởi vời chúng nằm trong cùng một tiến trình.
Các hệ thống sơ khai bao gồm một tier client và một tier server. Tier của client là một ch−ơng trình desktop sử dụng th− viện socket của một mạng để kết nối tới server. Tier của server là một server cơ sở dữ liệu. T−ơng tự nh− vậy các hệ thống web sơ khai bao gồm một trình duyệt giao tiếp với một server web, một hệ thống đơn trên mạng để gửi các file từ hệ thống file.
Do các ứng dụng web ngày càng phức tạp và bắt đầu yêu cầu truy cập cơ sở dữ liệu, nên mô hình 2-tier của client/server đ−ợc ứng dụng cho web server tạo thêm một mô hình tier thứ 3, với nhiệm vụ truyền thông giữa trình duyệt web client và cơ sở dữ liệu.
Các ứng dụng web hiện đại nhìn chung có 2 tier cơ bản. Tier công việc mô hình hoá miền công việc, và nói chuyện trực tiếp với cơ sở dữ liệu. Tier
thể hiện lấy dữ liệu từ tier công việc và thể hiện nó cho ng−ời dùng. Trình duyệt web hoạt động giống nh− là một client trong thiết lập của nó.
Việc đ−a Ajax vào có thể đ−ợc xem nh− là sự phát triển của một tier client mới, chia tách tier thể hiện truyền thống chịu trách nhiệm luồng công việc và quản lý phiên giữa web server là client.
Hình2.13: Di chuyển phản hồi của tier thể hiện từ server tới trình duyệt
Vai trò của tier thể hiện phía server có thể đ−ợc giảm nhiều và việc điều khiển luồng công việc đ−ợc chuyển giao cho một client mới, đ−ợc viết trong JavaScript và đ−ợc đặt trên trình duyệt.
Tier mới trong ứng dụng của chúng ta mang lại các khả năng mới nh− đã nói, đồng thời mang đến những phức tạp hơn. Vì vậy ta cần phải quản lý nó.
2.3 Duy trì các mô hình phía client và server.
Trong một ứng dụng Ajax, ta vẫn cần phải mô hình hoá công việc trên server, liên quan chặt chẽ tới cơ sở dữ liệu và các tài nguyên một cách tập trung. Mặc dù vậy, để tạo ra cho mã client khả năng hiệu quả và thông minh, chúng ta muốn duy trì ít nhất một mô hình partial trong trình duyệt web. Từ đó làm nảy sinh vấn đề duy trì 2 mô hình một cách đồng bộ với một mô hình khác.
Việc thêm vào một tier luôn tạo ra sự phức tạp cũng nh− những truyền thông ngoài dự kiến. May thay, vấn đề này không phải là vấn đề mới mẻ, và những vấn đề t−ơng tự nh− thế này đã đ−ợc tính đến trong phát triển web
J2EE, ví dụ, có sự chia tách giữa tier công việc và tier thể hiện. Mô hình miền domain dựa trên tier công việc và đ−ợc sắp xếp bởi tier thể hiện, sau đó tạo ra nội dung web và gửi tới trình duyệt. Bằng việc sử dụng đối t−ợng “transfer object” ta đã giải quyết đ−ợc vấn đề này, và điều này là khá giống với các đối t−ợng Java đ−ợc thiết kế để truyền dữ liệu giữa các tier.
Ajax tạo ra cho ta những thách thức mới. Trong J2EE, cả 2 tier đ−ợc viết bằng một ngôn ngữ chung với một cơ chế thủ tục từ xa đ−ợc cung cấp, còn Ajax thì khá khác biệt. Có 2 yêu cầu cơ bản đối với việc truyền thông giữa các tier là việc đọc và viết dữ liệu của server.
III. Bức tranh toàn cảnh: Các thiết kế server thông dụng.
Framework server đ−ợc sử dụng cho tất cả các ứng dụng Ajax.
Hình2.14: Lập trình web khi không có framework.
3.1 Làm việc với các framework dựa trên thành phần
Khi viết một trang HTML cho một ứng dụng web, ng−ời quản lý trang phải có một tập các định nghĩa các thành phần giao diện ng−ời dùng, đ−ợc đặt tên d−ới dạng các thành phần HTML. Tập đặc tính này ko thay đổi trong vòng gần 10 năm, đ−ợc so sánh với các bộ công cụ giao diện đồ hoạ ng−ời dùng hiện đại.
Các Widget cho trang web
Nhằm hạn chế các thao tác thực hiện khi lập trình, Ajax cung cấp các công cụ (toolkit) của các thành phần phía server. Ví dụ với desktop sẽ tạo ra các hình ảnh đồ hoạ… Khi sử dụng các widget, chúng tự động tạo ra đoạn mã HTML và JavaScript mà cung cấp chức năng t−ơng tự nh− trong trình duyệt.
Hình 2.15: Kiến trúc của một web framework dựa vào thành phần
3.2 Làm việc với kiến trúc h−ớng dịch vụ
Loại framework cuối cùng chúng ta xem xét ở đây là kiến trúc h−ớng dịch vụ (SOA- Service – oriented architecture). Một dịch vụ trong một SOA là những thứ có thể loại bỏ từ mạng và sẽ trả về một tài liệu đ−ợc cấu trúc hoá giống nh− một trả lời. Điều cần nhấn mạnh ở đây chính là dữ liệu, không phải là nội dung. Các dịch vụ web là những dịch vụ thông dụng hiện nay và chúng sử dụng XML nh− là dịch vụ lingua franca cũng làm việc tốt với Ajax
Chú ý: Thuật ngữ Dịch vụ Web, th−ờng đ−ợc nhắc tới trong các hệ thống sử dụng SOAP làm ph−ơng tiện trao đổi.
Khám phá các đối t−ợng server của Ajax
Có rất nhiều công cụ SOA và các công cụ dịch vụ web xuất hiện, tạo ra khả năng khám phá các đối t−ợng server cũ viết bằng Java, C# hoặc PHP trực tiếp nh− là một dịch vụ web, với một bản đồ 1-1 giữa các ph−ơng thức đối t−ợng với giao diện dịch vụ web. Các công cụ của Microsoft Visual Studio cũng hỗ trợ các tính năng này, cũng giống nh− Apache Axis đã làm cho Java. Một số l−ợng lớn các toolkit của Ajax nh− là DWR (cho Java) và SAJAX (cho PHP.NET…) tạo ra nhữn khả năng với mã client chỉ định JavaScript.
Những công cụ này có thể rất hữu ích. Chúng cũng có thể không đ−ợc sử dụng nếu nh− không đáp ứng đ−ợc yêu cầu. Chính vì thế để sử dụng đúng các công cụ này, ta sẽ định nghĩa một đối t−ợng server để mô tả từng ng−ời.
Public class Person{
Private String name=null;} Public Person(){
Public String getName(){ Return name;
}
public void setName(String name){ this.name=name;
} } <dwr> <init>
<convert id=”person” converter=”bean” match=”com.person”/>
</init> <allow>
<create creator=”new” javascript=”person”> <para name=”class” value=”com.Person”> </create>
</allow> </dwr>
Hình 2.16: Hệ thống xử lý tất cả các đối t−ợng và hệ thống sử dụng Facade xử lý một số ít các đối t−ợng.
3.3. Trao đổi dữ liệu
Trong phần tr−ớc ta đã xem xét các mô hình kiến trúc lớn mà mô tả cách thức ứng dụng web hoạt động cũng nh− chỉ ra rất nhiều chức năng. Qua sự phân tích trên, ta thấy đ−ợc tầm quan trọng của truyền thông giữa các mô hình client và server. Trong phần này ta sẽ xem xét vấn đề một cách thực tế hơn. Nếu nh− tập trung vào việc trao đổi dữ liệu một chiều, ta có rất nhiều chức năng. Có công cụ này trong tay, ta có thể thực hiện nhiều quyết định hơn về kỹ thuật nào sẽ đ−ợc sử dụng.
Việc chuyển dữ liệu sạch không thực sự liên tục trong ứng dụng web cơ sở, và vì thế ngôn ngữ mô hình ít đ−ợc phát triển trong lĩnh vực này. Ta sẽ cố gắng tránh nó bằng cách tự định nghĩa một vài tr−ờng hợp của riêng chúng ta. Đầu tiên ta giả thiết rằng chúng ta chia t−ơng tác ng−ời dùng thành 4 loại: Chỉ client, content-centric, script-centric và data-centric. T−ơng tác thuần client rất đơn giản, vì thế ta sẽ giải quyết vấn đề này .
3.3.1 T−ơng tác với client
T−ơng tác với client là t−ơng tác trong đó t−ơng tác ng−ời sử dụng đ−ợc sử lý bằng một kịch bản mà đã đ−ợc load sẵn trong trình duyệt. Với mô hình này, ta không cần tài nguyên của web server_ cần cho việc load và trách nhiệm của server. Với những t−ơng tác nh− vậy phù hợp với những tính toán trivial ví dụ nh− thêm vào thuế buôn bán hoặc vé tầu theo yêu cầu của khách hàng. Để hoạt động hiệu quả nhất thì việc xử lý cần ngắn gọn và không đổi trong suốt thời gian t−ơng tác với khách hàng. Trong tr−ờng hợp của tàu thuỷ, chúng ta hoàn toàn an tâm bởi vì số l−ợng các chức năng sẽ đ−ợc yêu cầu từ 2 tới 5, không phải vài nghìn, và chi phí tàu hoặc
3.3.2 T−ơng tác content-centric
Trong mô hình t−ơng tác content-centric, nội dung HTML vẫn đ−ợc server tạo ra và đ−ợc gởi tới một IFrame đ−ợc nhúng trong trang chính.
Hình 2.17: Mô hình content-centric
Client tạo ra một IFrame và đ−a yêu cầu tới server. Nội dung đ−ợc tạo ra từ Model, View, Controller trên tier thể hiện server và trả về cho IFrame. Không cần phải có các yêu cầu cho một mô hình công việc trên tier client.
Mã client –tier chỉ cần hiểu một l−ợng ít logic công việc của ứng dụng, và chịu trách nhiệm sắp xếp IFrame và xây dựng URL có liên quan tới nội dung. Mối quan hệ giữa client và các tier thể hiện là không rõ nét, hầu hết các công việc vẫn đ−ợc tải trên server. Với mô hình t−ơng tác này sẽ cho phép rất nhiều HTML tồn tại trên Web. Mô hình này đ−ợc sử dụng bó gọn trong một số tr−ờng hợp nhất định.
Vấn đề:
Do các t−ơng tác content-centric giống với các trang web hội thoại, các t−ơng tác này có rất nhiều hạn chế của cách làm cũ. Tài liệu nội dung bị tách biệt với IFrame từ trang mà IFrame đ−ợc nhúng vào.
3.3.3 Các t−ơng tác script-centric
Khi ta gửi một file JavaScript từ web server tới trình duyệt, file này thực hiện trong trình duyệt cho chúng ta. Nếu ta tạo ra JavaScript mà ta sẽ gửi từ một ch−ơng trình, chúng ta sẽ thiết lập đ−ợc một hệ thống phức tạp hơn. Theo
truyền thống, các ch−ơng trình client/server trao đổi dữ liệu với nhau và nhờ việc trao đổi thông tin qua mạng này đã tạo ra sự linh hoạt.
Trong một ứng dụng web cơ bản, một đoạn JavaScript và HTML của nó đ−ợc chuyển chung với nhau, và kịch bản chỉ làm việc với một trang cụ thể. Sử dụng Ajax, ta có thể tải các kịch bản và các trang độc lập với nhau, nhờ đó ta có thể dễ dàng thay đổi một trang nào đó theo nhiều cách khác nhau, phụ thuộc vào đoạn kịch bản mà ta load về. Mã tạo thành ứng dụng client của ta có thể đ−ợc mở rộng khi thực hiện. Điều này tạo ra thách thức cũng nh− cơ hội lớn.
- Thứ nhất hoạt động mạng đ−ợc tách khỏi background, nhờ đó bỏ qua đ−ợc cảm giác nhấp nháy.
Trạng thái tự nhiên của kịch bản mà ta tạo ra sẽ phụ thuộc vào các hook mà ta phát triển ở client
Có 2 vấn đề cần xử lý khi áp dụng mô hình này. Thứ nhất với việc thay đổi mã ở server và client có thể gây ra đổ vỡi giữa chúng. Các nguyên tắc thiết kế theo kiểu module có thể loại bỏ vấn đề này, thông qua việc cung cấp mô hình Facade.
Vấn đề thứ hai cần quan tâm đó là luồng JavaScript đ−ợc thiết kế đăc biệt cho client này, và nó không t−ơng thích khi sử dụng cho nội dung khác.
* Tải các kịch bản vào IFrame
Nếu ta tải một JavaScript bằng một tag<script> HTML, script sẽ tự động thực hiện nhờ bộ biên dịch. Nếu ta sử dụng một IFrame không nhìn thấy đ−ợc để tải kịch bản của ta, ta cần tập trung vào việc tạo ra kịch bản, do tất cả các t−ơng tác khác đã đ−ợc tạo ra cho chúng ta
* Vấn đề và giới hạn
Khi ta tải một kịch bản trực tiếp từ server, chúng ta truyền đi một bản tin, và làm giảm băng thông trong một vài phạm vi nào đó. Ta cũng tách tính logic khỏi thể hiện.
Hình 2.18: Kiến trúc Script – centric cho một ứng dụng Ajax.
3.3.4 T−ơng tác data-centric
Trong một vài tr−ờng hợp, ta muốn chia sẻ bảng dữ liệu của client Ajax với một vài dạng client khác nh− client Java hay .Net. Trong tr−ờng hợp này, ta có thể đ−a ra một dạng dữ liệu trung gian thay vì một tập các lệnh JavaScript. Giải pháp ở đây là server sẽ phục vụ một luồng dữ liệu “sạch”, của riêng mã client của ta, thay vì dùng một thực thể JavaScript.
*) Sử dụng dữ liệu XML
Dữ liệu XML là dạng dữ liệu đ−ợc dùng trong máy tính hiện đại. Môi tr−ờng trình duyệt hiện đại, và đối t−ợng XMLHttpRequest cung cấp các hỗ trợ để xử lý XML rất tốt. Nếu nh− XMLHttpRequest nhận đ−ợc một phải hồi với một loại nội dung XML nh− là application/xml hoặc text/xml, nó có thể biểu diễn phản hồi đó d−ới dạng một DOM.
Ưu điểm lớn nhất của XML ở chỗ nó tự động xây dựng thông tin, và ta lợi dụng −u điểm này để cung cấp một số l−ợng các tag <info>, ta dịch ra