BAB 2 TINJAUAN PUSTAKA. bentuk sesuai dengan tipe data dan konteks penggunaan [7]. Tujuannya yaitu

Transkripsi

1 BAB 2 TINJAUAN PUSTAKA 2.1 Metadata Metadata adalah data dari objek yang mendeskripsikan sumber informasi atau data. Metadata berasal dari jenis media apa saja dan mempunyai bermacam-macam bentuk sesuai dengan tipe data dan konteks penggunaan [7]. Tujuannya yaitu mengenali dan mengevaluasi sumber daya, melacak perubahan pada proses sumber daya aplikasi, merealisasikan manajemen yang sederhana dan efisien pada jaringan data skala besar dan merealisasikan penemuan yang efisien, pencarian, integrasi dan manajemen sumber daya informasi [8]. Metadata dapat berfungsi sebagai identifikasi sumber daya yang diperlukan maupun menjadi katalog yang menjelaskan detail dan spesifikasi suatu data, serta sebagai arsip untuk disimpan dalam jangka waktu yang lama [4]. Berdasarkan pengalaman kerja, menggunakan metadata dapat membantu pembacaan dan pemrosesan data digital oleh mesin menjadi lebih mudah. Ada beberapa standar metadata yang dapat digunakan seperti DC (Dublin Core), MARC (Machine- Readable Cataloging), IEEE LOM (Institute of Electrical and Electronics Engineering Learning Object Model) dan lain-lain [9] [10]. Standar metadata Dublin Core merupakan standar metadata yang memiliki elemen sederhana namun efektif untuk menggambarkan berbagai sumber daya. 6

2 7 Dublin Core memiliki dua jenis tingkatan yaitu unqualified dan qualified. Dublin Core unqualified memiliki lima belas elemen sedangkan Dublin Core qualified termasuk tiga elemen tambahan yaitu Audience, Provenance, dan RightHolder yang disebut juga qualifier untuk menyempurnakan semantik elemen yang mungkin berguna pada penelusuran sumber daya. Semantik Dublin Core telah didirikan oleh sebuah grup lintas disiplin yang mencakup ilmu perpustakaan, ilmu komputer, komunitas museum dan bidang lainnya yang berhubungan [11]. Tabel 2.1 Pemetaan Metadata antara MARC dan Dublin Core Unqualified MARC Dublin Core 100, 110, 111, 700, 710, 711 Contributor , 662 Coverage 751, 752 Creator 008/07-10 Date 260$c$g , except 506, 530, 540, 546 Description 340 Format 856$q 020$a, 022$a, 024$a Identifier 856$u 008/35-37 Language 041$a$b$d$e$f$g$h$j $a$b Publisher 530, $o$t Relation 506, 540 Rights 534$t Source 786$o$t 050, 060, 080, 082 Subject 600, 610, 611, 630, 650, , 246 Title Leader06, Leader07 Type 655

3 8 Beragam standar metadata yang dapat digunakan akan menjadi masalah pada saat integrasi akan dilakukan. Pada implementasinya, harus digunakan satu jenis metadata yang dapat menyatukan seluruh metadata yang akan digunakan sebagai format standar untuk pengumpulan data. Pemetaan metadata dapat digunakan untuk transformasi elemen yang terdapat pada satu jenis metadata ke jenis metadata lainnya. Contoh pemetaan metadata antara MARC dan Dublin Core unqualified dijabarkan pada Tabel 2.1. Tabel 2.2 Penggunaan Kode 20X 24X pada Metadata MARC [12] Kode Keterangan 210 Abbreviation Title = singkatan judul 222 Key Title = judul unik tertentu yang digunakan untuk serial 240 Uniform Title = judul utama yang muncul untuk dokumen-dokumen yang memiliki judul ganda 242 Translation of Title by Cataloging Agency = terjemahan judul oleh agensi pengatalogan 243 Collective Uniform Title = judul umum yang digagas oleh pengatalog untuk mengumpulkan karya-karya pengarang yang produktif 245 Title Statement = judul utama sebuah dokumen 246 Varying Form of Title = bentuk alternatif dari judul muncul ketika sebuah bentuk yang pada dasarnya berbeda dari judul pada kode 245 dan jika berkontribusi untuk identifikasi lebih lanjut 247 Former Title = digunakan apabila satu dokumen katalog mewakili beberapa judul yang berhubungan dengan satu kesatuan Dengan menggunakan metadata MARC, sebuah dokumen dapat direpresentasikan secara mendetail. Misalnya pengelompokan metadata MARC

4 9 dengan bentuk 20X 24X merupakan sekumpulan kode tertentu yang dapat digunakan untuk merepresentasikan judul dan segala sesuatu yang berhubungan dengan judul. Keterangan mengenai kode 20X 24X dijabarkan pada Tabel 2.2. Dari beberapa kode pada Tabel 2.2 yang berhubungan dengan judul, diambil sebanyak dua kode untuk dijadikan sebagai referensi pemetaan metadata yaitu 245 dan 246. Pemilihan dua kode tersebut didasari pada kedekatan pengertian kedua kode tersebut dengan Title pada Dublin Core unqualified. Keakuratan dan ketepatan yang dipengaruhi oleh transformasi metadata tidak dapat diabaikan. Elemen kombinasi, definisi elemen semantik dan bidang aplikasi dari bentuk standar harus dapat diadopsi dan dikenali dengan baik oleh sebagian besar sistem [13]. 2.2 Format Metadata Perhatian yang cukup besar telah diberikan untuk meningkatkan efisiensi dan ruang lingkup web crawler. Web crawler komersial diperkirakan hanya mencakup sekitar 16% keseluruhan isi web [14]. Untuk meningkatkan efisiensi, sejumlah teknik telah diusulkan seperti memperkirakan pembuatan web dan pembaharuan yang lebih akurat, serta strategi crawling yang lebih efisien [15] [16]. Namun, menurut Michael L. Nelson [17], semua pendekatan ini berasal dari fakta bahwa protokol HTTP (HyperText Transfer Protocol) tidak menyediakan semantik untuk memungkinkan web server menjawab pertanyaan mengenai sumber daya yang dimiliki atau yang telah berubah sejak tanggal tertentu. Sejumlah

5 10 pendekatan telah diusulkan untuk memperbaharui semantik pada server HTTP, mulai dari konvensi tentang bagaimana menyimpan indeks URL yang populer [18], hingga kombinasi indeks dan ekstensi HTTP [19]. WebDAV (Web-based Distributed Authoring and Versioning) [20] telah menyediakan beberapa pembaharuan semantik melalui ekstensi HTTP, akan tetapi tidak diterapkan secara luas. RSS (Really Simple Syndication) [21] merupakan format sindikasi yang telah diterapkan secara luas, tidak dapat digunakan untuk memilih data berdasarkan selang waktu tertentu. OAI-PMH memiliki kelengkapan semantik yang umum dan sangat baik yang merupakan standar de facto untuk pertukaran metadata dalam komunitas perpustakaan digital [17] [6]. Penerapan repositori OAI-PMH berdasarkan dokumen XML (extensible Markup Language) telah diuraikan [22], dibatasi oleh skenario tertentu, bukan konten web umum dan tidak terintegrasi langsung ke web server. Karena tidak terintegrasi oleh web server, beberapa peneliti berusaha untuk mengintegrasikan OAI-PMH dengan web server Apache menggunakan modul yang dinamakan mod_oai [17]. 2.3 OAI-PMH OAI-PMH menyediakan kerangka interoperabilitas aplikasi independen berdasarkan pengumpulan metadata. Ada dua komponen utama OAI-PMH yaitu Penyedia Data (Data Provider) dan Penyedia Layanan (Service Provider). Penyedia Data mengelola sistem yang mendukung OAI-PMH sebagai alat untuk mempublikasikan metadata. Persyaratan untuk implementasi OAI-PMH sebagai penyedia data adalah metadata yang disimpan dalam database, web server yang dapat

6 11 diakses via Internet, antarmuka pemrograman, indentifikasi arsip, identifikasi nilai unik untuk masing-masing dokumen, jenis metadata Dublin Core unqualified, penanggalan untuk metadata (tanggal dibuat/modifikasi terakhir) dan hirarki logika. Di sisi lain, penyedia layanan mengumpulkan metadata melalui OAI-PMH sebagai dasar untuk membangun layanan tambahan. OAI-PMH menggunakan satu standar metadata yaitu Dublin Core unqualified [11]. Penyedia karya ilmiah yang masih menggunakan metadata selain Dublin Core dapat melakukan transformasi metadata menjadi Dublin Core unqualified tanpa perlu menghapus metadata yang sedang digunakan. Akses terhadap metadata yang dimiliki harus diberikan secara bebas agar metadata tersebut dapat dimanfaatkan oleh pihak lain. Dalam hal ini, penyedia karya ilmiah berperan sebagai penyedia data. Penyedia karya ilmiah harus memiliki sebuah repositori, yaitu sebuah server yang dapat diakses melalui jaringan komputer, dan dapat memproses enam permintaan OAI-PMH yaitu Identify, ListMetadataFormats, ListSets, ListRecords, GetRecord dan ListIdentifiers [23]. Fungsi repositori ini adalah untuk mempublikasikan metadata kepada pengumpul metadata. Berikut ini entitas OAI-PMH dicetak dengan huruf miring, sedangkan protokol permintaan dicetak dengan jenis huruf courier [17]: a. Sebuah repositori OAI-PMH mempublikasikan metadata sumber daya. Dengan pengertian bahwa sumber daya diluar dari ruang lingkup OAI-PMH.

7 12 b. Item adalah titik awal ke seluruh metadata yang berhubungan dengan sumber daya. Pada protokol, item diidentifikasikan sebagai identifier. c. Sebuah item dapat memberikan akses ke satu atau lebih record. Record berisi metadata (dan informasi sekunder mengenai metadata). Sebuah record tertentu pada OAI-PMH diidentifikasikan sebagai kombinasi dari identifier (dari item), metadataprefix untuk menentukan format metadata yang digunakan pada publikasi metadata dan datestamp. Datestamp adalah tanggal dan waktu pembuatan atau modifikasi metadata. Sebagai catatan bahwa datestamp adalah properti catatan metadata, bukan item sebagaimana yang digunakan pada OAI-PMH versi 1.x. Hal ini mencerminkan bahwa metadata dari berbagai macam format metadata kemungkinan tersedia dan dapat dimodifikasi sendiri sehingga mempunyai datestamp yang berbeda. d. OAI-PMH juga mendefinisikan set sebagai konsep pilihan untuk pengelompokan item untuk tujuan pengumpulan data tertentu. Repositori dapat mengorganisir item menjadi set. OAI-PMH mendukung tiga protokol permintaan yang ditujukan untuk membantu pengumpul agar mengerti repositori OAI-PMH yaitu: a. Identify: digunakan untuk mengambil informasi mengenai sebuah repositori seperti administrator dan lain-lain. b. ListMetadataFormats: digunakan untuk mengambil format metadata yang tersedia pada satu repositori.

8 13 c. ListSets: digunakan untuk mengambil struktur set dari sebuah repositori. Informasi ini sangat berharga untuk pengumpulan jenis metadata tertentu. OAI-PMH mendefinisikan tiga buah protokol permintaan lainnya yang ditujukan untuk pengumpulan metadata secara aktual yaitu: a. ListRecords: digunakan untuk mengumpulkan record dari sebuah repositori. Argumen pilihan mengizinkan pengumpulan secara selektif terhadap records berdasarkan set dan/atau datestamp. b. GetRecord: digunakan untuk mengambil sebuah record tertentu dari sebuah repositori. Dibutuhkan argumen yang menjelaskan bahwa identifier sebuah item berasal dari record yang diminta dan metadata format dari metadata harus disertakan pada record. c. ListIdentifiers merupakan penyingkatan dari ListRecords yang hanya mengambil informasi mengenai identifier, datestamp dan set. Sebagai contoh sebuah repositori yang mendukung OAI-PMH pada URL protokol permintaan berikut digunakan untuk memperoleh metadata seluruh item yang mengalami perubahan sejak 10 Oktober 2010 dalam bentuk Dublin Core: metadataprefix=oai_dc&from=

9 14 Permintaan OAI (HTTP) Balasan OAI (XML) Bahasa Pemrograman (cth. PHP, Java Servlets) Skrip: - Uraikan argumen - Buat pesan kesalahan - Buat query SQL - Buat keluaran XML Web Server (cth. IIS, Apache) Permintaan SQL Penyedia Data OAI Database Balasan DB Gambar 2.1 Diagram Arsitektur Penyedia Data [24] Pada OAI-PMH terdapat mekanisme untuk membatasi jumlah metadata yang dapat ditampilkan oleh penyedia data. Metadata yang tidak lengkap harus memiliki sebuah tag tambahan, yaitu resumptiontoken pada akhir metadata. Tag ini berisi argumen yang membentuk satu alamat URL untuk menampilkan metadata berikutnya. Mekanisme penggunaan resumptiontoken diilustrasikan pada Gambar 2.2. Ambil seluruh metadata repo.org/verb=listrecords&metadataprefix=oai_dc Memberikan 100 dari150 metadata Penyedia Layanan 100 metadata + resumptiontoken ID1 Ambil metadata berikutnya repo.org/verb=listrecords&resumptiontoken=id1 Penyedia Data Memberikan 50 metadata terakhir 50 metadata Gambar 2.2 Ilustrasi Mekanisme resumptiontoken

10 15 Penggunaan resumptiontoken ditujukan untuk memisahkan respon yang berpotensi memakan waktu yang lama menjadi beberapa respon waktu yang lebih pendek. Sebagai contoh jika sebuah repositori memberikan respon sebanyak satu juta record, belum ada repositori maupun pengumpul yang dapat menangani respon tersebut. Untuk mengatasinya repositori dapat memilih untuk memisahkan seluruh record yang terkumpul menjadi beberapa bagian yang masing-masing berjumlah 1000 record. Ukuran resumptiontoken ditentukan oleh repositori, bukan pengumpul. Karena masing-masing repositori memiliki ketenuan yang berbeda untuk menentukan nilai resumptiontoken, mengakibatkan penyedia layanan kesulitan untuk memprediksi nilainya. Ada beberapa parameter pilihan yang dapat ditambahkan yaitu: a. expirationdate, yaitu batas waktu yang disediakan penyedia data untuk memastikan bahwa metadata yang dikirimkan adalah sah b. completelistsize, yaitu jumlah daftar metadata selengkapnya c. cursor, yaitu jumlah metadata yang telah dikirim Dari sisi penyedia data, terdapat kemungkinan munculnya permasalahan pada implementasi resumptiontoken yaitu apabila terjadi perubahan database selama operasi pengumpulan metadata. Gambar 2.3 menunjukkan kasus yang mungkin terjadi apabila terdapat perubahan konten database di antara permintaan awal dan permintaan lanjutan. Jika penyedia data hanya mengingat total data yang telah

11 16 terkirim maka akan ada kemungkinan terjadinya ketidaksesuaian pada permintaan selanjutnya. Ada dua buah solusi yang dapat diterapkan yaitu menduplikasi data pada tabel permintaan dan solusi lainnya adalah menyimpan tanggal permintaan awal dengan parameter lainnya dan menggunakannya seperti argumen until. Ambil seluruh metadata repo.org/oai?verb=listrecords& metadataprefix=oai_dc&from= Ada 267 metadata, diberikan metadata + resumptiontoken ID1 Ambil metadata selanjutnya repo.org/oai?verb=listrecords& resumptiontoken=id1 Ada 268 metadata, diberikan metadata + resumptiontoken ID2 Penyedia Data ID1={ from= , until=empty, set=empty, mdp=oai_dc, date= T15:00:00Z, delivered=100 } (1) select dc-data from metadata-table (2) 267 dokumen (4) select dc-data from metadata-table (5) 268 dokumen Database (3) insert, update, delete Gambar 2.3 Permasalahan pada Implementasi resumptiontoken 2.4 Sistem Pengumpul Metadata Terdistribusi Menurut Tanenbaum [25], kumpulan dari beberapa komputer independen yang terlihat sebagai sebuah komputer tunggal bagi penggunanya merupakan sebuah sistem terdistribusi. Secara normal, setiap sistem terdistribusi mengandalkan layanan yang disediakan oleh jaringan komputer. Salah satu karakteristik yang penting pada sistem terdistribusi adalah perbedaan antara berbagai komputer dan cara berkomunikasi disembunyikan dari pengguna. Selain itu pengguna dan aplikasi dapat berinteraksi dengan sistem terdistribusi dengan cara yang seragam dan konsisten.

12 17 Empat tujuan utama yang harus terpenuhi dalam membangun sebuah sistem terdistribusi yaitu [25]: a. Menghubungkan pengguna dan sumber daya Sistem terdistribusi yang dibangun ditujukan untuk mempermudah pengguna dalam mengakses sumber daya yang jauh dan membaginya dengan pengguna lain. b. Transparansi Distribusi proses dan sumber daya yang secara fisik terdiri dari beberapa komputer harus disembunyikan sehingga pengguna hanya merasa menggunakan komputer tunggal. c. Keterbukaan Sistem terdistribusi yang dibangun adalah sebuah sistem yang menawarkan layanan berdasarkan peraturan standar yang menjelaskan sintaks dan semantik layanan tersebut. d. Skalabilitas Skalabilitas sebuah sistem terdistribusi dapat diukur selama terdapat setidaknya tiga buah dimensi yang berbeda [26]. Pertama, ukuran sebuah sistem yang maksudnya dapat menambah pengguna atau sumber daya dengan mudah pada sistem tersebut. Kedua, pengguna dan sumber daya memungkinkan untuk dipisahkan dengan jarak yang jauh. Ketiga, sistem secara administrasi dapat ditingkatkan, yang maksudnya adalah kemudahan pengelolaan sistem pada saat terjadi pengembangan administrasi organisasi.

13 Komunikasi Komunikasi antar proses adalah jantung dari sistem terdistribusi. Pertukaran informasi antar mesin yang berbeda merupakan hal yang sangat penting. Empat model komunikasi yang sering digunakan adalah Remote Procedure Call (RPC) [27], Remote Method Invocation (RMI) [28], Message-Oriented Middleware (MOM) [29] dan stream [25]. Model komunikasi yang dipilih pada penelitian ini adalah RMI karena dapat diimplentasikan pada platform komputer yang berbeda. Ruang lingkup penelitian yang berupa jaringan komputer lokal juga menjadi pertimbangan pemilihan RMI. Komputer Jaringan Komputer Aplikasi Klien Penyedia Layanan Program menunggu respon Program melanjutkan eksekusi kode berikutnya return() Memanggil layanan Prosedur lokal dieksekusi dan mengembalikan hasilnya Gambar 2.4 Diagram Sekuensial Untuk Remote Procedure Call (RPC) [30] RMI merupakan pengembangan dari RPC yang mendukung polymorphism [31]. Pada level dasar, RMI mirip dengan mekanisme RPC seperti pada Gambar 2.4.

14 19 RMI mempunyai beberapa kelebihan dibandingkan dengan RPC karena merupakan bagian dari pendekatan berorientasi objek dalam bahasa pemrograman java. Konektivitas pada sistem menggunakan fungsi native, artinya RMI dapat menggunakan pendekatan yang alami (natural), langsung dan sangat mendukung teknologi komputasi terdistribusi sehingga dapat ditambahkan fungsi java pada sistem. Sedangkan RPC tidak dapat menyediakan fungsi yang tidak tersedia pada platform target. Untuk mengimplementasikan fitur cross-platform seperti pada java, RPC membutuhkan usaha yang lebih besar dibandingkan dengan RMI. RPC harus mengkonversi argumen antar arsitektur sehingga masing-masing komputer dapat menggunakan tipe data native. Keterbatasan RMI dikarenakan pemanggilan fungsi hanya dapat dilakukan dengan java. Untuk memanggil fungsi dalam bahasa lain RMI bergantung pada teknologi lain seperti JNI (Java Native Interface) [32], JDBC (Java DataBase Connectivity) [33], RMI-IIOP (Remote Method Invocation over Internet Inter-Orb Protocol) [34] dan lain-lain. Menurut Nester [35], pada implementasinya RMI akan lambat khususnya untuk perhitungan yang membutuhkan performa tinggi. Hal ini dikarenakan RMI dirancang berdasarkan serialisasi objek yang lambat dan tidak mendukung performa yang tinggi untuk komunikasi jaringan. Selain itu tambahan byte-code yang diinterpretasikan menggunakan JVM (Java Virtual Machine) [36] membuat RMI lebih lambat dibandingkan dengan RPC. Tetapi, performa yang lebih baik didapat dari RMI pada saat implementasi pemanggilan fungsi yang bersifat multipleconcurrent karena dukungan thread pada bahasa java.

15 20 Sistem RMI dirancang untuk menyediakan pondasi bagi komputasi terdistribusi yang berorientasi objek. Arsitekturnya memungkinkan untuk penambahan server dan tipe referensi sehingga RMI dapat menambah fitur dengan terkoordinir [37]. expserver.getpolicy(); Stub Menggabung parameter Kirim permintaan Skel Memisahkan parameter Invoke implementation return new TodayPolicy() Impl Menerima hasil (atau exception) Menggabung hasil (atau exception) Kirim balasan Memisahkan balasan Kembalikan nilai (atau exception) Gambar 2.5 Stub dan Skeleton [37] Ketika klien menerima referensi ke sebuah server, RMI mengunduh stub yang menerjemahkan panggilan terhadap referensi menjadi panggilan jarak jauh ke server. Seperti yang ditunjukkan pada Gambar 2.5, stub menggabungkan argumen ke prosedur menggunakan serialisasi objek dan mengirimkannya ke server. Di sisi server sistem RMI menerima panggilan tersebut dan terhubung ke skeleton, yang bertanggung jawab untuk memisahkan argumen dan mengimplementasikan prosedur yang dipanggil. Ketika implementasi di sisi server telah selesai, apakah hasilnya adalah nilai atau exception, skeleton akan menggabungkan hasil tersebut dan mengirimkannya ke stub. Stub akan memisahkan balasan sesuai dengan yang dikirimkan dari server. Stub dan skeleton biasanya dibuat menggunakan program

16 21 kompilasi yang disebut rmic. Stub menggunakan referensi untuk berbicara dengan skeleton. Penelitian ini menggunakan bahasa java karena RMI hanya dapat diimplementasikan dengan bahasa tersebut. Implementasi RMI membutuhkan tiga buah lapisan abstraksi yang diilustrasikan pada Gambar 2.6. Program Klien Program Server Sistem RMI Stub dan Skeleton Remote Reference Layer Stub dan Skeleton Remote Reference Layer Transport Layer Gambar 2.6 Ilustrasi Implementasi RMI [38] Fungsi ketiga lapisan abstraksi tersebut adalah: a. Stub dan Skeleton yang menerima pemanggilan fungsi yang dibuat oleh klien ke variabel referensi di interface dan melewatkannya ke layanan RMI yang jauh. b. Remote Reference digunakan untuk menginterpretasikan dan referensi manajemen yang dibuat dari klien ke layanan objek yang jauh. c. Transport Layer, berdasarkan koneksi TCP/IP antara mesin-mesin di dalam jaringan komputer.

17 22 Klien yang akan menghubungi server RMI harus mempunyai referensi server RMI terlebih dahulu. Penggunaan fungsi Naming.lookup adalah mekanisme yang umum digunakan oleh klien untuk menginisialisasi referensi server RMI. Yang dilakukan oleh fungsi ini adalah menggunakan stub untuk membuat pemanggilan fungsi jarak jauh terhadap rmiregistry, yang kemudian mengembalikan referensi pada objek yang melakukan permintaan menggunakan fungsi lookup (Gambar 2.7). Setiap referensi jarak jauh berisi nama server dan nomor port agar klien dapat menentukan lokasi Virtual Machine yang melayani objek jarak jauh tertentu. Referensi nama server dan nomor port yang diperoleh klien akan digunakan untuk membuka koneksi soket ke server yang dituju. RMI Client RMI Registry (1) Membuat interface untuk referensi objek jarak jauh TesInterf ti; ti = (TesInterf)Naming.lookup( //rmisvr/namaobjek ); (2) Membuat objek baru dari class stub yang sedang berjalan pada server RMI (rmisvr) untuk class stub (3) Memanggil fungsi lookup (namaobjek) dari rmiregistry dengan menggunakan referensi yang dibuat pada langkah (2) (4) Rmiregistry mengembalikan referensi pada namaobjek (5) Naming.lookup mengembalikan referensi jarak jauh pada namaobjek Gambar 2.7 Pemanggilan Referensi Server oleh Klien

18 23 Pemanggilan fungsi pada server dilakukan oleh klien dan akan diproses melalui stub dan skeleton. Secara umum, parameter yang dapat dilewatkan pada stub dan skeleton hanyalah variabel native seperti String dan Integer. Akan tetapi, pada umumnya parameter yang akan dikirimkan baik melalui server ataupun klien tidak hanya berupa variabel native. Pengiriman objek dari sebuah class tertentu, baik class yang didefinisikan oleh Java maupun yang dibuat oleh pengembang program memerlukan implementasi class Serialization. Dengan adanya implementasi serialisasi, objek tertentu dapat dilewatkan melalui stream baik dari klien menuju server maupun sebaliknya Kebutuhan Penggunaan Sistem Terdistribusi Pertumbuhan metadata OAI-PMH yang dipublikasikan di Internet menyebabkan timbulnya kesulitan bila hanya dilakukan oleh satu pengumpul. Seperti halnya crawler, penggunaan beberapa pengumpul secara bersamaan dengan sistem terdistribusi akan sangat bermanfaat [39]. Dengan menggunakan metode ini diharapkan dapat meningkatkan kemampuan pengumpulan metadata secara maksimal. Beberapa manfaat dari sistem terdistribusi adalah: a. Skalabilitas, untuk mengimbangi pertumbuhan metadata OAI-PMH, kemampuan pengumpulan dapat ditingkatkan dengan menambah jumlah pengumpul yang dieksekusi secara paralel.

19 24 b. Penyebaran dan pengurangan beban jaringan, jika pengumpul dijalankan pada lokasi yang secara geografis berjauhan dan masing-masing mengumpulkan metadata pada lokasi geografisnya masing-masing. 2.5 Sinkronisasi Proses Paralel Sumber daya yang dimiliki oleh komputer tidak dapat dimanfaatkan secara maksimal apabila hanya menggunakan satu proses untuk melakukan pengumpulan metadata. Solusi yang dapat diterapkan untuk memanfaatkan sumber daya yang belum terpakai adalah dengan menggunakan proses paralel. Pada bahasa pemrograman java, proses paralel diterapkan menggunakan class Thread. Dengan menggunakan proses paralel pada bahasa java dapat menimbulkan sebuah masalah baru. Akses yang bersamaan terhadap satu objek tertentu memungkinkan untuk terjadinya kesalahan yaitu gangguan pada thread dan konsistensi memori. Untuk menghindari kesalahan-kesalahan ini diperlukan sinkronisasi pada objek agar dapat menerapkan satu akses khusus pada satu waktu (mutual exclusive access) pada bagian yang kritis diantara dua proses. Sinkronisasi diperlukan hanya untuk objek yang nilainya dapat berubah. Objek yang bersifat hanya dapat dibaca tidak perlu menerapkan sinkronisasi. Penerapan sinkronisasi pada bahasa java dilakukan dengan menggunakan kata kunci synchronized pada objek atau fungsi yang akan disinkronisasi. Sinkronisasi pada bahasa java memastikan adanya satu akses khusus pada satu waktu terhadap sumber daya yang digunakan bersama dan mencegah ketidaksesuaian data.

20 25 Penggunaan sinkronisasi juga mencegah kompiler melakukan pengurutan ulang yang dapat menyebabkan terjadinya masalah pada proses yang dijalankan bersama-sama. Sinkronisasi yang diterapkan sudah termasuk fitur penguncian, yaitu mencegah proses yang baru mengubah data pada memori pada saat ada proses yang sedang menggunakannya dan membuka akses setelah penggunaan memori selesai. Hal ini dapat mencegah ketidaksesuaian pembacaan memori.