Khóa luận Nghiên cứu lập trình cho các thiết bị di động áp dụng cho bài toán hướng dẫn du lịch

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CƠNG NGHỆ Lê Xuân Chính NGHIÊN CỨU LẬP TRÌNH CHO CÁC THIẾT BỊ DI ĐỘNG ÁP DỤNG CHO BÀI TỐN HƯỚNG DẪN DU LỊCH KHỐ LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY Ngành: Mạng và truyền thơng máy tính HÀ NỘI - 2010 ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CƠNG NGHỆ Lê Xuân Chính NGHIÊN CỨU LẬP TRÌNH CHO CÁC THIẾT BỊ DI ĐỘNG ÁP DỤNG CHO BÀI TỐN HƯỚNG DẪN DU LỊCH KHỐ LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY Ngành: Mạng và truyền thơng máy tính Cán bộ hướng dẫn: ThS Nguyễn Việt Anh HÀ NỘI - 2010 Tĩm Tắt Việc hướng dẫn du lịch ngày nay hết sức đa dạng, chúng ta cĩ thể được hướng dẫn thơng qua internet, hướng dẫn viên, sách báo…Nhưng tất cả các cách trên đều cĩ một hạn chế đĩ là tính độc lập, như internet thì chúng ta luơn phải cần một chiếc máy tính kết nối mạng, cịn hướng dẫn viên thì ta luơn phải đi theo sát họ…Vì vậy việc hướng dẫn du lịch qua mobile là một giải pháp tốt. Ứng dụng “Hướng dẫn du lịch qua mobile theo ngữ cảnh” được viết lên nhằm mục đích hướng dẫn khách tham quan thu được thơng tin một cách chính xác nhất về địa điểm mà họ quan tâm. Ứng dụng tổ chức dữ liệu dưới dạng cây, tùy vào ngữ cảnh mà người dùng đưa vào sẽ quyết định độ chi tiết của thơng tin trả về. Sau hơn 5 tháng nghiên cứu dưới sự hướng dẫn của thầy ThS Nguyễn Việt Anh và sự giúp đỡ của các bạn trong nhĩm khĩa luận. Bước đầu khĩa luận đã thu được những kết quả nhất định. - Áp dụng xử lý dữ liệu theo ngữ cảnh vào bài tốn du lịch. - Tìm hiểu về J2ME, Webservice. - Xây dựng thành cơng chương trình “Hướng dẫn du lịch qua mobile theo ngữ cảnh”. Ứng dụng đã đáp ứng được những chức năng cần thiết nhất trong việc hướng dẫn du lịch qua mobile theo ngữ cảnh. MỤC LỤC Lời nĩi đầu ...............................................................................................................................1 Mục tiêu của đề tài ..........................................................................................................3 Chương 1. Xử lý dữ liệu theo ngữ cảnh trên mobile ......................................................3 1.1. Giới thiệu ..................................................................................................................3 1.2. Hạn chế của hướng dẫn du lịch thơng thường......................................................3 1.3. Hướng dẫn du lịch theo ngữ cảnh ..........................................................................4 1.4. Các chương trình liên quan .....................................................................................4 1.5. Cấu trúc DTG ...........................................................................................................6 1.6. Xác định ngữ cảnh ...................................................................................................7 1.7. Kết luận .....................................................................................................................8 Chương 2. Ứng dụng “hướng dẫn du lịch qua mobile theo ngữ cảnh” .....................9 2.1. Ngữ cảnh của chương trình.....................................................................................9 2.2. Mơ hình kết nối ......................................................................................................10 2.3. Thiết kế cơ sở dữ liệu ............................................................................................11 2.3.1. Các bảng dữ liệu của chương trình ..........................................................11 2.3.2. Chi tiết các bảng .........................................................................................11 2.4. Mơ hình dữ liệu ......................................................................................................13 2.5. Cài đặt thuật tốn ...................................................................................................14 2.5.1. Các khái niệm cơ bản về cây ....................................................................14 2.5.2. Cài đặt cây ...................................................................................................16 2.6. Luồng xử lý dữ liệu của chương trình .................................................................20 2.6.1. LoginScreen ................................................................................................20 2.6.2. Welcome......................................................................................................21 2.6.3. List................................................................................................................22 2.6.4. Form .............................................................................................................24 2.7. Cài đặt thử nghiệm.................................................................................................25 Chương 3. J2ME...................................................................................................................26 3.1. Giới Thiệu ...............................................................................................................26 3.2. Những phiên bản Java ...........................................................................................26 3.3. Tại sao dùng J2ME? ..............................................................................................27 3.3.1. Configurations (Cấu hình).........................................................................27 3.3.2. Profile ..........................................................................................................28 3.4. Cấu hình CONFIGURATION và PROFILE được phát triển như thế nào? ...29 3.4.1. Máy ảo Java (JVM – Java Virtual Machines) ........................................29 3.4.2. KVM và CLDC liên quan như thế nào? ..................................................29 3.5. Tính tương thích giữa những phiên bản Java .....................................................30 3.5.1. Ứng dụng J2SE sẽ tiếp tục chạy trên mơi trường J2ME? .....................31 3.5.2. Những ứng dụng J2ME vẫn chạy trên J2SE? .........................................31 3.6. Kết chương..............................................................................................................31 Chương 4. Web service .......................................................................................................32 4.1. Định nghĩa...............................................................................................................32 4.2. Thành phần cơ bản của Web service ...................................................................32 4.3. Hoạt động của Web service ..................................................................................32 4.3.1. SOAP ...........................................................................................................33 4.3.2. WSDL (Web Service Definition Language) ...........................................33 4.3.3. UDDI(Universal Description, Discovery, and Integration) ..................33 4.5. Các thành phần chính của Web Service ..............................................................35 4.5.1. SOAP (Simple Object Access Protocol) .................................................35 4.6. WSDL (Web Service Definition Language) ......................................................35 4.6.1. Cấu trúc file WSDL ...................................................................................37 Chương 5. Kết luận ..............................................................................................................38 5.1. Kết luận ...................................................................................................................38 5.1.1. Các kết quả đạt được ..................................................................................38 5.1.2. Các vấn đề chưa giải quyết được .............................................................38 5.2. Hướng phát triển tương lai....................................................................................38 Lời cảm ơn! Sau hơn năm tháng tìm hiểu và thực hiện, luận văn “Nghiên cứu lập trình cho các thiết bị di động áp dụng cho bài tốn hướng dẫn du lịch” đã cơ bản hồn thành. Để đạt được kết quả này, em đã nỗ lực hết sức và đồng thời cũng nhận được rất nhiều sự quan tâm, giúp đỡ, ủng hộ của thầy cơ, bạn bè và gia đình. Điều đầu tiên, em xin gửi lời cảm ơn chân thành đến bộ mơn Mạng và Truyền thơng máy tính, Khoa Cơng nghệ thơng tin, Trường Đại học Cơng Nghệ, Đại học Quốc Gia Hà Nội và các thầy cơ đặc biệt là ThS Nguyễn Việt Anh đã tận tình giúp đỡ, hướng dẫn em hồn thành luận văn. Mình rất cảm ơn các bạn bè trong khoa, đặc biệt là nhĩm làm cùng khĩa luận và cộng đồng Java Việt Nam đã luơn bên cạnh, giúp đỡ và đĩng gĩp ý kiến trong suốt quá trình làm luận văn. Và con xin chân thành cảm ơn đến gia đình đã luơn động viên và tạo điều kiện thuận lợi nhất để con học tập và hồn thành luận văn. Luận văn đã hồn thành và cĩ được kết quả nhất định, tuy nhiện vẫn khơng thể tránh khỏi những sai sĩt. Rất mong sự cảm thơng và đĩng gĩp ý kiến nhiệt tình từ thầy cơ và các bạn. Hà Nội, tháng 5 năm 2010 Lê Xuân Chính 1 Lời nĩi đầu Mạng điện thoại di động xuất hiện tại Việt Nam từ đầu những năm 1990, và theo thời gian số lượng nhà cung cấp dịch vụ và số lượng thuê bao tăng lên hàng ngày. Giờ đây chiếc điện thoại di động khơng chỉ đơn thuần là gọi, nhắn tin và nghe mà nĩ cịn là một thiết bị giải trí đa phương tiện, tra cứu thơng tin rất tiện lợi... Việc xây dựng các ứng dụng trên điện thoại đi động là một lĩnh vực mới, hứa hẹn nhiều thú vị và là một xu thế tất yếu hiện nay. Các dịch vụ giá trị gia tăng trên điện thoại di động cĩ thể nĩ i là một mảnh đất màu mỡ cho các doanh nghiệp cung cấp dịch vụ di động. Ngày nay cĩ hai hướng phát triển ứng dụng trên thiết bị di động chính là sử dụng ngơn ngữ C++ trên nền hệ điều hành Symbian và J2ME. Các ứng dụng viết trên nền Symbian cĩ ưu thế truy cập trực tiếp các tài nguyên của điện thoại di động cũng như hỗ trợ hệ thống tập tin, thư mục…Nhưng việc phát triển trên nền Symbian tương đối phức tạp và dung lượng ứng dụng khá lớn. Cĩ thể nĩi J2ME là một đối thủ của Symbian API, J2ME cĩ ưu điểm là nhỏ gọn, tiện dụng, hỗ trợ hầu hết các dịng điện thoại hiện nay, kể cả điện thoại sử dụng hệ điều hành Symbian. J2ME khơng chỉ là ngơn ngữ dùng để viết cho các ứng dụng di động, mà nĩ cịn cĩ thể lập trình cho các thiết bị gia dụng, thẻ tín dụng điện tử, và các ứng dụng thơng minh khác. Rất khĩ để so sánh các dịng ngơn ngữ lập trình. Vì mỗi ngơn ngữ đều cĩ thế mạnh riêng của nĩ. Dựa trên tiêu trí tính phổ biến và thích hợp với điều kiện hiện thời, tơi đã chọn J2ME là ngơn ngữ để xây dựng ứng dụng. Với sự phát triển mạnh của mạng di động và ngày nay vấn đề về phần cứng đã được cải thiện một cách đáng kể về tốc độ xử lý và dung lượng bộ nhớ. Sự kiện đáng chú ý gần đây Việt Nam đã cĩ một số đơn vị cung cấp dịch vụ 3G. 3G, hay 3-G, (viết tắt của third-generation technology) là cơng nghệ truyền thơng thế hệ thứ ba, cho phép truyền cả dữ liệu thoại và dữ liệu ngồi thoại (tải dữ liệu, gửi email, tin nhắn nhanh, hình ảnh...). Với những thế mạnh vượt trội đĩ, 3G sẽ hứa hẹn là một mảnh đất cho các lập trình viên thỏa mãn đam mê lập trình trên các thiết bị di động. Và tiến tới hầu như tất cả các ứng dụng trên desktop sẽ cĩ mặt trên mobile. Dựa trên nền tảng ngơn ngữ J2ME, tơi đã xây dựng ứng dụng “hướng dẫn du lịch qua mobile theo ngữ cảnh”. Với một chiếc máy tính việc tra cứu thơng tin du lịch là việc cực kì đơn giản, chỉ bằng một cú click để truy cập sau vài giây thì bạn sẽ nhận được hàng triệu kết quả để tham khảo. Ngày nay chiếc điện thoại di động với những tính năng mạnh mẽ đi cùng, các chức năng dần tiến tới như desktop 2 chỉ là vấn đề thời gian, ứng dụng “hướng dẫn du lịch qua mobile theo ngữ cảnh” được viết nên nhằm trợ giúp các khách du lịch trong việc tìm kiếm và tra cứu thơng tin địa lý, điểm đặc biệt ở chương trình là tính mềm dẻo về dữ liệu trả về, khơng cĩ gì buồn chán hơn khi ta đọc đi đọc lại một lượng thơng tin cố định, mà khơng cĩ sự thay đổi theo thời gian. Ứng dụng của tơi đã giải quyết được vấn đề này, tùy vào thơng tin truy vấn của người dùng mà dữ liệu trả về sẽ khác nhau, cĩ thể nĩi đây là sự thơng minh của chương trình. Với sự phát triển về tốc độ của mạng di động, dung lượng của dữ liệu khơng cịn là vấn đề quan trọng nữa, vì vậy nội dung của ứng dụng sẽ thêm phong phú và đa dạng. Chương trình bước đầu đã hồn thành, dữ liệu lúc này đơn giản chỉ là chữ và hình ảnh, nhưng cũng đủ để truyền tải hết thơng tin tới người dùng. Nhận thấy 3G đã cĩ mặt tại Việt Nam, vì vậy hướng phát triển tương lai của chương trình là tích hợp thêm video, cụ thể ở đây là ứng dụng sử dụng cơng nghệ Video Streaming, hiện cịn rất mới, đây là hướng đi hứa hẹn nhiều thành cơng. Tuy đã đầu tư khá nhiều thời gian và cơng sức vào luận văn, nhưng khơng thể tránh khỏi những sai sĩt, tơi rất mong nhận được những đĩng gĩp và phản hồi từ thầy cơ và các bạn! Xin chân thành cảm ơn! Lê Xuân Chính 3 Mục tiêu của đề tài - Tìm hiểu ngơn ngữ lập trình J2ME. - Tìm hiểu Web service. - Tìm hiểu vể “xử lý dữ liệu theo ngữ cảnh”. - Xây dựng ứng dụng demo “Hướng dẫn du lịch qua mobile theo ngữ cảnh”. Chương 1. Xử lý dữ liệu theo ngữ cảnh trên mobile 1.1. Giới thiệu Những khách du lịch bụi thường phải dựa vào bản đồ hoặc dựa vào những biển hiệu trên đường đi để tự khám phá một thành phố lạ lẫm. Họ cần cĩ một người hướng dẫn viên giúp họ tới những nơi mà họ muốn, cho họ thơng tin về bất cứ những gì mà họ tìm thấy thậm chí là đảm bảo đưa họ trở về đúng giờ. Đây là mục tiêu chính của Dynamic Tour Guide - Hướng dẫn viên du lịch di động(DTG). DTG là một thiết bị di động cho phép cá nhân hĩa những thơng tin về tour du lịch. Nĩ chọn những địa điểm thu hút khách du lịch, lên lịch cho một tour thăm quan cá nhân, cung cấp những thơng tin về đường đi trong suốt quá trình du lịch và những thơng tin về mơi trường. Những thơng tin phản hồi thơng minh này dựa trên tất cả những phân tích về bối cảnh hiện tại để hỗ trợ cho khách du lịch bất cứ lúc nào. 1.2. Hạn chế của hướng dẫn du lịch thơng thường Khách du lịch luơn cần cĩ những thơng tin chi tiết về địa điểm mình tham quan ví dụ như: bảo tàng cĩ những giờ mở cửa khác nhau hoặc cĩ thể cĩ những giờ mở cửa thêm. Ví dụ vào những dịp cuối tuần, mùa hè thì những cửa hàng luơn kín chỗ, cịn vào khoảng tháng 11 thì luơn đĩng cửa. Nếu khơng nắm bắt được những thơng tin này, khách du lịch sẽ khơng cĩ được những chuẩn bị cần thiết, vì vậy chỉ cịn cách đi theo những biển hiệu, chỉ dẫn trên bản đồ hay đường đi. Những hướng dẫn viên du lịch thường chỉ hướng dẫn cho cả đồn khách, họ đi theo những tour đã định sẵn và chỉ tham quan những điểm chính, trong khi cĩ những địa điểm thú vị lại khơng được tham quan, mặc dù chỉ cách những điểm chính rất gần. Lý tưởng nhất là cĩ một thiết bị giống như hướng dẫn viên du lịch, luơn thường trực, am hiểu những địa danh và hiểu được sở thích cá nhân của khách du lịch, quản lý được về thời gian, biết được tình hình hiện tại, đưa ra một tour du lịch cá nhân, và cĩ thể cất gọn trong túi áo. Đây là mục tiêu của DTG. Mục đích ở đây là lập ra một tour 4 du lịch, giống như một chuyên viên hướng dẫn viên du lịch sẽ làm khi sau khi biết được những thơng tin về khách du lịch. Điều này hồn tồn cĩ thể thực hiện được bằng việc áp dụng cơng nghệ mới là kết hợp sự nhận thức về ngữ nghĩa và ngữ cảnh của máy tính. 1.3. Hướng dẫn du lịch theo ngữ cảnh Một khách du lịch luơn muốn khám phá ngay địa điểm họ sắp tới. Họ cĩ một hồ sơ về sở thích, điểm xuất phát và kết thúc và một khoảng thời gian cho tour du lịch. Những thơng tin này cần được nạp vào hệ thống. Ngữ cảnh ở đây là tất cả những thơng tin hiện thời về một địa điểm nhất định, một khoảng thời gian nhất định. Thách thức đặt ra là phải đưa ra một tour tối ưu dựa trên những thơng tin cá nhân và ngữ cảnh. Trong suốt quá trình tham quan, khách du lịch cĩ thể được hướng dẫn để đi tới tổ hợp các tịa nhà, địa điểm cần đến(Tour Building Block – TBB). Khi khách du lịch bắt đầu chuyến du lịch, DTG cĩ thể đo được tốc độ di chuyển và cập nhật những thơng tin này để cĩ thể tính tốn, sắp xếp lại tour du lịch. Ngay khi khách du lịch tới một TBB, DTG cĩ thể đưa ra thơng tin giới thiệu phù hợp với hồn cảnh hiện tại. Một số khách du lịch cĩ thể quyết định khám phá TBB bằng cách nhiều cách, ví dụ như đi bộ, hoặc xem lướt qua… Trong trường hợp này, những thơng tin thêm phù hợp cũng sẽ được cung cấp. Ngay khi khách du lịch rời khỏi TBB, DTG sẽ ngừng cung cấp thơng tin về TBB này và nạp lại quá trình điều hướng, cĩ thể sang TBB tiếp theo. Trong trường hợp du khách dừng chân lại lâu hơn dự kiến ban đầu thì thời gian cịn lại phải được tính tốn lại. Trên đường tới TBB tiếp theo, du khách cĩ thể sẽ bị phân tán bởi một điểm tham quan khác hoặc đơn giản là 1 cửa hàng. Lúc này DTG sẽ tạm dừng những gợi ý điều hướng và cung cấp những thơng tin về bối cảnh hiện tại nếu cĩ thể. Trong trường hợp này, DTG sẽ phải chờ cho tới khi du khách rời khỏi điểm hiện tại và tính tốn lại thời gian. 1.4. Các chương trình liên quan Tour Guides từ lâu đã trở thành 1 chủ đề rất quan trọng trong hoạt động nghiên cứu. Cũng cĩ nhiều chương trình được viết lên nhằm mục đích hướng dẫn theo ngữ cảnh, các chương trình đều cĩ đặc điểm riêng của nĩ nhưng đều cĩ những hạn chế nhất định, chỉ phục vụ cho những yêu cầu đặc biệt. Những dự án quan trọng sau đây cũng xử lý những vấn đề tương tự DTG. 5  Guide: Là một hướng dẫn viên du lịch di động - sử dụng hệ thống định vị theo từng ơ thay vì GPS. Khách du lịch cĩ thể chọn địa điểm tham quan theo phân loại trong chuyến du lịch. Đường đi đã được tính trước. Thứ tự tham quan cĩ thể được thay đổi phụ thuộc vào thời gian. Sở thích cá nhân hay thơng tin về ngữ cảnh được cung cấp sẵn.  DTG sẽ lên lịch một tour dựa theo hồ sơ cá nhân của khách du lịch. Khái niệm về hướng dẫn du lịch theo ngữ cảnh cũng được đề cập nhưng DTG xử lý vấn đề này tốt hơn.  Cyberguide: Là 1 trong những hướng dẫn viên du lịch đầu tiên. Nĩ làm việc với sự trợ giúp của GPS và tia hồng ngoại để nhận biết những thơng t in ngữ cảnh như vị trí của người dùng và sự điều hướng. Tour khơng được định trước, nhưng người dùng vẫn cĩ thể nhận thơng tin về bất cứ thứ gì, bất cứ địa điểm nào mà họ nhìn thấy. Yêu cầu về 1 đường dẫn tới những địa điểm ưa thích cũng cĩ thể được đáp ứng. Bên cạnh đĩ, nĩ cũng cho phép tạo nhật ký về tồn bộ tour. Khác biệt chính là sự tính tốn trước về tồn bộ tour du lịch dựa trên những sở thích của khách du lịch trong hệ thống DTG.  Dự án Crumpet: Cho phép 1 thiết bị di động tìm ra một địa điểm nhất định, thể hiện nĩ trên bản đồ và tính tốn 1 đường tới địa điểm đĩ. Địa điểm tham quan được tìm thấy trên bản đồ và người dùng phải quyết định xem cĩ đủ thời gian hay cĩ nên tham quan khơng.  Phần mềm phát triển bởi eNarro: Cung cấp những tour định sẵn, giới thiệu những địa điểm nổi tiếng ở những thành phố lớn trên thế giới. Khách du lịch cần cĩ 1 chiếc PDA và 1 thiết bị đặc biệt dành cho những tour đặc biệt. Họ cũng cần cĩ 1 phần mềm điều hướng, hướng dẫn họ đến 1 địa điểm khác. Những thơng tin hướng dẫn sau đĩ sẽ được truyền tải tới người dùng nhờ vào thiết bị nghe nhìn đặc biệt.  Người dùng chỉ cĩ thể chọn những tour được định sẵn – phù hợp với mục đích quảng bá. Những tour du lịch đã được định sẵn khơng phải là mục tiêu của DTG, cái mà nĩ hướng đến là tạo ra một tour du lịch mang tính cá nhân hĩa trong thời gian thực. Bên cạnh đĩ, nĩ cũng chú trọng đến những bối cảnh thực tại như thời gian đĩng/mở cửa 6 bằng cách luơn cập nhật thơng tin qua web service. Những thách thức mà DTG cần giải quyết là: Thu thập những thơng tin về sở thích cá nhân của khách du lịch để tạo 1 hồ sơ hồn chỉnh. Xếp hạng của TBBs(danh sách các địa điểm mà ta sẽ thăm) bằng cách kết hợp ngữ nghĩa. Đưa ra 1 tour du lịch trong thời gian sớm nhất cĩ thể. Nhận biết ngữ cảnh, mơi trường. Giám sát tour và điều hướng tour phù hợp. 1.5. Cấu trúc DTG Mỗi địa điểm, giống như một thành phần cĩ thể cĩ của TBB, chúng là mơ hình ngữ nghĩa của một nhà cung cấp nội dung sử dụng Authoring tool DTG. Mỗi TBB sẽ cĩ một WS(Web Service) riêng của nĩ. Một dịch vụ được cung cấp giống như là nhà hàng thì sẽ nằm trong hệ thống các các địa điểm nhà hàng và được quản lý bởi một WS. WS sẽ cung cấp các mơ hình ngữ nghĩa, các thơng tin hiện thời như là giờ mở cửa, đĩng cửa, hình thức giao dịch của cửa hàng… Các WS c ủa các TBB sẽ được đăng ký tại UDDI(Universal Description, Discovery, and Integration). Máy chủ DTG sẽ thực hiện thuật tốn phù hợp theo ngữ nghĩa để xếp hạng các điểm tham quan cho một khách du lịch cụ thể. Các thiết bị di động sẽ xác định được vị trí của nĩ, nếu ở trong thành phố thì sẽ thơng qua một hệ thống định vị tồn cầu GPS hoặc bên trong các tịa nhà như là bảo tàng thì sẽ thơng qua mạng WLAN, lưới hồng ngoại hoặc RFIDs. 7 Hình 1.1: Phát hiện đựa trên ngữ cảnh, mơi trường Sau khi đã chọn được một điểm du lịch, thì phần mềm định vị sẽ mơ phỏng các tour du lịch trên bản đồ, và hướng dẫn khách du lịch qua các tín hiệu âm thanh. DTG sẽ luơn theo dõi hành trình của các tour du lịch bằng cách thay đổi theo ngữ cảnh. Ví dụ như du khách thay đổi tốc độ di chuyển, đến một mức nào đĩ thì sẽ kích hoạt một tính tốn nào đĩ để đảm bảo đến được điểm mong muốn trong thời gian đã được định sẵn. 1.6. Xác định ngữ cảnh Bất kỳ một tính năng đặc trưng của một thực thể đều bị chi phối bởi ngữ cảnh của nĩ. Ngữ cảnh này sẽ được chia ra làm các dạng khác nhau: 1. Ngữ cảnh cá nhân: Ngữ cảnh cá nhân bao gồm những thơng tin cá nhân. Nĩ được xác định bởi các yếu tố tĩnh như tên, sở thích, thĩi quen như là tốc độ đi bộ, màu sắc… 2. Ngữ cảnh địa điểm: Ngữ cảnh địa điểm bao gồm các thơng tin về mơi trường, như là độ dài các con đường, số lượng các vị trí thực tế trên một con đường, thời tiết tại đĩ… 3. Hỗ trợ khám phá: Ngữ cảnh dịch vụ là miêu tả các dịch vụ cĩ sẵn . Hệ thống nhận thức ngữ cảnh cĩ khả năng thích ứng được với các chức năng vì nĩ cĩ khả năng lọc ra các thơng tin theo ngữ cảnh. Đây được gọi là trí thơng minh thích ứng với mơi trường xung quanh. Ngữ cảnh cá nhân được ánh xạ đến ngữ cảnh dịch vụ với từng địa điểm một. DTG sẽ làm việc bằng cách phát hiện các vị trí gần vị 8 trí hiện tại và yêu cầu các thơng tin sẵn cĩ, và đánh giá chúng theo sở thích cá nhân và tạo ra một tour du lịch trong một khoản thời gian giới hạn. DTG sẽ phụ thuộc vào các ngữ cảnh sau đây: Khoảng thời gian sẵn cĩ, các tour du lịch sẽ khác nhau về độ dài. Vị trí hiện tại, điểm bắt đầu và điểm cuối là khác nhau. Thời gian hiện tại(ngày hoặc mùa) . Ví dụ như thời gian đĩng mở cửa của các nhà hàng hoặc triển lãm. Sở thích cá nhân. Các điểm thăm quan lựa chọn sẽ được thay đổi cho phù hợp. Ngồi ra các DTG sẽ luơn giám sát các tour du lịch, bất kỳ sự thay đổi về tốc dộ di chuyển thì DTG sẽ điều chỉnh thích hợp để du khách đến được nơi đúng giờ. Tốc dộ di chuyển và thời gian cho một tour sẽ đưa ra các chú ý về vấn đề thời gian. Hướng đi của du khách tại vị trí hiện tại cĩ thể được thể hiện bằng các hình ảnh trực quan trên màn hình điện thoại, và các thơng tin phù hợp về vị trí đĩ. 1.7. Kết luận DTG sử dụng cơng nghệ tiên tiến để tạo ra các tour du lịch theo ngữ cảnh. Độc lập với vị trí và thời gian, xác định thơng tin cần thiết bằng cách xác định và truy vấn đến các web service cĩ sẵn. Nĩ hỗ trợ khách du lịch bằng cách đưa ra các dướng dẫn chuyển hướng và cung cấp thơng tin đúng lúc, đúng chỗ. Bất kỳ ảnh hưởng nào, hay quyết định tự phát của khách du lịch sẽ được phản hồi về server. 9 Chương 2. Ứng dụng “hướng dẫn du lịch qua mobile theo ngữ cảnh” Mấy năm gần đây việc phát triển các ứng dụng trên điện thoại di động đã trở lên phổ biến. Sự gia tăng về dung lượng bộ nhớ và tốc độ xử lý trên điện thoại đi động cho phép ta phát triển các ứng dụng mà trước kia tưởng chừng như chỉ cĩ thể phát triển trên desktop. Và sự ra đời của các ngơn ngữ lập trình cho điện thoại càng làm việc phát triển ứng dụng trên di động thêm dễ dàng và thú vị. Hướng dẫn du lịch qua sách báo, hướng dẫn viên, hay internet đã quá quen thuộc với mọi người. Mỗi phương thức đều cĩ ưu khuyết điểm riêng nhưng tựu chung lại chúng đều thiếu tính độc lập cao, ví dụ muốn tìm hiểu du lịch qua internet thì ta phải cần một chiếc máy tính để bàn khá là cồng kềnh, hướng dẫn viên thì ta phải luơn đi theo họ... Vì vậy phát triển ứng dụng hướng dẫn du lịch trên mobile là hết sức hợp lý và thích hợp trong thời điểm này, ứng dụng cĩ thể khai thác triệt để các tính năng của điện thoại di động như là tính độc lập, tức là người sử dụng luơn cĩ thể mang theo máy di động bên mình, về thơng tin hiển thị trên mobile về cơ bản chính là thơng tin hiển thị trên máy tính để bàn. Ứng dụng mà chỉ dùng để hiển thị thơng tin trên di động thay vì hiển thị trên desktop thì về cơ bản khơng cĩ gì là đáng chú ý lắm. Điểm mấu chốt ở đây là sự thơng minh của ứng dụng, tức là từ truy vấn của người sử dụng thì thơng tin trả về là khác nhau qua mỗi lần truy vấn, và tùy thuộc vào đối tượng truy vấn mà thơng tin trả về cũng khác nhau. Một ứng dụng điện thoại thơng minh, đặc biệt là ứng dụng hướng dẫn du lịch trên điện thoại thì cĩ thể coi như là một người bạn đồng hành và hướng dẫn viên du lịch nhiệt tình, cần là cĩ. Xuất phát từ ý tưởng đĩ, ứng dụng “hướng dẫn du lịch qua mobile theo ngữ cảnh” đã ra đời, với mục đích tra cứu thơng tin du lịch mọi chỗ mọi lúc. 2.1. Ngữ cảnh của chương trình Đây là ứng dụng hướng dẫn du lịch qua mobile theo ngữ cảnh. Vì vậy sự thơng minh của chương trình phụ thuộc rất nhiều vào lượng ngữ cảnh mà người dùng đưa vào. Ngữ cảnh càng nhiều thì thơng tin sẽ được trả về theo nhiều lớp, điều này sẽ giúp khách du lịch cĩ được một hướng dẫn thích hợp nhất. Như ở chương một thì “ngữ 10 cảnh là tất cả những thơng tin hiện thời về một địa điểm nhất định, một khoảng thời gian nhất định”, các ngữ cảnh mà tơi đưa vào chương trình là:  Thời gian: Một ngữ cảnh hết sức quan trọng, nĩ là ngữ cảnh chính của chương trình. Đi du lịch thì vấn đề là hết sức quan trọng và thời gian cũng là một ngữ cảnh luơn thay đổi, vì vậy việc thích ứng với sự thay đổi về thời gian để đưa ra một tour du lịch thích ứng là cần thiết.  Font: Đối tượng du lịch là rất da dạng trẻ, già… Ngồi chất lượng của thơng tin hướng dẫn thì vấn đề hiển thị cũng rất quan trọng, gĩp phần quan trọng vào sự thân thiện của chương trình với người dùng. Khơng cĩ gì khĩ chịu hơn là khi ta mắt kém mà nhìn vào màn hình với những dịng chữ nhỏ, hay màn hình hiển thị tương đối nhỏ mà chữ thì to chống hết màn hình.  Profile: Đây là thơng tin về người sử dụng, được lưu trong cơ sở dữ liệu trên server. Để sử dụng chương trình thì người dùng phải đăng nhập vào hệ thống, trong đĩ những thơng tin được lưu trữ như là tên, tuổi, giới tính…Những yếu tố này cũng là một thành phần ngữ cảnh của chương trình. 2.2. Mơ hình kết nối 11 Hình 2.1: Mơ hình kết nối • Ứng dụng viết trên điện thoại di động sử dụng ngơn ngữ J2ME. • Web server sử dụng JSP. • Cơ sở dữ liệu sử dụng MySQL. Ứng dụng viết trên điện thoại đĩng vai trị là 1 client giao tiếp với server thơng gia GPRS được cài đặt trên điện thoại thơng qua giao thức HTTP. Dựa vào các request/response từ phía client thì server sẽ truy vấn đến cơ sở dữ liệu MySQL thơng qua các store procedures. Khi người dùng chạy ứng dụng trên, và tiến hành đăng nhập vào chương trình, khi người dùng cĩ một thao tác bất kỳ trên ứng dụng và gửi 1 request đến server dưới dạng gĩi tin, gĩi tin sẽ được gửi dưới dạng sĩng GPRS đến trạm điện thoại, tại đây sẽ cĩ thiết bị chuyển các gĩi tin dạng sĩng GPRS sang dạng tín hiệu truyền trong đường truyền hữu tuyến Internet. Lúc này nhà cung cấp dịch vụ di động đĩng vai trị như là một gateway, làm trung gian liên lạc cho thiết bị di động và webserver. Gĩi tin được được máy di động gửi đến webserver là những gĩi tin HTTP request, và thiết bị di động sẽ nhận được các HTTP response từ webserver. Các gĩi tin HTTP request và HTTP response này sẽ chứa bên trong các thơng điệp SOAP request và SOAP response tương ứng. Các thơng điệp SOAP sẽ chứa các operation dùng để xử lý kết nối đến cơ sở dữ liệu tạo thành mơ hình truy cập hàm từ xa RPC(Remote Procedure Call). Các gĩi tin HTTP response sẽ đến nhà cung cấp mạng di động, chuyển thành tín hiệu GPRS và về đến client. Yêu cầu duy nhất trên điện thoại di động để giao tiếp được với server là diện thoại phải hỗ trợ GPRS và cĩ thư viện JSR 172. Thư viện JSR 172 cĩ chức năng tạo ra các thơng điệp SOAP và phân tích nội dung các thơng điệp này. Nếu khơng cĩ thư viện này thì điện thoại khơng thể giao tiếp được với server. 2.3. Thiết kế cơ sở dữ liệu 2.3.1. Các bảng dữ liệu của chương trình user_name(id, password, name, age, sex). info(infoID, label, image, content, brotherID, childID). log(id, date, route, font, time, level). 2.3.2. Chi tiết các bảng 12 User_name: Bảng chứa thơng tin về người dùng. . Tên Kiểu Nội dung Thuộc tính id varchar Mã đăng nhập chương trình của người dùng Khĩa chính password varchar Mật khẩu dùng để đăng nhập chương trình name varchar Họ tên đầy đủ của người dùng age int Tuổi của người dùng Sex int Giới tính của người dùng(1=Nam, 0=Nữ) Hình 2.2: Bảng user_name Info: Bảng chứa thơng tin về tất cả các địa điểm, địa danh cĩ trong cơ sở dữ liệu. Tên Kiểu Nội dung Thuộc tính infoID varchar Kí hiệu mã thơng tin Khĩa chính label varchar Tiêu đề của địa danh, địa điểm đĩ image blog Ảnh đại diện của địa danh, địa điểm đĩ content mediumtext Nội dung thơng tin của địa danh, địa điểm đĩ brotherID varchar Mã thơng tin về địa điểm cùng mức Khĩa ngồi childID varchar Mã thơng tin về địa điểm con Khĩa ngồi Hình 2.3: Bảng info Log: bảng chứa profile của người dùng. Tên Kiểu Nội dung Thuộc tính id varchar Mã đăng nhập chương trình của người dùng Khĩa chính date varchar Ngày tháng của lần đăng nhập gần nhất route varchar Dấu vết lộ trình tham quan người dùng font varchar Font chữ của người dùng lựa chọn time int Thời gian mà người dùng cĩ thể thăm quan Khĩa ngồi level int Mức độ đưa ra thơng tin theo ngữ cảnh Khĩa ngồi Hình 2.4: Bảng log 13 2.4. Mơ hình dữ liệu Hình 2.5: Mơ hình dữ liệu Các operator của Web service truy vấn đến cơ sở dữ liệu: checkLogin(String id, String password): kiểm tra việc đăng nhập. getAgeOfUser(String id): lấy về tuổi của người dùng. getNameOfUser(String id): lấy về họ tên của người dùng. getSexOfUser(String id): lấy về giới tính của người dùng 0=Nữ, 1=Nam. getDateVisited(String id): trả về ngày tháng thăm quan. updateDateVisited(String sdate, String id): cập nhập ngày tháng thăm quan của người dùng. getFont(String id): trả về font chữ mà người dùng lựa chọn updateFont(String id, String font): cập nhập lại font chữ mà người dùng vừa mới lựa chọn. 14 removeLog(String id): xĩa tất cả những lộ trình mà chương trình lưu trong cơ sở dữ liệu. getLabel(String infoID): trả về một mảng chứa label của từng địa điểm getContent(String infoID): lấy ra thơng tin về một địa điểm. getInfoID(String infoID): lấy ID của một thơng tin. getChildID(String infoID): lấy ID của một địa điểm con. getFather(String infoID): trả về ID của địa điểm cha getSize(String infoID): trả về số lượng các địa danh ở một mức thơng tin nào đĩ. 2.5. Cài đặt thuật tốn 2.5.1. Các khái niệm cơ bản về cây Chúng ta cĩ thể xác định khái niệm cây bằng hai cách: đệ quy và khơng đệ quy. Trước hết chúng ta đưa ra định nghĩa cây thơng qua các khái niệm trong đồ thị định hướng. Một ví dụ điển hình về cây là tập hợp các thành viên trong một dịng họ với quan hệ cha-con. Trừ ơng tổ của dịng họ này, mỗi một người trong dịng họ là con của một người cha nào đĩ trong dịng họ. Biểu diễn dịng họ dưới dạng định hướng: quan hệ cha-con được biểu diễn bởi các cung của đồ thị, nếu A là cha của B, thì trong đồ thi cĩ cung đi từ đỉnh A tới đỉnh B. Xem xét các đặc điểm của đồ thị định hướng này, chúng ta cĩ định nghĩa cây như sau: Cây là một đồ thị định hướng thỏa mãn các tính chất sau: Cĩ một đỉnh đặc biệt gọi là gốc cây. Mỗi đỉnh C bất kỳ khơng phải là gốc, tồn tại duy nhất một đỉnh P cĩ cung đi từ P đến C. Đỉnh P được gọi là cha của đỉnh C, và C là con của P. Cĩ đường đi duy nhất từ gốc tới mỗi đỉnh của cây. 15 Hình 2.6 Một số thuật ngữ hay dùng liên quan đến cây. Mở rộng của quan hệ cha-con. Là quan hệ tổ tiên-con cháu. Trong cây nếu cĩ đường đi từ đỉnh A đến đỉnh B thì A được gọi là tổ tiên của B, hay B là con cháu của A. Chẳng hạn, gốc cây là tổ tiên của các đỉnh cịn lại trong cây. Các đỉnh cùng cha được xem là anh em. Chẳng hạn. trong cây ở hình… các đỉnh B, C, D là anh em. Các đỉnh khơng cĩ con được gọi là lá. Trong hình 2.6, các đỉnh lá là E, F, C, G. Một đỉnh khơng phải là lá thì được gọi là đỉnh trong. Một đỉnh bất kỳ A cùng với tất cả các con cháu của nĩ lập thành một cây gốc là A. Cây này được gọi là cây con của cây đã cho. Nếu đỉnh A là con của gốc, thì cây con gốc A được gọi là cây con của gốc. Độ cao của cây là số đỉnh nằm trên đường đi dài nhất từ gốc tới mộ t lá. Chẳng hạn, cây trong hình 2.6 cĩ độ cao là 3. Dễ dàng thấy rằng, độ cao của cây là độ cao lớn nhất của cây con của gốc cộng thêm 1. Độ sâu của đỉnh là độ dài đường đi từ gốc tới đỉnh đĩ. Chẳng hạn, trong hình 2.6, đỉnh G cĩ độ sâu là 2. Cây là một cấu trúc dữ liệu phân cấp: các đỉnh của cây được phân thành các mức. Mức của mỗi đỉnh được xác định đệ quy như sau:  Gốc ở mức 1.  Mức của một đỉnh = mức của đỉnh cha +1. Như vậy, các đỉnh trong cùng một mức là đỉnh con của một đỉnh nào đĩ ở mức trên. Độ cao của cây chính là mức lớn nhất của cây. Ví dụ, cây trong hình 2.6 được 16 phân thành 3 mức: mức 1 chỉ gồm cĩ gốc, mức 2 gồm các đỉnh A, B, C, D, mức 3 gồm các đỉnh E, F, G. 2.5.2. Cài đặt cây Cây cĩ thể cài đặt bởi các CTDL khác nhau. Chúng ta cĩ thể sử dụng mảng để cài đặt cây. Song cách này khơng thuận tiện, ít được sử dụng. Sau đây, chúng ta trình bày hai phương pháp cài đặt cây thơng dụng nhất. Phương pháp 1 (chỉ ra danh sách các đỉnh con của mỗi đỉnh). Với mỗi đỉnh của cây, ta sử dụng một con trỏ trỏ tới một đỉnh con của nĩ. Và như vậy, mỗi đỉnh của cây được biểu diễn bởi một cấu trúc gồm hai thành phần: một biến data lưu dữ liệu chứa trong đỉnh đĩ và một mảng child các con trỏ trỏ tới các đỉnh con. Giả sử, mỗi đỉnh chỉ cĩ nhiều nhất K đỉnh con, khi đĩ ta cĩ thể mơ tả mỗi đỉnh bởi cấu trúc sau: const int K = 10; template { Item data; Node* child [K]; }; Chúng ta cĩ thể truy cập tới một đỉnh bất kỳ trong cây bằng cách đi theo các con trỏ bắt đầu từ gốc cây. Vì vậy, ta cần cĩ một con trỏ ngồi trỏ tới gốc cây, con trỏ root: Node * root; Hình 2.7: Cài đặt cây bởi mảng con trỏ. A B D C E F G root 17 Phương pháp 2 (chỉ ra con cả và em liền kề của mỗi đỉnh). Trong một cây, số đỉnh con của các đỉnh cĩ thể rất khác nhau. Trong trường hợp đĩ, nếu sử dụng mảng con trỏ, sẽ lãng phí bộ nhớ. Thay vì sử dụng mảng con trỏ, ta chỉ sử dụng hai con trỏ: con trỏ firstChild trỏ tới đỉnh con cả và con trỏ nextSibling trỏ tới em liền kề. Mỗi đỉnh của cây được biểu diễn bởi cấu trúc sau: template struct Node { Item data; Node*; firstChild; Node* nextSibling; }; Chúng ta cũng cần cĩ một con trỏ ngồi root trỏ tới gốc cây như trong phương pháp 1. Với cách này, cây trong hình 5.13 được cài đặt bởi CTDL như trong hình 5.14 Dễ dàng thấy rằng, xuất phát từ gốc đi theo con trỏ firstChild hoặc con trỏ nextSibling, ta cĩ thể truy cập tới đỉnh bất kỳ trong cây. Ta cĩ nhận xét rằng, các con trỏ nextSibling liên kết các đỉnh tạo thành một danh sách liên kết biểu diễn danh sách các đỉnh con của mỗi đỉnh. Hình 2.8: Cài đặt cây sử dụng hai con trỏ. Cần chú ý rằng, trong một số trường hợp, để thuận tiện cho các xử lý, ta cĩ thể đưa thêm vào cấu trúc Node một con trỏ parent trỏ tới đỉnh cha. A B C D G F E root 18 Do yêu cầu của bài tốn đặt ra là xử lý dữ liệu theo ngữ cảnh, tùy vào ngữ cảnh mà người dùng đưa vào sẽ truy suất ra dữ liệu thích hợp. Dữ liệu ở đây là thơng tin về từng địa danh và các địa điểm con của nĩ. Độ sâu của cây thơng tin sẽ quyết định mức độ chi tiết của thơng tin, vì vậy việc chọn phương pháp triển khai cây thứ 2 là khả thi. Hình 2.9: Ví dụ về một nhánh trong cây dữ liệu Trên đây ta ví dụ một nhánh thơng tin trong cơ sở dữ liệu của chương trình. Ở đây “Lăng tẩm Huế ” là root của cây. Ta sẽ chọn “Lăng Tây Sơn” là nhánh để phát triển. Mũi tên màu xanh lam: là phương thức lấy về infoID các địa điểm cùng mức. Mũi tên màu đỏ: là phương thức lấy về infoID địa điểm con. Mũi tên màu xanh lá cây: là phương thức lầy về infoID của địa điểm cha. Cấu trúc một node. 19 Hình 2.10: Cấu trúc một node infoID: ID của thơng tin một địa điểm. label: nhãn của thơng tin. image: ảnh đại diện của địa điểm. content: nội dung thơng tin về địa điểm đĩ. brotherID: ID thơng tin về địa điểm anh em cùng mức. childID: ID thơng tin về địa điểm con. 20 2.6. Luồng xử lý dữ liệu của chương trình Hình 2.11: Luồng xử lý của chương trình Chương trình gồm 5 Displayable chính: loginScreen, welcome, help, list, form. Các Displayable này sẽ cĩ nhiệm vụ hiển thị trực quan thơng tin trên màn hình điện thoại, giúp cho việc giao tiếp giữa người dùng và máy dễ dàng hơn. 2.6.1. LoginScreen Là một gĩi cĩ sẵn trong thư viện của J2ME, cĩ chức năng đưa ra một màn hình login trực quan cho người dùng, các thành phần của loginScreen là Username Filed, Password Field và Login Button 21 Hình 2.12: Màn hình đăng nhập 2.6.2. Welcome Đây là một Displayable mà thể hiện của nĩ là dưới dạng form.Form này cĩ nhiệm vụ hiển thị thơng tin người dùng như là họ tên, tuổi và giới tính và thơng tin về thời gian ghé thăm gần nhất. Form này cĩ các item ChoiceGroup giúp người dùng thao tác với chương trình đưa ra các request như là kích cỡ Font, và thời gian ghé thăm của người dùng. 22 Hình 2.13: Màn hình Welcome Các command trong welcome: Remove Log command: Xĩa hết tất cả file log, file mà lưu dấu vết đường đi của các lần ghé thăm của người dùng. OK command: Đưa người dùng đến màn hình List. Giúp Đỡ command: Đưa người dùng đến màn hình giúp đỡ Help Hình 2.14: Các command của màn hình Welcome 2.6.3. List 23 Displayable dưới dạng list, màn hình hiển thị danh sách những địa danh cĩ trong cơ sở sở dữ liệu, từ đây người dùng cĩ thể sử dụng các command để thao tác với chương trình như là xem thơng tin tham khảo về địa danh đĩ hay là dùng command “đi tiếp>>” để khám phá xem địa danh đĩ cịn cĩ các danh mục con. Hình 2.15: Màn hình danh sách các địa danh Các command trong List Thơng tin command: Đây là command đưa người dùng đến màn hình hiển thị thơng tin về địa danh mà ta đã chọn ở màn hình list. Đi tiếp>> command: Bản chất dữ liệu ở đây là dưới dạng cây thơng tin, một địa danh sẽ coi như là một cây, nĩ sẽ chi làm các địa danh con. Tùy vào địa danh thì cây thơng tin biểu diễn sẽ là nhiều nhánh con hay ít. Command này sẽ trỏ chính về màn hình list, nhưng với dữ liệu hiển thị khác, vấn đề này ta sẽ nĩi rõ hơn trong phần sau. Back: quay lại màn hình welcome. 24 Hình 2.16: Màn hình command của màn hình list 2.6.4. Form Displayable dưới dạng form cĩ nhiệm vụ hiển thị thơng tin dưới dạng text và hình ảnh. Hình 2.17: Màn hình hiện thị thơng tin địa điểm Các command trong form Back command: quay lại màn hình List. 25 2.7. Cài đặt thử nghiệm  Phần cứng: Điện thoại hỗ trợ kết nối GPRS, JSR172 hỗ trợ gửi nhận các gĩi tin SOAP. Server: hỗ trợ kết nối web, cơ sở dữ liệu đặt trực tiếp tại server hay database server riêng.  Phần mềm: Máy ảo Java. J2ME Wireless toolkit 2.5.2 for CLDC Server: GlassFish v3 domain Database: MySQL 26 Chương 3. J2ME 3.1. Giới Thiệu Tất cả đều bắt đầu từ phiên bản chuẩn của Java (J2SE) với câu châm ngơn nổi tiếng “Write once, run anywhere”. Ý tưởng này của Java là phát triển một ngơn ngữ cho phép bạn viết mã chỉ một lần, sau đĩ cĩ thể chạy trên bất kỳ nền tảng nào hỗ trợ máy ảo Java (JVM) mà khơng cần phải viết lại mã mới. Hai năm sau khi giới thiệu Java, một phiên bản mới của Java đã ra đời với tên gọi là Java 2 Enterprise Edition cung cấp sự hỗ trợ cho quy mơ hệ thống ứng dụng lớn, những ứng dụng phục vụ cho các xí nghiệp. Và thêm vào gần đây duy nhất trong gia đình họ Java là phiên bản nhỏ gọn (micro), hướng đến lập trình trên những thiết bị thơng tin gia dụng từ Internet – cho đến các máy TV, máy chụp ảnh, điện thoại di động, PocketPC… 3.2. Những phiên bản Java Chúng ta bắt đầu với một tĩm lượt lướt nhanh qua những nền tảng Java cĩ sẵn hiện thời:  Phiên bản chuẩn (J2SE): Thiết kế chạy trên desktop và những máy tính kiểu trạm làm việc.  Phiên bản xí nghiệp (Enterprise Edition) (J2EE): Đưa thêm vào những hỗ trợ dành cho Servlets, JSP và XML. Phiên bản này được nhắm vào những ứng dụng trên nền Web server.  Phiên bản nhỏ gọn (Micro Edition hay J2ME): Thiết kế cho những thiết bị cĩ bộ nhớ cĩ hạn, cả về sức mạnh màn hình và tốc độ xử lý kém. Ghi chú: Tháng mười hai 1998, Sun giới thiệu tên mới “Java 2” thay thế cho phiên bản Java 1.2. Tên mới này được dùng để quy ước cho tất cả các phiên bản của Java: Phiên bản chuẩn (J2SE) và phiên bản nhỏ gọn (J2ME). Hinh 1.1 cho thấy các phiên bản Java. 27 Hình 3.1 3.3. Tại sao dùng J2ME? J2ME được nhắm vào những thiết bị khách hàng (consumer device) với sức mạnh xử lý và tài nguyên cĩ hạn. Cĩ rất nhiều thiết bị dạng này như là điện thoại di động, máy quay phim , chụp hình. Những thiết bị này khơng cĩ tùy chọn để tải xuống và cài đặt từ xa như PC. Phần mềm điều khiển được cài sẵn trong quá trình sản xuất và bị áp đặt bởi nhà sản xuất. Với sự ra đời của J2ME, những thiết bị này khơng cịn tĩnh như xưa nữa , chúng hồn tồn cĩ thể được người dùng tự lập trình để thêm vào những tính năng mới. Khơng giống như bộ duyệt browser của PC cần tải xuống Java applets, để thực thi ứng dụng Java, J2ME cài trên thiết bị đã sẵn cĩ tùy chọn để duyệt, tải xuống và cài đặt cũng như thực thi những ứng dụng Java. Một nền tảng Java dùng chung cho mọi loại thiết bị là khơng thích hợp. Để hiểu rõ hơn J2ME phù hợp như thế nào khi áp dụng cho một phạm vi rộng các thiết bị nhúng ngày nay, chúng ta cần hiểu qua hai khái niệm mới, đĩ là khái niệm cấu hình (config) và thơng tin mơ tả (profile). 3.3.1. Configurations (Cấu hình) Để hỗ trợ phạm vi rộng lớn các sản phẩm phù hợp với nền J2ME, Sun đưa ra khái niệm cấu hình (Configuration). Một cấu hình định nghĩa một nền tảng Java dùng chung cho một số lớn các thiết bị cùng loại. Cấu hình gần như tương đương với hệ máy ảo Java (JVM). Cấu hình định 28 nghĩa những đặc tính ngơn ngữ Java và những thư viện Java lõi của JVM dành cho cấu hình đặc biệt đĩ. Những đặc tính dành cho một cấu hình áp dụng chủ yếu cho bộ nhớ, độ phân giải màn hình, giao thức kết nối mạng,và sức mạnh xử lý sẵn cĩ trên thiết bị. Các trả lời của Sun về J2ME (FAQ) như sau: “Cơng nghệ J2ME thiết kế dựa trên hai tâm điểm chính – dựa trên thiết bị mà bạn đang giữ trong tay và thiết bị mà bạn cĩ thể cắm nĩ vào sử dụng chung với nguồn điện hay thiết bị khác”. Những đặc trưng tiêu biểu sau đây của các thiết bị rơi vào định nghĩa cấu hình Configuration gồm cĩ: 3.3.1.1. Cấu hình dành cho thiết bị được kết nối (CDC – Connected Device Configuration). 512 kilobytes (tối thiểu) bộ nhớ để chạy Java. 256 kilobytes (tối thiểu) dành cho phân bổ bộ nhớ thực thi chương trình. Kết nối mạng, băng thơng (bandwidth) rộng và thường trực. 3.3.1.2. Cấu hình thiết bị được nối cĩ giới hạn (CLDC – Connected, Limited Device Configuration). 128 kilobytes (tối thiểu) bộ nhớ để chạy Java. 32 kilobytes (tối thiểu) dành cho phân bổ bộ nhớ thực thi chương trình. Hạn chế về giao diện người dùng. Nguồn năng lượng thấp, chẳng hạn như là nguồn pin. Kết nối mạng thường là khơng dây (wireless) với băng thơng và khả năng truy cập internet thấp. 3.3.2. Profile Định nghĩa về Configuration cho các thiết bị như trên là tương đối phù hợp cho hầu hết mọi thiết bị. Ví dụ các thiết bị di động, PDA đều cĩ thể xếp vào phân loại CLDC. Tuy nhiên, giữa điện thoại di động và PDA vã cĩ thiết bị với nhiều khả năng xử lý hơn cái kia. Chẳng hạn, kích thước màn hình đi động thường nhỏ hơn PDA. Nhằm mơ tả những khả năng khác biêt này và cũng để cung cấp nhiều tính linh hoạt hơn khi cơng nghệ thay đổi, Sun giới thiệu khái niệm Profile dành cho nền J2ME. Một Profile là định nghĩa mở rộng thêm cho một phân loại cấu hình Configuration. Profile cung cấp những thư viện cho phép người phát triển dùng để viết những ứng dụng chạy trên một kiểu thiết bị đặc biệt. 29 Ví dụ, Profile dành cho thiết bị thơng tin di động MIDP (Mobile Information Device Profile) định nghĩa tập những hàm API cho phép xử lý những thành phần giao diện người dùng nhập liệu trên thiết bị điện thoại di động, cách xử lý sự kiện, nơi chứa dữ liệu, giao thức kết nối mạng, đối tượng định giờ, quản lý những hạn chế về kích thước màn ảnh và bộ nhớ đặc thù của thiết bị di động. 3.4. Cấu hình CONFIGURATION và PROFILE được phát triển như thế nào? Sun định nghĩa: cấu hình Configuration và Profile được định nghĩa theo chuẩn cơng nghiệp mở bởi những nhĩm cơng ty và cộng đồng phát triển ứng dụng Java. Bằng cách này ngành cơng nghiệp cĩ thể quyết định những thành phần nào cần thiết để cung cấp một giải pháp hiệu quả hướng đến lĩnh vực cơng nghiệp của họ. 3.4.1. Máy ảo Java (JVM – Java Virtual Machines) Như bạn đã biết, cơ chế thực thi đằng sau bất kỳ ứng dụng Java nào (applet, servlet…) là JVM. Khi bạn biên dịch mã nguồn Java thành một lớp (file .class) và đặt chúng trong một file lưu trữ .JAR của Java, máy ảo JVM sẽ biên dịch file .class thành mã thực thi điều khiển bởi JVM. Các mã trong file .class gọi là mã byte code. JVM cũng chịu trách nhiệm cung cấp cơ chế an tồn, cấp phát và giải phĩng bộ nhớ cũng như quản lý những tiến trình, tiểu trình (thread) thực hiện bên trong. Nĩ chính là yếu tố làm lên chương trình Java. Đối với cấu hình dạng CLDC, Sun cài đặt một phiên bản thu nhỏ hơn dành cho JVM gọi là K Virtual Machine gọi tắt là KVM. Máy ảo KVM được thiết kế để điều khiển và chạy trên những thiết bị cĩ nguồn tài nguyên hạn chế. Rõ ràng là KVM khơng hồn tồn giống với JVM “truyền thống” của Java, máy ảo KVM: Thực thể chỉ yêu cầu 40 đến 80 kilobyte cho bộ nhớ thực thi. Chỉ cĩ thể cấp phát 20 đến 40 kilobyte bộ nhớ động. Chỉ cĩ thể chạy trên những bộ sử lys16 bít tốc độ 25 MHz. Cài đặt của KVM tuân theo những nguyên tắc đặc tả của CLDC. 3.4.2. KVM và CLDC liên quan như thế nào? Theo tài liệu của Sun: “CLDC là đặc tả cho một lớp máy ảo cĩ thể chạy trên các thiết bị dùng CLDC hỗ trợ profile”. Thực tế, CLDC mang những yêu cầu thỏa mãn những tính chất của một máy ảo. KVM là một bản cài đặt thỏa mãn những yêu cầu CLDC. Tổng quan về tồn cảnh và kiến trúc: 30 Kiến trúc chung: Bắt đầu với hệ điều hành chủ (OS) làm cơ sở tiếp theo là máy ảo (VM). VM sẽ thuộc 2 dạng: Đối với những hệ thống tuân theo đặc tả CDC thì đây sẽ là một máy ảo Java “truyền thống” cĩ nghĩa là như Java 2 phiên bản chuẩn (Java 2 Standard Edition). Đối với những hệ thống tuân theo chuẩn mơ tả CLDC, đây sẽ là loại máy ảo KVM theo yêu cầu bởi CLDC. Các thư viện lõi CLDC và CDC là phần tiếp theo trong lớp ứng dụng. Profile nằm ở lớp cao nhất và được thiết kế để cung cấp các cơng cụ đặc thù cho chủng loại thiết bị. Hình 3.2 3.5. Tính tương thích giữa những phiên bản Java Trong phần đầu chúng ta đã nghe nĩi đến châm ngơn của java “Write once, run anywhere”. Và cũng đã biết qua khái niệm Configuration và Profile, KVM. Liệu châm ngơn trên cịn đúng cho tất cả máy ảo Java? Câu trả lời là cịn tùy thuộc vào một số điều kiệm đi cùng. 31 3.5.1. Ứng dụng J2SE sẽ tiếp tục chạy trên mơi trường J2ME? J2ME là một phiên bản thu nhỏ về cơ bản từ phiên bản J2SE. Rất nhiều thành phần đã được loại bỏ để giữ cho nền tảng J2ME nhỏ và hiệu quả. Một ví dụ điển hình là thư viện AWT (Abstract Window ToolKit) đã thay đổi để cĩ khả năng hoạt động trên nhiều thiết bị - do nhiều thiết bị di động khơng cĩ những khả năng để cung cấp những thành phần giao diện người dùng tiên tiến như cửa sổ gối chồng lên nhau hay những thực đơn dạng thả xuống. Nếu bạn viết ứng dụng trên nền J2SE nhưng chỉ sử dụng những lớp cĩ sẵn trong J2ME Configuration thì ứng dụng của bạn cĩ thể chạy trên cả hai nền tảng. Nên nhớ, những ứng dụng như vậy sẽ bị ràng buộc với khả năng sử dụng giao diện người dùng thấp, theo như mơi trường J2ME. J2SE sử dụng một tập API khác hồn tồn J2ME để điều khiển giao diện màn hình. 3.5.2. Những ứng dụng J2ME vẫn chạy trên J2SE? Cùng một quy tắc như trên, nếu bạn hạn chế mã bạn chỉ sử dụng những lớp thư viện chung trên cả hai nền tảng, câu trả lời là vẫn chạy được. Tuy nhiên, phần lớn phần mềm bạn viết cho một thiết bị chạy J2ME sẽ yêu cầu giao diện và cách điều khiển sự kiện đặc thù. Như vậy, bạn sẽ gặp rất nhiều hạn chế khi muốn viết kiểu chương trình thích hợp cho cả hai nền tảng. 3.6. Kết chương Sun tạo ra Java 2 phiên bản Micro cho phép phát triển những ứng dụng Java cho thiết bị cĩ sức mạnh xử lý thấp và dung lượng bộ nhớ nhỏ hơn so với các ứng dụng trên nền tảng desktop truyền thống. Những sản phầm sử dụng J2ME cĩ thể bao gồm những thiết bị như mobile, PDAs, pager, máy chơi games, những hệ thống định vị, dẫn đường… J2ME được chia thành hai phạm trù rộng mà chúng ta đã biết và được gọi là Configuration. CDC là một tập hợp API dùng cho những thiết bị hạn chế về sức mạnh xử lý, màn hình và bộ nhớ như mobile, PDAs, Pocket PC… Cấu hình Configuration gần gũi với máy ảo Java. Với loại CDC, máy ảo Java hồn tồn tương thích với Java 2 phiên bản chuẩn. Configuration KVM là máy ảo dùng phát triển cho CLDC thay vì JVM. Trên cùng của lớp Configuration là Profile của thiết bị. Ở đây bạn sẽ tìm thấy các tập API dùng cho thiết kế giao diện người dùng, hỗ trợ nối mạng và lưu trữ. 32 Chương 4. Web service 4.1. Định nghĩa Một Web service được định nghĩa là một tập các phương thức cĩ thể được định vị thơng qua địa chỉ URL, các phương thức này được cơng bố trên hệ thống mạng và được dùng như những khối cơ bản để xây dựng một ứng dụng phân tán. Nĩi một cách đơn giản hơn, web service là tập hợp các phương thức cĩ thể được các ứng dụng khác triệu gọi từ xa (RPC- Remote Procedure Call) để hình thành nên một hệ ứng dụng phân tán. 4.2. Thành phần cơ bản của Web service Các thành phần cơ bản nhất của web service bao gồm HTTP, XML và SOAP (Simple Object Access Protocol). Việc phát triển những kỹ thuật này được điều hành bởi tổ chức W3C (World Wide Web Consortium). Chúng ta sẽ đề cập đến những kỹ thuật này ở những phần sau. 4.3. Hoạt động của Web service Hình 4.1: Hoạt động của Web Service Một ứng dụng web service thường gồm 2 phần: client và server. Client và server sẽ giao tiếp với nhau theo giao thức HTTP: Ứng dụng client gửi những lời gọi hàm đến server thơng qua các gĩi tin HTTP request và kế t quả thực thi hàm sẽ được server hồi đáp thơng qua các gĩi tin HTTP response. 33 4.3.1. SOAP Các thơng điệp sẽ được định dạng theo chuẩn giao thức SOAP (Simple Object Access Protocol). Đây thực chất cũng chỉ là một ngơn ngữ được định nghĩa bên trên ngơn ngữ XML cĩ sẵn. 4.3.2. WSDL (Web Service Definition Language) Đây là file XML chứa các định nghĩa về các hàm trong Web service tương ứng. Các nhà phát triển ứng dụng sẽ phải dựa vào nội dung file này để biết Web service hỗ trợ những hàm này và nhận những tham số tương ứng, kết quả trả về như thế nào. Nếu chúng ta phát triển Web service trong mơi trường J2ME thì khơng nhất thiết phải hiểu rõ cấu trúc về file WSDL, vì trong bộ cơng cụ Wireless Toolkit của Sun đã cung cấp sẵn cơng cụ Stub Generator. Chức năng của bộ cơng cụ này là đọc file WSDL và phát sinh thành những lớp java tương ứng cho nhà phát triển ứng dụng. 4.3.3. UDDI(Universal Description, Discovery, and Integration) Đây là cơng cụ giúp cho những nhà phát triển Web Service cơng bố những thơng tin về web service của mình cho cộng đồng các nhà phát triển ứng dụng. Người dùng sẽ dựa vào những thơng tin này để sử dụng web service trong ứng dụng riêng của mình tạo thành một hệ ứng dụng phân tán. Mối quan hệ giữa các thành phần SOAP,WSDL,UDDI cĩ thể được mơ tả như sau: Một ứng dụng web service client cần sử dụng một web service được đặt tại một nơi nào đĩ trên hệ thống mạng. Trước tiên, client sẽ truy vấn đến các mẫu tin UDDI, cĩ thể theo tên, loại hay một thơng tin riêng biệt nào đĩ. Khi đã xác định được web service cần tìm, client cĩ thể lấy thơng tin về địa chỉ của tài liệu WSDL của web service này dựa trên mẫu tin UDDI. Tài liệu WSDL sẽ mơ tả cách thức liên lạc với web service, định dạng của gĩi tin truy vấn và phản hồi theo cũng được mơ tả bằng XML schema. Dựa vào những thơng tin này client cĩ thể tạo những gĩi tin SOAP tương ứng để liên lạc với server. Ứng dụng web service cĩ thể được cài đặt ở những mức độ cao hơn như những mơ hình sau: 34 Hình 4.2: Mơ hình một client truy suất đến nhiều web services cùng một lúc Hình 4.3: Một web service cĩ thể triệu tập đến các web services khác 35 4.5. Các thành phần chính của Web Service Web service dựa vào khá nhiều cơng nghệ bên dưới như HTTP, XML, SOAP… Mỗi cơng nghệ nêu trên đều cĩ phạm vi ứng dụng khá sâu rộng và địi hỏi nhiều thời gian tìm hiểu cũng như trình bày. Luận văn khơng cĩ tham vọng trình bày cặn kẽ về tất cả các cơng nghệ trên mà chỉ xin giới thiệu những nét cơ bản và sơ lược về các cơng nghệ chính. Việc trình bày này chỉ nhằm mục đích cung cấp cho người đọc cái nhìn khái quát hơn về web service, tuy nhiên quá trình phát triển ứng dụng web service thơng thường khơng địi hỏi kiến thức sâu về lãnh vực này vì đã cĩ rất nhiều cơng cụ hỗ trợ và lập trình viên đã được “che” đi những cơng việc phức tạp bên dưới. 4.5.1. SOAP (Simple Object Access Protocol) SOAP là một giao thức đơn giản nhằm mục đích trao đổi thơng tin trong mơi trường ứng dụng phân tán. SOAP dựa trên nền cơng nghệ XML và bao gồm 2 thành phần: Một “bì thư” (envelope) để quản lý các thơng tin mở rộng và mang tính điều khiển. Một chuẩn mã hĩa quy định cách thể hiện thơng tin trong envelope. SOAP cĩ thể được sử dụng kết hợp với các giao thức chuẩn khác như SMTP, HTTP/HTTPS, FTP… Tuy nhiên hiện nay chỉ mới cĩ HTTP/HTTPS được xem như giao thức chuẩn để trao đổi gĩi tin SOAP. Việc sử dụng SOAP như một giao thức trao đổi dữ liệu chuẩn khiến web service cĩ khả năng hoạt động trên nhiều mơi trường lập trình khác nhau như Java, .NET,… 4.6. WSDL (Web Service Definition Language) Khi chúng ta đã xây dựng hồn thành web service cần phải cung cấp tài liệu mơ tả để các nhà phát triển client cĩ thể sử dụng được web service trên. Tài liệu mơ tả web service cần mơ tả được vị trí web service, các hàm nĩ cung cấp, tham số kèm theo… Tài liệu WSDL là một tài liệu thỏa mãn các nhu cầu trên. WSDL (Web Service Definition Language) là một ngơn ngữ dựa trên cú pháp XML dùng để định nghĩa một web service. Nĩi cách khác, một file WSDL như một người trung gian đứng giữa web service và ứng dụng web service client. Trong tài liệu WSDL, chúng ta sẽ định nghĩa các phương thức được web service hỗ trợ, các kiểu dữ liệu được xử dụng trong các phương thức cùng các thơng điệp được 36 trao đổi giữa client và server ứng với mỗi phương thức. Chúng ta chỉ phải định nghĩa các kiểu dữ liệu phức tạp như mảng, các lớp được khai báo thêm trong chương trình, mảng các lớp … cịn các kiểu dữ liệu cơ bản như int, string, float …đã được hỗ trợ sẵn. Sau đĩ, chúng ta gộp chung các định nghĩa này kết hợp với các giao thức mạng bên dưới để hình thành một end-point (tạm dịch là một đầu cuối). Hình 4.4 Web Service Endpoint Một endpoint interface (gọi tắt là một enpoint) gồm cĩ nhiều ports, mỗi port quy định một cách liên lạc với web service khác nhau ứng với mỗi giao thức bên dưới khác nhau. Sự kết hợp của web service với một giao thức mạng như thế được gọi là một binding, như trong hình 2.4 chúng ta thấy cĩ 3 binding khác nhau. Port 1 sử dụng SOAP/HTTP binding, Port 2 sử dụng SOAP/HTTPS binding, Port 3 sử dụng các dạng binding khác. Như vậy ứng với web service trên, ta cĩ đến 3 phương tiện khác nhau để triệu gọi các hàm. Các hình thức binding thơng dụng nhất hiện nay vẫn là SOAP/HTTP POST và SOAP/HTTPS (hỗ trợ bảo mật thơng qua SSL). Việc phát sinh file WSDL sẽ được tự động thực hiện bởi các bộ cơng cụ (như Netbeans 6.8) do đĩ chúng ta khơng nhất thiết phải hiểu rõ cấu trúc file WSDL. Tuy nhiên, nếu hiểu cấu trúc file WSDL sẽ cung cấp cho chúng ta thêm nhiều tùy biến cũng như khả năng sửa lỗi (debug) tốt hơn. 37 4.6.1. Cấu trúc file WSDL Một tài liệu WSDL thực chất chỉ là một danh sách các định nghĩa. Trong một file WSDL, phần tử gốc được đặt tên là "definitions". Phần tử này chứa năm phần tử con chính để định nghĩa web service. Thứ tự xuất hiện của các phần tử con này: Phần tử "types": định nghĩa các kiểu dữ liệu dùng để trao đổi giữa client và server (chỉ định nghĩa các kiểu dữ liệu phức tạp như structure, class…). Phần tử "message": định nghĩa các thơng điệp được trao đổi. Phần tử "portType": định nghĩa một tập các chức năng web service hỗ trợ và thơng điệp tương ứng đối với mỗi chức năng đĩ. Phần tử "binding": Sau khi đã định nghĩa các port, ta cần chỉ rõ ràng buộc giữa các ports này và các giao thức tầng dưới. Phần tử binding sẽ đảm nhiệm chức năng này (sẽ được đề cập kỹ hơn ở phần sau). Phần tử "service": Cĩ tác dụng gom các ports đã định nghĩa thành từng nhĩm. 38 Chương 5. Kết luận 5.1. Kết luận Sau hơn 5 tháng nghiên cứu dưới sự hướng dẫn của ThS Nguyễn Việt Anh và sự giúp đỡ nhiệt tình của các bạn trong nhĩm khĩa luận. Bước đầu khĩa luận đã thu được một số kết quả nhất định. 5.1.1. Các kết quả đạt được Tìm hiểu về J2ME, Webservice. Xây dựng thành cơng chương trình “Hướng dẫn du lịch qua mobile theo ngữ cảnh”. Ứng dụng demo gồm 2 địa danh đĩ là “Văn miếu Quốc Tử Giám” và “Lăng tẩm Huế”, bước đầu chương trình xử lý sự chi tiết của nội dung theo độ sâu là 5 mức. Ngữ cảnh của ứng dụng là thời gian cĩ thể ghé thăm, font, profile. Người dùng hồn tồn cĩ thể cài đặt ứng dụng khi điện thoại của họ hỗ trợ kết nối GPRS. 5.1.2. Các vấn đề chưa giải quyết được Chức năng người dùng tự bổ sung dữ liệu cho chương trình chưa hồn thành. Chưa giải quyết được việc tự động thay đổi lộ trình do tác động bởi một ngoại cảnh nào đĩ trong quá trình du lịch. Giải quyết sự cố mất kết nối với Webservice chưa hồn thành. 5.2. Hướng phát triển tương lai Chương trình mới chỉ thực hiện được những chức năng cơ bản, và ngữ cảnh đưa vào chương trình chưa nhiều và giao diện cũng chưa được đẹp lắm. Trong thời gian tới hướng phát triển của em là: Hồn thiện giao diện để giúp người sử dụng thao tác dễ dàng hơn. Đưa thêm nhiều ngữ cảnh vào hơn để chương trình thêm mềm dẻo mới người dùng. Mở rộng cơ sở dữ liệu. Với sự phát triển của 3G, việc đưa video vào ứng dụng là hướng phát triển tốt vì vậy VideoStreaming là cách giải quyết tốt nhất. 39 Tài liệu tham khảo Tiếng việt: [1] Đặng Nguyễn Kim Anh, Đào Anh Tuấn. Nghiên cức Java Mobile và xây dựng ứng dụng minh họa. Đại học Khoa Học Tự Nhiên, 2005. [2] Phạm Tấn Liêm. Phát triển game di độg với J2ME, Nxb Giao Thơng Vận Tải, 2005. [3] Phương Lan, Trần Tiến Dũng. Java tập 3. Nền tảng của J2ME, tr15-22. English: [1] Bruce Eckel, Thinking in Java 3rd, Prentice Hall, New Jersey, 1998. Telecooperation Johannes Kepler University Linz, Austria, 2007. [2] Context-Aware Adaptation in a Mobile Tour Guide. Ronny Kramer, Marko Modsching, Joerg Schulze, Klaus ten Hagen. Department of Computer Science, University of Applied Sciences Zittau / Gưrlitz, Germany K.tenHagen@HS-ZiGr.de [3] David Chappell - Tyler Jewell, Java Web Services, O'Reilley, 2002. [4] Jason Lam. J2ME Game Development with MIDP2. [5] Kim Topey,Java Web Service in A Nutshell, O'Reilley, 2003. [6] Michael Juntao Yuan, Enterprise J2ME™: Developing Mobile Java Application, Prentice Hall PTR, 2003. [7] Roger Riggs, Programming Wireless Devices with the Java™ 2 Platform Micro Edition, Addision Wesley, 2003.