T2 — Chương 2 Cơ Sở Lý Thuyết (Kiến Trúc) - congsinhv/fluxion GitHub Wiki
Chương 2: Cơ Sở Lý Thuyết
Issues: #12, #10, #11, #13, #14, #15, #16, #19 Tuần: 2–3 | 31/03 – 13/04/2026
Chương này trình bày nền tảng lý thuyết cho hệ thống Fluxion MDM, bao gồm: tổng quan về Quản lý Thiết bị Di động (MDM), kiến trúc phần mềm (EDA, Microservices, Serverless, Cloud-Native), design patterns (Saga, CQRS, FSM), ứng dụng Mô hình Ngôn ngữ Lớn (LLM) cho trợ lý thông minh, và khảo sát giải pháp MDM hiện có trên thị trường.
Bối cảnh ứng dụng: Điện thoại trả góp / cho thuê doanh nghiệp
Fluxion được thiết kế cho use case cốt lõi: quản lý điện thoại trả góp / cho thuê tại thị trường Việt Nam (FPT Shop, Thế Giới Di Động, MobiFone, Viettel Post, v.v.). Vấn đề thực tế: công ty bán iPhone trả góp 24 tháng, nếu khách ngừng trả nhưng đã cầm máy → công ty mất cả máy lẫn tiền (~$1,000/máy × hàng nghìn máy = rủi ro thất thoát > $10M/năm).
Fluxion giải quyết:
- Push MDM profile vào máy trước khi giao khách → kích hoạt vòng đời
idle → registered → enrolled → active - Khách đóng đủ hàng tháng → giữ
active; khách trễ hạn → admin lock từ xa (active → locked) kèm popup fullscreen nhắc nợ - Khách thanh toán → admin unlock (
locked → active), khách dùng tiếp bình thường, data giữ nguyên - Khách hoàn thành đủ kỳ trả góp (24/24) → hệ thống
release→ unenroll MDM → máy thành 100% sở hữu khách (graduation, không wipe data)
Các mục trong chương này — từ kiến trúc hướng sự kiện tới Finite State Machine — đều phục vụ trực tiếp workflow trên. Các tính năng phụ (compliance audit, enterprise BYOD, anomaly detection) là value-add bonus nhưng không phải target chính.
Mục Lục Chương 2 (Master)
| Mục | Nội dung | Wiki Page | Trạng thái |
|---|---|---|---|
| 2.1 | Tổng quan về MDM | Trang này (bên dưới) | ✅ |
| 2.2 | Kiến trúc hướng sự kiện (EDA) | T2 — Kiến trúc hướng sự kiện (EDA) | ✅ |
| 2.3 | Microservices và Serverless Computing | T2 — Microservices và Serverless Computing | ✅ |
| 2.4 | Cloud-Native Applications | T2 — Microservices và Serverless Computing (mục cuối) | ✅ |
| 2.5 | Choreography-based Saga Pattern | T3 — Choreography-based Saga Pattern | ✅ |
| 2.6 | CQRS Pattern | T3 — CQRS Pattern | ✅ |
| 2.7 | Finite State Machine và Harel Statechart | T3 — Finite State Machine và Harel Statechart | ✅ |
| 2.8 | NLP và Large Language Models | T3 — NLP và Large Language Models cho Trợ Lý Thông Minh | ✅ |
| 2.9 | Khảo sát giải pháp MDM hiện có | T3 — Khảo sát giải pháp MDM hiện có | ✅ |
Lưu ý: Mỗi wiki page có internal numbering riêng (phục vụ viết chi tiết). Bảng trên là numbering chính thức cho luận văn. Khi consolidate sang Word/LaTeX, sử dụng numbering từ bảng này.
Phụ lục — Hướng phát triển tương lai:
- T2 — Anomaly Detection trong IoT và MDM — Nghiên cứu Isolation Forest cho phát hiện bất thường thiết bị (đã nghiên cứu, không triển khai trong phạm vi đồ án). Xem #18.
Tổng quan nội dung (~25–30 trang khi consolidate)
- Mục 2.1–2.4 (Kiến trúc): MDM, EDA, Microservices, Serverless, Cloud-Native — nền tảng kiến trúc hệ thống
- Mục 2.5–2.7 (Design Patterns): Saga (xử lý lệnh phân tán), CQRS (tách read/write), FSM (vòng đời thiết bị) — patterns áp dụng trực tiếp trong Fluxion
- Mục 2.8 (AI/ML): NLP/LLM — ứng dụng LLM tăng cường công cụ (Tool-Augmented LLM) cho trợ lý thông minh MDM
- Mục 2.9 (Khảo sát): So sánh Jamf Pro, Intune, MicroMDM, Fleet, Mosyle, Kandji — gap analysis cho Fluxion
2.1 Tổng Quan về Mobile Device Management (MDM)
2.1.1 Định Nghĩa MDM
Mobile Device Management (MDM) là một giải pháp phần mềm cho phép các tổ chức giám sát, quản lý và bảo mật từ xa các thiết bị di động (smartphone, tablet, laptop) sử dụng trong môi trường doanh nghiệp [2]. MDM hoạt động theo mô hình client-server: một phần mềm agent hoặc management profile được cài đặt trên thiết bị, giao tiếp với máy chủ quản lý trung tâm thông qua giao thức bảo mật (HTTPS) để nhận chính sách, lệnh, và báo cáo trạng thái [9].
Theo Viện Tiêu chuẩn và Công nghệ Quốc gia Hoa Kỳ (NIST), MDM là thành phần trung tâm trong chiến lược bảo mật thiết bị di động doanh nghiệp, đảm nhiệm vai trò kiểm soát truy cập, thực thi chính sách, và ứng phó sự cố từ xa [2].
2.1.2 Lịch Sử Phát Triển: MDM → EMM → UEM
Sự phát triển của quản lý thiết bị di động doanh nghiệp trải qua ba giai đoạn chính [8][11]:
| Giai đoạn | Thời kỳ | Đặc điểm | Ví dụ |
|---|---|---|---|
| MDM (Mobile Device Management) | 2000–2012 | Quản lý thiết bị ở mức hệ điều hành: lock, wipe, policy enforcement. Bắt đầu với BlackBerry Enterprise Server (BES, 1999) cho BlackBerry, mở rộng sang iOS/Android khi smartphone bùng nổ từ 2007 | BlackBerry BES, Good Technology |
| EMM (Enterprise Mobility Management) | 2012–2017 | Mở rộng sang quản lý ứng dụng (MAM), nội dung (MCM), và danh tính (MIM). Gartner đề xuất thuật ngữ EMM để phản ánh phạm vi rộng hơn | AirWatch, MobileIron |
| UEM (Unified Endpoint Management) | 2017–nay | Hợp nhất quản lý tất cả endpoints (mobile, desktop, IoT) trong một nền tảng duy nhất. Hội tụ MDM + EMM + PC management | Microsoft Intune, VMware Workspace ONE |
Trong nghiên cứu này, thuật ngữ MDM được sử dụng theo nghĩa gốc — tập trung vào quản lý thiết bị di động (device-level management) — phù hợp với phạm vi đồ án.
2.1.3 Các Chức Năng Cốt Lõi của MDM
Tác giả tổng hợp từ tài liệu Apple Developer Documentation [1], NIST SP 800-124 [2], và các nguồn công nghiệp [5][8] thành bảy nhóm chức năng cốt lõi trong vòng đời quản lý thiết bị:
1. Đăng ký thiết bị (Device Enrollment) Bước đầu tiên trong vòng đời quản lý — thiết bị được liên kết với máy chủ MDM thông qua xác thực certificate. Mỗi nền tảng có phương thức riêng: Apple sử dụng Automated Device Enrollment (ADE), Apple Configurator, hoặc đăng ký thủ công (manual enrollment); Android hỗ trợ Android Enterprise Zero-Touch; Windows dùng Azure AD Join [1][2].
2. Quản lý cấu hình (Configuration Profiles)
MDM triển khai cấu hình lên thiết bị thông qua configuration profiles — các tệp khai báo (declarative) chứa cài đặt mạng (Wi-Fi, VPN), email, certificate, và hạn chế tính năng. Trên iOS, đây là các tệp .mobileconfig tuân theo định dạng XML property list [1].
3. Thực thi chính sách bảo mật (Security Policy Enforcement) Áp dụng chính sách bảo mật bắt buộc trên thiết bị: yêu cầu mật khẩu phức tạp, mã hóa dữ liệu (FileVault, Data Protection), vô hiệu hóa tính năng không an toàn (camera, Bluetooth, AirDrop), kiểm soát cài đặt ứng dụng [1][2].
4. Lệnh từ xa và truy vấn (Remote Commands & Queries) Apple MDM phân biệt rõ hai loại thao tác từ xa [1]:
- Commands (lệnh): Thay đổi trạng thái thiết bị — DeviceLock, EraseDevice, RestartDevice, InstallProfile, RemoveProfile
- Queries (truy vấn): Chỉ đọc thông tin — DeviceInformation, InstalledApplicationList, SecurityInfo, CertificateList
Sự phân biệt này quan trọng vì queries an toàn (idempotent), trong khi commands yêu cầu xác nhận và kiểm soát quyền.
5. Quản lý ứng dụng (Application Management / MAM) Phân phối, cập nhật và thu hồi ứng dụng trên thiết bị. Apple cung cấp Volume Purchase Program (VPP, nay là Apple Business Manager — Apps and Books) cho phép mua và phân phối ứng dụng hàng loạt mà không cần Apple ID cá nhân [1].
6. Quản lý hàng tồn kho (Inventory & Compliance) Thu thập thông tin chi tiết thiết bị: số serial, phiên bản OS, danh sách ứng dụng, mức pin, dung lượng lưu trữ, thuộc tính phần cứng. Thông tin này phục vụ kiểm toán (audit), đánh giá tuân thủ chính sách, và phát hiện thiết bị vi phạm [2].
7. Quản lý vòng đời (Device Lifecycle Management) Quản lý toàn bộ vòng đời thiết bị: triển khai ban đầu (provisioning), duy trì hoạt động (maintenance), cập nhật phần mềm (OS update), và thu hồi an toàn (unenrollment/wipe) khi thiết bị hết hạn sử dụng hoặc nhân viên rời tổ chức [1][2].
2.1.4 Chế Độ Giám Sát Thiết Bị Apple (Supervised vs Unsupervised)
Trên hệ sinh thái Apple, khả năng quản lý MDM phụ thuộc trực tiếp vào chế độ giám sát (supervision mode) của thiết bị [1]:
| Khả năng | Unsupervised | Supervised |
|---|---|---|
| Khóa thiết bị (DeviceLock) | ✅ | ✅ |
| Xóa dữ liệu (EraseDevice) | ✅ | ✅ |
| Cài đặt profile cấu hình | ✅ | ✅ |
| Hạn chế ứng dụng (App Blacklist) | ❌ | ✅ |
| Single App Mode (Kiosk) | ❌ | ✅ |
| Thay đổi wallpaper | ❌ | ✅ |
| Tắt Activation Lock | ❌ | ✅ |
| Xóa MDM profile bởi người dùng | ✅ (có thể xóa) | ❌ (không thể xóa) |
Bảng 2.1: So sánh khả năng MDM theo chế độ giám sát [1]
Thiết bị supervised (được giám sát) — thường là thiết bị thuộc sở hữu doanh nghiệp, đăng ký qua ADE — cho phép MDM server kiểm soát toàn diện hơn, bao gồm các tính năng mà thiết bị unsupervised không hỗ trợ [1]. Sự phân biệt này ảnh hưởng trực tiếp đến thiết kế hệ thống MDM khi xác định phạm vi lệnh khả dụng.
2.1.5 Kiến Trúc Tổng Quan Hệ Thống MDM
Kiến trúc MDM tuân theo mô hình client-server bao gồm năm thành phần chính [1][2][9]:
1. Máy chủ quản lý (MDM Server) Thành phần trung tâm lưu trữ chính sách, hàng đợi lệnh, thông tin thiết bị, và xử lý logic nghiệp vụ. MDM server tiếp nhận yêu cầu từ admin console, xếp lệnh vào hàng đợi, và phối hợp với kênh push notification để kích hoạt thiết bị [2].
2. Tác nhân trên thiết bị (MDM Agent / Management Profile) Thành phần phía thiết bị chịu trách nhiệm nhận lệnh, thực thi, và báo cáo kết quả. Trên iOS, MDM agent được tích hợp sẵn trong hệ điều hành (không cần cài app riêng) — kích hoạt thông qua MDM enrollment profile chứa certificate xác thực [1].
3. Kênh thông báo đẩy (Push Notification Channel) Kênh giao tiếp bất đồng bộ để kích hoạt thiết bị check-in với server. Mỗi nền tảng sử dụng dịch vụ push riêng:
| Nền tảng | Dịch vụ Push | Giao thức |
|---|---|---|
| Apple iOS/macOS | Apple Push Notification Service (APNS) | HTTP/2, certificate-based |
| Android | Firebase Cloud Messaging (FCM) | HTTPS, token-based |
| Windows | Windows Push Notification Service (WNS) | HTTPS, OAuth-based |
Bảng 2.2: Kênh push notification theo nền tảng [1][12][13]
4. Cơ sở hạ tầng chứng chỉ số (Certificate Infrastructure) MDM yêu cầu hạ tầng PKI (Public Key Infrastructure) cho xác thực hai chiều (mutual TLS): server certificate, client certificate (per-device), và push certificate (per-platform). Trên Apple, MDM server cần Apple Push Certificate từ Apple Push Certificates Portal [1].
5. Bảng điều khiển quản trị (Admin Console) Giao diện web hoặc desktop cho phép quản trị viên xem trạng thái thiết bị, phát hành lệnh, cấu hình chính sách, quản lý người dùng, và tạo báo cáo [2].
2.1.6 Giao Thức Apple MDM (Apple MDM Protocol)
Apple MDM Protocol là giao thức tiêu chuẩn định nghĩa cách thiết bị iOS/iPadOS/macOS giao tiếp với máy chủ MDM, dựa trên HTTPS và sử dụng property lists (plist/XML) để trao đổi dữ liệu [1].
Đặc điểm kỹ thuật chính:
- Xác thực SSL hai chiều (Two-Way SSL/TLS): Cả server và thiết bị phải trình bày certificate hợp lệ. Thiết bị nhận X.509 certificate duy nhất với UDID (Unique Device Identifier) trong trường Subject khi enroll [1].
- Mô hình hàng đợi lệnh (Command Queue Model): Server không "push" lệnh trực tiếp lên thiết bị — lệnh được lưu trong hàng đợi phía server. Khi thiết bị check-in, server trả về lệnh đang chờ xử lý dưới dạng plist [1].
- Check-in kích hoạt bởi APNS: Khi có lệnh mới, server gửi silent push notification qua APNS → thiết bị thức dậy → kết nối HTTPS đến MDM server → lấy lệnh → thực thi → gửi kết quả qua HTTPS response [1].
Ba phương thức đăng ký thiết bị (Enrollment):
| Phương thức | Quy trình | Use Case |
|---|---|---|
| Automated Device Enrollment (ADE/DEP) | Thiết bị được assign trong Apple Business Manager → khi activate, tự động liên hệ Apple servers → nhận MDM server URL → enroll tự động (zero-touch) [1] | Thiết bị doanh nghiệp (COPE), triển khai hàng loạt |
| Apple Configurator | Kết nối USB, cấu hình trực tiếp qua macOS app, cài MDM profile + supervision [1] | Triển khai tại chỗ, thiết bị shared (kiosk, classroom) |
| Đăng ký thủ công (Manual/User Enrollment) | Người dùng mở URL → tải .mobileconfig → cài đặt profile → thiết bị gửi UDID + challenge token đến server → server ký certificate → enrolled [1] |
BYOD, thiết bị cá nhân |
Bảng 2.3: So sánh phương thức đăng ký thiết bị Apple MDM [1]
Vòng lặp lệnh tiêu chuẩn (MDM Command Cycle):
1. Admin gửi yêu cầu lệnh đến MDM Server
2. Server xếp lệnh vào hàng đợi (command queue)
3. Server gửi silent push notification qua APNS
4. Thiết bị nhận push → kết nối HTTPS đến MDM Server
5. Server trả về lệnh (plist) → thiết bị thực thi
6. Thiết bị gửi kết quả qua HTTPS response
7. Nếu còn lệnh trong queue → lặp lại bước 5–6
8. Không còn lệnh → server trả response rỗng → thiết bị ngắt kết nối
Xu hướng: Quản lý Thiết bị Khai báo (Declarative Device Management — DDM)
Apple giới thiệu Declarative Device Management (DDM) từ WWDC 2021, đánh dấu sự chuyển đổi từ mô hình imperative (server ra lệnh cụ thể) sang mô hình declarative (server khai báo trạng thái mong muốn, thiết bị tự thực thi) [10]. DDM cho phép thiết bị chủ động áp dụng và duy trì cấu hình mà không cần server liên tục poll — giảm tải cho cả server và mạng. Tuy Fluxion sử dụng mô hình imperative truyền thống (command queue + APNS), DDM là hướng phát triển đáng lưu ý cho các phiên bản tương lai.
2.1.7 Ứng Dụng MDM Trong Doanh Nghiệp
Mô hình triển khai MDM:
| Khía cạnh | Cloud MDM | On-Premise MDM | Hybrid MDM |
|---|---|---|---|
| Triển khai | SaaS, nhà cung cấp quản lý | Máy chủ tự quản trong data center | Cloud + On-Premise kết hợp |
| Chi phí ban đầu | Thấp (subscription) | Cao (infrastructure, licensing) | Trung bình |
| Khả năng mở rộng | Cao, tự động | Giới hạn bởi infrastructure | Linh hoạt |
| Kiểm soát bảo mật | Phụ thuộc nhà cung cấp | Toàn quyền kiểm soát | Tuỳ chỉnh |
| Độ trễ | Phụ thuộc internet | Thấp (local network) | Biến động |
| Ví dụ | Jamf Cloud, Microsoft Intune | VMware Workspace ONE (self-hosted) | Tổ chức lớn |
Bảng 2.4: So sánh mô hình triển khai MDM [2][5]
Các mô hình sở hữu thiết bị:
- BYOD (Bring Your Own Device): Thiết bị cá nhân nhân viên — MDM phân vùng (containerization) để cách ly dữ liệu doanh nghiệp và cá nhân, cho phép xóa an toàn dữ liệu công ty mà không ảnh hưởng dữ liệu cá nhân [2]
- COPE (Corporate-Owned, Personally-Enabled): Thiết bị thuộc sở hữu doanh nghiệp nhưng cho phép sử dụng cá nhân — MDM kiểm soát toàn diện với phân vùng cho không gian cá nhân [2]
- COBO (Corporate-Owned, Business-Only): Thiết bị doanh nghiệp chỉ dùng cho công việc — MDM kiểm soát hoàn toàn, không có không gian cá nhân [2]
2.1.8 Thách Thức Kỹ Thuật Trong MDM
| Thách thức | Mô tả |
|---|---|
| Khả năng mở rộng (Scalability) | Hàng nghìn thiết bị check-in đồng thời tạo áp lực lớn lên server MDM và cơ sở dữ liệu [2] |
| Phân phối lệnh thời gian thực (Real-time Command Delivery) | Độ trễ từ khi admin gửi lệnh đến khi thiết bị thực thi phụ thuộc vào APNS và trạng thái mạng [1] |
| Kết nối thiết bị không ổn định (Device Connectivity) | Thiết bị di động thường offline hoặc trên mạng không ổn định — cần cơ chế retry và persistence [2] |
| Quản lý chứng chỉ số (Certificate Lifecycle) | APNS certificate hết hạn hàng năm; device certificate cần renew khi enroll lại — mất certificate = mất khả năng quản lý [1] |
| Đồng bộ trạng thái (State Synchronization) | Thiết bị có thể không phản hồi sau khi nhận lệnh — cần cơ chế timeout và callback để đảm bảo nhất quán trạng thái [1] |
Bảng 2.5: Thách thức kỹ thuật trong hệ thống MDM [1][2]
Áp dụng trong Fluxion: Các thách thức trên được giải quyết thông qua kiến trúc cloud-native hướng sự kiện: Lambda auto-scaling cho scalability, APNS + event-driven pipeline cho real-time delivery, SQS persistence + DLQ retry cho device connectivity, và event-driven callback cho state synchronization. Chi tiết kiến trúc và giải pháp được trình bày tại Chương 3 (Phân tích & Thiết kế).
2.2 Kiến Trúc Hướng Sự Kiện (EDA)
Kiến trúc hướng sự kiện (Event-Driven Architecture — EDA) là mô hình kiến trúc phần mềm trong đó các thành phần giao tiếp thông qua việc phát sinh, truyền tải, và xử lý các sự kiện (events) bất đồng bộ [3]. EDA đặc biệt phù hợp cho hệ thống MDM nơi các hành động (lệnh, callback, check-in) diễn ra bất đồng bộ giữa nhiều thành phần phân tán.
Xem chi tiết: T2 — Kiến trúc hướng sự kiện (EDA)
Áp dụng trong Fluxion: Event Producer = Lambda resolvers; Event Channel = SNS fan-out → SQS queues; Event Consumer = Lambda workers xử lý bất đồng bộ. Pattern EDA giải quyết loose coupling giữa các tầng hệ thống.
2.3 Microservices và Serverless Computing
Kiến trúc microservices tổ chức ứng dụng thành tập hợp các dịch vụ nhỏ, độc lập, triển khai riêng biệt, giao tiếp qua API hoặc messaging [3]. Serverless Computing (Function-as-a-Service — FaaS) mở rộng microservices bằng cách loại bỏ hoàn toàn quản lý server — mỗi function được kích hoạt bởi event, tự động scale, và thanh toán theo số lần gọi [7].
Xem chi tiết: T2 — Microservices và Serverless Computing
Áp dụng trong Fluxion: Lambda resolvers phân tách theo domain (microservices); SQS-triggered Lambda workers (serverless FaaS); Cognito, AppSync, SNS, SQS, RDS là managed services (BaaS) thay thế self-built infrastructure.
2.4 Cloud-Native Applications
Ứng dụng cloud-native, theo định nghĩa của Cloud Native Computing Foundation (CNCF), là phần mềm được thiết kế tận dụng tối đa khả năng co giãn (elasticity), tự phục hồi (resilience), và khả năng quan sát (observability) của nền tảng đám mây [6]. Cách tiếp cận này kết hợp microservices, container, orchestration tự động, và API khai báo (declarative APIs).
Xem chi tiết: T2 — Microservices và Serverless Computing (mục 2.7)
Áp dụng trong Fluxion: Hệ thống tuân thủ nguyên tắc cloud-native: Lambda (stateless compute), Terraform (declarative IaC), AppSync (managed API), CloudWatch (observability).
Bảng So Sánh Tổng Hợp: Monolith / Microservices / Serverless / EDA
| Chiều đánh giá | Monolith | Microservices | Serverless (FaaS) | EDA |
|---|---|---|---|---|
| Đơn vị triển khai | Toàn bộ app | Service | Function | Handler/Consumer |
| Coupling | Chặt (tight) | Lỏng (loose) | Lỏng | Rất lỏng (async) |
| Giao tiếp | In-process | HTTP/gRPC | Event trigger | Message/Event |
| Scaling | Toàn bộ app | Per service | Per function | Per consumer |
| Trạng thái | Dễ (shared memory) | Cần thiết kế | Stateless | Stateless consumer |
| Độ trễ | Thấp nhất | Thấp (local network) | Cold start 100ms–3s | Async (không đồng bộ) |
| Fault isolation | Kém | Tốt | Tốt | Rất tốt (DLQ) |
| Chi phí idle | Cao | Cao | Rất thấp | Rất thấp |
| Observability | Dễ | Phức tạp | Phức tạp | Phức tạp |
Bảng 2.6: So sánh tổng hợp các mô hình kiến trúc [3][7]
Áp dụng trong Fluxion: Hệ thống kết hợp cả bốn mô hình: Microservices (Lambda resolvers domain-separated) + Serverless FaaS (event-driven command pipeline) + EDA (SNS/SQS async messaging) + Container (ECS cho inbound callbacks). Đây là kiến trúc cloud-native hybrid phù hợp với đặc thù workload MDM — chi tiết tại T4 — Thiết kế kiến trúc tổng thể.
Sơ Đồ Tổng Quan Kiến Trúc Fluxion
Hình 2.1: Kiến trúc tổng quan hệ thống Fluxion MDM trên AWS — chi tiết tại T4 — Thiết kế kiến trúc tổng thể
Tổng Hợp
Chương 2 xây dựng nền tảng lý thuyết toàn diện cho hệ thống Fluxion MDM. Phần tổng quan MDM (mục 2.1) trình bày lịch sử phát triển từ MDM sang EMM rồi UEM, bảy nhóm chức năng cốt lõi, kiến trúc hệ thống MDM tổng quát (năm thành phần), và giao thức Apple MDM với ba phương thức đăng ký thiết bị (ADE, Configurator, Manual). Sự phân biệt giữa supervised và unsupervised devices, cũng như giữa commands và queries trong Apple MDM, tạo cơ sở cho thiết kế DeviceFSM và Command Pipeline ở các chương sau.
Phần kiến trúc phần mềm (mục 2.2–2.4) tổng hợp bốn mô hình kiến trúc bổ trợ: kiến trúc hướng sự kiện (EDA), microservices, serverless computing, và cloud-native applications. Bảng so sánh tổng hợp (Bảng 2.6) cho thấy mỗi mô hình giải quyết một nhóm yêu cầu phi chức năng khác nhau — EDA cho tính bất đồng bộ, serverless cho khả năng mở rộng, microservices cho tách biệt domain, container cho xử lý inbound ổn định. Sự kết hợp hybrid này phản ánh nguyên tắc cloud-native và tạo nền tảng kỹ thuật vững chắc cho các design pattern (Saga, CQRS, FSM) được trình bày trong phần tiếp theo của chương.
Tài Liệu Tham Khảo
[1] Apple Inc. (2024). MDM Protocol Reference. Apple Developer Documentation. https://developer.apple.com/documentation/devicemanagement/mdm
[2] NIST. (2023). Guidelines for Managing the Security of Mobile Devices in the Enterprise (SP 800-124 Rev. 2). National Institute of Standards and Technology. https://csrc.nist.gov/pubs/sp/800/124/r2/final
[3] Fowler, M., & Lewis, J. (2014). Microservices: A Definition of This New Architectural Term. martinfowler.com. https://martinfowler.com/articles/microservices.html
[4] Botta, A., De Donato, W., Persico, V., & Pescapé, A. (2016). Integration of Cloud Computing and Internet of Things: A Survey. Future Generation Computer Systems, 56, 684–700. https://doi.org/10.1016/j.future.2015.09.021
[5] Fleet Device Management. (2025). What is Apple MDM? How Mobile Device Management Works. https://fleetdm.com/articles/what-is-apple-mdm
[6] CNCF. (2018). Cloud Native Definition v1.0. https://github.com/cncf/toc/blob/main/DEFINITION.md
[7] AWS. (2023). Serverless Applications Lens — AWS Well-Architected Framework. https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/welcome.html
[8] Disterer, G. & Kleiner, C. (2013). BYOD — Bring Your Own Device. Procedia Technology, 9, 43–53. https://doi.org/10.1016/j.protcy.2013.12.005
[9] Rhee, K., Jeon, W., & Won, D. (2012). Security Requirements of a Mobile Device Management System. International Journal of Security and Its Applications, 6(2), 353–358. http://article.nadiapub.com/IJSIA/vol6_no2/49.pdf
[10] Apple Inc. (2024). Declarative Device Management. Apple Developer Documentation. https://developer.apple.com/documentation/devicemanagement/declarative-management
[11] Mobile Mentor. (2024). MDM to EMM to UEM to Modern Management — What a Journey! https://www.mobile-mentor.com/insights/mdm-emm-uem-modern-management-journey/
[12] Google. (2024). Firebase Cloud Messaging — About FCM Messages. Firebase Documentation. https://firebase.google.com/docs/cloud-messaging/concept-options
[13] Microsoft. (2024). Windows Push Notification Services (WNS) Overview. Microsoft Learn. https://learn.microsoft.com/en-us/windows/apps/design/shell/tiles-and-notifications/windows-push-notification-services--wns--overview