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 (MachineReadable 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 Universitas Sumatera Utara

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 100, 110, 111, 700, 710, 711 720 651, 662 751, 752 008/07-10 260$c$g 500-599, except 506, 530, 540, 546 340 856$q 020$a, 022$a, 024$a 856$u 008/35-37 041$a$b$d$e$f$g$h$j 546 260$a$b 530, 760-787$o$t 506, 540 534$t 786$o$t 050, 060, 080, 082 600, 610, 611, 630, 650, 653 245, 246 Leader06, Leader07 655

Dublin Core Contributor Coverage Creator Date Description Format Identifier Language

Publisher Relation Rights Source Subject Title Type

Universitas Sumatera Utara

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 222

Abbreviation Title = singkatan judul Key Title = judul unik tertentu yang digunakan untuk serial Uniform Title = judul utama yang muncul untuk dokumen-dokumen yang memiliki judul ganda Translation of Title by Cataloging Agency = terjemahan judul oleh agensi pengatalogan Collective Uniform Title = judul umum yang digagas oleh pengatalog untuk mengumpulkan karya-karya pengarang yang produktif Title Statement = judul utama sebuah dokumen 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 Former Title = digunakan apabila satu dokumen katalog mewakili beberapa judul yang berhubungan dengan satu kesatuan

240 242 243

245 246

247

Dengan

menggunakan

metadata

MARC,

sebuah

dokumen

dapat

direpresentasikan secara mendetail. Misalnya pengelompokan metadata MARC


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


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


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.


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.


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


14

Permintaan OAI (HTTP)

Balasan OAI (XML)

Bahasa Pemrograman (cth. PHP, Java Servlets)

Web Server (cth. IIS, Apache)

Skrip: - Uraikan argumen - Buat pesan kesalahan - Buat query SQL - Buat keluaran XML

Permintaan SQL

Balasan DB

Database

Penyedia Data OAI

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 100 metadata + resumptionToken “ID1” Penyedia Layanan

Penyedia Data

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

Gambar 2.2 Ilustrasi Mekanisme resumptionToken


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


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=2011-01-01

(1) select dc-data from metadata-table Penyedia Data

Ada 267 metadata, diberikan 100 100 metadata + resumptionToken “ID1”

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

Ada 268 metadata, diberikan 100

(2) 267 dokumen ID1={ from=2011-01-01, until=empty, set=empty, mdP=oai_dc, date=2010-1212T15:00:00Z, delivered=100 }

(3) insert, update, delete

(4) select dc-data from metadata-table (5) 268 dokumen

Database

100 metadata + resumptionToken “ID2”

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.


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.


18

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. Komputer A

Jaringan

Aplikasi Klien

Komputer B Penyedia Layanan

Program menunggu respon

return() Program melanjutkan eksekusi kode berikutnya

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.


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.


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(); Menggabung parameter Kirim permintaan Memisahkan parameter Invoke implementation

Skel

Stub

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


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.

Sistem RMI

Program Klien

Program Server

Stub dan Skeleton

Stub dan Skeleton

Remote Reference Layer

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.


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


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


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.


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.


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

Recommend Documents