Balisage Paper: Pola Desain XQuery – Pola desain banyak digunakan di dalam komunitas berorientasi objek. Mereka terbukti matang dan solusi yang dapat digunakan kembali yang memfasilitasi pengembangan modul dengan kopling minimal.
Balisage Paper: Pola Desain XQuery
zorba-xquery – Selain itu, pola desain juga merupakan konstruksi tingkat tinggi yang berkontribusi untuk meningkatkan komunikasi antar pengembang. Saat ini, XQuery dan keluarga spesifikasinya digunakan lebih dari sekadar menanyakan koleksi dan dokumen XML. XQuery semakin banyak digunakan sebagai bahasa pemrograman multi-paradigma yang lengkap.
Baca Juga : Tutorial Cara Menggunakan XQuery
Selama dekade terakhir, pola desain menjadi semakin populer sebagai solusi umum dan dapat digunakan kembali untuk masalah desain perangkat lunak yang umum terjadi di komunitas berorientasi objek. Saat ini, hampir setiap aplikasi, komponen, atau API yang dikembangkan yang ditulis dalam bahasa berorientasi objek dibangun menggunakan pola desain (mis. [ Cooper2000 , Cooper2002 ]). Pola seperti itu meningkatkan pengembangan perangkat lunak dalam perspektif berikut [ Gamma1994 ]:
- Perangkat Lunak dan Desain yang Dapat Digunakan Kembali : Pola Desain sering kali merupakan pendorong utama untuk menyediakan enkapsulasi yang lebih baik dan mengurangi sambungan antar komponen perangkat lunak. Akibatnya, perangkat lunak yang menunjukkan pola desain lebih dapat digunakan kembali, fleksibel, dan dapat diperluas.
- Dokumentasi : Menggunakan nama pola dalam dokumentasi perangkat lunak memungkinkan pengembang mengenali/mengingat struktur dan desain API secara instan.
- Komunikasi dan Pengajaran : Pola desain merupakan bahasa umum untuk meningkatkan komunikasi antara perancang perangkat lunak dan analis. Selain itu, kosakata yang mapan memudahkan diskusi antara pengembang dengan latar belakang bahasa pemrograman yang berbeda.
Meskipun, diterima secara luas dan diterapkan dalam komunitas berorientasi objek, pola desain jarang dievaluasi di luar komunitas ini. Misalnya, di dunia fungsional mereka tidak pernah dievaluasi pada tingkat pemrograman aplikasi yang kompleks.
Dalam “Pola Desain Logika Fungsional” [ AntoyHanus02FLOPS ] pola desain telah dievaluasi dalam bahasa fungsional untuk memecahkan masalah spesifik pada tingkat yang sangat rendah; sedangkan [ Narbel2007 ] membahas pada tingkat meta. Dari perspektif ini, ketakutan Tom DeMarco dari tahun 1996 telah terbukti masuk akal:
“Karena Pola Desain menyebut dirinya hanya peduli dengan perangkat lunak berorientasi objek saja, saya khawatir pengembang perangkat lunak di luar komunitas objek mungkin mengabaikannya. Ini akan memalukan. […] Semua perancang perangkat lunak menggunakan pola; lebih memahami abstraksi yang dapat digunakan kembali pekerjaan kita hanya dapat membuat kita lebih baik dalam hal itu.” [ DeMarco96 ]
XQuery [ XQ11 ] — bahasa fungsional dan deklaratif — telah dirancang oleh World Wide Web Consortium sebagai bahasa pemrosesan XML tujuan umum, berguna dalam berbagai arsitektur dan lingkungan. Meskipun, pada awalnya, XQuery terutama digunakan untuk meminta data XML dalam sistem basis data (mis. [ XQueryInAction]), semakin menjadi bahasa pemrograman aplikasi yang lengkap.
Salah satu skenario di mana XQuery digunakan sebagai bahasa pemrograman lengkap disebut arsitektur XML ujung ke ujung. Dalam arsitektur seperti itu, XML adalah bentuk utama di mana informasi disimpan dan diproses. Informasi ini terus-menerus di seluruh pemanggilan program yang berurutan, dan XQuery adalah bahasa utama untuk mengakses informasi ini untuk pencarian, filter, transformasi, pembaruan, dan untuk menulis alur kerja aplikasi yang lebih kompleks.
Selain itu, dalam program tersebut, XQuery juga menjadi fasih dengan entitas web seperti layanan web, Atom, JSON, pesan HTTP, dan teknik otentikasi umum seperti OpenID atau OAuth. Bersama dengan spesifikasi ekstensinya, Pembaruan XQuery [XQUF ], XQuery Scripting [ XQSE ], dan XQuery Full Text [ XQFT ], XQuery saat ini bermain di liga yang sama dengan bahasa pemrograman tujuan umum seperti Java, Python, atau Ruby sambil mempertahankan keunggulannya dalam hal ekspresif dan dukungan kelas satu untuk menangani sumber daya web.
Secara keseluruhan, perubahan terbaru ini secara langsung berkaitan dengan pertumbuhan aplikasi XQuery yang kompleks [ Kaufmann2009 ]. Salah satu contoh aplikasi semacam itu dikembangkan oleh pelanggan perusahaan tempat penulis bekerja. Aplikasi ini adalah aplikasi Enterprise Resource Planning (ERP) yang seluruhnya ditulis dalam XQuery di atas Server Aplikasi Web Sausalito [ Sausalito2010 ].
Aplikasi ini terdiri dari 28.000 baris kode XQuery yang diimplementasikan dalam 135 modul XQuery. Dengan mengaudit aplikasi ini, kami menemukan gejala umum di basis kode dan proses pengembangan:
- Modul memiliki kopling yang kuat antara satu sama lain. Mereka didasarkan pada kolaborasi kompleks yang mengurangi kegunaannya kembali dalam kerangka kerja atau aplikasi lain. Dalam kebanyakan kasus, memperluas atau menyusun modul akan memerlukan pemfaktoran ulang kode yang mengganggu.
- Beberapa desain struktural berulang dirujuk menggunakan kosakata yang berbeda. Meskipun mereka dapat dilihat sebagai identik dari sudut pandang abstrak. Ini meningkatkan penghalang masuk ke basis kode secara signifikan.
Seperti yang dijelaskan di awal bagian ini, masalah seperti itu telah dipecahkan dalam komunitas berorientasi objek dengan mengembangkan dan menerapkan pola desain. Didorong oleh pengamatan ini, kami memutuskan untuk mulai menggunakan pola desain untuk mengatasi ketidaksesuaian yang dijelaskan di atas.
Selain memotivasi penggunaan pola desain untuk XQuery, kontribusi makalah ini adalah (1) untuk mengidentifikasi ketidaksesuaian dalam aplikasi dunia nyata dan (2) menunjukkan bagaimana ketidaksesuaian ini dapat diperbaiki dengan menggunakan pola desain. Secara khusus, kami menyajikan empat pola desain dan menjelaskan bagaimana masing-masing pola tersebut memecahkan satu masalah desain tertentu dalam aplikasi contoh (yang sedang berjalan) kami.
Sisa dari makalah ini disusun sebagai berikut. Di Bagian 2 , kami menjelaskan kasus penggunaan untuk contoh kami yang sedang berjalan. Contoh ini akan digunakan untuk menunjukkan masalah desain yang ada dalam aplikasi dunia nyata. Di masing-masing dari empat bagian berikut (yaitu Bagian 3 , 4 , 5 , dan 6 ), kami menyajikan satu pola desain untuk memecahkan salah satu masalah desain yang diidentifikasi.
Menjalankan Contoh: Aplikasi AtomPub
Protokol Penerbitan Atom adalah protokol berbasis HTTP untuk membuat dan memperbarui sumber daya di web. Akhir-akhir ini, menjadi banyak digunakan untuk mengimplementasikan API untuk layanan cloud. Contoh yang paling menonjol mungkin adalah Protokol Data Google .
AtomPub dibangun di atas Format Sindikasi Atom yang merupakan representasi XML dari kumpulan sumber daya yang sewenang-wenang (misalnya umpan web). Oleh karena itu, XQuery sangat cocok untuk mengimplementasikan layanan (cloud) berbasis AtomPub.
Kami menggunakan aplikasi AtomPub untuk menyajikan pola desain untuk XQuery. Aplikasi ini sangat cocok untuk banyak pola (umum) karena sebagian besar komponennya harus dapat digunakan kembali oleh komponen aplikasi lainnya. Selain itu, memanfaatkan perpustakaan yang ada (misalnya untuk komunikasi dan otentikasi HTTP) memerlukan beberapa keputusan desain yang cermat untuk dibuat. Pada dasarnya, aplikasi AtomPub terdiri dari dua komponen utama: klien dan server. Klien adalah aplikasi XQuery yang harus mengimplementasikan dua kasus penggunaan dasar berikut:
- Kasus Penggunaan 1: Kirim permintaan HTTP untuk membuat entri Atom.
- Kasus Penggunaan 2: Kirim permintaan HTTP untuk mengambil entri Atom tertentu. Entri yang dihasilkan harus diubah menjadi HTML.
Server adalah aplikasi yang berjalan di dalam server aplikasi berkemampuan XQuery. Artinya, fungsinya dipicu oleh permintaan HTTP. Fungsi-fungsi tersebut memiliki akses ke konten permintaan HTTP menggunakan modul (HTTP) yang disediakan oleh server aplikasi. Server bertindak sebagai mitra dari permintaan klien. Secara khusus, itu harus dapat menyelesaikan dua kasus penggunaan berikut:
- Kasus Penggunaan 3: Terima entri AtomPub dan simpan. Seharusnya dimungkinkan untuk menyimpan entri di lokasi yang berubah-ubah seperti sistem file atau koleksi XQuery.
- Use Case 4: Posting pesan di Twitter untuk setiap entri yang dibuat di Use Case 3.
Di bagian selanjutnya dari makalah ini, kami menunjukkan bagaimana tantangan desain dalam mengimplementasikan kasus penggunaan yang dijelaskan dapat diselesaikan dengan memanfaatkan pola desain. Kita mulai dengan Kasus Penggunaan 1 dan 2 dari klien di Bagian 3 dan 4 , masing-masing. Setelah itu, Bagian 5 dan 6 menjelaskan desain dan implementasi Kasus Penggunaan 3 dan 4.
Rantai Tanggung Jawab
Di bagian ini, kita membahas implementasi Use Case 1. Artinya, kita ingin mengembangkan program XQuery yang memublikasikan entri Atom ke server berkemampuan AtomPub. Karena tidak semua orang diizinkan untuk memublikasikan entri, server AtomPub memerlukan autentikasi menggunakan mekanisme autentikasi HTTP dasar.
Protokol AtomPub menetapkan bahwa entri diterbitkan dengan mengirimkan permintaan HTTP POST ke server. Payload permintaan ini berisi entri yang akan dipublikasikan. Otentikasi HTTP dasar memerlukan nama pengguna dan kata sandi untuk menjadi bagian dari HTTP-Header.
Untuk membuat panggilan HTTP dalam program XQuery, kami memutuskan untuk mengandalkan (standar de-facto) Klien HTTP EXPath. Klien HTTP ini bekerja dengan melewatkan elemen XDM yang menjelaskan permintaan ke fungsi yang disebut send-request.
Untuk mengimplementasikan kasus penggunaan pertama kami, klien AtomPub dapat diimplementasikan dengan ketergantungan kabel antara modul yang bertanggung jawab untuk mengonfigurasi dan mengirim permintaan HTTP dan modul yang bertanggung jawab untuk otentikasi.
Namun, ini jelas akan membuat klien AtomPub kurang fleksibel dan dapat digunakan kembali dalam skenario lain. Misalnya, mengubah mekanisme otentikasi menjadi sesuatu seperti OAuth atau OpenID akan memerlukan perubahan yang mengganggu pada modul AtomPub atau akan menghasilkan basis kode lain yang sangat berlebihan.
Untuk meningkatkan fleksibilitas dan penggunaan kembali aplikasi kami, kami menetapkan dua persyaratan desain berikut. Klien AtomPub harus dipisahkan dari
- mekanisme otentikasi apa pun yang dapat berkolaborasi dengannya saat runtime.
- implementasi tertentu dari lapisan transport, yaitu klien HTTP.
Untuk memenuhi persyaratan ini, kami telah merancang klien AtomPub menggunakan pola Rantai Tanggung Jawab [ Gamma1994 ]. Maksud dari pola ini adalah sebagai berikut:
Kurangi penggabungan antara modul yang berbeda dengan memindahkan dependensi bersarang di luar modul dan mengintegrasikan fungsi dependen secara berurutan ke dalam rantai. Lewati item di sepanjang rantai dan berikan masing-masing fungsi ini kesempatan untuk memanipulasi atau memproses item tersebut.
