BAB 2 TINJAUAN PUSTAKA

(1)

BAB 2

TINJAUAN PUSTAKA

2.1 Arsitektur Perangkat Lunak

Arsitektur perangkat lunak adalah sekumpulan pernyataan yang menggambarkan komponen perangkat lunak dan fungsi-fungsi yang ada pada komponen tersebut. Ia menggambarkan struktur teknis, batasan-batasan, ciri-ciri, serta antarmuka pada komponen-komponen tersebut. Arsitektur merupakan rancangan fisik sistem dan oleh karena itu membutuhkan rencana yang matang pada saat pembuatannya (Krafzig et al, 2004).

Arsitektur perangkat lunak merupakan struktur sebuah sistem, yang meliputi elemen perangkat lunak, sifat (property) yang tampak dari elemen itu, serta relasi di antara elemen-elemen tersebut (Bass et al dalam Krafzig et al, 2004). Sifat yang tampak misalnya fungsi apa saja yang disediakan oleh elemen, bagaimana kinerjanya, bagaimana penanganan kesalahannya, sumber daya apa saja yang digunakan.

Menurut Erl (2009), ada tiga elemen yang saling berkaitan erat ketika berbicara tentang arsitektur perangkat lunak. Pertama adalah arsitektur teknologi, yaitu desain fisik dari suatu perangkat lunak. Kedua adalah infrastruktur teknologi, yaitu lingkungan pendukung yang termasuk di dalamnya perangkat keras dan perangkat lunak. Ketiga adalah perangkat lunak itu sendiri. Berikut adalah diagram sederhana yang memperlihatkan keterkaitan ketiga elemen tersebut.

(2)

Gambar 2.1 Hubungan arsitektur, infrastruktur, dan perangkat lunak (Erl, 2009)

Istilah “arsitektur” berasal dari istilah yang digunakan pada bidang konstruksi bangunan. Sebuah bangunan memiliki desain fisik yang digambarkan dalam cetak biru arsitektur (architecture blueprint) atau disebut juga spesifikasi arsitektur. Suatu bangunan berada dalam lingkungan tertentu. Lingkungan ini bisa memberikan dukungan ataupun tidak terhadap bangunan tersebut. Sebagai contoh, bangunan perumahan yang dididukung oleh sarana transportasi, pembangkit tenaga listrik, dan sistem pembuangan limbah. Lingkungan pendukung inilah yang disebut infrastruktur. Agar bangunan dapat memanfaatkan infrastruktur tersebut, desain fisiknya harus mengintegrasikan berbagai infrasturktur tadi ke dalam arsitekturnya. Oleh karena itu, spesifikasi arsitektur sebuah bangunan haruslah memperhatikan infrastruktur di sekitarnya. Begitu juga dengan perangkat lunak, rancangan arsitekturnya harus memperhatikan infrastruktur di mana perangkat lunak ini akan ditempatkan.

2.2 Arsitektur Berorientasi Layanan (Service Oriented Architecture atau SOA)

Apabila melihat kehidupan sehari-hari, aktivitas yang terjadi di dalam kota tempat kita tinggal dapat dijadikan analogi untuk memahami apa itu layanan (service). Salah satu aktivitas yang dapat dikatakan berorientasi layanan (service oriented) adalah kegiatan

(3)

bisnis. Setiap perusahaan telah berorientasi layanan, masing-masing perusahaan menawarkan layanan yang dapat digunakan oleh beragam konsumen. Secara kolektif, mereka membentuk suatu komunitas bisnis. Suatu komunitas bisnis tidak ditangani oleh perusahaan tunggal yang menyediakan semua layanan, melainkan ada berbagai perusahaan yang menawarkan layanannya masing-masing. Berbagai perusahaan yang tergabung dalam komunitas tersebut dapat tersebar di berbagai tempat.

Keterkaitan antara perusahaan yang satu dengan yang lainnya juga minimal. Ini diperlukan agar apabila ada suatu perusahaan yang berpotensi, perusahaan tersebut dapat berkembang tanpa terhalang ketergantungan pada perusahaan lain. Perusahaan yang ada bersifat mandiri sehingga dapat mengembangkan kegiatan bisnisnya sendiri. Namun walaupun bersifat mandiri, berbagai perusahaan tersebut tetap harus mematuhi suatu aturan tertentu, misalnya penggunaan mata uang yang standar untuk urusan pertukaran barang dan jasa. Aturan ini adalah hal penting, terutama untuk konsumen. Dengan adanya standarisasi, konsumen tidak dipaksakan untuk mengikuti aturan baru yang dibuat oleh suatu perusahaan tertentu. Hal ini akan menjaga keharmonisan kegiatan bisnis yang ada.

Berdasarkan analogi di atas, layanan dapat diartikan sebagai suatu unit solusi mandiri yang tidak seutuhnya terisolasi serta mengikuti suatu aturan atau standarisasi tertentu. Secara teknis, solusi ini berupa logika program tertentu (Erl, 2005). Layanan dapat pula diartikan sebagai sekumpulan kemampuan. Contohnya layanan pemesanan barang yang menawarkan kemampuan untuk membuat pesanan, memeriksa status pesanan, mengganti pesanan, serta membatalkan pesanan (Erl, 2008).

Mabrouk (2008) mengutip definisi layanan dari “Web Services and Service-Oriented Architecture: The Savvy Manager’s Guide” sebagai fungsi-fungsi yang telah terdefinisi, bersifat independen, serta tidak bergantung pada keadaan layanan yang lainnya. Kemudian definisi lain dikutip dari “SearchSystemChannel.com” sebagai satu unit pekerjaan yang dilakukan oleh entitas komputasi tertentu, seperti manusia ataupun program komputer.

(4)

Setiap perangkat lunak yang memanggil dan berinteraksi dengan layanan dikatakan pemakan layanan (service consumer). Sebagai contoh ada aplikasi yang berinteraksi dengan layanan, maka aplikasi tersebut dikatakan service consumer. Ada juga layanan yang memanggil dan berinteraksi dengan layanan lain. Dalam hal ini, layanan tersebut juga berperan sebagai service consumer.

Gambar 2.2 Beberapa bentuk service consumer (Erl, 2009)

Istilah lain yang juga sering digunakan untuk service consumer adalah service requester. Kemudian istilah yang digunakan untuk unit yang memberikan layanan adalah service provider. Istilah ini dikeluarkan oleh World Wide Web Consortium (W3C).

Sejumlah layanan yang terpisah dan dikumpulkan menjadi satu (agregasi) untuk mengotomatisasi tugas ataupun proses bisnis tertentu disebut service composition. Pada service composition, setidaknya harus ada minimal dua buah layanan dan sebuah

(5)

penggerak yang memulai komposisi (initiator). Jika tidak, interaksi hanya merupakan pertukaran data biasa antara satu layanan ke layanan lain.

Gambar 2.3 Komposisi layanan (Erl, 2009)

Berorientasi layanan dapat diartikan sebagai suatu cara berpikir yang terdiri dari seperangkat prinsip tertentu. Penerapan prinsip ini dalam mendesain solusi akan menghasilkan solusi yang berorientasi layanan. Unit paling mendasar pada solusi berorientasi layanan adalah layanan (service) (Erl, 2009).

Erl (2005) mendefinisikan SOA sebagai bentuk arsitektur teknologi yang menganut prinsip-prinsip berorientasi layanan. Ketika diwujudkan dalam teknologi web service, SOA memberikan potensi untuk mendukung prinsip-prinsip ini di seluruh proses bisnis dan domain otomatisasi perusahaan. Idealnya, SOA distandarisasi di seluruh perusahaan, namun untuk mencapai target ini dibutuhkan transisi yang direncanakan dengan matang serta dapat mendukung teknologi ataupun sistem yang saat ini masih ada dan digunakan (legacy system).

(6)

SOA membangun model arsitektur yang fokus pada peningkatan efisiensi, kelincahan, serta produktivitas perusahaan dengan menempatkan layanan sebagai hal utama. Sebagai bentuk arsitektur teknologi, implementasi SOA dapat berupa kombinasi berbagai teknologi, produk, application programming interface (API), tambahan infrastruktur pendukung, serta bagian lain (Erl, 2009).

2.3 Prinsip Berorientasi Layanan

Erl (2005) memaparkan beberapa prinsip umum pada berorientasi layanan sebagai berikut:

1. Service reusability. Layanan dapat digunakan ulang, sehingga layanan harus didesain agar dapat mendukung penggunaan kembali.

2. Service contract. Agar service dapat berinteraksi, mereka harus memberikan kontrak yang berisi bentuk layanan dan informasi yang dipertukarkan.

3. Service loose coupling. Layanan tidak terhubung erat. Maksudnya layanan didesain agar dapat bekerja tanpa bergantung pada layanan tertentu.

4. Service abstraction. Layanan membungkus logika. Bagian yang tampak dari luar hanyalah kontrak layanan. Logika serta implementasi di balik itu tidak kelihatan dan tidak penting bagi peminta layanan.

5. Service composability. Beberapa layanan dapat disusun untuk membentuk layanan baru.

6. Service autonomy. Layanan bersifat mandiri. Pengembangan layanan dapat dilakukan terpisah. Layanan memiliki kendali penuh terhadap logika yang dimilikinya.

7. Service statelessness. Layanan tidak didesain untuk menyimpan informasi keadaan tertentu (state).

8. Service discoverability. Layanan harus dapat ditemukan. Deskripsi layanan harus dapat dicari dan dimengerti oleh peminta layanan.

Hubungan prinsip berorientasi layanan dan berorientasi objek diuraikan dalam Tabel 2.1 dan Tabel 2.2.

(7)

Tabel 2.1.a Hubungan berorientasi layanan dengan berorientasi objek Berorientasi layanan Berorientasi objek

Service reusability Prinsip modularitas dengan pembuatan class pada dasarnya adalah bagaimana membuat sesuatu yang dapat digunakan ulang. Prinsip lain seperti abstraksi dan enkapsulasi juga mendukung penggunaan ulang dengan membuat pemisahan yang jelas antara interface dan implementasi.

Service contract Penggunaan interface dalam pengembangan aplikasi berorientasi objek menunjukkan hal yang serupa dengan prinsip service contract dalam orientasi layanan. Interface menunjukkan deskripsi abstrak sebuah class, yang sama halnya dengan WSDL pada sebuah web service.

Service loose coupling Pembuatan interface dapat menghilangkan ketergantungan sebuah class. Interface hanya memberikan informasi struktur sebuah class. Implementasinya harus dilakukan secara terpisah di luar interface, yakni pada class yang mengimplementasi interface tersebut. Service abstraction Prinsip abstraksi pada orientasi objek meminta class menyediakan

interface ke lingkungan luar sehingga class ini dapat diakses dengan interface yang disediakan. Enkapsulasi mendukung hal ini dengan melakukan pembungkusan detail class, di mana logika yang ada dalam class tidak ditampilkan ke luar.

Service composability Orientasi objek mendukung konsep asosiasi, seperti agregasi (aggregation) dan komposisi (composition). Hal yang sama juga didukung oleh orientasi layanan.

Service autonomy Orientasi layanan memungkinkan berbagai unit pemrosesan logika bekerja secara mandiri, tidak tergantung dengan unit-unit lain. Service statelessness Objek terdiri dari sekumpulan class dan data yang secara alami

bersifat stateful (menyimpan informasi keadaan). Menerapkan stateful pada pembuatan layanan juga memungkinkan, namun prinsip steteless lebih ditekankan pada orientasi layanan. Menerapkan sifat stateless (tidak menyimpan informasi keadaan) merupakan penyimpangan dari hal ini.

(8)

Tabel 2.1.b Hubungan berorientasi layanan dengan berorientasi objek (lanjutan) Berorientasi layanan Berorientasi objek

Service discoverability Membuat interface class yang konsisten merupakan langkah yang dapat mengidentifikasi dan membedakan berbagai unit pemrosesan logika. Hal ini juga mendukung penggunaan ulang karena class menjadi lebih mudah ditemukan.

2.4 Implementasi Layanan

Erl (2009) memaparkan beberapa teknologi yang dapat digunakan dalam implementasi layanan. Pada umumnya semua teknologi yang dapat digunakan untuk mengembangkan sistem terdistribusi dapat digunakan untuk mengembangkan layanan. Saat ini, layanan dapat diimplementasikan sebagai:

1. Komponen 2. Web service 3. REST service

Komponen adalah perangkat lunak yang didesain sebagai bagian dari sistem terdistribusi. Kemampuannya dipublikasi sebagai method, sehingga dapat dipanggil oleh aplikasi maupun perangkat lunak lain. Komponen biasanya terikat pada platform tertentu (platform-specific), contohnya adalah komponen yang dikembangkan dengan teknologi .NET ataupun Java.

Gambar 2.4 Notasi komponen dan service sebagai komponen (Erl, 2009)

(9)

Web service adalah bentuk implementasi layanan yang menyediakan kontrak terpisah yang terdiri dari Web Service Description Language (WSDL) dan satu atau lebih definisi skema XML serta mungkin juga ekspresi WS-Policy. Web service mempublikasi kemampuannya dalam bentuk operasi (operation), membentuk antarmuka teknis yang tidak tergantung framework maupul platform tertentu. Web service terdiri dari service contract, unit layanan dan unit pemrosesan pesan. Ilustrasi dari web service adalah sebagai berikut.

Gambar 2.5 Ilustrasi web service (Erl, 2009)

Representational State Transfer (REST) berarti membuat sistem terdistribusi berdasarkan resources. REST services (disebut juga RESTful services) adalah perangkat lunak yang didesain dengan penekanan pada kesederhanaan, skalabilitas, serta kegunaan.

2.5 Komponen Arsitektur Berorientasi Layanan

Erl (2005) memaparkan komponen SOA sebagai berikut:

1. Pesan (messages) yaitu data yang dibutuhkan untuk menyelesaikan suatu unit kerja.

2. Operasi (operations) yaitu logika yang dibutuhkan untuk menyelesaikan suatu unit kerja.

3. Layanan (services) yaitu sekumpulan operasi yang dapat melakukan tugas tertentu. 4. Proses (processes) yaitu aturan bisnis yang menentukan operasi layanan apa yang

(10)

Sebagai pengantar sebelum pembahasan tentang web service, berikut adalah bagian yang sama yang terdapat pada web service:

1. Pesan SOAP (SOAP messages)

2. Operasi layanan web (web service operations) 3. Layanan web (web services)

4. Aktivitas (activity)

Setiap layanan terdiri dari satu atau lebih operasi. Setiap operasi mengatur pengolahan fungsi tertentu yang dapat ditangani oleh layanan. Pengolahan ini terdiri dari pengiriman dan penerimaan pesan. Dengan menyusun bagian-bagian ini, layanan membentuk suatu aktivitas atau proses yang dapat mengotomatisasi suatu tugas tertentu.

Gambar 2.6 Service dan Operations (Erl, 2005)

Gambar 2.7 Operation dan Messages (Erl, 2005)

(11)

Gambar 2.8 Activity (Erl, 2005)

Komponen SOA saling terhubung seperti pada gambar di bawah ini. Operasi mengirim dan menerima pesan untuk melakukan kerja. Layanan mengelompokkan sekumpulan operasi yang sejenis. Proses dapat menyusun layanan. Proses memanggil beberapa operasi untuk menyelesaikan suatu pekerjaan.

Gambar 2.9 Hubungan komponen SOA (Erl, 2005)

2.6 Layanan Web (Web Service)

Web service adalah sebuah antarmuka (interface) yang menggambarkan sekumpulan operasi-operasi yang dapat diakses melalui jaringan, misalnya internet, dalam bentuk pesan XML (Kreger dalam Priyambodo, 2005). Web service merupakan sepotong atau sebagian informasi atau proses yang dapat diakses oleh siapa saja, kapan saja dengan

(12)

menggunakan piranti apa saja, tidak terikat dengan sistem operasi atau bahasa pemrograman yang digunakan (Manes dalam Priyambodo, 2005).

Web service dapat dibangun dengan menggunakan bahasa pemrograman apa saja dan juga dapat diimplementasikan pada platform manapun. Hal ini dimungkinkan karena web service berkomunikasi menggunakan sebuah standar format data yang universal yaitu XML dan menggunakan protokol SOAP (Hamids dalam Priyambodo, 2005).

2.7 Web Service Description Language (WSDL)

Mabrouk (2008) memaparkan bahwa WSDL merupakan dokumen yang ditulis menggunakan XML untuk menggambarkan web service. WSDL menunjukkan lokasi dan operasi apa yang diberikan oleh layanan sehingga dapat digunakan oleh peminta layanan (service consumer). Suatu WSDL menggambarkan empat hal berikut:

1. Layanan yang disediakan oleh web service, seperti daftar operasi yang dapat digunakan serta atribut pesan.

2. Tipe data pesan, baik pesan masukan (input) maupun pesan keluaran (output). 3. Informasi binding untuk protokol transportasi, seperti HTTP dan JMS.

4. Alamat layanan yang digunakan untuk memanggilnya.

WSDL merupakan sebuah bahasa berbasis XML yang digunakan untuk mendefinisikan web service dan menggambarkan cara untuk mengakses web service tersebut (Shohoud dalam Priyambodo, 2005). Deskripsi WSDL mendefinisikan sebuah service sebagai kumpulan dari port, di mana tiap-tiap port didefinisikan secara abstrak sebagai portType yang mendukung sekumpulan operasi. Tiap-tiap operasi memproses sekumpulan pesan tertentu (Priyambodo, 2005). Berdasarkan tulisan yang berjudul “Introduction to WSDL”, WSDL telah menjadi rekomendasi W3C sejak 26 Juni 2007.

Erl (2005) menjelaskan bahwa WSDL menggambarkan titik hubungan sebuah penyedia layanan (service provider), yang juga dikenal dengan sebutan service endpoint atau endpoint saja. WSDL menyediakan definisi formal dari antarmuka

(13)

endpoint, sehingga apapun yang akan berkomunikasi dengan layanan mengetahui dengan tepat bagaimana ia harus menyusun pesannya. WSDL juga memberikan lokasi fisik (alamat) sebuah layanan. Suatu WSDL dapat dibagi kedalam dua kategori yaitu deskripsi abstrak dan deskripsi konkit, seperti diperlihatkan pada gambar berikut.

Gambar 2.10 Deskripsi abstrak dan deskripsi konkrit pada WSDL (Erl, 2005)

Deskripsi abstrak memberikan informasi tentang antarmuka web service tanpa tergantung teknologi apapun yang digunakan. Dengan memisahkan informasi ini, integritas deskripsi layanan (service description) dapat dijaga terhadap semua perubahan yang mungkin terjadi pada platform di mana layanan dijalankan. Ada tiga bagian utama dalam deskripsi abstrak, yaitu portType, operation dan message. Bagian portType menjelaskan pesan (message) apa saja yang dapat diproses oleh layanan ke dalam sekumpulan fungsi yang disebut sebagai operasi (operation). Setiap operasi menunjukkan aksi tertentu yang dilakukan oleh layanan. Operasi terdiri dari sekumpulan pesan masukan (input message) dan pesan keluaran (output message). Pada WSDL versi 2.0, portType berganti nama menjadi interface.

(14)

Agar suatu web service dapat menjalankan prosesnya, definisi antarmuka abstrak perlu dihubungkan dengan suatu implementasi teknologi yang nyata, yakni protokol transportasi. Hubungan ini didefinisikan dalam deskripsi konrit suatu WSDL, yang terdiri dari binding, port dan service. Binding menggambarkan teknologi transportasi yang akan digunakan layanan untuk berkomunikasi. SOAP adalah bentuk yang paling umum, namun teknologi lain juga dapat digunakan. Binding dapat diterapkan pada keseluruhan antarmuka atau pada operasi tertentu. Port menggambarkan lokasi fisik di mana layanan dapat diakses dengan protokol tertentu. Service digunakan untuk menunjukkan sekumpulan endpoint yang saling berhubungan. Pada WSDL versi 2.0, port berganti nama menjadi endpoint.

Gambar 2.11 Elemen pada dokumen WSDL (Erl, 2005)

Pada suatu dokumen WSDL, elemen paling luar adalah <definitions>. Dalam elemen tersebut terdapat lima element utama yaitu:

(15)

2. Elemen <message> untuk mendefinisikan format pesan, baik itu pesan masukan (input) atau pesan keluaran (output) suatu operasi.

3. Elemen <portType> untuk mendefinisikan sekumpulan operasi (operation). Tiap-tiap elemen <operation> mendefinisikan sebuah operasi serta pesan masukan yang dibutuhkan dan pesan keluaran yang diberikan oleh operasi tersebut.

4. Elemen <binding> untuk memetakan operasi-operasi dan pesan yang telah didefinisikan pada portType ke suatu protokol tertentu.

5. Elemen <service> untuk mendefinisikan sekumpulan port yang saling berhubungan. Elemen <port> memetakan binding ke lokasi sebuah web service.

2.8 Simple Object Access Protocol (SOAP)

Mabrouk (2008) menerangkan bahwa SOAP merupakan protokol yang berbasiskan XML. Protokol ini memberikan kemudahan kepada aplikasi untuk bertukar informasi menggunakan protokol transportasi seperti HTTP. Beberapa keuntungan yang membuat SOAP sangat direkomendasikan dan telah menjadi protokol komunikasi yang paling banyak digunakan untuk web service adalah sebagai berikut:

1. SOAP tidak tergantung pada platform manapun (platform independent). 2. SOAP dapat digunakan dalam jaringan internet.

3. Pesan SOAP dapat dibaca manusia, terstruktur, serta berbasis teks karena berupa XML

SOAP merupakan protokol yang digunakan untuk mempertukarkan data atau informasi dalam format XML (Scheinbum dalam Priyambodo, 2005). SOAP dapat dikatakan sebagai gabungan antara HTTP dengan XML karena SOAP umumnya menggunakan protokol HTTP sebagai sarana transportasi datanya dan data yang akan dipertukarkan ditulis dengan format XML. Karena SOAP menggunakan HTTP dan XML, maka SOAP memungkinkan pihak-pihak yang berbeda dapat saling mempertukarkan datanya (Priyambodo, 2005).

Erl (2005) menjelaskan bahwa tujuan utama SOAP adalah untuk memberi definisi format pesan yang standar. Struktur pesan ini cukup sederhana, tetapi dapat diperluas

(16)

dan disesuaikan dengan kebutuhan. Setiap pesan SOAP dipaket ke dalam suatu wadah yang disebut envelope.

Gambar 2.12 Struktur dasar pesan SOAP (Erl, 2005)

Header berisi header block. Header block melengkapi pesan dengan beragam informasi yang mungkin dibutuhkan oleh web service. Penggunaan header block memberikan kemungkinan pesan dapat menampung informasi tambahan yang banyak dan bervariasi. Beberapa contoh fitur yang dapat ditambahkan dengan penggunaan header block yaitu:

1. Instruksi pemrosesan yang akan dieksekusi oleh entitas terentu 2. Informasi routing

3. Mekanisme keamanan (security) 4. Pemrosesan transaksi (transaction)

Isi pesan yang sesungguhnya ditampung dalam body, yang biasanya berupa data dalam format XML. Isi body ini sering disebut sebagai message payload. Bagian body ini juga dapat berisi elemen fault, yang digunakan untuk menyampaikan informasi ketika terjadi suatu kesalahan (exception).

(17)

Pada suatu pesan SOAP, elemen paling luar adalah <Envelope>. Dalam elemen tersebut terdapat elemen opsional <Header> dan elemen wajib <Body>.

Gambar 2.13 Elemen pada pesan SOAP (Erl, 2005)

Ada dua atribut penting yang menentukan bentuk pesan SOAP serta tipe data yang digunakan untuk merepresentasikan data, yaitu atribut style yang digunakan oleh elemen soap:binding serta atribut use yang ada di elemen soap:body. Kedua elemen ini berada pada elemen soap:binding suatu dokumen WSDL.

(18)

Atribut style pada elemen soap:binding dapat bernilai document atau rpc. Document mendukung keseluruhan dokumen XML dimasukkan ke dalam body SOAP, sementara rpc lebih mencerminkan komunikasi RPC tradisional yang mendukung tipe data parameter. Atribut use pada elemen soap:body dapat bernilai literal atau encoded. SOAP memiliki tipe datanya sendiri untuk merepresentasikan isi body. Kemudian, dikeluarkan dukungan untuk tipe data XSD. Atribut ini menunjukkan tipe data mana yang akan digunakan. Penggunaan literal menunjukkan bahwa tipe data XSD akan digunakan. Kombinasi style dan use yang mungkin adalah sebagai berikut: 1. Style RPC dan use encoded (disingkat rpc/encoded)

2. Style RPC dan use literal (disingkat rpc/literal)

3. Style document dan use encoded (disingkat document/encoded) 4. Style document dan use literal (disingkat document/literal)

Butek (2005) memaparkan perbedaan kombinasi style dan use tersebut. Pembahasan ini akan menggunakan contoh method berikut:

public void myMethod(int x, float y);

Pada rpc/encoded, akan dihasilkan WSDL dengan elemen message dan portType lebih kurang sebagai berikut:

Contoh pesan SOAP untuk memanggil operasi myMethod dengan nilai x = 5 dan nilai y = 5.0 adalah sebagai berikut.

<soap:envelope> <body>

(19)

</body> </soap:envelope>

Tabel 2.3 Kelebihan dan kekurangan rpc/encoded

Kelebihan Kekurangan

1. WSDL cukup sederhana.

2. Nama operasi muncul di pesan SOAP, sehingga penerima mudah untuk mengetahui pesan ini untuk operasi yang mana.

1. Informasi encoding (seperti xsi:type= "xsd:int") terkadang tidak diperlukan dan hanya menambah ukuran pesan. 2. Pesan tidak dapat divalidasi

menggunakan skema XML.

3. Tidak sesuai aturan web services interoperability (WS-I).

Pada rpc/literal, WSDL yang dihasilkan tetap sama seperti pada WSDL dengan rpc/encoded. Perbedaannya terletak pada pesan SOAP untuk memanggil operasinya: <soap:envelope> <body> <myMethod> <x>5</x> <y>5.0</y> </myMethod> </body> </soap:envelope>

Tabel 2.4 Kelebihan dan kekurangan rpc/literal

1. WSDL tetap sederhana.

2. Nama operasi muncul di pesan SOAP, sehingga penerima mudah untuk mengetahui pesan ini untuk operasi yang mana.

3. Informasi encoding sudah tidak dimasukkan.

4. Sesuai aturan WS-I.

1. Pesan tidak dapat divalidasi menggunakan skema XML.

Bentuk document/encoded tidak pernah digunakan dan tidak sesuai aturan WS-I. Pada document/literal, WSDL yang dihasilkan mengalami perubahan:

(20)

</types>

Contoh pesan SOAP untuk bentuk WSDL ini adalah sebagai berikut:

<soap:envelope> <soap:body> <xElement>5</xElement> <yElement>5.0</yElement> </soap:body> </soap:envelope>

Tabel 2.5 Kelebihan dan kekurangan document/literal

1. Tidak ada informasi encoding.

2. Pesan dapat divalidasi menggunakan skema XML.

1. WSDL menjadi lebih rumit.

2. Nama operasi tidak muncul di pesan SOAP, sehingga lebih menyulitkan bagi penerima pesan.

3. WS-I hanya mengizinkan satu node anak di bawah node soap:body.

Selain keempat bentuk di atas, ada bentuk tambahan yang disebut document/literal

wrapped. WSDL yang dihasilkan mengalami perubahan menjadi sebagai berikut: <types>

</complexType> </element>

(21)

</schema> </types>

Contoh pesan SOAP untuk bentuk WSDL ini adalah sebagai berikut:

<soap:envelope> <soap:body> <myMethod> <x>5</x> <y>5.0</y> </myMethod> </soap:body> </soap:envelope>

Sekilas bentuk pesan ini sama dengan bentuk pesan pada rpc/literal. Namun

<myMethod> anak dari <soap:body> sebenarnya berbeda. Pada document/literal

wrapped, ini adalah nama elemen pembungkus yang ditunjuk oleh pesan. Sementara pada rpc/literal, ini adalah nama operasi.

Tabel 2.6 Kelebihan dan kekurangan document/literal wrapped

1. Tidak ada informasi encoding.

2. Pesan dapat divalidasi menggunakan skema XML.

3. Nama operasi muncul di pesan SOAP. 4. Mengikuti aturan WS-I di mana

soap:body hanya memiliki satu anak.

1. WSDL menjadi semakin lebih rumit.

Bentuk document/literal wrapped berasal dari Microsoft dan tidak ada spesifikasi yang menjelaskan bentuk ini. Pembahasan di atas menunjukkan bahwa bentuk yang

(22)

paling baik adalah document/literal wrapped. Namun ada saat tertentu di mana bentuk tersebut tidak dapat digunakan. Misalnya ketika ada method yang di-overload berikut:

public void myMethod(int x, float y); public void myMethod(int x);

Ketika menggunakan bentuk document/literal wrapped, perlu elemen yang memiliki nama yang sama dengan nama operasi, dan hal ini tidak dapat dilakukan dalam XML. Solusi untuk hal ini dapat menggunakan bentuk document/literal.

Penggunaan document/literal tidak memungkinkan ketika ada method dengan jumlah dan tipe parameter yang sama, misalnya ada method berikut:

public void myMethod(int x, float y); public void myMethod(int x);

public void yourMethod(int x, float y);

Pada document/literal tidak ada nama operasi, sehingga tidak mungkin mengetahui pesan yang terdiri dari sebuah integer dan sebuah float adalah milik myMethod atau yourMethod. Solusi untuk hal ini dapat menggunakan bentuk rpc/literal.