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

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.

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 720 651, 662 Coverage 751, 752 Creator 008/07-10 Date 260$c$g 500-599, 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 546 260$a$b Publisher 530, 760-787$o$t Relation 506, 540 Rights 534$t Source 786$o$t 050, 060, 080, 082 Subject 600, 610, 611, 630, 650, 653 245, 246 Title

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

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

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

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.

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

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 http://repository.usu.ac.id/oai/, protokol permintaan berikut digunakan untuk memperoleh metadata seluruh item yang mengalami perubahan sejak 10 Oktober 2010 dalam bentuk Dublin Core:

http://repository.usu.ac.id/oai/request?verb=ListRecords& metadataPrefix=oai_dc&from=2010-10-10

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 Balasan DB Database Permintaan OAI (HTTP) Balasan OAI (XML) Penyedia Data OAI

Gambar 2.1Diagram 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.

Penyedia Layanan

Penyedia Data Ambil seluruh metadata

Memberikan 100 dari150 metadata 100 metadata + resumptionToken “ID1” repo.org/verb=ListRecords&metadataPrefix=oai_dc

Ambil metadata berikutnya

repo.org/verb=ListRecords&resumptionToken=ID1 Memberikan 50 metadata terakhir

50 metadata

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

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.

Database (1) select dc-data from metadata-table (2) 267 dokumen (3) insert, update, delete (4) select dc-data from metadata-table (5) 268 dokumen Ambil seluruh metadata

repo.org/oai?verb=ListRecords& metadataPrefix=oai_dc&from=2011-01-01

Ada 267 metadata, diberikan 100

100 metadata + resumptionToken “ID1”

Ambil metadata selanjutnya

repo.org/oai?verb=ListRecords& resumptionToken=ID1

Ada 268 metadata, diberikan 100

100 metadata + resumptionToken “ID2”

Penyedia Data ID1={ from=2011-01-01, until=empty, set=empty, mdP=oai_dc, date=2010-12-12T15:00:00Z, delivered=100 }

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.

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

2.4.1 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.

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.

Komputer A Komputer B Jaringan Aplikasi Klien Penyedia Layanan Program menunggu respon Program melanjutkan eksekusi kode berikutnya Memanggil layanan Prosedur lokal dieksekusi dan mengembalikan hasilnya return()

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

multiple-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].

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

expServer.getPolicy(); Menggabung parameter Kirim permintaan

Memisahkan parameter Invoke implementation

return new TodayPolicy() Menerima hasil (atau exception)

Menggabung hasil (atau exception) Kirim balasan

Memisahkan balasan

Kembalikan nilai (atau exception) Stub

Skel

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.

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.

Stub dan Skeleton Remote Reference

Layer Program

Klien

Stub dan Skeleton Remote Reference Layer Program Server Transport Layer Sistem RMI

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.

Gambar 2.7 Pemanggilan Referensi Server oleh Klien (1) Membuat interface untuk referensi objek jarak jauh

TesInterf ti;

ti = (TesInterf)Naming.lookup(“//rmisvr/namaObjek”);

(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

RMI Client RMI Registry

(2) Membuat objek baru dari classstub yang sedang berjalan pada server RMI (rmisvr) untuk classstub

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.

2.4.2 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.

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 classThread.

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.

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.