arsitektur perangkat lunak

NET303 Jenis kopling saat integrasi melalui database

Basis Data Integrasi atau integrasi melalui basis data adalah pola yang banyak digemari. NET303 Ini adalah pola di mana beberapa aplikasi atau layanan terintegrasi melalui basis data. Dalam kasus ekstrem, tetapi sayangnya tidak jarang terjadi, beberapa aplikasi berbagi tabel dalam basis data yang sama.

apps_sharing_a_column

Dalam postingan ini, saya ingin membahas berbagai jenis NET303 kopling yang tercipta ketika beberapa aplikasi terintegrasi melalui database yang sama. Sangat disarankan agar suatu layanan atau aplikasi memiliki datanya sendiri. Ketika suatu layanan memiliki datanya sendiri, ia menciptakan kontrak eksplisit melalui API yang bisnis-jujur berlawanan dengan kontrak implisit melalui tabel basis data yang implementasinya lebih rinci.

Berikut ini adalah berbagai jenis kopling.

  • Penggabungan skema. Skema basis data bersama harus mengakomodasi kebutuhan semua aplikasi yang mengakses basis data. Ini berarti mendapatkan persetujuan dari semua pengguna saat mengubah skema basis data. Salah satu hasil khusus dari penggabungan skema adalah ketika Anda berakhir dengan tabel yang jarang, di mana kolom-kolom tertentu hanya digunakan oleh satu aplikasi atau sebagian dari aplikasi tersebut. Hal ini menambah beban kognitif tim yang membangun aplikasi yang tidak menggunakan kolom-kolom tersebut.
  • Penggabungan data. Semantik data dalam tabel juga harus selaras di semua aplikasi yang berbeda. Hal ini bisa menjadi rumit seiring waktu karena semantik data sebagian tertanam di dalam basis data dan sebagian lagi di dalam aplikasi. Sering kali, saya melihat status suatu proses yang disimpan di dalam basis data seperti "Dimulai", "Diproses", "Selesai" dan ditafsirkan secara berbeda oleh aplikasi yang berbeda. Mengubah status ini menjadi sangat sulit karena menciptakan efek berantai di semua aplikasi yang menggunakannya. Menambahkan status baru juga bisa sulit.
  • Kopling abstraksi. Ketika sistem dari luar domain mengakses tabel basis data suatu aplikasi, hal ini menciptakan penggabungan abstraksi di mana abstraksi yang terhubung dengan sistem eksternal lebih merupakan detail implementasi daripada abstraksi yang jujur ​​dalam bisnis. Misalnya, ketika pelanggan diperlihatkan inventaris "mentah" dari basis data untuk toko tertentu, padahal yang sebenarnya mereka inginkan adalah inventaris "tersedia untuk dijual" untuk toko tersebut. Inventaris yang tersedia untuk dijual memperhitungkan permintaan toko, inventaris yang hilang, inventaris yang rusak, dan sebagainya. Ketika memperlihatkan inventaris mentah, pelanggan kemudian harus mengakses tabel lain atau membangun logika lain untuk mendapatkan inventaris yang tersedia untuk dijual. Dengan demikian, memperlihatkan abstraksi yang jujur ​​dalam bisnis sebagai layanan seperti inventaris yang tersedia untuk dijual menyembunyikan kompleksitas inventaris di dalam layanan dan menyediakan cara bagi layanan untuk mengembangkan implementasinya seiring waktu. Selain itu, memikirkan antarmuka sistem dengan cara yang jujur ​​dalam bisnis membuat sistem lebih dipahami secara luas dan mengurangi beban kognitif bagi pengembang yang menggunakan abstraksi tersebut. Oleh karena itu, yang terbaik adalah memisahkan antarmuka sistem dari implementasi yang mendasarinya.
  • Penggandengan penyebaran. Sebagai hasil langsung dari penggabungan skema dan data, perubahan basis data harus dikoordinasikan dengan semua sistem yang mengakses basis data. Basis data merupakan detail implementasi sistem. Perubahan pada basis data seharusnya tidak memerlukan koordinasi rilis dengan konsumennya selama antarmuka sistem belum diubah.
  • Penggandengan waktu proses. Ketika beberapa aplikasi mengakses basis data yang sama, sulit untuk melakukan penskalaan atau pengujian kinerja aplikasi-aplikasi tersebut secara terpisah. Untuk mereplikasi "beban produksi" pada suatu aplikasi, Anda harus membuat aktivitas di semua aplikasi yang mengakses basis data tersebut untuk benar-benar memahami kondisi deadlock/race pada aplikasi tersebut. Intinya, akan sangat sulit untuk berkomitmen pada SLA suatu aplikasi karena isolasi antara lalu lintas yang berasal dari berbagai aplikasi sangat minim.

Terima kasih sudah membaca! Komentar/masukan diterima.

Standar
Pemrograman, arsitektur perangkat lunak

Anda akan membuat kesalahan, tapi jangan membuat kesalahan yang mahal!

Saya punya teman pilot, dan seseorang bertanya, "Bukankah sebagian besar kontrol pesawat bekerja dalam mode otomatis? Lalu kenapa gajimu tinggi?". Jawabannya, "Yah, saya tidak dibayar untuk 99% kejadian ketika semuanya berjalan lancar. Saya dibayar untuk 1% kejadian ketika semuanya berjalan buruk, dan dalam hal itu sayalah penentu antara hidup dan mati." Terkadang, saya suka memandang pekerjaan saya sebagai pemimpin teknologi dari sudut pandang itu—dibayar untuk menghindari kesalahan yang paling mahal. Meskipun untungnya, sering kali, saya tidak bertanggung jawab atas keputusan hidup dan mati. 🙂

Idealnya, Anda ingin menghindari semua kesalahan. Namun faktanya adalah, kita tidak bisa menghindari semua kesalahan karena kita kekurangan konteks yang diperlukan, atau keahlian, atau hanya lebar pita. Jadi, apa hal terbaik berikutnya? Saya suka Inilah cara saya. mengkategorikan kesalahan: kesalahan multi juta dolar, satu juta dolar atau kesalahan sub-juta dolar mengkategorikan kesalahan: kesalahan multi juta dolar, satu juta dolar atau kesalahan sub-juta dolar. “Keranjang” ini berasal dari biaya kesalahan yang saya buat secara pribadi atau alami dari pekerjaan sehari-hari saya dalam membangun perangkat lunak, biasanya untuk klien perusahaan besar.

Sekarang pertanyaannya adalah bagaimana kita mengkategorikan kesalahan?

Saya belum menghabiskan cukup waktu untuk memikirkan heuristik untuk Keranjang ini, tetapi saya punya beberapa contoh:

  • Kesalahan bernilai jutaan dolar. Tidak menyusun perangkat lunak Anda berdasarkan konsep bisnis akan menjadi kesalahan yang merugikan jutaan dolar. Kesalahan seperti ini tidak langsung merugikan dan sulit dideteksi. Kesalahan ini secara drastis membatasi kemampuan organisasi untuk berkembang seiring waktu. Saya yakin semua orang melakukan kesalahan ini, beberapa di antaranya tidak terlalu parah, dan sangat penting untuk memperhatikan hal ini. Inilah yang seharusnya diperhatikan secara aktif oleh CTO organisasi.
  • Kesalahan jutaan dolar. Tidak memiliki logika yang tepat di lapisan yang tepat pada aplikasi/layanan Anda akan menjadi kesalahan yang sangat besar. Misalnya, logika domain Anda tertanam dalam basis data dan kini pemrosesan Anda tidak dapat diskalakan hingga Anda menskalakan basis data Anda, yang berarti Anda harus membeli lebih banyak lisensi untuk basis data Anda.
  • Kesalahan di bawah sejuta dolar. Kelas "Tuhan" bisa menjadi contoh kesalahan yang bernilai di bawah jutaan dolar. Dibawah ini sebagian besar fitur bisnis Anda bergantung pada satu kelas dalam basis kode Anda. Menambah fitur bisnis baru atau mempertahankan fitur yang sudah ada memerlukan biaya yang sangat mahal.

Kategorisasi kesalahan memberikan fokus yang diperlukan pada kesalahan yang harus Anda hindari – kesalahan yang paling mahal dan kesalahan lainnya yang dapat Anda tunda atau tangani di "saat terakhir yang bertanggung jawab". Menghindari kesalahan bernilai jutaan dolar membutuhkan perencanaan yang matang.

Kembali ke contoh kita, ketika melihat perangkat lunak tertentu, Anda harus berfokus pada apakah perangkat lunak tersebut disusun berdasarkan konsep bisnis (di mana pemikiran Desain Berbasis Domain dapat sangat membantu), sebelum Anda terlalu jauh menelusuri kode dan mencari kelas Tuhan. Jika Anda meluangkan waktu dengan bijak untuk menghindari kesalahan bernilai jutaan dolar, Anda mungkin masih akan menemukan beberapa kelas Tuhan, tetapi setidaknya biaya perbaikannya tidak akan terlalu mahal.

Standar
Keahlian

Pengujian fitur sebagai dokumentasi interaktif

Pengujian fitur ditulis untuk menguji perilaku perangkat lunak, bukan implementasinya. Pengujian ini sebisa mungkin ditulis dalam bahasa domain yang ramah bisnis. Gherkin adalah bahasa yang umum digunakan untuk menulis pengujian fitur dengan Cucumber sebagai framework yang menjalankannya. Saya menggunakan gherkin/cucumber untuk menulis pengujian fitur, dan dalam tulisan ini, saya akan menggunakan pengujian gherkin dan pengujian fitur secara bergantian.

Penggunaan tes acar sebagai dokumentasi yang dapat dieksekusi merupakan ide yang cukup umum. Yang saya sadari baru-baru ini adalah bahwa tes-tes ini tidak hanya merupakan dokumentasi yang dapat dieksekusi, tetapi juga merupakan dokumentasi interaktif. Mari kita ambil contoh uji fitur yang menguji konversi kuantitas inventaris suatu produk menjadi tingkat inventaris.

Fitur: Ubah jumlah inventaris untuk suatu produk menjadi tingkat inventaris

Diberikan bahwa jumlah persediaan untuk produk dengan SKU “1234567890123” adalah “10”
Dan tingkat persediaan “tersedia” ketika kuantitasnya antara “5” dan “3”
Dan tingkat persediaan “rendah” ketika kuantitasnya berada antara “2” dan “1”
Dan tingkat persediaan “kehabisan stok” ketika kuantitasnya berada antara “0” dan “0”
Kapan Saya mengonversi jumlah inventaris untuk SKU “1234567890123” ke tingkat inventarisnya
Kemudian tingkat persediaan untuk SKU “1234567890123” adalah “tersedia”

Fitur ini memberi saya gambaran yang cukup baik tentang apa yang diharapkan bisnis dan bagaimana fitur tersebut seharusnya diimplementasikan. Jika saya membuat perubahan pada kode untuk fitur ini, dan saya menjalankan pengujian dan berhasil, kemungkinan besar saya tidak mengalami masalah apa pun. Dokumentasi yang dapat dieksekusi, FTW!

Untuk melangkah lebih jauh, yang bisa saya lakukan dengan uji fitur ini adalah berinteraksi dengannya. Katakanlah saya ingin tahu bagaimana kode menangani kondisi batas. Saya bisa dengan mudah mengubah kuantitas di Given dari 10 menjadi 3 dan mengamati apa yang terjadi.

Diberikan that the inventory quantity for a product with SKU “1234567890123” is “3”
Dan tingkat persediaan “tersedia” ketika kuantitasnya antara “5” dan “3”
Dan tingkat persediaan “rendah” ketika kuantitasnya berada antara “2” dan “1”
Dan tingkat persediaan “kehabisan stok” ketika kuantitasnya berada antara “0” dan “0”
Kapan Saya mengonversi jumlah inventaris untuk SKU “1234567890123” ke tingkat inventarisnya
Kemudian tingkat persediaan untuk SKU “1234567890123” adalah “tersedia”

Jika saya mendapat jawaban yang sama seperti sebelumnya yang ada dalam stok maka tampaknya kode tersebut bekerja dengan benar untuk kondisi batas juga, sedangkan jika tidak maka ada bug.

Saya harap contoh yang cukup penting ini bermanfaat untuk memahami apa yang saya maksud dengan dokumentasi interaktif. Saya merasa "penyempurnaan" pengujian ini sangat berguna untuk memahami cara kerja kode atau cara kerjanya.

Untuk waktu yang lama, saya berpikir bahwa jika pemilik produk/analis bisnis tidak terlibat dalam penulisan pengujian fitur, pengujian ini hanya akan menjadi beban. Namun belakangan ini, saya berpendapat bahwa pengujian ini bermanfaat bahkan bagi para pengembang. Jika Anda seperti saya yang sering berpindah-pindah basis kode, pengujian ini membantu Anda memahami fungsionalitas bisnis dengan cepat tanpa perlu khawatir tentang implementasi/kode. Selain itu, seperti yang disebutkan dalam contoh di atas, saya dapat berinteraksi dengan pengujian ini untuk memvalidasi perilaku yang ada/baru dengan cepat. Pentingnya menulis pengujian ini dalam bahasa domain yang mudah dipahami sangatlah penting.

Standar
Android, Desain, Mobile

Pemrosesan Operasi MDM

Ini adalah blog kelima di seri tentang membangun solusi MDM khusus. Blog ini akan membahas secara detail implementasi alur kerja pemrosesan operasi.

Alur kerja pemrosesan operasi diwakili oleh mesin status di server. mengkategorikan kesalahan: kesalahan multi juta dolar, satu juta dolar atau kesalahan subjuta dolar berfungsi.

Saat admin membuat operasi baru untuk perangkat, status default yang mereka mulai adalah "tertunda". Saat perangkat menerima notifikasi, mereka akan meminta operasi. Pada tahap ini, operasi "tertunda" dikembalikan ke tablet. Setelah perangkat selesai memproses operasi, status tersebut akan dikirimkan kembali ke server. Berdasarkan status operasi, operasi tersebut ditandai sebagai "berhasil" atau "gagal". Jika tablet tidak dapat menyelesaikan pemrosesan operasi dalam jangka waktu yang dapat dikonfigurasi, tablet akan diatur ke "waktu habis".

Satu hal yang perlu diperhatikan adalah kami tidak membedakan antara operasi yang baru dibuat dan yang sedang diproses oleh tablet. Keduanya direpresentasikan oleh status "tertunda". Hal ini disengaja karena dari alur kerja pemrosesan operasi, keduanya sama. Artinya, setiap kali operasi meminta operasinya, kami akan mengembalikan operasi baru dan operasi yang mungkin sudah diproses. Ini sangat berguna untuk kondisi kesalahan. Ada kemungkinan tablet mengalami crash saat memproses salah satu operasi dan karenanya tidak mendapat kesempatan untuk mengonfirmasi statusnya. Dalam hal ini, saat tablet kembali melakukan operasinya, operasi yang tertunda akan dikembalikan. Tidak ada kerugian dalam memproses operasi yang sama dua kali. Dalam hal ini, operasi-operasi tersebut bersifat idempoten.

Ada mesin status lain yang kami gunakan untuk 'alur kerja notifikasi'. Itu dipertahankan berdasarkan per perangkat. mengkategorikan kesalahan: kesalahan multi juta dolar, satu juta dolar atau kesalahan sub-juta dolar berfungsi.

Ketika operasi baru dibuat untuk suatu perangkat, kami menandai perangkat tersebut sebagai "notifikasi diperlukan". Ketika notifikasi dikirim ke perangkat, notifikasi tersebut ditandai sebagai "notifikasi terkirim". Ketika perangkat datang untuk menjalankan operasinya, notifikasi tersebut ditandai sebagai "notifikasi tidak diperlukan". Jika perangkat tidak pernah datang untuk menjalankan operasinya, karena dimatikan atau semacamnya, notifikasi tersebut ditandai sebagai "notifikasi habis waktu".

Alur kerja notifikasi diimplementasikan melalui pekerjaan latar belakang. Alur kerja ini mengirimkan notifikasi ke perangkat dan mengelola mesin status. Selain itu, alur kerja ini juga menandai operasi yang telah habis waktunya.

Standar
Android, Desain, Mobile

Kepatuhan Tablet MDM

Ini adalah blog keempat di seri tentang membangun solusi MDM khusus. Di blog ini, saya membahas secara mendalam alur kerja pemrosesan operasi dan bagaimana alur kerja tersebut digunakan untuk menentukan "kepatuhan" sebuah tablet.

Namun mengapa ‘kepatuhan’ itu penting?

Kepatuhan akan memberi tahu admin apakah suatu perangkat memerlukan tindakan atau tidak. Ada 4 status kepatuhan yang dapat dicapai suatu perangkat.

"Sesuai" berarti tidak ada tindakan yang perlu diambil. "Tidak Sesuai" berarti perangkat tidak dalam kondisi yang diharapkan. "Di-root" berarti perangkat telah di-root dan rentan terhadap manipulasi. Perangkat ini harus segera ditindaklanjuti untuk menghindari penyalahgunaan. "Tidak Diketahui" berarti perangkat tidak terputus dari kontak selama jangka waktu tertentu, dalam kasus kami, 60 menit. Jika suatu perangkat "tidak sesuai", informasi tambahan akan diberikan untuk membantu admin menyelesaikan masalah.

Jadi bagaimana kita menentukan kepatuhan?

Untuk memahami kepatuhan, kita perlu memahami kategori operasi. Dua kategori operasi tersebut adalah "satu kali" dan "persisten". Operasi satu kali bersifat sementara dan membantu diagnosis atau pemeliharaan tablet. Contohnya termasuk melakukan ping ke perangkat untuk mendapatkan informasinya, membuka kunci perangkat, membuka blokir pengaturan, dan mengatur ulang PIN pada perangkat. Operasi persisten adalah operasi yang menentukan kondisi tablet yang diharapkan. Contohnya termasuk konten tablet, kebijakan kata sandi tablet, dan lain-lain.

Hanya operasi persisten yang berkontribusi terhadap kepatuhan tablet. Jika semua operasi persisten berhasil dijalankan oleh tablet, tablet dikatakan patuh.

Sebagai catatan tambahan, operasi persisten dibuat untuk sekelompok perangkat, misalnya sekolah, distrik, dan lain-lain, sedangkan operasi satu kali dibuat pada tingkat perangkat individual. Komposisi kelompok perangkat dapat bersifat statis, misalnya siswa dari satu sekolah, atau dinamis, misalnya siswa kelas 6 di suatu distrik.

Standar
Android, arsitektur, Desain, Seluler, Pemrograman

MDM Operation serialization

AndroiIni adalah blog ketiga di seri tentang membangun solusi MDM (Manajemen Perangkat Seluler) khusus untuk tablet Android. first Blog ini memberikan gambaran umum tentang solusi MDM dan membahas arsitektur server. Kedua salah satunya tentang arsitektur agen MDM Android.

Ide dasarnya adalah kita memiliki agen MDM yang berjalan di tablet, mengambil "operasi" dari server MDM, mengeksekusinya, dan mengembalikan statusnya ke server. Dalam blog ini, saya akan membahas beberapa detail implementasi spesifik pada agen MDM Android, khususnya seputar serialisasi pemrosesan "operasi", yang mengharuskan kita mengimplementasikan sinkronisasi multi-utas di Android.

Pertama-tama, apa itu operasi?

Operasi merupakan tugas yang diinginkan server agar dijalankan oleh tablet, misalnya, menetapkan kebijakan kata sandi, memasang aplikasi, memblokir pengaturan pada tablet, dan lain sebagainya.

Jadi, apa masalahnya?

Masalahnya adalah memastikan, selama pemrosesan operasi di tablet, hanya satu operasi dengan tipe tertentu yang dieksekusi pada satu waktu tertentu. Ini berarti dua operasi PasswordPolicy tidak boleh dieksekusi secara bersamaan. Namun, tidak masalah jika operasi PasswordPolicy dieksekusi secara paralel dengan operasi InstallApp. Bahkan, hal itu diinginkan. Menjalankan operasi dengan tipe yang sama secara paralel memiliki kelemahan serius.

Kondisi balapan

Misalkan operasi yang dijalankan secara paralel adalah operasi PasswordPolicy. Salah satu operasi ingin menerapkan kebijakan kata sandi sebagai Normal (kata sandi 4 digit) sementara yang lain menginginkannya sebagai Kuat (kata sandi 6 alfanumerik). Sekarang, berdasarkan operasi mana yang terakhir dijalankan, kebijakan kata sandi akan ditetapkan di tablet, bukan yang terakhir dibuat oleh server. Lebih buruk lagi, server bisa tidak sinkron dengan tablet, berdasarkan operasi mana yang terakhir mengirimkan statusnya.

Jadi, apa solusinya?

Masuk ke Android. Seperti yang telah disebutkan sebelumnya, agen MDM adalah komponen Android. Android menyediakan IntentService yang dapat memecahkan masalah serupa. Pada dasarnya, ini adalah Layanan yang memproses satu Intent (permintaan asinkron) dalam satu waktu. Layanan ini memelihara antrean untuk Intent yang masuk dan memunculkan satu utas pekerja untuk memprosesnya secara berurutan. Layanan ini menyediakan metode untuk menangani Intent. Setelah metode dieksekusi, metode ini akan mengambil Intent berikutnya yang menunggu di antrean. Kedengarannya seperti yang kita inginkan, bukan? Kita hanya perlu membuat IntentService untuk setiap jenis operasi dan terus menjalankan Intent pada IntentService yang sesuai, saat operasi tiba. Beginilah tampilannya.

mutlithreaded-serialization-naive

Tapi tunggu dulu! Selalu ada tapi, kan?

Apa masalahnya sekarang?

Masuklah ke multi-threading. Beberapa operasi harus berpindah ke thread lain untuk menyelesaikan pemrosesannya, yaitu thread Utama, yang juga dikenal sebagai thread UI. Android mewajibkan semua aktivitas UI dilakukan di thread Utama. Jadi, operasi PasswordPolicy kita akan diteruskan ke thread Utama untuk menampilkan kotak dialog guna mengubah kata sandi guna mengonfirmasi kebijakan kata sandi yang baru. Ketika kontrol diteruskan ke thread Utama, thread pekerja menganggap prosesnya selesai, tanpa menunggu respons dari thread Utama. Ia dengan senang hati melanjutkan pemrosesan operasi berikutnya, sementara operasi sebelumnya mungkin masih menunggu respons pengguna di thread Utama. Sial! Serialisasi dalam lingkungan multi-thread tidaklah mudah.

Jadi sekarang, apa yang kita lakukan?

Sekarang yang kita lakukan adalah memblokir thread pekerja hingga thread utama selesai melakukan tugasnya. Kita menyediakan callback ketika kita keluar dari thread pekerja. Ketika thread utama selesai, callback dipanggil untuk membuka blokir thread pekerja, melakukan aktivitas penyelesaian untuk operasi tersebut (mengirim status ke server), lalu melepaskan kontrol. Android akan mengambil Intent berikutnya dan memproses operasi berikutnya. Misi selesai! 🙂 Berikut diagram pseudo-sekuens untuk melakukannya.

mutlithreaded-serialization

Kita bisa mengimplementasikan ini dengan cara yang sepenuhnya non-pemblokiran, dengan membuat operasi penyelesaian memicu operasi berikutnya. Namun, dengan cara ini, sulit untuk memiliki batas waktu pada pemrosesan operasi karena berpindah antar thread. Pemblokiran membuatnya sangat mudah untuk melakukannya. Kita menggunakan Java CountDownLatch dengan batas waktu untuk memblokir thread. Secara konseptual, ini juga lebih mudah dipahami. Dan karena ini adalah thread latar belakang/pekerja, memblokirnya bukanlah masalah besar.

Terima kasih sudah membaca! Komentar/saran diterima.

Standar
Android, arsitektur, Desain, Seluler, Pengalaman Pengguna

Arsitektur Tablet MDM

Ini adalah bagian kedua dari blog saya seri yang membahas tentang membangun solusi MDM (Manajemen Perangkat Seluler) khusus. Jika Anda belum membaca bagian pertama, Anda harus memeriksanya. Di Sini.

Seperti yang telah disebutkan di blog sebelumnya, sebagai bagian dari solusi MDM, kami memiliki agen MDM yang berjalan di tablet yang mengambil operasi dari server, mengeksekusinya, dan mengembalikan status operasi tersebut ke server MDM. Sebagai pengingat singkat, berikut beberapa contoh operasi tersebut:

  • Instalasi aplikasi secara senyap
  • Pengaturan blok pada tablet
  • Blokir aplikasi/aplikasi di tablet
  • Setel ulang pin pada tablet
  • Reset pabrik tablet

Dalam postingan ini, saya akan berbicara tentang bagaimana kami mewujudkan penerapan beberapa operasi yang menantang ini.

Jadi, untuk memperjelas konteksnya, jika Anda mengembangkan aplikasi Android biasa, Anda hanya akan memiliki akses ke API Android yang terbuka untuk umum. Arsitektur Anda akan terlihat seperti di bawah ini.
normal-app-tablet-architecture

Namun, ketika Anda membangun agen MDM, API yang diekspos publik tidak cukup untuk mengimplementasikan beberapa operasi. Jadi, misalnya, jika Anda ingin menginstal aplikasi secara diam-diam (instalasi terjadi di latar belakang, tanpa sepengetahuan pengguna), tidak ada API publik untuk melakukannya. Namun, jika Anda melihat kode sumber Android, terdapat metode yang dapat melakukan hal tersebut. Lalu, apa yang harus kita lakukan?

Nah, di sinilah kita perlu sedikit memperluas wawasan. Seperti yang telah saya sebutkan sebelumnya, kami bertanggung jawab atas solusi menyeluruh, perangkat keras, dan perangkat lunak. Hal ini memberi kami ruang lingkup yang besar dalam hal kustomisasi platform Android, dan beginilah cara kami melakukannya.

Kami bekerja sama langsung dengan vendor perangkat keras untuk pengadaan perangkat Android. Perangkat ini dilengkapi dengan citra sistem Android yang dirancang khusus untuk kebutuhan kami. Citra sistem merupakan kombinasi dari sistem operasi Android, aplikasi OEM (Original Equipment Manufacturer, dalam hal ini, vendor perangkat keras), driver khusus perangkat, dan lain-lain. Seperti yang kita ketahui, Android adalah platform sumber terbuka dan vendor perangkat keras bebas untuk menyesuaikannya, selama memenuhi CTS (Compatibility Test Suite) Android.

Kami membangun layanan Android yang akan mengekspos beberapa API Android yang tidak tersedia untuk umum. Sebut saja "layanan jembatan". Kami menyerahkan layanan ini kepada vendor perangkat keras kami untuk disertakan dalam citra sistem kustom kami. Dengan menyertakan layanan jembatan dalam citra sistem, layanan ini akan memberikannya akses ke API non-publik Android, karena layanan ini akan dianggap sebagai bagian dari sistem operasi Android. Layanan jembatan ini selanjutnya akan diakses oleh agen MDM kami untuk mengimplementasikan beberapa operasi. Dan boom, selesai! Sekarang kami memiliki akses ke API non-publik Android.

Kami tidak berhenti hanya dengan mengekspos API non-publik; kami melangkah lebih jauh. Kami menyertakan beberapa komponen Android kustom dalam citra sistem. Misalnya, salah satu persyaratan bisnis adalah hanya mengizinkan aplikasi tertentu untuk berjalan di tablet. Untuk ini, kami memiliki utilitas App Killer yang mematikan aplikasi yang tidak termasuk dalam daftar "aplikasi yang diizinkan". Daftar ini diambil dari server MDM sebagai bagian dari suatu operasi dan diumpankan ke utilitas App Killer di tablet.

Beberapa persyaratan lainnya, seperti memblokir pengaturan tertentu di tablet, diterapkan dengan mengganti kode aplikasi Pengaturan yang merupakan bagian dari sistem operasi Android. Dengan semua penyesuaian ini, beginilah tampilan arsitektur kami.

mdm-tablet-architecture

Keren sekali rasanya menyadari bahwa kita bisa melakukan apa pun yang kita inginkan dengan sistem operasi Android! :). Tapi, tentu saja, semua ini ada harganya.

Pertama-tama, layanan jembatan ini menghadirkan risiko keamanan dan kami mengatasinya dengan memastikan bahwa layanan tersebut hanya dapat diakses oleh agen MDM kami. Kekhawatiran besar lainnya adalah, ketika Android mengubah salah satu API ini, yang mana API tersebut bebas mereka lakukan karena tidak dipublikasikan, kami harus melakukan perubahan yang sesuai pada layanan jembatan kami. Selain itu, menyusun logistiknya tidaklah mudah, terutama karena siklus umpan balik yang panjang yang terlibat dalam pengujian integrasi antara citra sistem, layanan jembatan, dan agen MDM. Setiap perubahan citra sistem harus disertifikasi oleh Google dengan melewati CTS, yang menambah penundaan. Membuat perubahan pada citra sistem mengharuskan kami untuk kembali ke vendor perangkat keras yang memakan waktu. Saat ini, vendor perangkat keras membutuhkan waktu sekitar 3 hari untuk memproses satu perubahan citra sistem, tergantung pada kompleksitas perubahannya. Oleh karena itu, kami harus merencanakan perubahan ini jauh-jauh hari.

Namun, ketika Anda membangun solusi manajemen perangkat seluler, Anda membutuhkan kemampuan ini. Hal ini telah meningkatkan pengalaman pengguna tablet secara signifikan. Misalnya, di tablet, kita dapat menginstal aplikasi secara diam-diam tanpa perlu mengklik tombol OK di beberapa layar. Bayangkan jika pengguna harus melakukan ini untuk ratusan aplikasi! Pada saat itu, hal ini menjadi sebuah kebutuhan, bukan sekadar 'kelebihan'.

Sungguh menyenangkan "meretas" dengan sistem operasi Android. Semoga Anda menyukai blog ini. Jangan ragu untuk memberi tahu saya pendapat Anda. Terima kasih sudah membaca!

Standar
Android, Desain, Seluler

Pengenalan MDM

Ini adalah blog pertama di seri dalam membangun solusi MDM khusus.

Pertama-tama, apa yang ingin kita bangun?

Kami sedang membangun platform pembelajaran untuk pendidikan K-12 berbasis tablet Android. Tablet ini akan digunakan oleh guru dan siswa, terutama di dalam kelas. Tablet ini membantu guru memfasilitasi kelas dan menyediakan berbagai alat serta aplikasi untuk berinteraksi dengan siswa dan membantu mereka belajar lebih baik.

Jadi, apa itu MDM dan mengapa kita membutuhkannya?

MDM adalah singkatan dari Manajemen Perangkat Seluler. Mengingat tablet ini akan digunakan di berbagai sekolah, solusi MDM memungkinkan kami mengelolanya dari jarak jauh. Ini termasuk mengunduh berbagai konten pembelajaran, memasang aplikasi pendidikan, mengatur kebijakan kata sandi di tablet, dan sebagainya, dari jarak jauh. Karena tablet digunakan di lingkungan sekolah, solusi MDM juga bertanggung jawab untuk menyediakan wadah yang aman dan terlindungi untuk menjalankan aplikasi. Ini termasuk mengaktifkan/menonaktifkan pengaturan tertentu di tablet. Solusi MDM juga menyediakan solusi masuk tunggal bagi pengguna tablet. Hal ini memungkinkan kami untuk menyimpan kredensial pengguna sekali dan menggunakannya seumur hidup pengguna. Ini juga memberi kami kemampuan untuk menyesuaikan konten di tablet untuk pengguna tertentu.

Jadi, bagaimana kami menerapkannya?

mdm-server-architecture

Solusi MDM memiliki dua komponen utama: pertama, agen MDM yang ada di tablet, dan kedua, server MDM. Pada dasarnya, pengguna Admin berinteraksi dengan server MDM untuk melakukan "operasi" pada tablet (atau sekelompok tablet) melalui portal web. Contoh operasinya adalah "memasang aplikasi" di tablet. Untuk menjalankan operasi ini, server MDM memberi tahu tablet melalui GCM, agen MDM di tablet menerima notifikasi, meminta server MDM untuk melakukan operasinya melalui HTTP, server MDM mengirimkan operasi tersebut, dan kemudian agen MDM menjalankan operasi tersebut di tablet dan mengirimkan statusnya kembali ke server. Status tersebut kemudian ditampilkan kepada pengguna Admin di portal web.

Contoh operasi lainnya meliputi:

  • Memblokir pengaturan pada tablet
  • Mengaktifkan VPN
  • Setel ulang kata sandi di tablet
  • Mengirim pesan
  • Membatalkan pendaftaran pengguna di tablet
  • Reset pabrik tablet

dan masih banyak lagi.

Untuk membangun ketahanan dalam sistem, kami telah memperkenalkan mekanisme coba lagi di server. Jika server tidak mendapatkan respons dari tablet dalam jangka waktu yang telah ditentukan, kami akan mencoba mengirimkan notifikasi lagi ke tablet. Kami juga telah membangun mekanisme "tarik" ke dalam tablet, yang berarti setiap kali tablet di-boot ulang, tablet akan meminta operasinya dari server. Operasi-operasi ini bersifat idempoten, yang berarti jika dijalankan beberapa kali, status sistem akhir akan tetap sama.

Pada bagian selanjutnya, saya akan berbicara tentang arsitektur tablet, yang memerlukan beberapa "peretasan" keren pada sistem operasi Android. Begini caranya!

Standar
Android, arsitektur, Desain, Seluler

Manajemen Perangkat Seluler

Selama kurang lebih setahun terakhir, saya sangat beruntung bisa membangun solusi MDM (Manajemen Perangkat Seluler) khusus untuk tablet Android. Ini adalah seri blog yang membahas arsitektur umum solusi MDM dan spesifikasi komponen tablet Android serta komponen server dari solusi MDM.

Ini dibagi menjadi 5 bagian. Berikut 5 bagiannya:

Perkenalan
Arsitektur Tablet
Serialisasi Operasi
Kepatuhan Tablet
Alur Kerja Pemrosesan Operasi

Semoga Anda menikmati serial ini. Komentar dipersilakan.

Standar
arsitektur, Keahlian, Desain, Java, Pemfaktoran ulang

pengkodean jiwa

Kemarin saya melakukan perjalanan tanpa henti selama 12 jam[1] Code Fest untuk merombak irisan tipis aplikasi web 2-tier menjadi 3-tier. Prosesnya sangat produktif dan harus saya akui, inilah hal yang menenangkan jiwa pengembang saya, dan karena itulah namanya. 🙂

Pendorong utama untuk refactoring adalah bahwa logika inti dari aplikasi terhubung erat pada kedua ujungnya dengan kerangka kerja yang digunakan. Di satu sisi, itu terikat pada kerangka kerja aplikasi web, Play dan di ujung lain ORM, Ebean. Kami berhasil memindahkan logika bisnis ke tingkatan terpisah, yang bagus dengan sendirinya, tetapi juga memungkinkan kami menguji unit logika bisnis tanpa mengganggu kerangka kerja, yang terus terang bisa sangat buruk. Sebagai efek lanjutan, kami juga berhasil membagi model menjadi 2 varian, satu untuk mendukung database melalui Ebean dan yang lainnya untuk menghasilkan tampilan JSON menggunakan Jackson. Ini memungkinkan kami memisahkan dua masalah dan mengujinya dengan baik secara terpisah. Demikian pula, kami dapat menguji pengontrol secara terpisah. Kami menyingkirkan sebagian besar pengujian fungsional kami yang menguji jalur yang tidak menyenangkan yang kami miliki pengujian unit di tempat yang tepat yaitu, pengontrol, model tampilan, model layanan dan database.

Saya cukup takjub dengan banyaknya hal yang bisa kami selesaikan dalam sehari. Berikut beberapa hal penting yang bisa kami dapatkan dari eksperimen ini:

  • Sehari sebelumnya, kami berdiskusi tentang bagaimana kami ingin merestrukturisasi kode, terutama berfokus pada pemisahan tanggung jawab dan peningkatan uji coba unit kode. Kami menyepakati serangkaian prinsip tertentu, yang berfungsi sebagai panduan yang baik dalam proses refactoring. Pada hari refactoring, kami menyadari bahwa tidak semua hal yang kami diskusikan dapat diterapkan, tetapi kami melakukan penyesuaian yang wajar selama prosesnya.
  • Fokuslah pada tujuan akhir. Terus ingatkan diri Anda tentang gambaran besarnya. Jangan biarkan perubahan kecil mengalihkan perhatian Anda, tuliskan di selembar kertas agar tidak lupa.
  • Berpasangan sangat membantu. Jika Anda terbiasa berpasangan, saat melakukan refactoring pada skala ini, manfaatnya berlipat ganda. Membantu Anda tetap fokus pada tujuan akhir, memecahkan masalah dengan cepat berkat pengetahuan kolektif, dan juga mengurangi waktu siklus pengambilan keputusan secara signifikan saat melakukan penyesuaian pada desain awal. Saya juga menyarankan untuk memilih pasangan yang sejalan dengan Anda dalam hal aturan dasar pendekatan pengembangan. Anda tentu tidak ingin terlibat dalam diskusi tentang bagaimana atau mengapa Anda harus menulis pengujian dan berapa ukuran komitmen yang baik.
  • Memiliki alat praktis yang membantu Anda memulai dengan cepat. Saya dan pasangan saya cukup tahu alat apa yang harus digunakan untuk semua masalah yang dihadapi. Pada satu titik, kami sempat kesulitan menguji metode dan konstruktor statis. Pasangan saya tahu tentang PowerMock, kami mencobanya dan berhasil. Dan begitulah, PowerMock sudah termasuk dalam proyek. Jangan terlalu banyak berdebat, pilih sesuatu yang berhasil dan lanjutkan. Jika tidak berhasil untuk skenario tertentu, masukkan ke dalam daftar refactoring Anda.
  • Untungnya, kami sudah memiliki banyak uji fungsional untuk memvalidasi perilaku yang diharapkan, yang sangat berguna untuk memastikan kami tidak merusak sistem. Jika Anda tidak memiliki kemewahan ini, pilihlah sepotong kecil fungsionalitas untuk direfaktor yang dapat Anda uji secara manual dengan cepat.
  • Komitmen kecil namun sering. Sekali lagi, kehebatannya semakin terasah dalam skenario seperti ini.
  • Katakan tidak pada rapat. Ya, Anda bisa hidup tanpa rapat sehari pun, bahkan jika Anda adalah presiden perusahaan. 🙂

Apakah Anda sudah melakukan pengkodean jiwa akhir-akhir ini? 🙂

[1] Baiklah, tidak sampai 12 jam, tetapi hal itu selalu ada dalam pikiranku. 😉

Standar