BAB II DASAR TEORI. 2.1 Event. 2.2 Web Service II-1

Transkripsi

1 BAB II DASAR TEORI Pada bab ini akan dibabarkan dasar-dasar teori yang menjadi landasan pengerjaan tugas akhir ini. Dasar-dasar teori ini didapatkan dari studi literatur yang merupakan salah satu metodologi dalam pengerjaan tugas akhir ini. Dasar-dasar teori mencakup kajian terhadap event, web service, WSDL, SOAP, RFC2445, dan penanggalan Gregorian. 2.1 Event Event dalam tugas akhir ini berarti suatu kejadian yang mendapat perhatian. Kejadian ini bisa telah terjadi, sedang terjadi, atau akan terjadi. Kejadian ini juga dapat berupa kejadian yang tidak direncanakan sebelumnya(insidental), seperti kelahiran atau kematian dan kejadian yang telah direncanakan sebelumnya, seperti rapat, pesta, ujian, atau perlombaan. Ada dua jenis event, event yang hanya terjadi sekali dan event yang terjadi secara berulang. Biasanya kejadian yang tidak direncanakan sebelumnya, termasuk dalam event yang hanya terjadi sekali. Sedangkan kejadian yang direncanakan bisa terjadi sekali atau berulang. 2.2 Web Service Web service adalah salah satu bentuk sistem perangkat lunak yang didesain untuk mendukung interaksi mesin-ke-mesin melalui jaringan. Web service memiliki interface yang dideskripsikan dalam format yang dapat dibaca oleh mesin. Sistem-sistem lainnya berinteraksi dengan web service menggunakan pesan SOAP yang umumnya dikirim melalui HTTP dalam bentuk XML [W3C04]. Definisi diatas diberikan oleh World Wide Web Consortium(W3C) yang merupakan badan yang menciptakan dan mengembangkan standar web service. Tetapi secara umum, web service tidak terbatas hanya pada standar SOAP saja. Salah satu pustaka yang mengulas lengkap tentang web service menyebutkan definisi yang lebih umum: web service adalah aplikasi yang diakses melalui internet menggunakan protokol standar internet dan menggunakan XML sebagai format pesannya [RIC06]. II-1

2 II-2 Definisi yang lebih luas diatas lebih cocok diberikan kepada web service daripada definisi yang lebih ketat dan membatasi yang diberikan oleh W3C karena web service tidak dibentuk berdasarkan standar SOAP semata-mata saja Arsitektur Web Service Secara umum, arsitektur web service dapat dilihat pada gambar II-1. Gambar II-1 Arsitektur web service Pada gambar diatas, ada tiga komponen yang membuat web service berjalan. Ketiga komponen itu adalah: 1. Service Registry Service registry adalah sistem yang mengatur pendaftaran web service. Agar suatu web service yang dibuat mudah ditemukan oleh orang lain, maka web service itu perlu didaftarkan disini. Pengguna yang membutuhkan suatu web service tertentu dapat dengan

3 II-3 mudah menemukannya dari daftar yang disediakan disini. Deskripsi dari layanan yang tersedia berupa WSDL dan Universal Description Discovery and Integration(UDDI). UDDI secara singkat adalah yellow pagesnya web service. 2. Service Requester Service requester adalah pengguna yang meminta layanan web service. Untuk menggunakan suatu web service, pengguna dapat menemukan web service tersebut melalui service registry atau dapat secara langsung melakukan hubungan dengan service provider. 3. Service Provider Service provider adalah penyedia layanan web service. Penyedia dapat mendaftarkan web servicenya di service registry atau tidak. Penyedia yang mendaftarkan layanannya mengirimkan deskripsi tentang layanannya dalam bentuk WSDL dan UDDI Jenis Web Service Jenis web service dapat dibagi menjadi dua, yaitu REST dan SOAP Representational State Transfer(REST) REST adalah salah satu jenis web service yang menerapkan konsep perpindahan antar state. State disini dapat digambarkan seperti jika browser meminta suatu halaman web, maka server akan mengirimkan state halaman web yang sekarang ke browser. Bernavigasi melalui link-link yang disediakan sama halnya dengan mengganti state dari halaman web. Begitu pula REST bekerja, dengan bernavigasi melalui link-link HTTP untuk melakukan aktivitas tertentu, seakan-akan terjadi perpindahan state satu sama lain. Perintah HTTP yang bisa digunakan adalah fungsi GET, POST, PUT atau DELETE. Balasan yang dikirimkan adalah dalam bentuk XML sederhana tanpa ada protokol pemaketan data, sehingga informasi yang diterima lebih mudah dibaca dan diparsing di sisi client. Dalam pengaplikasiannya, REST lebih banyak digunakan untuk web service yang berorientasi pada resource. Maksud orientasi pada resource adalah orientasi yang menyediakan resource-resource sebagai layanannya dan bukan kumpulan-kumpulan dari aktifitas yang mengolah resource itu. Alasan mengapa REST tidak digunakan dalam tugas akhir ini karena orientasi pada resourcenya itu, sedangkan aplikasi event calendar membutuhkan pemanggilan metode yang bisa dikerjakan terhadap kumpulan resource

4 II-4 event. Selain itu, karena standarnya yang kurang sehingga tidak begitu cocok diterapkan dalam aplikasi yang membutuhkan kerjasama antar aplikasi lain, dimana standar yang baik akan sangat berguna karena berbicara dalam satu bahasa yang sama. Beberapa contoh web service yang menggunakan REST adalah: Flickr API(Application Program Interface), YouTube API, Amazon API Simple Object Access Protocol(SOAP) SOAP adalah protokol untuk saling bertukar pesan dalam format XML antar komputer di dalam jaringan, biasanya menggunakan HTTP/HTTPS [SOA07]. Web service dalam tugas akhir ini menggunakan SOAP 1.1 sebagai protokol pengiriman pesannya. Dalam menjalankan tugasnya, SOAP menggunakan struktur XML tertentu dalam pengirimkan request kepada web service. Penerimaan respon dari web servicepun memiliki strukturnya sendiri. Agar lebih mudah dalam memahami SOAP, di bawah ini diberikan salah satu contoh struktur dari SOAP 1.1 request: <?xml version="1.0" encoding="utf-8"?> <SOAP-ENV:Envelope xmlns:soap-env=" xmlns:ns1="urn:exampleapi"> <SOAP-ENV:Body> <ns1:getpeoplebyfirstlastname> <first>j*</first> <last>*</last> </ns1:getpeoplebyfirstlastname> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Struktur ini terdiri dari dua bagian, Envelope dan Body. Envelope berisi keteranganketerangan tentang namespace yang digunakan dalam dokumen XML ini, dan juga dapat berisi atribut dan header. Sedangkan Body berisi pesan yang akan dikirimkan ke web service. Dalam contoh diatas, Body berisi permintaan akan operasi

5 II-5 getpeoplebyfirstlastname yang disediakan suatu web service dengan parameter yang dikirimkan berupa nama depan dengan huruf pertama j dan nama belakang apa saja. Sedangkan contoh SOAP 1.1 response yang didapat dari server diberikan dalam contoh dibawah: <?xml version="1.0" encoding="utf-8"?> <SOAP-ENV:Envelope xmlns:soap-env=" xmlns:soap-enc=" <SOAP-ENV:Body> <result> <SOAP-ENC:Struct> <id>1</id> <firstname>john</firstname> <lastname>smith</lastname> </SOAP-ENC:Struct> <SOAP-ENC:Struct> <id>2</id> <firstname>jane</firstname> <lastname>doe</lastname> </SOAP-ENC:Struct> </result> </SOAP-ENV:Body> S </SOAP-ENV:Envelope> t r Struktur SOAP response di atas juga sama dengan struktur SOAP request yang diterangkan sebelumnya, tetapi bisa kita lihat disini, isi dari body memiliki tag result yang berisi balasan atau output dari operasi web service yang dipanggil pada pesan SOAP request. Beda halnya dengan REST, SOAP web service lebih menekankan pada web service yang berorientasi service. Ketimbang mengambil resource-resource seperti dalam REST, SOAP lebih ke arah pemanggilan metode-metode yang memanipulasi resource-resource yang ada, dalam arti lain, melayani kebutuhan pengguna yang lebih beragam. Beberapa contoh SOAP web service adalah Google API, Yahoo! API, dan aplikasi event calendar.

6 II Web Service Definition Language(WSDL) SOAP dapat berjalan sendiri tanpa bantuan WSDL, tetapi hal ini akan menyulitkan pengembang di sisi client karena tidak tahu harus mengharapkan operasi dan bentuk data apa. Karena itu WSDL diciptakan sebagai pendefinisi sebuah web service. WSDL adalah tata bahasa XML yang digunakan untuk mendeskripsikan sebuah web service. WSDL menjabarkan bagaimana web service diakses, operasi-operasi web service, bagaimana pesan disampaikan, dan struktur dari pesan tersebut [RIC06]. Dalam tugas akhir ini, web service yang dibangun akan dijabarkan menggunakan WSDL 1.1. Struktur dari WSDL 1.1 adalah sebagai berikut: <definitions xmlns=" <types> </types> <message> </message> <porttype> </porttype> <binding> </binding> <service> </service> </definitions> Struktur ini terdiri atas lima bagian, yaitu: 1. Types Bagian types menjabarkan definisi tipe data yang digunakan dalam pertukaran pesan, tipe data disini dapat berupa tipe data sederhana ataupun tipe data yang kompleks.

7 II-7 2. Message Bagian message berisi abstraksi parameter input dan output yang diharapkan dari pertukaran pesan. Parameter input dan output ini menggunakan tipe data yang dijabarkan di bagian types. 3. PortType Bagian porttype berisi koleksi dari abstraksi operasi-operasi web service dan abstraksi pesan-pesan yang digunakan oleh tiap-tiap operasi. 4. Binding Bagian binding adalah bagian yang menjabarkan informasi mengenai protokol transpor yang digunakan dan format pesannya. 5. Service Yang terakhir adalah bagian service, bagian ini yang mendeskripsikan nama dan lokasi dari suatu web service. 2.3 RFC2445(iCalendar) RFC2445 berisi spesifikasi mengenai penjadwalan dan pengalendaran internet. RFC2445 menjadi standar bagi format kalendar yang ditransmisikan melalui internet dan dinamakan icalendar. Dewasa ini banyak aplikasi yang sudah memberikan dukungannya terhadap standar ini, diantaranya adalah ical, Mozilla Calendar(Lightning dan Sunbird), Microsoft Office Outlook 2007, dan lain-lain. Aplikasi web event calendar yang dibuat dalam tugas akhir ini menggunakan komponen event yang dijabarkan dalam RFC2445, yaitu vevent. vevent adalah bagian dari standar RFC2445 yang mendeskripsikan bagaimana sebuah event dijabarkan. vevent berisi banyak komponen, di bawah ini dicantumkan komponen-komponen yang penting dan dijadikan rujukan bagi struktur data event yang akan dibuat: 1. UID yang berisi unique identifier bagi suatu event. Unique identifier ini terdiri dari gabungan local date-time, suatu sekuens id yang unik, dan nama host tempat event dibuat. Sekuens id yang unik ini bisa berupa apa saja, tetapi yang digunakan dalam aplikasi ini adalah gabungan empat digit waktu mikro dan enam alfabet acak. 2. DTSTART yang mendeskripsikan kapan suatu event dimulai. Format DTSTART yang didukung oleh aplikasi web event calendar adalah format local date-time, yaitu YYYYMMDDTHHMMSS (Y=tahun, M=bulan, D=hari, T=time, H=jam, M=menit, S=detik).

8 II-8 3. DTEND yang mendeskripsikan kapan suatu event berakhir. Format DTEND yang digunakan sama dengan format yang digunakan pada DTSTART. 4. DTSTAMP yang mendeskripsikan kapan suatu event dibentuk atau diubah. Format DTSTAMP adalah local date-time. 5. SUMMARY yang berisi rangkuman dari suatu event. Formatnya berupa teks. 6. DESCRIPTION yang berisi deskripsi lengkap dari suatu event. Formatnya berupa teks. 7. CATEGORIES yang berisi pilihan apakah event tersebut berupa bisnis, perayaan, pribadi, dsb. Formatnya berupa teks. 8. RRULE yang mendeskripsikan aturan bagi event yang berulang. Formatnya berupa seperangkat aturan yang dinamakan recurrence rule. 9. LOCATION yang berisi tempat event terjadi. Formatnya berupa teks. 10. CONTACT yang berisi informasi mengenai pihak yang dapat dihubungi untuk mendapatkan informasi lebih tentang event yang terjadi. Formatnya berupa teks. Jika pembaca tertarik untuk mempelajari standar RFC2245 lebih jauh lagi, standar ini terletak pada situs berikut: Teori Penanggalan Gregorian Penanggalan Gregorian merupakan bentuk revisi dari penanggalan Julian, yang diusulkan oleh doctor Aloysius Lilius dan disahkan oleh Paus Gregorius XIII pada tanggal 24 Februari Penanggalan Gregorian merupakan penanggalan yang paling banyak digunakan sekarang di seluruh dunia [GRE07]. Satu tahun dalam penanggalan Gregorian berisi 365 hari atau 366 hari, yang dibagi ke dalam dua belas bulan, tergantung pada apakah tahun tersebut jatuh dalam aturan tahun kabisat atau tidak. Tahun kabisat dalam penanggalan Gregorian harus memenuhi aturan sebagai berikut: tahun kabisat terjadi setiap kelipatan empat tetapi bukan kelipatan seratus, atau kelipatan empat ratus. Hal ini yang membedakan penanggalan Gregorian dari Julian. Penanggalan Julian memberikan tahun kabisat setiap kelipatan empat, sehingga dalam siklus 400 tahun penanggalan Julian lebih dahulu tiga hari daripada penanggalan Gregorian. Penanggalan Gregorian terdiri dari dua belas bulan, yaitu Januari yang berisi 31 hari, Februari yang berisi 28 hari bila tahun biasa dan 29 hari bila tahun kabisat, Maret yang berisi 31 hari, April

9 II-9 yang berisi 30 hari, Mei yang berisi 31 hari, Juni yang berisi 30 hari, Juli yang berisi 31 hari, Agustus yang berisi 31 hari, September yang berisi 30 hari, Oktober yang berisi 31 hari, November yang berisi 30 hari, dan Desember yang berisi 31 hari. Satu tahun Gregorian setara dengan hari. Jika mengacu pada mean tropical year yang memiliki hari pada tahun 2000, maka penanggalan Gregorian memiliki tingkat kesalahan satu hari setiap 3300 tahun. Hal ini menjadikan penanggalan Gregorian jauh lebih akurat daripada penanggalan Julian yang memiliki kesalahan satu hari setiap 128 tahun.