Web Service Security dengan OWSM

Kerahasian suatu informasi harus kita jaga. Untuk itu perlu adanya security. Dengan adanya security, hanya orang-orang yang berhak yang bisa mengakses resource (dalam hal ini web service) yang kita miliki. Untuk web service, security yang di sediakan oleh Oracle adalah OWSM.

Apa itu OWSM ?

OWSM adalah Oracle Web Service Manager. OWSM merupakan solusi yang di tawarkan Oracle untuk kebijakan manajemen dan keamanan di dalam infrastruktur. Cara pemakaiannya sangat mudah, karena di kontrol dengan User Interface yang apik di aplikasi Oracle Enterprise Manager (Oracle EM).

OWSM menggunakan username dan password yang ada di Oracle Weblogic sebagai otentikasinya. Semua user diatur oleh Security Realm di Oracle Weblogic Console.

Bagaimana cara menggunakannya ?

Ada prasyarat yang harus dipenuhi, yaitu :

• Web Service yang telah di deploy di Weblogic. Dalam hal ini saya menggunakan contoh ini.
• User selain weblogic di Security Realm. Tidak dianjurkan menggunakan user weblogic, karena user weblogic memiliki otoritas yang luas.

Setelah prasyarat dipenuhi, langkah-langkah menggunakan OWSM di Web Service kita adalah :

• Login ke EM (http://hostname:port/em) dengan username weblogic.
• Pilih Web Service yang akan di pasang OWSM. Dalam hal ini HelloWorld Web Service.
• Klik Policies

• Klik Attach To/Deatach Form 

• Pilih nama servicenya. Dalam hal ini hi_client_ep.
• Pilih oracle/wss_username_token_service_policy

• Klik OK untuk simpan.
• Selesai

Bagaimana cara testingnya ?

Ada 2 cara, yaitu :

1. Test melalui Enterprise Manager
2. Test melalui SOAP-UI

Menggunakan EM

Cara testing dengan EM sangatlah mudah, yaitu :

• Login ke EM (http://hostname:port/em) dengan username weblogic.
• Pilih Web Service yang akan kita test. Dalam hal ini HelloWorld Web Service.
• Expand bagian Security.

• Pilih OWSM Security Policies.
• Masukkan username dan password yang ada di Security Realm.
• Isi parameter input-nya.
• Tunggu nilai baliknya dan selesai.

Menggunakan SOAP-UI

Untuk penggunaan SOAP-UI sedikit lebih rumit, karena ada username dan password yang harus kita atur terlebih dahulu. Berikut langkah-langkahnya :

• Buka aplikasi SOAP-UI
• Bikin project dengan WSDL dari HelloWorld Web Service.
• Klik dua kali pada bagian project properties.

• Pilih WS-Security Configurations.
• Pilih Outgoing WS-Security Configurations.

• Pilih Add a New Outgoing WS-Security Configurations.
• Masukkan yang unik untuk configuration. Dalam hal ini HelloWorld.
• Pilih Add a New WSS Entry pada bagian bawah.
• Pilih username.
• Isikan username dan password.
• Pilih PasswordTest pada bagian Password Type.

• Klik dua kali pada bagian HiBinding.
• Pilih Service Endpoints.
• Pada bagian Outgoing WS pilih HelloWorld.

• Klik dua kali pada bagian request.
• Isikan parameter input-nya.
• Tunggu nilai baliknya dan selesai.

Apa yang terjadi jika kita mengisikan username dan password ?

Akan terjadi error seperti berikut :

WebLogic Whole Server Migration

Oracle WebLogic Server memiliki fitur yang bernama whole server migration. Migration di sini mengacu kepada proses memindahkan WebLogic instance yang tergabung dalam sebuah WebLogic cluster dari mesin yang satu ke mesin lainnya. Tujuan dari fitur ini adalah untuk menjamin deployment yang memiliki transaksi JMS dan JTA, seperti pada keluarga Oracle SOA Suite, dapat dilanjutkan ketika salah satu node mengalami kegagalan.

Node Manager dibutuhkan untuk dapat menjalankan fitur ini, di mana tugasnya adalah:

1. Inisialisasi konfigurasi server migration. Proses migrasi akan gagal jika WebLogic instance dijalankan tanpa melalui Node Manager.
2. Mengontrol siklus hidup WebLogic instance (start, stop, suspend, dsb.)
3. Mengaktifkan dan menonaktifkan virtual IP (VIP) address dari WebLogic instance pada mesin yang menjadi tanggung jawabnya.
4. Mount dan unmount shared disk untuk managed server domain (MSERVER_HOME).

Pada kesempatan kali ini, saya akan membuat simulasi sederhana tentang fitur migrasi ini. Pada simulasi ini saya telah mengkonfigurasi sebuah domain yang berisi sebuah cluster BAM_Cluster dengan 2 buah instance WLS_BAM1 dan WLS_BAM2. Hanya ada 2 VIP pada konfigurasi ini, yaitu milik AdminServer dan WLS_BAM1, karena engine dari BAM bersifat singleton service. Sehingga hanya WLS_BAM1 saja yang dapat berpindah dari mesin BAMHOST1 ke mesin BAMHOST2. Node Manager sudah terkonfigurasi pada masing-masing mesin.

Langkah-langkahnya adalah sebagai berikut:

1. Membuat Tabel ACTIVE pada Database

Status dari WLS_BAM1 dan WLS_BAM2 tersimpan pada sebuah tabel database secara periodik akan di-update. Ketika sebuah instance tidak meng-update tabel tersebut, diasumsikan instance tersebut mengalami kegagalan dan jika instance tersebut termasuk ke dalam migratable server maka instance tersebut akan dipindahkan ke mesin yang lain. Jalankan SQL script pada $WL_HOME/server/db/oracle/920/leasing.ddl untuk membuat tabel ACTIVE.

2. Membuat Data Source untuk Tabel ACTIVE (Opsional) 

Langkah ini opsional jika tabel ACTIVE berada pada koneksi data source yang telah ada sebelumnya di WebLogic. Jika diletakkan pada skema database yang belum terdaftar, daftarkan terlebih dahulu ke data source yang baru.

3. Konfigurasi Hak Akses oracle dan Environment Variable

Seperti yang telah disebutkan sebelumnya, Node Manager berperan dalam mengaktifkan dan menonaktifkan VIP pada sebuah mesin. Agar dapat melakukan hal tersebut, Node Manager membutuhkan akses sudo tanpa password untuk menjalankan perintah /sbin/ifconfig dan /sbin/arping. Tambahkan 2 baris berikut pada file /etc/sudoers dengan menggunakan perintah visudo.

Defaults:oracle !requiretty
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping

Update variabel PATH, sebaiknya diletakkan di file ~/.bashrc:

PATH=$MSERVER_HOME/bin/server_migration:$PATH
PATH=$WL_HOME/common/bin:$PATH
PATH=$WL_HOME/common/nodemanager:$PATH
export PATH

4. Menambahkan Konfigurasi Node Manager

Tambahkan 3 baris berikut pada file konfigurasi nodemanager.properties:

Interface=bond1
NetMask=255.255.255.0
UseMACBroadcast=true

Interface yang dimaksud di atas adalah network interface yang digunakan untuk VIP dari WLS_BAM1. Jika VIP yang digunakan adalah eth0:1, maka masukkan eth0 pada konfigurasi. Restart Node Manager di kedua mesin setelah melakukan update tersebut.

5. Konfigurasi Server Migration

Whole server migration dapat dilakukan pada sebuah cluster, sehingga untuk mengaktifkannya buka konfigurasi BAM_Cluster kemudian pilih Configuration -> Migration. Pada bagian "Candidate Machines for Migratable Servers", pilih BAMHOST1 dan BAMHOST2. Pilih Database pada bagian Migration Basis dan arahkan Data Source for Automatic Migration ke data source yang telah ada atau telah dibuat pada langkah ke-2. Save.

Navigasi ke informasi instance WLS_BAM1, kemudian pilih Configuration -> Migration. Check Automatic Server Migration Enabled, kemudian pilih hanya BAMHOST2 pada Candidate Machines, karena kita hanya akan mengaktifkan WLS_BAM1 untuk dimigrasikan ke BAMHOST2. Pilih Save, Activate Changes. 

6. Validasi dan Simulasi

Start WLS_BAM1 dan WLS_BAM2 melalui WebLogic Administration Console, kemudian amati output dari nodemanager.log dari kedua mesin. Simulasikan shutdown pada WLS_BAM1 dengan cara meng-kill proses tersebut dengan perintah kill -9 <PID>. Lakukan perintah kill sebanyak 2 kali untuk memicu proses server migration. Berikut adalah potongan log pada BAMHOST1:

<Sep 11, 2013 9:21:10 AM> <INFO> <Successfully removed 10.11.12.13 from bond1:1.><Sep 11, 2013 9:21:10 AM> <INFO> <Successfully removed 10.0.56.66 from bond1:1.>
<Sep 11, 2013 9:21:10 AM> <INFO> <BAM_Domain> <WLS_BAM1> <Server failed so attempting to restart (restart count = 1)>
<Sep 11, 2013 9:21:10 AM> <INFO> <BAM_Domain> <WLS_BAM1> <Sleeping for 30 seconds before attempting to restart server>
<Sep 11, 2013 9:21:40 AM> <INFO> <BAM_Domain> <WLS_BAM1> <Starting WebLogic server with command line: /u02/app/oracle/admin/BAM_Domain/mserver/BAM_Domain/bin/startWebLogic.sh >
<Sep 11, 2013 9:21:40 AM> <INFO> <BAM_Domain> <WLS_BAM1> <Working directory is '/u02/app/oracle/admin/BAM_Domain/mserver/BAM_Domain'>
<Sep 11, 2013 9:21:40 AM> <INFO> <BAM_Domain> <WLS_BAM1> <Rotated server output log to "/u02/app/oracle/admin/BAM_Domain/mserver/BAM_Domain/servers/WLS_BAM1/logs/WLS_BAM1.out00015">
<Sep 11, 2013 9:21:40 AM> <INFO> <BAM_Domain> <WLS_BAM1> <Server error log also redirected to server log>
<Sep 11, 2013 9:21:40 AM> <INFO> <BAM_Domain> <WLS_BAM1> <Server output log file is '/u02/app/oracle/admin/BAM_Domain/mserver/BAM_Domain/servers/WLS_BAM1/logs/WLS_BAM1.out'>
<Sep 11, 2013 9:21:44 AM> <INFO> <Successfully brought 10.11.12.13 with netmask 255.255.255.0 online on bond1:1>
<Sep 11, 2013 9:21:56 AM> <INFO> <Successfully removed 10.11.12.13 from bond1:1.>
<Sep 11, 2013 9:21:56 AM> <INFO> <BAM_Domain> <WLS_BAM1> <Server failed during startup so will not be restarted>

Sedangkan pada BAMHOST2 log-nya adalah seperti ini:

<Sep 11, 2013 9:22:15 AM> <INFO> <BAM_Domain> <WLS_BAM1> <Boot identity properties saved to "/u02/app/oracle/admin/BAM_Domain/mserver/BAM_Domain/servers/WLS_BAM1/data/nodemanager/boot.properties">
<Sep 11, 2013 9:22:15 AM> <INFO> <BAM_Domain> <WLS_BAM1> <Startup configuration properties saved to "/u02/app/oracle/admin/BAM_Domain/mserver/BAM_Domain/servers/WLS_BAM1/data/nodemanager/startup.properties">
<Sep 11, 2013 9:22:15 AM> <INFO> <BAM_Domain> <WLS_BAM1> <Rotated server output log to "/u02/app/oracle/admin/BAM_Domain/mserver/BAM_Domain/servers/WLS_BAM1/logs/WLS_BAM1.out00002">
<Sep 11, 2013 9:22:15 AM> <INFO> <BAM_Domain> <WLS_BAM1> <Server error log also redirected to server log>
<Sep 11, 2013 9:22:15 AM> <INFO> <BAM_Domain> <WLS_BAM1> <Starting WebLogic server with command line: /u02/app/oracle/admin/BAM_Domain/mserver/BAM_Domain/bin/startWebLogic.sh >
<Sep 11, 2013 9:22:15 AM> <INFO> <BAM_Domain> <WLS_BAM1> <Working directory is '/u02/app/oracle/admin/BAM_Domain/mserver/BAM_Domain'>
<Sep 11, 2013 9:22:15 AM> <INFO> <BAM_Domain> <WLS_BAM1> <Rotated server output log to "/u02/app/oracle/admin/BAM_Domain/mserver/BAM_Domain/servers/WLS_BAM1/logs/WLS_BAM1.out00003">
<Sep 11, 2013 9:22:15 AM> <INFO> <BAM_Domain> <WLS_BAM1> <Server error log also redirected to server log>
<Sep 11, 2013 9:22:15 AM> <INFO> <BAM_Domain> <WLS_BAM1> <Server output log file is '/u02/app/oracle/admin/BAM_Domain/mserver/BAM_Domain/servers/WLS_BAM1/logs/WLS_BAM1.out'>
<Sep 11, 2013 9:22:19 AM> <INFO> <Successfully brought 10.11.12.13 with netmask 255.255.255.0 online on bond1:1>

Pada log tersebut terlihat Node Manager pada BAMHOST1 mencoba untuk me-restart instance WLS_BAM1 setelah 30 detik. Setelah proses di-kill untuk yang kedua kalinya, Node Manager tidak melakukan restart kembali. Node Manager pada BAMHOST2 menerima pesan bahwa WLS_BAM1 dalam kondisi yang gagal pada BAMHOST1 kemudian mencoba untuk mengaktifkan VIP WLS_BAM1 pada BAMHOST2 dan men-startup WLS_BAM1. Pada posisi akhir, instance WLS_BAM1 telah aktif pada BAMHOST2.

Selamat mencoba. :)

Menyimpan Attachment BPM ke dalam Webcenter Content

Post kali ini akan menjelaskan bagaimana cara menyimpan attachment yang ada di Oracle BPM ke dalam Webcenter Content. Secara default, BPM telah menyediakan fungsi attachment untuk workflownya. Akan tetapi, apabila kita menggunakan default attachment BPM, file yang telah kita upload sebelumnya tidak dapat digunakan kembali apabila kita menginisiasi proses baru.

Apabila pengguna aplikasi BPM kita membuat task baru, dia harus terus menerus meng-attach kembali dokumennya, meskipun sebelumnya dia telah pernah meng-attach dokumen tersebut. Menyebalkan bukan?

Selain itu, apabila kita sudah mempunyai Webcenter Content, akan sangat membantu apabila semua dokumen yang berjalan dalam workflow BPM juga tersimpan dalam Content. Hal ini akan memudahkan dalam Reuse dokumen, mempropagasi security content ke BPM dan juga gruping dokumen. 

Ikuti langkah-langkah berikut untuk mengintegrasikan BPM dan WebCenter Content anda:

1. Buka Enterprise Manager untuk domain SOA anda. Buka Domain -> SOA -> soa-infra. Klik kanan soa-infra -> SOA Administration -> pilih Workflow Config. 
   
2. Detil Workflow Config terbuka -> klik 'More Workflow Configuration Properties'. 
   
3. Buka Workflow Config -> Human Workflow dan parameter-parameter human workflow di BPM dapat di-specify disini 
   
4. Kita akan fokus pada parameter UcmIdcUrl yang merupakan parameter yang akan digunakan untuk 'menembak' alamat Content Server kita. 
   
5. Klik dan masukkan alamat content server kita idc://<hostame>:4444 
   
6. Next, kita set port content server kita untuk listen di port 4444. Buka Domain -> Webcenter -> Content -> Content Server -> Oracle Webcenter Content. Klik dan masukkan IP filter dan port (dalam konteks ini 4444). Restart Managed Server UCM_server anda. 
   
7. Berikutnya kita membuat credential mapping di domain SOA kita. Buka weblogic domain ->  bpm_domain (nama domain anda) -> klik kanan -> Security -> Credential. 
   
   
   
   
   
8. Create Map -> Masukkan WF-ADMIN-USER. Kemudian Create Key -> Masukkan WF-ADMIN-USER sebagai map, dan WF-ADMIN-CREDENTIAL sebagai key name, type = password, username = weblogic, password = password anda 
   
   
9. Create Workflow anda. Buat Human Task dan buka tab Documents. Pastikan checkbox yang ada di tab ini dicentang, hal ini untuk menandakan bahwa Human Task yang anda buat akan menyimpan dokumennya ke Webcenter Content yang telah dikonfigurasi di langkah nomor 5. Autogenerate form untuk human task ini.
   
    
   
10. Deploy project BPM anda dan buka BPM workspace. Klik Process yang anda buat di langkah nomor 9 dan klik tombol + di attachment.
    
    
11. Anda dapat melihat bahwa akan ada pilihan baru untuk 'Upload file to Webcenter Content' yang mana akan menyimpan attachment anda ke dalam Webcenter Content. Selain itu, kita dapat menggunakan pilihan "Associate Webcenter Content document" untuk menggunakan kembali dokumen yang sudah pernah kita upload sebelumnya di Webcenter Content. 
    
    
    
    
    
    
    That's all guys, semoga membantu!

Cara Setup Framework Spring di Netbeans

       Berikut merupakan cara yang mudah untuk mensetup framework spring di netbeans.tapi sebelumnya untuk mencobanya alangkah baiknya mendownload:

- http://www.oracle.com/technetwork/java/javase/downloads/index.html  {java}
- https://netbeans.org/downloads {Netbeans}

 terlebih dahulu.

1.Setelah mendownload java dan netbeans maka buatlah project java dengan meng-create java project di netbeans

2. Pilihlah category java application.

3.Berilah nama pada project yang anda buat. project ini kita beri nama cobaApplication.

4.Setelah membuat project cobaApplication maka struktur project akan terlihat seperti ini :

5.Kemudian kita akan meng-input library yang akan dibutuhkan. maka dari itu pilih menu project properties.

6.Setelah itu pilihlah pada tab library.

7.kemudian pilihlah library yang dibutuhkan. dalam hal ini pilihlah springframework 3.1.1 RELEASE.

8.Berikut setelah library dipilih.

9.Maka dalam project akan tampil seperti berikut.

10.Kemudian setelah library spring berhasil di-import maka kita harus membuat file xml konfigurasi untuk spring. file ini digunakan untuk meload bean komponen dimana nanti kita juga akan membuat bean komponen kita sendiri.

11. beri nama file xml kita dengan nama MySpring.xml, nama file bisa apa saja .
 
     

12. pilih next. kita akan membuat file xml well-formed.

13. Berikut isi dari file MySpring.xml tersebut.

14. Setelah kita membuat file spring xml konfigurasi kita,maka kita akan membuat bean class. nah class inilah yang nantinya akan diload sesuai dengan konfigurasi yang ada di MySpring.xml. berikut merupakan class tersebut.

15. Ketika class bean kita selesai dibuat maka kita kembali ke main class kita yaitu CobaApplication.java. file tersebut akan ter-create otomatis ketika kita membuat project pertama kali. pada class tersebut jangan lupa untuk meng-import package spring berikut.

16.Pada class CobaApplication.java tepatnya pada main methodnya kita akan coba mengeksekusi bean yang telah dibuat tadi dengan menggunakan framework spring. berikut source codenya.

17. Setelah itu cobalah untuk me-run program tersebut. jika berhasil maka akan tampak seperti berikut.

membandingkan SOAP dan REST webservice

SOAP Overview

Mengacu pada arsitektur RPC (remote procedural call) atau RMI (remote method invocation). Client mengakses sebuah method (umumnya dinyatakan melalui sebuah interface), yang merupakan representasi dari method (operasi) yang terdapat di server [1].

Arsitektur ini menyembunyikan mekanisme network messaging antara client dan server, maka logikanya, di suatu tempat di dalam arsitektur RPC, pasti terdapat proses 'binding' yang menunjukkan lokasi server dan method apa saja yang disupport oleh server tersebut.

Mengenai object yang dipertukarkan (melalui arguments atau result), terjadi peng-copy-an object antara client dan server [2]. Misalnya client menggunakan instance object A, dengan field f1, f2, f3 sebagai argument pada remote method, server pun harus memiliki instance sebuah object, kita sebut saja AA dengan field ff1, ff2, ff3 (yang masing2 adalah representasi dari f1, f2, f3 dari object A).

Untuk menangani pertukaran object tadi, dibutuhkan semacem 'parser' yang mengambil value2 dari object A, dikemas dalam suatu format tertentu (marshalling), dan dikirim ke server. Di sisi lain, server menerima message dalam format tertentu, yang harus di-parse value2nya ke dalam object AA (unmarshalling). Client mengenal object Stub sedangkan server menggunakan object Skeleton untuk kebutuhan tadi.

Secara umum urutan prosesnya: client <-> stub <-> network <-> skeleton <-> server.

Class-class yang melakukan proses-proses tersebut 'dibundle' sebagai sebuah proxy, dihandle oleh library. Yang langsung diakses oleh class client adalah interface yang memiliki remote method.

Sebagaimana sebuah operasi/method dalam object oriented programming, ada mekanisme exception handling. Secara otomatis, exception yang terjadi di sisi server akan di-throw melalui element fault pada soap message. Element ini akan berisi nama class dan deskripsi exception [3]. Dengan kata lain, informasi yang spesifik mengenai exception di server akan dibawa ke client.

Selain itu jika client menerapkan exception handling terkait aktivitas tersebut, perlu diperhatikan juga bagaimana jika client dan server menggunakan bahasa yang berbeda (misalnya clientnya php, sedangkan servernya java, atau sebaliknya).

Semua spesifikasi teknis mengenai implementasi soap, seperti object-object yang digunakan (dalam argument dan resultnya), method atau operasi yang disupport, alamat endpoint, didefinisikan dalam WSDL [4]. Baik server maupun client, menggunakan acuan WSDL yang sama dan untuk menyesuaikan, beberapa IDE telah menyediakan fitur untuk meng-generate classes-to-wsdl (bottom-top) atau wsdl-to-classes (top-bottom) sehingga development untuk implementasinya jauh lebih mudah.

Contoh soap message:  http://wiki.developerforce.com/page/Sample_SOAP_Messages_%2810.0_API%29.

REST Overview

Arsitektur ini mengacu pada network messaging melalui HTTP. Berbeda sudut pandang dengan SOAP, REST menggunakan sudut pandang representasi resource (data). Tiap resource dinyatakan dalam URI yang unique [5].

Saat client mengakses URI tertentu, bisa dibayangkan yang diakses oleh client itu adalah data. Aktivitas yang bisa dilakukan client terhadap data-data tersebut mengacu pada method yang dimiliki oleh protocol HTTP: GET (mengambil data), POST (input data), PUT (update data), DELETE (hapus data) [6].

Misalnya client mengirimkan HTTP method GET ke uri http://domain.com:8080/application/user/usercode, dan yang akan kita dapatkan sebagai response adalah detail informasi user yang codenya 'usercode'. Atau contoh lain, misalnya client mengirimkan HTTP method POST ke URI http://domain.com:8080/application/user untuk menginput user baru, dan response yang di dapat misalnya adalah informasi status input sukses/gagal, dll.

Berfokus pada representasi data memungkinkan kemudahan untuk melakukan streaming dalam berbagai bentuk tipe data (atau mime). Umumnya data yang dipertukarkan berupa json atau XML, bahkan plain text. Tidak menutup kemungkinan tipe mime lainnya, bergantung pada apa yang disupport oleh sang server.

Itu dari sisi clientnya.

Dari sisi servernya, untuk memungkinkan semua itu terjadi, server harus memliki method-method untuk menerima tiap HTTP method tadi, kemudian menerjemahkan URI yang diakses dan mesage yang dikirimkan untuk kemudian dipilah-pilah berdasarkan tiap informasi tadi fungsi/method/operasi apa yang harus dijalankan agar client mendapatkan result data yang diinginkan.

Dalam implementasinya, berbeda dengan SOAP yang parsingnya telah disediakan oleh library (baik client-side mau pun server-side) dan formatnya telah ditentukan dalam WSDL, arsitektur REST memberikan kesempatan kepada developer untuk membuat parsernya sendiri (baik client-side maupun server-side).

secara umum urutan prosesnya: client <-> parser <-> connector <-> network <-> connector <-> parser <-> server.

Karena tidak ada acuan teknis spesifik seperti WSDL, maka idealnya server harus menyediakan dokumen tambahan berupa spesifikasi format message (atau mime), alamat resource (URI), field-field yang dibutuhkan (saat request dan saat response), dan client harus menyesuaikan.

Mengenai exception, idealnya REST akan menggunakan HTTP response status [7] sebagai acuan (melalui status line [8]). Server melakukan mapping antara exception yang terjadi dengan HTTP response status. umumnya library REST menyediakan fasilitas untuk ini. Tapi tidak menutup kemungkinan untuk mengirimkan exception stacktrace atau status code melalui body message.

SOAP and REST Comparison

1. Message Format

SOAP menggunakan XML dengan content yang relatif besar jika dibandingkan dengan REST yang menggunakan XML. Pada REST, message yang dikirimkan hanya datanya saja, sedangkan SOAP mengirimkan hal-hal lain seperti yang termuat dalam envelopenya [11]. Jika kita bandingkan mengirimkan data yang sama, maka byte yang di-stream oleh SOAP pasti akan lebih besar dari REST.

Selain itu REST lebih fleksibel untuk mengubah format message, sebagai contoh misalnya ditemukan bahwa XML parsing membutuhkan effort lebih besar, maka message format bisa menggunakan json atau text plain.

2. Scalability

Pada SOAP, class Stub/Skeleton melakukan beberapa fungsi, seperti parsing dan open connection. keduanya dihandle oleh SOAP library. Kita tidak dapat mengukur effort masing-masing, misalnya berapa total size yang dibutuhkan hanya untuk parsing saja, atau untuk connectionnya saja.

REST lebih baik karena komponen-komponennya terpisah, seperti parser terpisah dengan open connection. Dengan arsitektur demikian, kita bisa mengukur effort (size atau duration) masing-masing komponen dengan spesifik, dan hal ini akan sangat memudahkan untuk melakukan tuning.

3. Conversation State (stateful/stateless)

Conversation dikatakan stateless jika server tidak menyimpan informasi tertentu mengenai request yang dilakukan oleh client, selain itu server tidak menyimpan session tertentu. Kasarnya, stateless conversation adalah 'cuma messaging saja'. Stateful adalah kondisi sebaliknya. Protocol HTTP secara 'alamiah' bersifat stateless, sehingga REST maupun SOAP dapat menerapkan stateless conversation.

Tambahan pada SOAP, selain stateless, dia juga men-support stateful conversation, misalnya melalui fitur WS-AtomicTransaction [9]. Untuk REST, hal demikian bisa dilakukan dengan tambahan coding server-side. Jika hal demikian dikatakan bukan REST, mari kita sebut saja dia bernama 'CustomizedREST' :D, yang pasti arsitektur demikian bisa dilakukan [10].

Mana yang lebih baik digunakan untuk kasus stateful? Menurut saya, disesuaikan dengan kebutuhan dan resource yang mengerjakan. SOAP bisa meminimalisir effort development (coding), tetapi kita tidak punya kontrol pada kinerja processingnya. REST lebih besar effort developmentnya, tetapi kontrol tetap milik developer.

4. Security

SOAP memiliki fitur security, bisa dilihat di http://msdn.microsoft.com/en-us/library/ms951273.aspx. Sedangkan REST bisa menggunakan SSL, tetapi berdasarkan sebuah diskusi di forum, SSL untuk REST bisa menimbulkan masalah saat load balancing [12]. Best practicenya adalah menggunakan TLS, dan otorisasi menggunakan OAuth [13], menurut referensi [13] itu pun tidak dianjurkan menggunakan SSL.

References

[1] http://web.cs.wpi.edu/~cs4514/b98/week8-rpc/week8-rpc.html

[2] http://oreilly.com/catalog/javarmi/chapter/ch10.html

[3] http://axis.apache.org/axis/java/user-guide.html#Exceptions

[4] http://docstore.mik.ua/orelly/xml/jxml/ch13_03.htm

[5] http://www.infoq.com/articles/rest-introduction

[6] http://www.ibm.com/developerworks/webservices/library/ws-restful/#N1007B

[7] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

[8] http://www.apl.jhu.edu/~hall/java/Servlet-Tutorial/Servlet-Tutorial-Response-Status-Line.html

[9] http://msdn.microsoft.com/en-us/library/ms996526.aspx#wsac_topic4

[10] http://www.findinglisp.com/blog/2004/11/web-application-design-rest-of-story.html

[11]http://publib.boulder.ibm.com/infocenter/cicsts/v3r1/index.jsp?topic=%2Fcom.ibm.cics.ts31.doc%2Fdfhws%2Fconcepts%2Fsoap%2Fdfhws_message.htm

[12] http://stackoverflow.com/questions/7551/best-practices-for-securing-a-rest-api-web-service

[13] http://www.restapitutorial.com/media/RESTful_Best_Practices-v1_1.pdf

Note

Review mengenai materi ini bersifat discussable, bisa terlihat maraknya pembahasan mengenai topik ini di mesin pencari dengan keyword, misalnya: rest vs soap.

Jika ada tambahan atau sanggahan atau ingin berdiskusi, silakan disampaikan melalui comment.