Mô hình phần mềm dịch vụ và ứng dụng cho điện thoại di động

Tổng quan dự án Mobile Access Các mục tiêu cụ thể của dự án: - Xây dựng hệ thống cho phép người dùng có thể mua các dịch vụ giống như họ đi mua sắm hàng hóa trên các trang web thương mại

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

VIỆN ĐÀO TẠO SAU ĐẠI HỌC

──────── * ───────

LUẬN VĂN THẠC SỸ Chuyên Ngành Xử Lý Thông Tin

Và Truyền Thông

ĐỀ TÀI:

DỤNG CHO ĐIỆN THOẠI DI ĐỘNG

Học viên : TRẦN TRUNG KIÊN

Lớp : XLTT&TT 2007-2009

Giáo viên hướng dẫn: TS.NGUYỄN HỒNG QUANG

Lời Cảm Ơn

Hoàn thành luận văn Thạc sỹ này, ngoài sự nỗ lực của cá nhân, tôi còn nhận được

sự giúp đỡ của rất nhiều thầy cô, gia đình, và bạn bè Để bày tỏ lòng biết ơn của mình, tôi xin được gửi lời cảm ơn sâu sắc tới Ban lãnh đạo Bộ môn Kỹ thuật Máy Tính, Ban lãnh đạo Viện Công nghệ Thông tin và Truyền Thông, Viện Đào tạo sau Đại học, Trường Đại học BKHN, đã tạo điều kiện cho tôi theo học và bảo vệ tốt nghiệp khóa học Thạc sỹ XLTT&TT

Tôi cũng xin được gửi lời cảm ơn chân thành và sâu sắc tới thầy hướng dẫn TS.Nguyễn Hồng Quang, TS.Nicolas Fournier –Orange Labs Các thầy đã đưa ra những định hướng chuyên môn, tạo điều kiện thuận lợi về môi trường làm việc trong suốt thời gian tôi thực tập và làm luận văn Sự tin tưởng, khích lệ của các thầy là nguồn động viên to lớn giúp tôi vượt qua mọi khó khăn

Tôi xin chân thành cảm ơn các thầy, cô ở Viện Cộng nghệ Thông tin và Truyền Thông, Đại học BKHN Các thầy, cô đã giảng dạy, cung cấp nguồn kiến thức tổng hợp để tôi có thể vững bức tiếp tục sự nghiệp của mình

Tôi xin trân trọng cảm ơn các đồng nghiệp ở Bộ môn Kỹ thuật Máy tính, các thầy, các anh, chị vừa là đồng nghiệp vừa là những người thầy, người bạn đã chia sẻ những kinh nghiệm, kiến thức, giúp đỡ tôi hoàn thành tốt mọi nhiệm vụ

Học viên: Trần Trung Kiên

M ục Lục

Chương 1 Giới Thiệu 6

1.1 Giới thiệu về dự án Mobile Access 6

1.1.1 Hệ thống các phòng thí nghiệm (Orange Labs 6

1.1.2 Dự án Mobile Access 7

1.2 Giới thiệu về mục tiêu của luận văn tốt nghiệp 8

Chương 2 Mô Hình Phần Mềm Dịch Vụ 10

2.1 Giới thiệu về Phần mềm dịch vụ (SaaS) 10

2.1.1 Phần mềm dịch vụ (SaaS) là gì ? 10

2.1.2 SaaS có phải là một giải pháp tiết kiệm chi phí và hiệu quả ? 10

2.1.3 Sự khác biệt giữa SaaS và mô hình nhà cung cấp dịch vụ ứng dụng (ASP) 11

2.2 Chuyển đổi từ phần mềm truyền thống sang mô hình phần mềm dịch vụ 11

2.2.1 Mô hình kinh doanh (Business Model) 12

2.2.2 Kiến trúc hệ thống (Application Architecture) 14

2.2.3 Phương thức hoạt động (Operational Structure) 21

Chương 3 J2ME Và LightWeight User Interface Toolkit 23

3.1 Cộng nghệ J2ME 23

3.1.1 Tổng quan về J2ME 23

3.1.2 Midlet 27

3.2 Lightweight User Interface Toolkit - LWUIT 40

3.2.1 Giới thiệu về Lightweight User Interface Toolkit – LWUIT 40

3.2.2 Các thành phần giao diện ( User Interface Component) 43

3.2.3 Các thành phần hỗ trợ ở mức thấp 46

Chương 4: Mobile Acces Và SaaSMobile Client 51

4.1 Kiến trúc hệ thống Mobile Access 51

4.1.1 Hoạt động của hệ thống Mobile Access 51

4.1.2 Kiến trúc hệ thống Mobile Access 55

4.2 Xây dựng ứng dụng SaaSMobile Client trên thiết bị di động 56

4.2.1 Giới thiệu SaaSMobile Client 56

4.2.2 Phân tích thiết kết SaaSMobile Client 57

4.2.1 Mô hình hóa yêu cầu bằng biểu đồ Ca sử dụng (Use case Diagram) 57

4.2.2 Kiến trúc thành phần của SaaSMobile Client 59

4.2.3 Biểu đồ gói tương ứng với kiến trúc 60

4.2.4 Biểu đồ tiến trình (Sequency Diagram) 61

4.2.5 Biểu đồ lớp 63

4.2.5.1 Biểu đồ các lớp chính của gói XMLParsing 63

4.2.6 Kết quả triển khai 68

Chương 5: Tích Hợp Orange APIs Vào Hệ Thống Mobile Access 72

5.1 Giới thiệu Orange APIs 72

5.2 Sử dụng Orange APIs 74

5.3 Tích hợp Orange API vào hệ thống Mobile Access 75

5.4 Kết quả triển khai 77

Chương 6: Kết Luận Và Hướng Phát Triển 80

6.1 Đánh giá kết quả đạt được 80

Tài Liệu Tham Khảo 83

1 Các tài liệu trích dẫn trong luận văn 83

2 Các tài liệu tham khảo thêm 83

Ph ụ Lục: Nhận xét của nơi thực tập tốt nghiệp 84

Danh mục các hình vẽ Hình 1 Hệ thống phòng thí nghiệm Orange Labs 7

Hình 2 Tổng quan dự án Mobile Access 8

Hình 3 Chuyển đổi sang mô hình phần mềm dịch vụ 12

Hình 4 So sánh tỷ lệ đầu tư các thành phần giứa phần mềm truyền thống và phần mềm dịch vụ 13

Hình 5 Mức độ hoàn thiện của phần mềm dịch vụ 15

Hình 6 Kiến trúc thành phần của mô hình phần mềm dịch vụ 17

Hình 7 Mô hình xác thực tập trung 19

Hình 8 Mô hình xác thực phi tập trung (Decentralized Authentication) 20

Hình 9 Minh họa cơ chế kiểm soát truy nhập (Access control) 21

Hình 10 Thêm lớp cho phương thức hoạt động mới 22

Hình 11 Kiến trúc các thành phần của J2ME 24

Hình 12 Vòng đời của Midlet 28

Hình 13 Trạng thái của Midlet theo các dãy sự kiện 28

Hình 14 Lớp Displayable trong Midlet 29

Hình 15 Các lớp con của lớp Screen 30

Hình 16 Hệ thống RMS 33

Hình 17 Minh họa quyền truy xuất RecordStore giữa các Midlet 34

Hình 18 Các luồng truy xuất vào ra 38

Hình 19 Kiến trúc LWUIT 41

Hình 20 Minh họa mô hình Model-View-Control 43

Hình 21 Các thành phần giao diện của LWUIT 43

Hình 22 Minh họa Form 44

Hình 23 Minh họa TabbedPane 45

Hình 24 Minh họa Calendar 45

Hình 25 Minh họa Button,TextArea,List,ComboBox 46

Hình 26 BorderLayout 47

Hình 27 BoxLayout 47

Hình 28 FlowLayout 48

Hình 29 Grid Layout 48

Hình 30 GroupLayout 49

Hình 31 Mô tả hoạt động của hệ thống 51

Hình 32 So sánh với mô hình cung cấp hàng hóa 52

Hình 33 Biểu đồ Use case của hệ thống Mobile Access 53

Hình 34 Biểu đồ Use Case của người dùng cuối 54

Hình 35 Kiến trúc thánh phần hệ thống Mobile Access 55

Hình 36 SaaSMobile Client: Mô tả hoạt động 57

Hình 37 Biểu đồ ca sử dụng SaaSMobileClient 58

Hình 38 Kiến trúc thành phần của SaaSMobile Client 59

Hình 39 Biểu đồ gói 60

Hình 40 Biểu đồ tiến trình Cập nhật các dịch vụ 61

Hình 41 Biểu đồ tiến trình: Khởi tạo dịch vụ 61

Hình 42 Biểu đồ tiến trình Sử dụng dịch vụ 62

Hình 43 Biểu đồ lớp gói XMLParsing 63

Hình 44 Biểu đồ lớp gói Connector 65

Hình 45 Biểu đồ lớp gói UI 66

Hình 46 Biểu đồ lớp của gói AppProcess 67

Hình 47 Biểu đồ lớp của gói User 68

Hình 48 Menu các dịch vụ 69

Hình 49 Dịch vụ Danh bạ 69

Hình 50 Dịch vụ SMS 70

Hình 51 Các dịch vụ khác 71

Hình 52 Minh họa sử dụng Orange API 75

Hình 53 Kiến trúc thành phần của Paserelle 76

Hình 54 Danh mục các ứng dụng sử dụng Personal APIs 77

Hình 55 Người dùng thực hiện xác thực đối với hệ thống 78

Hình 56 Thêm sự kiện vào lịch làm việc 78

Hình 57 Thêm danh bạ vào sổ địa chỉ 79

Hình 58 Upload File 79

Danh mục các bảng Bảng 1 Một số API của RMS 38

Bảng 2 Mô tả tác nhân trong use case của hệ thống Mobile Access 54

Bảng 3 Mô tả tác nhân 55

Bảng 4 Personal API 72

Bảng 5 Instant API 73

Bảng 6 Advanced API 74

C hương 1 Giới Thiệu

Trong chương đầu tiên, tôi xin giới thiệu ngắn gọn về phòng thí nghiệm BIZZ/CIL, nơi luận văn tốt nghiệp cao học này được thực hiện Đồng thời, trình bày về dự án nghiên cứu phát triển đã tham gia tại nơi thực tập và mục tiêu, nhiệm

vụ của luận văn tốt nghiệp

1.1 Giới thiệu về dự án Mobile Access

1.1.1 Hệ thống các phòng thí nghiệm (Orange Labs)

Tập đoàn Frace Telecom là một tập đoàn lớn, hoạt động ở nhiều quốc gia, cung cấp các dịch vụ về truyền thông và di động Các phòng thí nghiệm mang tên Orange Labs được thành lập để thực hiện các hoạt động nghiên cứu, phát triển (Rerearch and Development – R&D) Các phòng thí nghiệm này đóng vai trò quan trọng trong việc giúp France Telecom nghiên cứu và triển khai những công nghệ mới, đưa ra các dịch vụ tốt nhất cho khách hàng Các phòng thí nghiệm được tổ chức phân cấp, phân chia theo chức năng và được thành lập ở nhiều nơi trên nước Pháp và các nước khác bao gồm: Mỹ, Anh, Nhật, Trung Quốc

NESS (Network Echanced Services

Hình 1 Hệ thống phòng thí nghiệm Orange Labs

Mỗi phòng thí nghiệm lại được chia thành nhiều đơn vị nhỏ hơn (Department), CIL/BIZZ là một đơn vị thuộc phòng thí nghiệm CIL (Center d’intégration logicielle), nhiệm vụ của CIL/BIZZ là nghiên cứu và phát triển mang tính ứng dụng trực tiếp

CIL/BIZZ tại Lannion tham gia nghiên cứu và phát triển những dự án liên quan tới tích hợp hệ thống phần cứng và phần mềm, đưa ra những kiến trúc mới trong việc cung cấp dịch vụ khách hàng

1.1.2 Dự án Mobile Access

Mobile Access là dự án nhằm đưa ra phương thức mới trong việc cung cấp các dịch vụ giá trị gia tăng cho mạng di động, cụ thể là mạng di động của tập đoàn France Telecom Ở các nước phát triển, mặc dù hạ tầng mạng viễn thông đã phát triển và hầu hết khách hàng của các mạng di động đều có thể truy cập internet với tốc độ cao Tuy nhiên, do sự đa dạng của các loại điện thoại di động, các cách thức cung cấp dịch vụ cho khách hàng hiện tại gặp rất nhiều khó khăn Theo cách phân phối dịch vụ hiện nay, mỗi khi khách hàng muốn sử dụng một tiện ích nào đó, họ thường phải tải và cài đặt các phần mềm tương ứng, mỗi loại điện thoại lại phải có một phiên bản riêng Đây là một trong những khó khăn đối với cả người dùng và nhà cung cấp dịch vụ

Hình 2 Tổng quan dự án Mobile Access

Các mục tiêu cụ thể của dự án:

- Xây dựng hệ thống cho phép người dùng có thể mua các dịch vụ giống như họ đi mua sắm hàng hóa trên các trang web thương mại điện tử

- Đưa ra những ứng dụng mới cho di động

- Tích hợp hệ thống Oragne APIs có sẵn vào hệ thống mới

1.2 Giới thiệu về mục tiêu của luận văn tốt nghiệp

Trong thời gian một vài năm gần đây, phần mềm dịch vụ (Sorftware as a service- SaaS) nổi lên như một mô hình phân phối phần mềm mới Theo dự đoán của Gartner [1], tới năm 2011, thị trường dành cho SaaS sẽ tăng 21% Với lý do đó, nhóm nghiên cứu đã quyết định kết hợp với salesforce – một trong những công ty hàng đầu cung cấp phần mềm dịch vụ (SaaS) để đưa ra mô hình cung cấp các dịch

vụ của tập đoàn Frace Telecom Mục tiêu của luận văn tốt nghiệp cao học cũng là một phần công việc của đề tài này, các mục tiêu của luận văn tốt nghiệp bao gồm:

- Tìm hiểu về mô hình phần mềm dịch vụ (SaaS)

- Sử dụng J2ME và LWUIT Framework để xây dựng phần mềm trên di

động cho phép người dùng sử dụng phần mềm dịch vụ mà France Telecom cung cấp

-Tìm hiều về Orange APIs và đưa ra kiến trúc để tích hợp vào hệ thống cung cấp phần mềm dịch vụ (SaaS)

Luận văn tốt nghiệp được bố trí thành các chương và bao gồm các nội dung như sau:

Chương 1: Giới thiệu chung về dự án Mobile Access và nhiệm vụ của luận văn

tốt nghiệp

Chương 2: Mô hình phần mềm dịch vụ (SaaS)

Chương 3: J2ME và LightWeight User Interface Toolkit (LWUIT)

Chương 4: Hệ thống Mobile Access và Xây dựng ứng dụng SaaSMobile Client Chương 5: Orange APIs và tích hợp vào hệ thống Mobile Access

Chương 6: Kết luận và hướng phát triển

Chương 2 Mô Hình Phần Mềm Dịch Vụ

Phần mềm dịch vụ (Software as a service –SaaS) là một trong những xu thế mới của các nhà cung cấp giải pháp công nghệ thông tin Theo trào lưu “ Internet thay đổi mọi thứ”, một số nhà phân tích cho rằng phần mềm dịch vụ sẽ dần thay thế các phần mềm truyền thống được phân phối và cài đặt trên máy của người sử dụng Nghiên cứu, tìm hiều về Phần mềm dịch vụ chính là một phần công việc của luận văn này

2.1.1 Phần mềm dịch vụ (SaaS) là gì ?

Phần mềm dịch vụ (SaaS)[2] là một mô hình triển khai, phân phối phần mềm, trong đó các ứng dụng được phân phối và quản lý như là các dịch vụ Trong mô hình này, phần mềm được phát triển, hoạt động trên nền tảng web và được quản lý bởi nhà cung cấp, cho phép người dùng truy cập từ xa Không giống như phần mềm đóng gói truyền thống người sử dụng thường phải cài đặt vào hệ thống máy tính hoặc các máy chủ của họ, nhà cung cấp phần mềm dịch vụ SaaS làm chủ sở hữu phần mềm và chạy phần mềm đó trên hệ thống máy tính của họ Khách hàng không sở hữu phần mềm nhưng họ có thể thuê nó để tiết kiệm chi phí, thường thì khách hàng sẽ trả phí thuê theo tháng

2.1.2 SaaS có phải là một giải pháp tiết kiệm chi phí và hiệu quả ?

Triển khai các phần mềm dịch vụ SaaS rẻ hơn (hay ít nhất là lúc khởi đầu) và đơn giản hơn việc triển khai các sản phẩm phần mềm đóng gói truyền thống Khách hàng của phần mềm dịch vụ SaaS thường thanh toán một khoản phí được rát mỏng hàng tháng cho mỗi người dùng phần mềm Các công ty sẽ không phải mất nhiều chi phí thuê tư vấn, đầu từ cơ sở hạn tầng, và dễ dàng ước lượng được các chi phí cho việc sử dụng phần mềm dịch vụ Việc nâng cấp sản phẩm SaaS cũng dễ dàng hơn, hay nói chính xác thì việc nâng cấp được thực hiện đồng bộ và ở phía nhà cung cấp Tuy vậy, tính hiệu quả của việc sử dụng phần mềm dịch vụ so vơi phần mềm đóng gói truyền thống sẽ tùy thuộc vào nhiều yếu tố và đặc điểm nhu cầu

của riêng các công ty Điều này đôi khi được ví như hiệu quả của việc bạn mua một chiếc ôtô tự lái so với bạn sử dụng dịch vụ xe tắc xi

2.1.3 Sự khác biệt giữa SaaS và mô hình nhà cung cấp dịch vụ ứng dụng (ASP)

Khi mô hình nhà cung cấp dịch vụ ứng dụng (ASP) phát triển rầm rộ trong nhưng thời gian trước đây, họ đã đưa ra những tính năng tương tự như các nhà cung cấp sản phẩm phần mềm dịch vụ SaaS đưa ra hiện nay: sản phẩm cho thuê và được truy cập qua Internet Vấn đề mà các mô hình nhà cung cấp dịch vụ ứng dụng gặp phải đó chính là việc họ nỗ lực đáp ứng nhu cầu cụ thể khác nhau của từng khách hàng Do đó, các nhà cung cấp sản phẩm theo mô hình ASP đã mất nhiều chi phí

để đảm bảo đủ cơ sợ hạ tầng và triển khai các ứng dụng phục vụ khách hàng Các nhà cung cấp phần mềm dịch vụ SaaS thành công hiện nay như Salesforce[3] , LeanLogistics và Ketera đã giải quyết triệt để được các vấn đề về khả năng mở rộng và độ tin cậy của hệ thống phần, việc làm này đã khiến cho sản phẩm theo

mô hình SaaS tỏ ra ưu thế hơn so với mô hình ASP Thay vì cố gắng đáp ứng tất

cả các yêu cầu cụ thể của tất cả người dùng thì họ đưa ra các giải pháp “một cho tất cả”, đây chính là cách tiếp cận dựa trên kiến trúc Multi-tenacy[4] (một chương trình dùng chung cho mọi khách hàng) Bất cứ tính năng hay chức năng nào mà các nhà cung cấp SaaS thêm vào phần mềm đều dựa trên những phản hồi của khách hàng nhằm cung cấp một phần mềm thích hợp nhất phục vụ cho số đông Nhờ đó, phía nhà cung cấp dịch vụ có thể cung cấp dịch vụ với chi phí thấp hơn,

và đảm bảo khách hàng luôn được sử dụng những phiên bản tốt nhất

mềm dịch vụ

Để chuyển đổi từ mô hình cung cấp phần mềm truyền thống sang cung cấp phần mềm dịch vụ, các nhà cung cấp phải thay đổi mô hình kinh doanh, kiến trúc ứng dụng , và cách thức hoạt động của hệ thống [5]:

Hình 3 Chuyển đổi sang mô hình phần mềm dịch vụ

2.2.1 Mô hình kinh doanh (Business Model)

Trong mô hình kinh doanh mới này, cách thức sở hữu phần mềm đã chuyển đổi từ việc mua phần mềm thành thuê phần mềm, cơ sở hạ tầng và đội ngũ kỹ thuật sẽ chỉ tập trung ở phía nhà cung cấp dịch vụ, giá thành sử dụng của phần mềm giảm,

và thị trường khách hàng cũng được mở rộng hơn

2.2.1.1 Thay đổi cách thức sở hữu phần mềm

Khi chuyển sang cung cấp phần mềm như là một dịch vụ, thay vì bán quyền sở hữu phần mềm cho khách hàng, nhà cung cấp phần mềm sẽ cho thuê các sản phẩm của họ Theo cách thức truyền thống, các phần mềm sẽ được đóng gói và cung cấp cho khách hàng Khách hàng sẽ cài đặt phần mềm lên hệ thống máy tính của họ Trong mô hình cung cấp phần mêm dịch vụ, khách hàng không phải chi tiền để mua toàn bộ phần mềm đóng gói, họ chỉ trả tiền khi họ sử dụng phần mềm của nhà cung cấp Phương thức thuê phần mềm này có thể tính theo nhiều cách: tính theo

số người dùng, tính theo thời gian sử dụng

2.2.1.2 Chuyển đổi hạ tầng, đội ngũ quản trị từ khách hàng sang nhà cung cấp dịch vụ

Trong mô hình truyền thống, để sử dụng các phần mềm, khách hàng phải đầu tư vào các mục sau:

-Phầm mềm: gồm các chương trình phần mềm mà khách hàng sử dụng -Phần cứng: gồm các thiết bị tạo nên cơ sở hạ tầng của hệ thống để vận hành các phần mềm

-Đội ngũ kỹ thuật, chuyên gia: gồm các kỹ thuật viên hoặc chuyên gia, nhóm người này sẽ đảm bảo cho hoạt động của hệ thống phần cứng và các phần mềm ứng dụng

Khi chuyển đổi sang mô hình cung cấp phần mềm dịch vụ, khách hàng có thể vẫn phải đầu tư để mua phần cứng, và thuê đội ngũ kỹ thuật, nhưng khi đó, hệ thống phần cứng sẽ đơn giản hơn rất nhiều và nhiệm vụ của đội ngũ kỹ thuật cũng được giảm thiểu đáng kể Dưới đây là bảng minh họa về tỷ lệ chi phí đầu tư của khách hàng khi sử dụng phần mềm truyền thống và phần mềm dịch vụ

Hình 4 So sánh tỷ lệ đầu tư các thành phần giứa phần mềm truyền thống và phần mềm

dịch vụ

2.2.1.3 Giảm giá thành của phần mềm dịch vụ

Thông qua việc cung cấp một giải pháp cho mọi khách hàng, nhà cung cấp có thể giảm giá thành của phần mềm dịch vụ, trong khi vẫn đảm bảo khách hàng của họ đang được sử dụng những sản phẩm tốt nhất Lấy ví dụ, một nhà cung cấp phần mềm dịch vụ có 50 công ty sử dụng dịch vụ của họ Phía nhà cung cấp sử dụng 5 máy chủ và một đội ngũ kỹ thuật viên để vận hành phần mềm Nếu như 50 công ty

nói trên sử dụng phần mềm truyền thống, mỗi công ty phải đầu tư máy chủ và thuê đội ngũ kỹ thuật riêng để vận hành hệ thống của họ, như vậy chi phí cao hơn rất nhiều so với việc sử dụng phần mềm dịch vụ

2.2.1.4 Thay đổi về đối tượng khách hàng

Bằng cách cung cấp phần mềm dịch vụ, các nhà cung cấp sẽ có thêm một lượng lớn các khách hàng là các công ty nhỏ lẻ mà trước đây vốn không thể đủ kinh phí

để mua các phần mềm truyền thống Trong mô hình sử dụng phần mềm truyền thống, một công ty nhỏ và có vốn đầu tư ít không thể đủ kinh phí để mua một phần mềm thật tốt phục vụ cho công việc của họ bởi giá thành của những phần mềm có chất lượng cao là rất đắt đỏ Tuy nhiên, khi chuyển sang sử dụng phần mềm dịch

vụ, công ty này hoàn toàn có thể sử dụng các phần mềm chất lượng cao với chi phí thấp hơn

2.2.2 Kiến trúc hệ thống (Application Architecture)

Để có thể cung cấp được phần mềm dịch vụ, các nhà sản xuất phần mềm phải thực hiện hàng loạt thay đổi trong kiến trúc của phần mềm Trong số những thay đổi

đó, ba tiêu chí sau đây đóng vai trò cốt lõi:

-Tính linh động (scalable)

-Tối ưu hóa multi-tenant (Multi-tenant-efficient)

-Có khả năng tùy biến cao (Configurable)

Tính linh động của một ứng dụng thể hiện ở việc chất lượng của ứng dụng đó không thay đổi khi qui mô của ứng dụng thay đổi

Multi-tenancy là một kiểu kiến trúc phần mềm, trong đó chỉ một thực thể (instance) của phần mềm được chạy trên hệ thống máy chủ và phục vụ cho nhiều khách hàng (tenant – customer company) Việc thiết kế phần mềm theo kiến trúc Multi-tenancy một cách hiệu quả là một trong những yêu cầu then chốt dẫn tới sự thành công của nhà cung cấp dịch vụ Đây cũng chính là điểm khác biệt rõ ràng nhất của mô hình phần mềm dịch vụ so với mô hình nhà cung cấp dịch vụ ứng dụng (Application service provider- ASP ) truyền thống, mô hình ASP đã tỏ rõ những nhược điểm và không thành công trong quá khứ

Một trong những thay đổi quan trọng trong kiến trúc của phần mềm dịch vụ là khả năng tùy biến cao Thay vì phải sửa đổi ứng dụng cho phù hợp với nhu cầu của từng khách hàng, phần mềm dịch vụ phải cung cấp được khả năng tùy biến cao thông qua việc thay đổi các cấu hình Khách hàng sẽ sử dụng các metadata để cấu hình phần mềm theo yêu cầu của họ

Một cách tổng quát, chúng ta có thể phân chia mức độ hoàn thiện của phần mềm dịch vụ theo các mức sau:

Hình 5 Mức độ hoàn thiện của phần mềm dịch vụ

2.2.2.1 Mức độ thứ nhất

Đây là mô hình giống như mô hình nhà cung cấp ứng dụng dịch vụ truyền thống

riêng, và các phiên bản này độc lập với nhau Về cơ bản, nhà cung cấp có thể chuyển đổi các ứng dụng Client-Server truyền thống sang mô hình phần mềm dịch

vụ (SaaS) ở mức độ này mà không phải thay đổi lại kiến trúc phần mềm Tuy vậy, nếu chỉ triển khai ở mức độ này thì nhà cung cấp phần mềm dịch vụ (SaaS) sẽ không đạt được những tối ưu về giá thành sản phẩm, và gặp nhiều khó khăn trong việc nâng cấp hệ thống

2.2.2.2 Mức độ thứ hai

Ở mức độ này, nhà cung cấp dùng chung một phiên bản phần mềm cho tất cả khách hàng (Hình 5.2), phiên bản này cung cấp khả năng để khách hàng có thể cấu hình thay đổi cách thức hoạt động và tương tác của phần mềm đối với họ Mặc

dù tất cả chương trình phục vụ cho khách hàng là như nhau, nhưng các chương trình này là hoàn toàn độc lập với nhau

Việc chuyển đổi từ mô hình phần mềm truyền thống sang mô hình phần mềm dịch

vụ (SaaS) ở mức độ này yêu cầu nhà cung cấp phải có những thay đổi đáng kể trong kiến trúc phần mềm So với mức độ thức nhất, việc nâng cấp hệ thống được thực hiện dễ dàng hơn vì tất cả các khách hàng đều dùng chung một phiên bản Tuy nhiên, do mỗi khách hàng có một chương trình riêng nên nhà cũng cấp vẫn sẽ gặp khó khăn trong việc đảm bảo cơ sở hạ tầng để đồng thời thực thi các chương trình riêng đó Mỗi khi có thêm một khách hàng, nhà cung cấp phải thực hiện chạy một chương trình riêng phục vụ khách hàng đó, và điều này đồng nghĩa với việc chi phí cho phần cứng, hệ thống lưu trữ dữ liệu tăng lên, dẫn tới giá thành của phần mềm dịch vụ chưa được giảm nhiều

với chi phí thấp Một hạn chế duy nhất ở mức độ này là khả năng linh động, mở rộng của phần mềm Khi qui mô khách hàng lớn hơn, nhà cung cấp sẽ phải chuyển sang dùng một server mạnh hơn để chạy chương trình

2.2.2.4 Mức độ thứ tư

Ở mức độ này (Hình 5.4), nhà cung cấp sẽ phục vụ đồng thời các khách hàng thông qua một bộ phân tải (load-balanced farm) Hệ thống của nhà cung cấp có thể tùy biến tăng hoặc giảm các instance và các server để phục vụ các instance đó mà không phải thay đổi lại kiến trúc phần mềm Điều này một mặt đảm bảo nhà cung cấp có khả năng linh hoạt trong việc sử dụng tài nguyên phù hợp với yêu cầu của khách hàng, mặt khác vẫn giữ nguyên khả năng tùy biến cấu hình, tính riêng tư của khách hàng

Như vậy, để đảm bảo hiệu quả, phần mềm dịch vụ phải đạt được các tính năng về

sự linh hoạt, cung cấp khả năng tùy biến cấu hình, và phải được thiết kế để tối ưu hóa chi phí nhằm giảm giá thành sản phẩm Để đáp ứng các yêu cầu đó, trong tài liệu hướng dẫn của mình [5], hãng Microsoft đưa ra mô hình kiến trúc như sau:

Trong kiến trúc trên, Process Services và Business Services có vai trò giống như trong các kiến trúc Client- Server truyền thống khác Sự khác biệt chủ yếu nằm ở Metadata Services và cơ chế của Security Services

• Process Services:có vai trò xử lý và đưa ra các dữ liệu cần thiết, cung cấp đầu

vào cho tầng trình diễn hoặc các Smart Client

• Business Services:thực hiện các thao tác liên quan tới cơ sở dữ liệu, cung cấp đầu vào cho Process Services

• Directory Services: thực hiện các thao tác lưu trữ, tổ chức và tìm kiếm các thông tin liên quan tới tài khoản người dùng (user account)

• Metadata Services: Dịch vụ này đảm bảo cung cấp cho khách hàng khả năng

chỉnh sửa và cấu hình ứng dụng theo yêu cầu của họ Về cơ bản, khách hàng có thể tùy biến thay đổi cấu hình theo bốn thuộc tính sau:

- Tùy biến giao diện:Khách hàng thường muốn thay đổi giao diện theo một

phong cách nào đó để phù hợp với thương hiệu của họ Vì vậy các phần mềm dịch vụ thường cung cấp khả năng thay đổi giao diện của chương trình cho khách hàng: thay đổi cách bố trí các chức năng, thay đổi màu sắc, phông chữ,…

- Tùy biến qui trình làm việc: Để đáp ứng các yêu cầu đa dạng của khách

hàng, phần mềm dịch vụ (Saas) phải cung cấp cho người sử dụng cơ chế để tùy biến thay đổi qui trình làm việc phù hợp với công việc và mô hình kinh doanh của họ Ví dụ: Một công ty A yêu cầu mọi đơn hàng đều phải được cấp phép bởi 1 bộ phận chuyên trách, trong khi đó công ty B yêu cầu mọi đơn hàng phải đồng thời được duyệt bởi 2 bộ phận khác nhau Khi đó, phần mềm dịch vụ (SaaS) cung cấp cho khách hàng phải có cơ chế cho phép khách hàng tùy biến thiết lập qui trình làm việc theo đặc thù riêng của họ

- Tùy biến quyền truy cập: Mỗi khách hàng sẽ được trao quyền trong việc

tạo và quản lý các tài khoản người sử dụng trong công ty của họ Khách hàng đồng thời cũng được cung cấp cơ chế để tùy biến thiết lập cơ chế truy cập thông tin theo đặc thù riêng của khách hàng

• Sercurity Services: Dịch vụ bảo mật cung cấp hai cơ chế quan trọng là xác thực và thẩm quyền (authentication and authorization)

- Xác thực (authentication): Xác thực là việc kiểm tra xem một tài khoản

người dùng nào đó có đúng là tài khoản hợp lệ của hệ thống hay không Các phần mềm dịch vụ (SaaS) cung cấp một cơ chế gọi là Quản trị ủy quyền (delegated Administrator) Theo cơ chế này, khách hàng được trao quyền tạo, quản lý các tài khoản người sử dụng, nhà cung cấp dịch vụ có vai trò xác

thực các tài khoản đó Có hai cách tiếp cận là xác thực tập trung (Centralized

authentication) và xác thực không tập trung (Decentralized Authentication)

Trong cách tiếp cận xác thực tập trung, nhà cung cấp tạo ra duy nhất một cơ

sở dữ liệu lưu trữ toàn bộ thông tin liên quan tới các tài khoản và mọi thao tác liên quan tới việc quản lý các tài khoản người dùng đều được chứng thực qua một ứng dụng của hệ thống

Hình 7 Mô hình xác thực tập trung

Cách tiếp cận xác thực tập trung này có ưu điểm là dễ triển khai và không yêu cầu phía khách hàng phải có cơ sở hạ tầng riêng cho việc chứng thực Tuy nhiên, cách tiếp cận này không cho phép thực hiện cơ chế đăng nhập một lần (single sign-on)

Trong cách tiếp cận xác thực phi tập trung (Decentralized Authentication),

nhà cung cấp sẽ tạo ra một dịch vụ trung gian giúp cho khách hàng ánh xạ các tài khoản người dùng nội bộ của họ vào tài khoản người dùng của nhà cung cấp dịch vụ Cách tiếp cận này cung cấp cho khách hàng tính năng đăng nhập một lần (single sign-on), cho phép người dùng chỉ cần thực hiện các thao tác chứng thực một lần duy nhất khi họ làm việc với các hệ thống khác nhau mà vẫn đảm bảo được các yêu cầu về bảo mật

Hình 8 Mô hình xác thực phi tập trung (Decentralized Authentication)

- Thẩm quyền (Authorization): Thẩm quyền là việc xác định xem một tài

khoản người dùng nào đó được thực hiện những quyền/chức năng gì trong hệ thống Quản lý việc truy nhập tới tài nguyên và thực hiện các chức năng trong phần mềm dịch vụ (SaaS) được phân thành các mức độ chức năng khác nhau (roles) Mỗi người dùng hay nhóm người dùng sẽ thuộc một hoặc nhiều lớp

chức năng nhất định, và lớp người dùng này sẽ có quyền thực hiện các chức năng tương ứng với mức độ đó

Hình 9 Minh họa cơ chế kiểm soát truy nhập (Access control)

Trong mô hình phần mềm dịch vụ (SaaS), các khách hàng được cung cấp cơ chế phân quyền cho các tài khoản người dùng của mình cho phù hợp với mô hình kinh doanh của họ

2.2.3 Phương thức hoạt động (Operational Structure)

Ngoài việc tạo ra những sản phẩm tốt, đưa ra mô hình kinh doanh hợp lý, các nhà cung cấp phần mềm dịch vụ (SaaS) phảm đảm bảo vận hành và quản lý hệ thống của họ một cách hiệu quả, chính xác, đồng thời đảm bảo chất lượng của dịch vụ cung cấp cho khách hàng

So với các kiến trúc hệ thống phần mềm truyền thống, hệ thống phần mềm dịch vụ (SaaS) sẽ có thêm một lớp mới được đặt tên là Shared Services Lớp này sẽ đảm nhiệm các vai trò sau:

-Theo dõi quá trình sử dụng phần mềm dịch vụ (SaaS) của người dùng và tính chi phí dựa trên thời gian và tài nguyên mà họ đã dùng

-Kiếm soát hiệu năng của hệ thống để đảm bảo thực hiện đúng các thỏa thuận về chất lượng dịch vụ đối với khách hàng (Service level agreement – SLA –bản cam kết tiêu chuẩn của dịch vụ)

Hình 10 Thêm lớp cho phương thức hoạt động mới

Như vậy, trong chương này, luận văn đã trình bày về mô hình phần mềm dịch vụ (SaaS), kiến trúc chung của một mô hình phần mềm dịch vụ thành công, và cách thức chuyển đổi từ mô hình phần mềm truyền thống sang mô hình phần mềm dịch

vụ (SaaS) Trong chương tiếp theo, luận văn sẽ trình bày về J2ME và LightWeight User Interface Toolkit, nền tảng này sẽ được dùng để xây dựng chương trình client chạy trên điện thoại di động để sử dụng các phần mềm dịch vụ của các nhà cung cấp

Chương 3 J2ME Và LightWeight User Interface Toolkit

Trong chương này, luận văn sẽ trình bày về kiến trúc J2ME và LWUIT framework Các kiến thức được trình bày không đi sâu, hướng dẫn các kỹ năng lập trình mà được trình bày theo cách thức để người đọc có được khung nhìn tổng quát, các tính năng, điểm mạnh, điểm yếu của từng framework Từ đó, có thể đưa

ra quyết định sử dụng công nghệ phù hợp với dự án của mình

3.1.1 Tổng quan về J2ME

Công nghệ Java của hãng SUN ra đời từ năm 1995 và đã được cộng đồng phát triển ứng dụng nhiệt liệt chào đón và sử dụng rộng rãi Từ các ứng dụng lớn cho doanh nghiệp tới những ứng dụng cho cá nhân và các ứng dụng mini cho các thiết

bị cấp thấp, tất cả đều có thể sử dụng công nghệ Java SUN chia Java thành nhiều phiên bản khác nhau, phù hợp với mục đích của từng dự án:

- Phiên bản thông thường: Java 2 Standard Edition (J2SE)

- Phiên bản dùng cho các dự án doanh nghiệp lớn, các ứng dụng phân tán : Java 2 Enterprise Edition (J2EE,

- Phiên bản dành cho các thiết bị có cấu hình thấp: Java 2 Micro Edition (J2ME)

J2ME được phát triển từ kiến trúc Java Card, Embeded Java và Personal Java của phiên bản Java 1.1 Đến sự ra đời của Java 2 thì Sun quyết định thay thế Personal Java và đươc gọi với tên mới là Java 2 Micro Edition, hay viết tắt là J2ME Đúng với tên gọi, J2ME là nền tảng cho các thiết bị có tính chất nhỏ, gọn

Thị trường của J2ME được mở rộng ra cho nhiều chủng loại thiết bị như:

-Các loại thẻ cá nhân như Java Card

-Máy điện thoại di động

-Máy PDA (Personal Digital Assistant - thiết bị trợ giúp cá nhân)

-Các hộp điều khiển dành cho tivi, thiết bị giải trí gia dụng …

Hình 11 Kiến trúc các thành phần của J2ME

3.1.1.1 Cấu hình (Configuration ): là đặc tả định nghĩa môi trường phần mềm

trong các thiết bị và được phân loại bởi tập hợp các đặc tính như [6]:

- Kiểu bộ nhớ và dung lượng bộ nhớ

- Kiểu và tốc độ bộ vi xử lý

- Kiểu mạng kết nối

Một thiết bị di động có hỗ trợ một cấu hình do SUN đưa ra thì nhà sản xuất thiết bị

di động đó phải tuân thủ và thực thi đấy đủ các đặc tả trong cấu hình để các lập trình viên có thể phát triển ứng dụng trên dòng các thiết bị di động đó

Hiện nay Sun đã đưa ra 2 kiểu cấu hình :

• CLDC (Connected Limited Device Configuration- Cấu hình thiết bị kết nối giới hạn): được thiết kế để nhắm vào thị trường các thiết bị cấp thấp (low-

end), các thiết bị này thông thường là máy điện thoại di động và PDA với khoảng 512 KB bộ nhớ

• CDC- Connected Device Configuration (Cấu hình thiết bị kết nối): CDC

được đưa ra nhắm đến các thiết bị có tính năng mạnh hơn dòng thiết bị thuộc CLDC nhưng vẫn yếu hơn các hệ thống máy để bàn sử dụng J2SE Những thiết

bị này có nhiều bộ nhớ hơn (thông thường là trên 2Mb) và có bộ xử lý mạnh hơn Các sản phẩm này có thể kể đến như các máy PDA cấp cao, các thiết bị gia dụng trong gia đình …

3.1.1.2 Profile: Profile mở rộng cho Configuration bằng cách thêm vào các lớp cung cấp các tính năng cho từng thiết bị chuyên biệt Mỗi profile sẽ định nghĩa một tập hợp các lớp khác nhau, vì vậy ta không thể chuyển một ứng dụng Java viết cho một profile này và chạy trên một máy hỗ trợ một profile khác Cũng với lý do

đó, bạn không thể lấy một ứng dụng viết trên J2SE hay J2EE và chạy trên các máy

hỗ trợ J2ME Mobile Information Device Profile (MIDP) là một trong những profile phổ biến nhất Profile này sẽ bổ sung các tính năng như hỗ trợ kết nối, các thành phần hỗ trợ giao diện người dùng … vào cấu hình CLDC Profile này được thiết kế chủ yếu để nhắm vào điện thọai di động với đặc tính là màn hình hiển thị hạn chế, dung lượng chứa có hạn Do đó MIDP sẽ cung cấp một giao diện người dùng đơn giản và các tính năng mạng cơ bản dựa trên nền HTTP

Tuy nhiên MIDP không phải là cây đũa thần cho mọi lập trình viên vì như chúng

ta đã biết, MIDP được thiết kế cho các máy di động có cấu hình rất thấp

• Những chức năng MIDP không thể làm được :

- Phép tính dấu phẩy động (floating point): Phép tính này đòi hỏi rất nhiều tài nguyên CPU và phần lớn các CPU cho các thiết bị di động không hỗ trợ phép tính này, do đó MIDP cũng không có

- Bộ nạp class (Class Loader)

- Hỗ trợ từ khóa finalize() như trong J2SE: Việc “dọn dẹp“ tài nguyên trước khi nó bị xóa được đẩy về phía các lập trình viên

Tuy nhiên, điều đó không có nghĩa là mọi dữ liệu quan trọng sẽ mất đi mỗi

Record Management system (RMS) để cung cấp khả năng lưu trữ cho các thiết bị này

• Những chức năng MIDP cung cấp:

- Các lớp và kiểu dữ liệu: Phần lớn các lớp mà các lập trình viên Java quen thuộc vẫn còn được giữ lại ví dụ như các lớp trong gói java.util như Stack, Vector và Hastable cũng như Enumeration

Tuy nhiên, mong bạn đọc chú ý là tôi nhấn mạnh từ “phần lớn” vì bạn không thể dùng Iterator Trong phần phụ lục, tôi sẽ liệt kê các gói (package) cũng như số lượng của chúng được hỗ trợ trong môi trường J2ME bao gồm CLDC, CDC và MIDP

- Hỗ trợ đối tượng Display: Đúng như tên gọi một chương trình MIDP sẽ hỗ trợ duy nhất một đối tượng Display là đối tượng quản lý việc hiển thị dữ liệu trên màn hình điện thoại

- Hỗ trợ Form và các giao diện người dùng

-Nâng cấp các tính năng bảo mật như:

+Download qua mạng an toàn hơn qua việc hỗ trợ giao thức HTTPS

+Kiểm soát việc kết nối giữa máy di động và server: ví dụ như các chương trình không thể kết nối tới server nếu thiếu sự chấp thuận của người sử dụng

-Thêm các API hỗ trợ Multimedia Một trong những cải tiến hấp dẫn nhất của MIDP 2.0 là tập các API media của nó Các API này là một tập con chỉ hỗ trợ

âm thanh của Mobile Media API (MMAPI)

- Mở rộng các tính năng của Form Nhiều cải tiến đã được đưa vào API javax.microedition.lcdui trong MIDP 2.0, nhưng các thay đổi lớn nhất (ngoài API cho game) là trong Form và Item

- Hỗ trợ các lập trình viên Game bằng cách tung ra Game API: Có lẽ Sun đã kịp nhận ra thị trường đầy tiềm năng của các thiết bị di động trong lĩnh vực Game Với MIDP 1.0 thì các lập trình viên phải tự mình viết code để quản lý các hành động của nhân vật cũng như quản lý đồ họa

Việc này sẽ làm tăng kích thước file của sản phẩm cũng như việc xuất hiện các đoạn mã bị lỗi Được hưởng lợi nhất từ Game API trong MIDP 2.0 không chỉ

là các lập trình viên Game mà còn là các lập trình viên cần sử dụng các tính năng đồ họa cao cấp

3.1.2.1 Vòng đời của Midlet

Các thiết bị di động quản lý một Midlet [7] thông qua một chương trình gọi là

Chương trình quản lý ứng dụng (Application Management Software –AMS)

AMS có nhiệm vụ khởi tạo, bắt đầu, tạm dừng, kích hoạt, hoặc dừng thực thi một Midlet Khi một Midlet được tạo ra, nó có thể ở một trong 3 trạng thái: được kích hoạt (active), tạm dừng (paused), và dừng hẳn (destroyed)

Hình 12 Vòng đời của Midlet

Trạng thái của Midlet được chuyển đổi qua lại thông qua các hàm startApp(), pauseApp(), destroyApp() Giả sử dụng ta có một ứng dụng gọi là DateTimeApp,

sơ đồ sau đây sẽ mô tả các trạng thái của Midlet theo các tác động của người dùng

và ASM:

Hình 13 Trạng thái của Midlet theo các dãy sự kiện

3.1.2.2 Các thành phần giao diện ở mức cao của ứng dụng MIDP

Một ứng dụng Midlet chỉ có 1 đối tượng Display Đối tượng này dùng để lấy thông tin về các đối tượng được hiển thị trên màn hình điện thoại, và bao gồm các phương thức để tác động lên đối tượng đó Đối tượng Display này đóng vai trò như một “màn hình logic”, và trên đó có thể hiển thị nhiều đối tượng khác kế thừa

từ lớp Displayable như: Forms, TextBoxes, ChoiceGroups,

MIDP chứa 2 lớp con của lớp Displayable là Screen và Canvas Hình dưới đây mô

tả mối quan hệ trên

Hình 14 Lớp Displayable trong Midlet

Một đối tượng lớp Screen không được hiển thị trực tiếp trên thiết bị di động, lớp

Screen này sẽ được thừa kế bởi các thành phần hiển thị ở mức cao, chính các thành phần này sẽ được hiển thị ra trên màn hình Hình dưới đây sẽ mô tả mối quan hệ của lớp Screen và các thành phần thể hiện ở mức cao

Hình 15 Các lớp con của lớp Screen

3.1.2.3 Các thành phần giao diện ở mức thấp của ứng dụng MIDP

Mặc dù các hàm API mức cao cung cấp tương đối đầy đủ các thành phần để xây dựng giao diện ứng dụng người dùng thông thường Tuy nhiên các thành phần cấp cao này không cung cấp phương tiện để vẽ trực tiếp lên các đối tượng được hiển thị Vì thiếu khả năng này nên các ứng dụng được tạo ra sẽ gặp nhiều giới hạn khi người lập trình muốn hiển thị hình ảnh theo cách riêng của họ Ví dụ, hầu hết các nhà phát triển game di động đều phải tự vẽ lại các hình ảnh của riêng chương trình

mà họ xây dựng Để giải quyết vấn đề đó, các hàm API cấp thấp cho phép người lập trình thể hiện các ý tưởng theo cách riêng của họ

Canvas và Graphics là 2 lớp chính cung cấp các API cấp thấp Canvas là một khung vẽ cho phép người phát triển có khả năng vẽ lên các đối tượng đang được hiển thị cũng như xử lý các sự kiện Còn lớp Graphics cung cấp các công cụ thật

sự để vẽ như drawRoundRect() và drawString()

• Lớp Canvas

Lớp Canvas cung cấp một khung vẽ cho phép tạo ra giao diện tùy biến người dùng Một số lượng lớn các phương thức trong lớp này được dùng để xử lý sự kiện, vẽ ảnh và chuỗi lên thiết bị hiển thị Lớp Canvas cung cấp:

- Hệ thống tọa độ

- Các phương thức để vẽ lên trên đối tượng Canvas

- Các phương thức xử lý các sự kiện hành động

- Các phương thức xử lý các sự kiện phím nhấn

- Các phương thức xử lý sự kiện hành động của Game

- Các phương thức xử lý sự kiện con trỏ

3.1.2.4 Xử lý sự kiện trong Midlet

• Đối tượng Command

Khi một sự kiện xảy ra trên thiết bị di động, một đối tượng Command giữ thông tin về sự kiện đó Thông tin này bao gồm loại hành động thực thi, nhãn của mệnh lệnh và độ ưu tiên của chính nó Trong J2ME, các hành động nói chung được thể hiện dưới dạng các nút trên thiết bị Nếu có quá nhiều hành động được hiển thị trên thiết bị, thiết bị sẽ tạo ra một thực đơn để chứa các hành động này Trong MIDP profile, không phải mọi đối tượng đều có thể tiếp nhận các hành động, chỉ

có các thành phần MIDP sau đây mới có thể chứa đối tượng Command là: Form, TextBox, List và Canvas

Các bước cơ bản để xử lý các sự kiện với một đối tượng Command:

hay Canvas

- Tạo một bộ lắng nghe

Khi có một sự kiện xảy ra, bộ lắng nghe sẽ phát sinh một lời gọi đến phương thức commandAction() Trong phần cài đặt của phương thức này, người lập trình

có thể xác định đối tượng nào phát sinh ra sự kiện và tạo ra các xử lý tương ứng

• Đối tượng Item

Ngoài việc xử lý sự kiện bằng đối tượng Command ta có thể xử lý sự kiện bằng đối tượng Item Nhiều đối tượng trong MIDP đã được định nghĩa trước cho việc

xử lý các sự kiện cụ thể nào đó Ví dụ đối tượng DateField cho phép người sử dụng chọn lựa ngày và giờ trên màn hình, đối tượng TextField cho phép người dùng nhập vào một chuỗi các ký tự, số và các ký tự đặc biệt Tương tự như việc xử lý sự kiện bằng đối tượng Command, khi có một thay đổi xảy ra đối với bất kỳ thành phần Item nào thì phương thức itemStateChanged() sẽ được gọi Và người lập trình sẽ thực hiện các xử lý bên trong phương thức itemStateChanged() này

3.1.2.5 Record Management System (Hệ thống quản lý bản ghi)

MIDP không sử dụng hệ thống file để lưu trữ dữ liệu Thay vào đó MIDP lưu toàn

bộ thông tin vào non-volatile memory bằng hệ thống lưu trữ gọi là Hệ thống quản

lý bản ghi ( Record Management System - RMS)

RMS là hệ thống được tổ chức và quản lý dưới dạng các record Mỗi record có thể chứa bất kỳ loại dữ liệu nào, chúng có thể là kiểu số nguyên, chuỗi ký tự hay có thể là một ảnh và kết quả là một record là một chuỗi (mảng) các byte RMS lưu dữ liệu gần như một cơ sở dữ liệu, bao gồm nhiều dòng, mỗi dòng có một số định danh duy nhất:

Hình 16 Hệ thống RMS

Một tập các bản ghi (sau này gọi là RecordStore) là tập hợp các record được sắp xếp có thứ tự Mỗi record không thể đứng độc lập mà nó phải thuộc vào một RecordStore nào đó, các thao tác trên record phải thông qua RecordStore chứa nó Khi tạo ra một Record trong RecordStore, Record được gán một số định danh gọi là Record ID Record đầu tiên được tạo ra sẽ được gán Record ID là

1 và sẽ tăng thêm 1 cho các Record tiếp theo

Cần chú rằng Record ID không phải là chỉ mục (index), các thao tác xóa record trong RecordStore sẽ không gây nên việc tính toán lại các Record ID của các Record hiện có, cũng như không làm thay đổi Record ID của các Record được tạo mới, ví dụ: Sau khi ta xóa Record id 3, ta thêm một Record mới, Record đó sẽ có

id là 4

• Midlet suite là tập các Midlet có thể chia sẻ cùng tài nguyên (như RecordStore), các biến tĩnh (static variable) trong các lớp và các Midlet này sẽ được đóng gói trong cùng một file jar khi triển khai

RecordStore được phân biệt với nhau bằng tên, và các RecordStore trong cùng một Midletsuite phải có tên khác nhau, nhưng trong 2 Midletsuite khác nhau có thể có các RecordStore có tên giống nhau (2 RecordStore này là hoàn toàn khác nhau)

Một ứng dụng Midlet có thể truy cập tới các RecordStore của một Midlet khác trong dùng Midletsuite Ngược lại, một ứng dụng Midlet không thể truy cập tới

Hình 17 Minh họa quyền truy xuất RecordStore giữa các Midlet

Đường liền thể hiện việc truy xuất RecordStore do Midlet đó tạo ra, đường nét đứt

là RecordStore do Midlet khác tạo ra

Trong MidletSuite One, Midlet #1 và Midlet #2 cùng có thể truy xuất 4 Record store Các Midlet trong MidletSuite One không thể truy xuất RecordStore trong MidletSuite Two và ngược lại

• Khả năng lưu trữ của RMS

Dung lượng vùng nhớ (non-volatile memory) dành riêng cho việc lưu trữ dữ liệu trong RMS thay đổi tùy theo thiết bị di động Đặc tả MIDP yêu cầu rằng các nhà sản xuất thiết bị di động phải dành ra vùng nhớ có kích thước ít nhất 8K cho việc lưu trữ dữ liệu trong RMS Đặc tả không nêu giới hạn trên cho mỗi Record RMS cung cấp các API để xác định kích thước của mỗi Record, tổng dung lượng của RecordStore và kích thước còn lại của vùng nhớ này Do đó trong quá trình phát triển các ứng dụng J2ME, người lập trình phải cân nhắc việc sử dụng vùng nhớ này

• Tốc độ truy xuất dữ liệu

Các thao tác trên vùng nhớ non-volatile memory tất nhiên sẽ chậm hơn nhiều so với truy xuất dữ liệu trên bộ nhớ RAM (volatile memory) Việc này giống như so sánh tốc độ đọc ổ cứng và tốc độ đọc từ RAM trên máy tính Vì vậy trong kỹ thuật lập trình, người lập trình phải thường xuyên cache dữ liệu và các thao tác liên quan đến RMS chỉ thực hiện tập trung một lần (lúc khởi động hay đóng ứng dụng)

• C ơ chế luồng an toàn

Nếu RecordStore chỉ được sử dụng bởi một MIDlet, RMS sẽ dành riêng một Thread để thực hiện các thao tác trên RecordStore Tuy nhiên, nếu có nhiều MIDlet và Thread cùng chia sẻ một RecordStore thì phải chú ý đến kỹ thuật lập trình Thread để đảm bảo không có sự xung đột dữ liệu

• Một số API trong RMS

Tuy không có đầy đủ tính năng như một hệ quản trị cơ sở dữ liệu nhưng RMS cung cấp các tính năng cơ bản để có thể thao tác trên tập các bản ghi như: khởi tạo, thêm bản ghi, xóa bản ghi, tìm kiếm, lọc bản ghi,

Sau đây là một số API cơ bản:

RecordStore Class: javax.microedition.rms.RecordStore

recordStoreName)

Xóa RecordStore

static String[] listRecordStores()

Danh sách các RecordStore trong MIDlet suite

int addRecord(byte[] data, int

int getRecord(int recordId,

byte[] buffer,

int offset)

Lấy nội dung của record vào dãy byte

int getRecordSize(int recordId) Kích thước record

int getNextRecordID() Lấy record id của record mới

int getNumRecords() Số lượng các record

long getLastModified() Thời gian thay đồi gần nhất

int getVersion() Version của RecordStore

String getName() Tên của RecordStore

int getSize() Kích thước của RecordStore

int getSizeAvailable() Số byte trống cho

void removeRecordListener

(RecordListener listener)

Gỡ bỏ listener

Bảng 1 Một số API của RMS

3.1.2.6 Các luồng vào ra và Liên kết mạng

Với kích thước hơn 200 kb, bao gồm hơn 100 class và interfaces, gói java.io, java.net của J2SE sẽ chiếm hầu hết bộ nhớ vốn dĩ đã nhỏ bé của những thiết bị di động Do đó Sun không thể kế thừa những gói này vào trong J2ME, mà họ đã xây dựng một chuẩn là Generic Connection Framework (GCF) GCF sẽ giúp cho các thiết bị di động có thể truy xuất được các tài nguyên mạng với địa chỉ được xác định bằng URL

Generic Connection Framework bao gồm một tập hợp các interfaces được khai báo trong package javax.microedition.io Hình vẽ sau thể hiện mối quan hệ giữa các interfaces:

Hình 18 Các luồng truy xuất vào ra

Thông qua các lớp này, J2ME cung cấp các phương thức lập trình socket hoặc kết nối mạng với giao thức Http như trong các nền tảng khác

Đặc tả của phiên bản MIDP 1.0 chỉ hỗ trợ HTTP, trong khi đó phiên bản hiện tại MIDP 2.0 hỗ trợ HTTP và HTTPS, cung cấp khả năng bảo mật tốt hơn

• Request and response protocols

Cả HTTP và HTTPS đều gửi request và response Máy client gửi request, còn server sẽ trả về response Client request bao gồm 3 phần sau:

-Header sẽ không gửi dữ liệu yêu cầu lên server, thay vào đó header chỉ request những meta information về server

-Body chứa nội dung mà bạn muốn gửi lên server

Sau khi nhận được và xử lý yêu cầu từ phía client, server sẽ đóng gói và gửi về phía client Cũng như client request, server cũng gồm 3 phần sau:

-Body Cũng giống như client, server gửi hầu hết những thông tin trong phần body cho client Client dùng input stream để đọc kết quả trả về từ server

3.2 Lightweight User Interface Toolkit - LWUIT

3.2.1 Giới thiệu về Lightweight User Interface Toolkit – LWUIT

(Lightweight User Interface Toolkit – LWUIT) được thiết kế để hỗ trợ người lập trình trên nền MIDP 2.0 và CLDC 1.1 tạo ra những ứng dụng có giao diện hẫp dẫn

và tinh tế trên các thiết bị di động LWUIT vừa cung cấp các thành phần đồ họa như trong gói javax.microedition.lcdui truyền thống, đồng thời cung cấp thêm một loạt thành phần đồ họa mới như các hiệu ứng hình ảnh và các thành phần Swing (giống như trong các ứng dụng Java trên máy tính) Hơn thế, điểm nổi bật nhất của LWUIT là cho phép dễ dàng kết hợp theme và các tài nguyên đi kèm (hình nền, các file đính kèm,…) với các ứng dụng, đồng thời ứng dụng LWUIT sẽ

có giao diện đồng nhất trên mọi loại thiết bị, mọi nền tảng hệ điều hành

3.2.1.1 Tại sao lại cần có LWUIT

Java ME cho phép các nhà lập trình phát triển các ứng dụng khả chuyển giữa các loại thiết bị khác nhau dựa trên nền tảng J2ME Sự thật là khi hầu hết chức năng

cơ bản của các ứng dụng này đều hoạt động tốt trên các thiết bị khác nhau, tuy nhiên thành phần giao diện người dùng của ứng dụng trên mỗi loại thiết bị lại không thống nhất và ảnh hướng tới chất lượng của ứng dụng [8]

Một lý do nữa khiến SUN đưa ra LWUIT là cuộc cạnh tranh khốc liệt giữa các hãng cung cấp ứng dụng dẫn tới yêu cầu ngày càng cao về mặt đồ họa, giao diện của các ứng dụng Với lý do đó, LWUIT được đưa ra để cung cấp cho người lập trình một công cụ mạnh hơn để bổ sung các tính năng đồ họa cho ứng dụng của

họ, đồng thời vẫn đảm bảo ứng dụng chạy được trên các thiết bị cấu hình thấp Như vậy, LWUIT ra đời với 3 mục đích chính sau:

-Cung cấp công cụ để người lập trình viết các ứng dụng có giao diện đẹp hơn, nhiều hiệu ứng hơn

-Tạo nên sự thống nhất về giao diện ứng dụng trên các nền tảng khác nhau