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 log
Giới Thiệu
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 France Telecom là một công ty lớn hoạt động toàn cầu, chuyên cung cấp dịch vụ truyền thông và di động Để thúc đẩy nghiên cứu và phát triển (R&D), họ đã thành lập các phòng thí nghiệm Orange Labs, đóng vai trò quan trọng trong việc nghiên cứu và triển khai công nghệ mới nhằm cung cấp dịch vụ tốt nhất cho khách hàng Các phòng thí nghiệm này được tổ chức theo cấu trúc phân cấp và chức năng, với sự hiện diện tại nhiều quốc gia, bao gồm Pháp, Mỹ, Anh, Nhật Bản và Trung Quốc.
DIAM (Services à valuer ajoutée sur réseaux d’entreprise et M2M) Olivier Bouillant
MUSE (Marché, Usage, nouveaux service Entreprises) Philippe Guillermin
SDE (Service de Données aux Entreprises) Frédéric Tendron
Core Networks RDC Roberto Kung
Integrated Services, Residential and Personal Olivier Strilka
Corporate and Enterprise Services RDC Valérie Duburcq
Middleware and Advanced Platforms Franỗoise Colaitis
Access Networks RDC Igor Bednarek
Hệ thống phòng thí nghiệm Orange Labs bao gồm nhiều phòng thí nghiệm nhỏ hơn, trong đó CIL/BIZZ là một đơn vị thuộc phòng thí nghiệm CIL (Center d’intégration logicielle) Nhiệm vụ chính của CIL/BIZZ là nghiên cứu và phát triển các ứng dụng mang tính chất thực tiễn.
CIL/BIZZ tại Lannion đang tích cực tham gia nghiên cứu và phát triển các dự án tích hợp hệ thống phần cứng và phần mềm, nhằm tạo ra những kiến trúc mới để nâng cao chất lượng dịch vụ khách hàng.
Dự án Mobile Access nhằm cung cấp phương thức mới cho dịch vụ giá trị gia tăng trên mạng di động của tập đoàn France Telecom Mặc dù hạ tầng viễn thông ở các nước phát triển đã hoàn thiện và người dùng có thể truy cập internet tốc độ cao, nhưng sự đa dạng của điện thoại di động gây ra nhiều khó khăn trong việc cung cấp dịch vụ Hiện tại, khách hàng thường phải tải và cài đặt phần mềm riêng cho từng loại điện thoại để sử dụng tiện ích, điều này tạo ra trở ngại cho 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 một hệ thống cho phép người dùng dễ dàng mua các dịch vụ tương tự như khi họ mua sắm hàng hóa trên các trang web thương mại điện tử Hệ thống này sẽ mang lại trải nghiệm tiện lợi và nhanh chóng, giúp người dùng tiếp cận dịch vụ một cách đơn giản và hiệu quả.
- Đư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
Giới thiệu về mục tiêu của luận văn tốt nghiệp
Trong những năm gần đây, phần mềm dịch vụ (SaaS) đã trở thành một mô hình phân phối phần mềm mới và dự kiến thị trường SaaS sẽ tăng 21% vào năm 2011 theo Gartner Nhóm nghiên cứu đã hợp tác với Salesforce, một trong những công ty hàng đầu cung cấp SaaS, nhằm phát triển mô hình cung cấp dịch vụ cho tập đoàn France Telecom Mục tiêu của luận văn tốt nghiệp cao học cũng nằm trong khuôn khổ của đề tài này, với các mục tiêu cụ thể được xác định.
- Tìm hiểu về mô hình phần mềm dịch vụ(SaaS)
- Sử dụng J2ME và LWUIT Framework để ây dựng phần x 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.
Mô Hình Phần Mềm Dịch Vụ
Giới thiệu về Phần mềm dịch vụ (SaaS)
2.1.1 Phần mềm dịch vụ (SaaS) là gì ?
Phần mềm dịch vụ (SaaS) là mô hình phân phối và quản lý phần mềm qua internet, cho phép người dùng truy cập ứng dụng từ xa mà không cần cài đặt trên máy tính cá nhân Trong mô hình này, nhà cung cấp sở hữu và vận hành phần mềm trên hệ thống của họ, giúp khách hàng tiết kiệm chi phí bằng cách thuê dịch vụ thay vì mua đứt phần mềm Khách hàng thường trả phí thuê hàng tháng, mang lại sự linh hoạt và tiện lợi trong việc sử dụng phần mềm.
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 phần mềm dịch vụ SaaS thường rẻ hơn và đơn giản hơn so với phần mềm đóng gói truyền thống, với khách hàng chỉ cần thanh toán một khoản phí hàng tháng cho mỗi người dùng Các công ty không cần đầu tư lớn vào hạ tầng hoặc thuê tư vấn, giúp dễ dàng ước lượng chi phí sử dụng Việc nâng cấp sản phẩm SaaS cũng diễn ra đồng bộ và do nhà cung cấp thực hiện Tuy nhiên, tính hiệu quả của phần mềm dịch vụ so với phần mềm truyền thống phụ thuộc vào nhu cầu và đặc điểm riêng của từng công ty, tương tự như việc so sánh giữa ôtô tự lái và dịch vụ taxi.
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)
Mô hình nhà cung cấp dịch vụ ứng dụng (ASP) đã từng phát triển mạnh mẽ với các tính năng tương tự như phần mềm dịch vụ SaaS hiện nay, nhưng gặp khó khăn trong việc đáp ứng nhu cầu đa dạng của khách hàng, dẫn đến chi phí cao cho hạ tầng và triển khai Ngược lại, các nhà cung cấp SaaS thành công như Salesforce, LeanLogistics và Ketera đã giải quyết hiệu quả vấn đề mở rộng và độ tin cậy của hệ thống, nhờ vào cách tiếp cận “một cho tất cả” dựa trên kiến trúc Multi-tenancy Họ phát triển tính năng phần mềm dựa trên phản hồi của khách hàng, từ đó cung cấp dịch vụ với chi phí thấp hơn và đảm bảo khách hàng luôn sử dụng phiên bản tốt nhất.
Chuyển đổi từ phần mềm truyền thống sang mô hình phần mềm dịch vụ
Để chuyển đổi từ mô hình cung cấp phần mềm truyền thống sang mô hình cung cấp phần mềm dịch vụ (SaaS), các nhà cung cấp cần điều chỉnh mô hình kinh doanh và kiến trúc ứng dụng của mình Sự thay đổi này không chỉ giúp tối ưu hóa quy trình cung cấp dịch vụ mà còn nâng cao trải nghiệm người dùng, đồng thời đáp ứng nhu cầu thị trường ngày càng cao.
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)
Mô hình kinh doanh mới đã thay đổi cách sở hữu phần mềm từ mua sang thuê, với cơ sở hạ tầng và đội ngũ kỹ thuật được tập trung ở nhà cung cấp dịch vụ Điều này dẫn đến giá thành sử dụng phần mềm giảm và mở rộng thị trường khách hàng.
2.2.1.1 Thay đổi cách thức sở hữu phần mềm
Khi chuyển sang mô hình phần mềm như dịch vụ (SaaS), nhà cung cấp không còn bán quyền sở hữu phần mềm mà cho thuê sản phẩm Thay vì cài đặt phần mềm trên hệ thống máy tính, khách hàng chỉ trả tiền khi sử dụng dịch vụ Mô hình này giúp giảm chi phí ban đầu cho khách hàng và có thể tính phí theo số người dùng hoặc 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 và chuyên gia bao gồm các kỹ thuật viên và chuyên gia, có trách nhiệm đảm bảo hoạt động hiệu quả của hệ thống phần cứng cũng như các phần
Khi chuyển sang mô hình cung cấp phần mềm dịch vụ, khách hàng vẫn cần đầu tư vào phần cứng và đội ngũ kỹ thuật, nhưng hệ thống phần cứng sẽ đơn giản hơn và nhiệm vụ của đội ngũ kỹ thuật sẽ được giảm thiểu Dưới đây là bảng minh họa tỷ lệ chi phí đầu tư của khách hàng khi sử dụng phần mềm truyền thống so với 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ụ
Bằng cách cung cấp giải pháp cho từng khách hàng, nhà cung cấp có thể giảm chi phí phần mềm dịch vụ mà vẫn đảm bảo chất lượng sản phẩm Chẳng hạn, nếu một nhà cung cấp có 50 công ty sử dụng dịch vụ, trong đó 5 công ty vẫn dùng phần mềm truyền thống, mỗi công ty sẽ phải đầu tư vào máy chủ và đội ngũ kỹ thuật riêng, dẫn đến chi phí cao hơn 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ụ, nhà cung cấp có thể thu hút một lượng lớn khách hàng là các công ty nhỏ, những đơn vị trước đây không đủ khả năng tài chính để đầu tư vào phần mềm truyền thống Các công ty nhỏ với nguồn vốn hạn chế thường gặp khó khăn trong việc mua phần mềm chất lượng cao do giá thành cao Tuy nhiên, khi chuyển sang mô hình phần mềm dịch vụ, các công ty này có cơ hội tiếp cận phần mềm chất lượng với chi phí thấp hơn, giúp cải thiện hiệu quả công việc của họ.
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ố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.
Một trong những thay đổi quan trọng trong kiến trúc phần mềm dịch vụ là khả năng tùy biến cao Thay vì sửa đổi ứng dụng cho từng khách hàng, phần mềm dịch vụ cần cung cấp tính năng tùy chỉnh thông qua việc thay đổi cấu hình Khách hàng có thể sử dụng 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 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) đòi hỏi nhà cung cấp phải thực hiện những thay đổi lớn trong kiến trúc phần mềm Việc nâng cấp hệ thống trở nên dễ dàng hơn do tất cả khách hàng sử dụng chung một phiên bản Tuy nhiên, vì mỗi khách hàng có chương trình riêng, nhà cung cấp gặp khó khăn trong việc duy trì cơ sở hạ tầng để thực thi các chương trình đó đồng thời Mỗi khi có khách hàng mới, nhà cung cấp phải triển khai một chương trình riêng, dẫn đến chi phí cho phần cứng và hệ thống lưu trữ dữ liệu gia tăng, làm cho giá thành của phần mềm dịch vụ chưa giảm nhiều.
2.2.2.3 Mức độ thứ ba Ở mức độ này, nhà cung cấp chạy một chương trình duy nhất để phục vụ mọi khách hàng (Hình 5.3) Chương trình này cho phép khách hàng tùy biến cấu hình và có cơ chế bảo mật đảm bảo tính toàn vẹn và riêng tư dữ liệu của từng khách hàng Đứng trên góc độ khách hàng, mỗi khách hàng vẫn cảm thấy như họ đang dùng một chương trình dành riêng cho họ Khi đã ở mức độ này, nhà cung cấp đã tối ưu hóa sử dụng các tài nguyên của mình, và có khả năng cung cấp phần mềm 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.
J2ME Và LightWeight User Interface Toolkit
Cộng nghệ J2ME
Công nghệ Java, được phát triển bởi hãng SUN từ năm 1995, đã nhanh chóng nhận được sự chào đón nồng nhiệt từ cộng đồng và được sử dụng rộng rãi Java phù hợp cho nhiều loại ứng dụng, từ các giải pháp lớn cho doanh nghiệp đến các ứng dụng cá nhân và mini cho thiết bị cấp thấp SUN đã chia Java thành nhiều phiên bản khác nhau, mỗi phiên bản được thiết kế phù hợp với mục đích cụ thể 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, Embedded Java và Personal Java của phiên bản Java 1.1, đã chính thức ra mắt với tên gọi Java 2 Micro Edition khi Sun quyết định thay thế Personal Java Như tên gọi của nó, J2ME là nền tảng lý tưởng cho các thiết bị nhỏ gọn và di động.
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ý
Hiện nay Sun đã đưa ra 2 kiểu cấu hình :
CLDC, or Connected Limited Device Configuration, is specifically designed for low-end devices such as mobile phones and PDAs, typically equipped with around 512 KB of memory.
CDC (Cấu hình thiết bị kết nối) được thiết kế cho các thiết bị có tính năng vượt trội hơn so với CLDC, nhưng vẫn kém hơn các hệ thống máy tính để bàn sử dụng J2SE Những thiết bị này thường có dung lượng bộ nhớ lớn hơn 2MB và sở hữu bộ xử lý mạnh mẽ hơn Ví dụ về các sản phẩm thuộc loại này bao gồm các máy PDA cao cấp và 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 ỗi profile M 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
Mặc dù MIDP mang lại nhiều lợi ích cho lập trình viên, nhưng nó không phải là giải pháp hoàn hảo cho tất cả MIDP được phát triển đặc biệt cho các thiết bị di động có cấu hình thấp, điều này có thể hạn chế khả năng sử dụng và tính linh hoạt của nó trong các ứng dụng phức tạp hơn.
• Những chức năng MIDP không thể làm được :
Phép tính dấu phẩy động (floating point) yêu cầu tài nguyên CPU cao, tuy nhiên hầu hết các CPU trên thiết bị di động không hỗ trợ loại phép tính này, dẫn đến việc MIDP cũng không tích hợp tính năng này.
- 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
- Hỗ trợ hạn chế thao tác bắt lỗi.
- Phần lớn các thư viện API cho Swing và AWT không thể sử dụng được trong MIDP
Các thiết bị J2ME không hỗ trợ tính năng quản lý file và thư mục, điều này có thể khiến bạn ngạc nhiên Thực tế, các thiết bị này không tương thích với các thiết bị lưu trữ thông thường như ổ cứng.
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:
Trong lập trình Java, các lớp và kiểu dữ liệu quen thuộc vẫn được duy trì, bao gồm các lớp trong gói java.util như Stack, Vector và Hashtable, cùng với Enumeration.
Trong bài viết này, tôi nhấn mạnh rằng phần lớn các gói (package) được hỗ trợ trong môi trường J2ME, bao gồm CLDC, CDC và MIDP, không thể sử dụng Iterator Danh sách chi tiết về các gói và số lượng của chúng sẽ được trình bày trong phần phụ lục.
Chương trình MIDP hỗ trợ một đối tượng Display, chuyên 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.
- Hỗ trợ Timer và Alert.
- Cung cấp tính năng Record Management System (RMS) cho việc lưu trữ dữ liệu
Tháng 11 năm 2003 Sun đã tung ra MIDP 2.0 với hàng loạt tính năng khác được cung cấp thêm so với bản 1.0 (Hiện nay tại Việt Nam đã có những đời điện thoại hỗ trợ MIDP 2.0 ví dụ như Nokia 6600 hay Sony Ericsson P900) Các cải tiến nổi bật so với MIDP 1.0:
-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 kết nối giữa thiết bị di động và máy chủ là rất quan trọng; ví dụ, các chương trình sẽ không thể kết nối tới máy chủ nếu không có sự chấp thuận từ người dùng.
Một trong những cải tiến nổi bật của MIDP 2.0 là việc bổ sung các API hỗ trợ Multimedia Các API này tạo thành một tập con chuyên biệt, tập trung vào việc hỗ trợ âm thanh trong Mobile Media API (MMAPI).
Lightweight User Interface Toolkit - LWUIT
3.2.1 Giới thiệu về Lightweight User Interface Toolkit – LWUIT
LWUIT (Lightweight User Interface Toolkit) được phát triển để hỗ trợ lập trình viên trên nền MIDP 2.0 và CLDC 1.1 trong việc tạo ra các ứng dụng di động với giao diện hấp dẫn và tinh tế Nó không chỉ cung cấp các thành phần đồ họa truyền thống từ gói javax.microedition.lcdui mà còn bổ sung nhiều thành phần mới, bao gồm hiệu ứng hình ảnh và các thành phần Swing tương tự như trong các ứng dụng Java trên máy tính Điểm nổi bật của LWUIT là khả năng dễ dàng tích hợp theme và tài nguyên đi kèm như hình nền, giúp ứng dụng có giao diện đồng nhất trên mọi thiết bị và 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 lập trình viên phát triển ứng dụng khả chuyển giữa các thiết bị khác nhau dựa trên nền tảng J2ME Mặc dù các chức năng cơ bản của ứng dụng hoạt động tốt trên nhiều thiết bị, nhưng thành phần giao diện người dùng lại không đồng nhất, ảnh hưởng đến chất lượng tổng thể của ứng dụng.
LWUIT được SUN phát triển nhằm đáp ứng nhu cầu ngày càng cao về đồ họa và giao diện trong bối cảnh cạnh tranh khốc liệt giữa các nhà cung cấp ứng dụng Công cụ này giúp lập trình viên bổ sung các tính năng đồ họa mạnh mẽ cho ứng dụng của họ, đồng thời đảm bảo khả năng hoạt động trên các thiết bị có cấu hình thấp Tóm lại, LWUIT ra đời với ba mục đích chính: nâng cao trải nghiệm người dùng, tăng cường tính năng đồ họa và hỗ trợ đa dạng thiết bị.
-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
-Đảm bảo các ứng dụng LWUIT chạy nhanh và chạy tốt, kể cả trên các thiết bị cấu hình thấp
LWUIT là một thư viện được phát triển dựa trên các lớp nguyên thủy của MIPD2.0 và LCDC1.1, đảm bảo rằng các ứng dụng sử dụng LWUIT hoàn toàn tương thích và có thể chạy trên các thiết bị hỗ trợ ứng dụng J2ME truyền thống.
Các thành phần trong LWUIT được xây dựng theo mô hình MVC (Model-View-Control), một thiết kế giao diện người dùng hướng đối tượng hiệu quả, xuất hiện vào cuối thập kỷ 90.
1970 Một đối tượng trong mô hình này bao gồm ba phần: Model (mô hình), View (hiển thị), Controller (Điềukhiển)
Mô hình (Model) chứa trạng thái dữ liệu của từng thành phần, với các loại mô hình khác nhau cho từng thành phần cụ thể Chẳng hạn, mô hình của một thanh cuộn (scrollbar) có thể lưu trữ thông tin về vị trí hiện tại của "thumb", giá trị tối thiểu và tối đa, cùng với độ rộng của thumb Trong khi đó, một menu chỉ cần chứa danh sách các mục menu mà người dùng có thể lựa chọn Đối với thành phần văn bản, mô hình cũng nắm giữ thông tin về cấu trúc của nó Mô hình có trách nhiệm giao tiếp gián tiếp với View và Controller, nghĩa là nó không biết đến sự tồn tại của chúng và không duy trì các tham chiếu tới chúng, mà thay vào đó, nó sẽ gửi các sự kiện đến View và Controller.
View liên quan đến cách người dùng nhìn thấy các thành phần trên màn hình, được gọi là "look" Ví dụ điển hình là thanh tiêu đề trên cửa sổ, thường nằm ở đỉnh Trên nền tảng MacOS, nút đóng nằm ở phía bên trái, trong khi trên Windows, nút đóng lại nằm ở phía bên phải Đây là những cách hiển thị khác nhau của cùng một loại đối tượng cửa sổ.
View đóng vai trò quan trọng trong việc thay đổi cách hiển thị và cập nhật thông tin mới, thông qua việc nhận các thông điệp gián tiếp từ Model hoặc Controller.
Controller là thành phần quản lý việc điều khiển và xử lý các tương tác giữa giao diện và người sử dụng Khi có sự kiện như click chuột, sự kiện bàn phím, hoặc lệnh vẽ lại màn hình xảy ra, Controller xác định thành phần gây ra sự kiện và thực hiện các thay đổi cần thiết Nó gửi thông điệp đến Model và View để đảm bảo sự tương tác hiệu quả.
Mô hình Model, View, Controller (MVC) tương tác để tạo ra một scrollbar hiệu quả Model lưu trữ thông tin về giá trị tối thiểu và tối đa, trong khi View xác định cách vẽ scrollbar và vị trí của nó Controller đảm nhiệm việc xử lý các sự kiện chuột, kết quả là một scrollbar hoàn chỉnh với đầy đủ chức năng của MVC.
Hình 20 Minh họa mô hình Model-View-Control
3.2.2 Các thành phần giao diện ( User Interface Component)
Component là đối tượng hiển thị được trên giao diện và có khả năng tương tác với , người dùng Ví dụ: một nút (button), combo box, …
Dưới đây là hệ thống các thành phần giao diện mà LWUIT cung cấp
Hình 21 Các thành phần giao diện của LWUIT
• Lớp Component: là lớp cha của tất các các lớp khác mà LWUIT cung cấp Như vậy bất kỳ một đối tượng nào cũng có thể gọi là component.
Lớp Container là một đối tượng có khả năng chứa đựng các đối tượng khác hoặc thậm chí là các đối tượng container khác Các thành phần bên trong container được sắp xếp theo nhiều cách khác nhau, chẳng hạn như theo hàng, cột, hoặc căn trái, phải, mang lại sự linh hoạt trong việc thiết kế giao diện.
Bằng cách đưa các component vào các container khác nhau, người lập trình có thể bố trí layout của màn hình giao diện theo cách họ mong muốn
Lớp Form là một container bao gồm TitleBar và MenuBar, trong đó TitleBar là hộp tiêu đề và MenuBar chứa các lệnh cùng menu Khoảng không giữa TitleBar và MenuBar được sử dụng để chứa các thành phần khác như Button, Text area, và List Hình vẽ dưới đây minh họa một form với TitleBar.
“Form Title” , MenuBar chứa lệnh Exit, và bên trong Form chứa nội dung văn bản: “This space is for the Content pane”.
• Lớp TabbedPane: tabbed Pane là một container cho phép hiển thị đồng thời nhiều nhóm các component Mỗi nhóm các component sẽ được ánh xạ với một tab
• Lớp Calendar: cung cấp thông tin cùng với các phương thức liên quan tới thời gian, ngày tháng năm.
LWUIT offers various classes such as TextArea and TextFile for displaying text content, while List and ComboBox classes are used for showcasing component lists Additionally, it includes Label, Button, and CheckBox classes for rendering interactive buttons.
Hình 25 Minh họa Button,TextArea,List,ComboBox
3.2.3 Các thành phần hỗ trợ ở mức thấp
Một ứng dụng thường bao gồm nhiều thành phần như thư viện, file ảnh, font và theme, được gọi là tài nguyên của ứng dụng LWUIT hỗ trợ việc đóng gói tất cả các tài nguyên này thành một file nhị phân đi kèm với ứng dụng.
Các kiểu tài nguyên mà LWUIT cho phép bao gồm:
LWUIT cung cấp tính năng tiện lợi cho lập trình viên thông qua LWUIT Designer, cho phép tạo ra các tài nguyên liên quan đến ứng dụng Tính năng này tương tự như việc tạo file CSS để định dạng cho các trang web trong ứng dụng web.
Lớp Layout Manager dùng để bố trí các component trong một container Các kiếu bố trí mà LWUIT hỗ trợ bao gồm:
-BorderLayout: bố trí các component trên một container thành 5 phần: ở giữa (center), trên (south),dưới (north), trái (west), phải (east)
Hình 26 BorderLayout -BoxLayout:bố trí các component theo hàng hoặc cột
-FlowLayout:bố trí các component lần lượt từ trái qua phải, từ trên xuống dưới
Mobile Acces Và SaaSMobile Client
Kiến trúc hệ thống Mobile Access
4.1.1 Hoạt động của hệ thống Mobile Access
Hệ thống Mobile Access nhằm mục đích cung cấp một phương thức phân phối phần mềm mới, cho phép người dùng lựa chọn dịch vụ qua giao diện web Các dịch vụ này sẽ được tự động cập nhật trên các thiết bị di động, mang lại sự tiện lợi và hiệu quả cho người sử dụng.
Hình 31 Mô tả hoạt động của hệ thống
Hoạt động của hệ thống dưới góc độ người dùng được mô tả như sau:
- Người dùng truy cập vào địa chỉ cung cấp dịch vụ
The system will prompt users to enter their username and password for authentication This authentication process is integrated with the existing authentication system of France Telecom.
- Sau khi xác thực thành công, người dùng được chuyển tới quầy dịch vụ (Rich Internet Application -RIA builder) Ở quầy dịch vụ này, người dùng sẽ lựa chọn
Sau khi hoàn tất việc lựa chọn, các ứng dụng được chọn sẽ tự động cập nhật trên thiết bị của người dùng thông qua kết nối mạng.
Chúng ta có thể thấy rõ hơn mô hình trên khi so sánh với việc mua hàng hóa ở siêu thị như trong sơ đồ sau
Hình 32 So sánh với mô hình cung cấp hàng hóa
Khác với phương pháp phân phối ứng dụng truyền thống trên thiết bị di động, nơi người dùng cần tải về và cài đặt ứng dụng, mô hình mới cho phép cung cấp
Ngoài người sử dụng, hệ thống còn bao gồm nhiều tác nhân khác, và sự hiện diện của các tác nhân này được minh họa rõ nét qua biểu đồ use case tổng quan dưới đây.
Hình 33 Biểu đồ Use case của hệ thống Mobile Access
Mô tả các tác nhân:
Tên tác nhân Mô tả
Mobile end users access services on their mobile devices, while portal end users utilize services both on mobile devices and through a portal Customer administrators manage the portal, setting up and overseeing applications and accounts for end users.
Quản trị viên Orange trên hệ thống portal chịu trách nhiệm quản lý hệ thống và các dịch vụ thanh toán, bao gồm việc tính cước ngoài Đội ngũ hỗ trợ Orange đảm nhận công việc chăm sóc khách hàng Hệ thống thông tin là tác nhân bên ngoài tương tác với hệ thống Mobile Access API dịch vụ Mobile Orange có khả năng tương tác hiệu quả với hệ thống Mobile Access.
Hệ thống Mobile Access cần thực hiện các công việc quan trọng để phục vụ người sử dụng cuối (mobile user), bao gồm việc cung cấp thông tin dễ dàng, đảm bảo tính bảo mật và hỗ trợ truy cập nhanh chóng.
UC- MOB - 006 UC- MOB - 005 UC- MOB - 004 UC- MOB - 003 UC- MOB - 002
Hình 34 Biểu đồ UseCasecủa người dùng cuối
UC-MOB 001- Xác thực với hệ thống
UC-MOB 002- Load dịch vụ về thiết bị
UC-MOB 003- Lựa chọn sử dụng một dịch vụ
UC-MOB 004- Thao tác yêu cầu đối với dịch vụ
UC-MOB 005- Gửi yêu cầu
UC-MOB 006- Nhật kết quả
Bảng Mô tả tác nhân3
4.1.2 Kiến trúc hệ thống Mobile Access Để đáp ứng các yêu cầu trên, kiến trúc thành phần hệ thống Mobile Access bao gồm các thành phần như sau : [9]
Hình 35 Kiến trúc thánh phần hệ thống Mobile Access
• Mobile Designer DashBoard: Thành phần hiển thị các dịch vụ và cho phép user lựa chọn các dịch vụ theo yêu cầu
API Đồng Bộ Hóa Di Động Orange: Chịu trách nhiệm tương tác với các dịch vụ mới, đồng bộ hóa dữ liệu và cung cấp dịch vụ đến các thiết bị di động.
• Passerelle: Thành phần được tích hợp từ các hệ thống sử dụng các Orange API có sẵn
• Các API mà Mobile Access cung cấp thêm bao gồm : Orange Mobile Data Management API, Orange Mobile Configuration API, Orange Enterprise Data Exchange API.
Xây dựng ứng dụng SaaSMobile Client trên thiết bị di động
Trong luận văn này, chúng tôi tập trung vào việc nghiên cứu công nghệ và các thành phần của hệ thống cung cấp dịch vụ ứng dụng cho thiết bị di động trong dự án Mobile Access Các kiến thức liên quan đến mô hình phần mềm dịch vụ (SaaS), công nghệ J2ME, framework LWUIT, Orange APIs, và hệ thống Mobile Access đã được trình bày chi tiết trong các chương trước.
Trong mục này, luận văn sẽ trình bày về qui trình xây dựng ứng dụng trên thiết bị di động
4.2.1 Giới thiệu SaaSMobile Client Đứng dưới góc nhìn của người sử dụng, hệ thống cung cấp dịch vụ cho các thiết bị di động gồm hai phần rõ ràng, bao gồm:
-Hệ thống phía nhà cung cấp: đảm nhiệm vai trò cung cấp dịch vụ, chương trình, dữ liệu cho các thiết bị di động
Phần mềm trên thiết bị di động (SaaSMobile Client) hoạt động như một trình duyệt cho các ứng dụng web, cung cấp môi trường cần thiết để triển khai các dịch vụ trên thiết bị di động.
Hình 36 SaaSMobile Client: Mô tả hoạt động
Sau khi xác thực, người dùng có thể cấu hình và lựa chọn dịch vụ từ nhiều tùy chọn của nhà cung cấp thông qua mô đun RIA Builder RIA Builder sẽ gửi thông tin các dịch vụ đã chọn tới SaaSMobile Client Dựa trên dữ liệu này, SaaSMobile Client tự động tạo ra các ứng dụng trên thiết bị di động, cho phép người dùng truy cập và sử dụng các dịch vụ của nhà cung cấp một cách thuận tiện.
4.2.2 Phân tích thiết kết SaaSMobile Client
4.2.1 Mô hình hóa yêu cầu bằng biểu đồ Ca sử dụng (Use case
Hình 37 Biểu đồ ca sử dụng SaaSMobileClient
-SMS (Sort message service): Dịch vụ nhắn tin ngắn
-MMS (Multimedia message service): Dịch vụ tin nhắn đa phương tiện
-Contact:Dịch vụ liên quan tới danh bạ như: lưu danh bạ lên server, thêm, bớt địa chỉ,
-Navigation: Dịch vụ dẫn đường Người dùng sẽ nhận được thông tin chỉ hướng dưới dạng văn bản hoặc dưới dạng đồ họa (bản đồ có đánh dấu hướng)
-Update Service: Cập nhật các dịch vụ trên thiết bị di động khi người dùng thêm hoặc bớt các dịch vụ trên web cấu hình dịch vụ.
-Other Services:Các dịch vụ khác như Unlimited SMS, Calendar, eMail, Photo,…
Số lượng dịch vụ tùy thuộc vào nhà cung cấp
4.2.2 Kiến trúc thành phần của SaaSMobile Client Để đáp ứng các chức năng trên, mô hình của SaaSMobile Client được xây dựng gồm các mô đun như trong hình vẽ sau:
Hình 38 Kiến trúc thành phần của SaaSMobile Client
XML parsing involves reading data from XML files to extract service descriptions and the data sent from the server regarding those services.
-Connector: thực hiện quản lý các kết nối dựa trên giao thức http.
Quy trình ứng dụng bao gồm việc thực hiện các bước xử lý nội bộ nhằm đảm bảo các chức năng dịch vụ được cung cấp cho người dùng, chẳng hạn như xử lý sự kiện, lưu trữ và truy xuất dữ liệu từ hệ thống RMS.
UI Generator sử dụng dữ liệu được trích xuất từ XML Parsing để tạo ra các thành phần giao diện như form, button, textarea, checkbox và list thông qua các hàm của LWUIT.
-Mobile User: lưu thông tin và thực hiện các thao tác liên quan tới người sử dụng thiết bị di động.
4.2.3 Biểu đồ gói tương ứng với kiến trúc
Các mô đun trên được thiết kế thành các gói, trong mỗi gói có các lớp chính thực hiện chức năng của mô đun đó.
Gói Lớp chính Mô tả
Bóc tách các mô tả dữ liệu gửi về từ Server
Connector Http handle, RMSconnect; Thực thi và quản lý các kết nối tới
Server và Hệ thống lưu trữ RMS AppProcess MainService Thực hiện các tác vụ của dịch vụ
UI DynamicMenu Tạo ra các phần tử giao diện
User MUser Quản lý thông tin User
4.2.4 Biểu đồ tiến trình (Sequency Diagram)
• Cập nhật các dịch vụ:
:MUser :MainService :HttpHandle :ConfClientParser :DynamicMenu
Lấy dữ liệu từ Xml file
Lưu Mô tả thành phần UI
Mô tả thành phần UI :RMSConnect
Hình 40 Biểu đồ tiến trình Cập nhật các dịch vụ
• Khởi tạo dịch vụ (SMS, MMS, Contact,…):
Yêu cầu mô tả dịch vụ
Mô tả thành phần UI :RMSConnect
• Sử dụng dịch vụ (SMS, MMS, Contact, )
Lấy mô tả phần tử UI và dữ liệu Yêu cầu hiển thị
Hình 42 Biểu đồ tiến trìnhSử dụng dịch vụ
4.2.5.1 Biểu đồ các lớp chính của gói XMLParsing
Hình 43 Biểu đồ lớp gói XMLParsing
• Lớp KXmlParser: Là lớp đối tượng cung cấp các phương thức để thực
KXmlParser sẽ đưa ra các thông báo đó là thẻ bắt đầu hay kết thúc, và các thuộc tính của thẻ
Lớp KXmlParsePlus là một lớp đối tượng kế thừa từ KXmlParser, được thiết kế để xử lý file dữ liệu XML với nhiều loại thuộc tính khác nhau, bao gồm thuộc tính của dịch vụ và thuộc tính của các phần tử giao diện Để phân loại các loại dữ liệu hiệu quả, KXmlParsePlus bổ sung hai phương thức chính.
The ConfClientParser class works in conjunction with the KXmlParserPlus class to read configuration files, typically named ConfClient.xml, received from the server It subsequently stores specifications related to services and user interface elements into vectors.
Lớp Params là một đối tượng với các thuộc tính tương tự như tham số trong file XML, được sử dụng để lưu trữ các đặc tả của các thành phần giao diện người dùng trong quá trình bóc tách dữ liệu.
Lớp ElementaryService là một đối tượng chứa các thuộc tính tương tự như các tham số dịch vụ trong file XML Đối tượng này được sử dụng để lưu trữ các đặc tả của dịch vụ trong quá trình bóc tách dữ liệu.
4.2.5.2 Biều đồ các lớp chính của gói Connector
Hình 44 Biểu đồ lớp gói Connector
• Lớp HttpHandle: Quản lý kết nối từ MobileClient tới Server, lấy các dữ liệu dưới dạng XML từ server, gửi các tham số từ MobileClient lên server
Lớp RMSConnect quản lý kết nối tới hệ thống lưu trữ RMS (Record Store System) của thiết bị di động, cho phép lưu trữ các mô tả dịch vụ và các phần tử giao diện người dùng Nó cũng có khả năng lấy các mô tả từ RMS để cung cấp cho gói UIGenerator.
4.2.5.3 Biểu đồ các lớp chính gói UI (User Interface Generator)
Hình 45 Biểu đồ lớp gói UI
Lớp FlowLayoutScroll cung cấp các phương thức để điều chỉnh kích thước tương đối của các phần tử giao diện đồ họa, giúp tối ưu hóa trải nghiệm người dùng trên màn hình thiết bị di động.
• Lớp MyComponent:Lớp các đối tượng giao diện người sử dụng
• MyTextField: Lớp các đối tượng chứa văn bản
Lớp MyForm là một lớp kế thừa từ lớp form truyền thống của LWUIT, được thiết kế đặc biệt để xử lý các đối tượng form Lớp này cung cấp thêm các phương thức và thuộc tính nhằm hỗ trợ hiển thị các phần tử được trích xuất từ file dữ liệu XML.
Tích Hợp Orange APIs Vào Hệ Thống Mobile Access
Giới thiệu Orange APIs
Orange API là một hệ thống API cho phép các nhà phát triển bên thứ ba cung cấp dịch vụ cho khách hàng của Orange, dựa trên nền tảng của France Telecom Mục tiêu của mô hình này là tạo cơ hội cho việc phát triển và bán dịch vụ cho các đối tác, đồng thời nâng cao chất lượng dịch vụ mà Orange cung cấp cho khách hàng.
Hiện tại Orange đang cung cấp một hệ thống API rất phong phú và được chia thành ba loại sau [ ]10 : Personal API, Instant API, và Advanced API.
API cá nhân cho phép lập trình viên phát triển ứng dụng web, giúp khách hàng của Orange truy cập thông tin cá nhân như lịch làm việc, danh bạ, ảnh cá nhân và tin nhắn.
Authentication API API để thực hiện các thao tác xác thực người dùng
Tất cả các dịch vụ đều cần sử dụng API này API lịch cá nhân cho phép người dùng xem lịch làm việc, cũng như thêm, xóa và thay đổi các sự kiện API danh bạ cá nhân cho phép người dùng quản lý danh bạ, bao gồm việc thêm, bớt và sửa đổi các mục API nội dung cá nhân cung cấp quyền truy cập vào dịch vụ “Mes données” (http://mesdonnees.orange.fr) và API yêu thích cá nhân giúp người dùng lưu trữ các mục ưa thích.
Here is a rewritten paragraph that complies with SEO rules:The API enables users to access the "Mes favoris" service, allowing them to manage their personal messages, send and receive emails, and create photo albums, adding and organizing personal photos with ease.
,sửa, bớt các ảnh personal profile API API cho phép người dùng truy cập và thao tác với hồ sơ cá nhân của họ.
API tức thì cho phép lập trình viên phát triển ứng dụng web, giúp khách hàng của Orange gửi tin nhắn SMS, thực hiện cuộc gọi, gửi email và voicemail một cách dễ dàng.
SMS API API cho phép người dùng gửi tin nhắn
API SMS cho phép người dùng thực hiện các cuộc gọi, trong khi API location giúp xác định vị trí của họ API email hỗ trợ gửi và nhận email, còn API voicemail cho phép gửi và nhận thư thoại API voicemashup cung cấp khả năng sử dụng các dịch vụ thoại khác nhau Cuối cùng, nền tảng mobeasy API được thiết kế để tạo ra các website phục vụ người dùng di động.
API nâng cao của hệ thống Orange hỗ trợ các nhà phát triển tích hợp và khai thác những tính năng tiên tiến như hội thảo từ xa, hệ thống thông tin địa lý
API nâng cao cho phép người dùng truyền tải thông tin như SMS và đa phương tiện đến nhiều thuê bao khác Nhà phát triển có thể sử dụng API này để cung cấp dịch vụ hội thảo trực tuyến API cho phép người dùng xem thông tin về khả năng thiết bị di động của họ Ngoài ra, API định vị và chỉ đường giúp người dùng di động tìm kiếm vị trí Cuối cùng, API gửi tin nhắn SMS qua các giao thức mạng Internet và API thực hiện cuộc gọi cho phép người dùng kết nối dễ dàng.
Sử dụng Orange APIs
Các API của Orange hỗ trợ phát triển ứng dụng web, cung cấp cho người dùng dịch vụ từ SMS, danh bạ, lịch làm việc đến các dịch vụ cao cấp như hội thảo và tìm đường Luồng làm việc của bất kỳ ứng dụng nào sử dụng Orange API được xác định rõ ràng.
Hình 52 Minh họa sử dụng Orange API
Bước 1: Người dùng truy cập vào website cung cấp dịch vụ
Bước 2: Người dùng được chuyển tới trang xác thực của Orange thông qua
Bước 3 (tùy chọn): Người dùng phải thực hiện các thao tác xác thực nếu các dịch vụ khác yêu cầu
Bước 4: Người dùng sử dụng các dịch vụ
Bước 5, 6: Các yêu cầu dịch vụ, thông qua API được gửi tới hệ thống của Orange
Tích hợp Orange API vào hệ thống Mobile Access
Hiện nay, hệ thống Orange API đang trong giai đoạn triển khai phiên bản an pha và bê thống Mobile Access Để tích hợp Orange APIs vào hệ thống Mobile Access, nhóm phát triển đã đề xuất xây dựng một thành phần middleware có tên là Paserelle, hoạt động như cầu nối giữa SaaS GateWay 0F 1 và hệ thống cung cấp Orange APIs.
Hình 53 Kiến trúc thành phần của Paserelle
Mô-đun Xác thực Di động nhận thông tin xác thực của người dùng và kết hợp với mô-đun Kết nối để sử dụng API xác thực, từ đó tạo ra một chuỗi thẻ (token string) Thẻ này cho phép người dùng thực hiện các thao tác tiếp theo mà không cần phải đăng nhập lại vào hệ thống.
Ứng dụng phản hồi nhận yêu cầu từ người dùng, chuyển đổi thành dữ liệu XML thông qua SaaS GateWay Kết hợp với mô-đun Connector, ứng dụng sử dụng Orang API để trả lại kết quả dưới dạng file XML cho SaaS GateWay.
• Synchronization: thực hiện đồng bộ hóa dữ liệu giữa Parselle và SaaSGateWay sử dụng nên tảng Funambol 11[ ]
1 Xem Hình 35: Kiến trúc thành phần của hệ thống Mobile Access
Kết quả triển khai
Luận văn tập trung vào việc tích hợp Orange APIs vào hệ thống, với mục tiêu tìm hiểu và xây dựng thử nghiệm các ứng dụng web sử dụng Orange API Đồng thời, luận văn cũng đề cập đến việc gửi dữ liệu từ người dùng và kết quả đầu ra của các ứng dụng đến SaaS GateWay Dưới đây là một số hình ảnh minh họa cho các thử nghiệm đã được triển khai.
Hình 54 Danh mục các ứng dụng sử dụng Personal APIs
Hình 55 Người dùng thực hiện xác thực đối với hệ thống
Hình 56 Thêm sự kiện vào lịch làm việc
Hình 57 Thêm danh bạ vào sổ địa chỉ