Slide W06a membahas mitos-mitos tentang SOA (daftar delapan mitos dari CMU, 2006, plus mitos tambahan dari Erl, 2008). Intinya: SOA sering dianggap lebih mudah, lebih otomatis, dan lebih “teknologi” daripada kenyataannya. Konsep SOA dasar ada di 1_Pengantar Service Computing dan 2_SOA dan Web Service, prinsip desainnya di 5_SOA Design Principles, dan pengujiannya di 14_SOA Testing.
Mitos #1: SOA menyediakan arsitektur lengkap sebuah sistem
SOA adalah architectural pattern/style/paradigm, bukan arsitektur sistem itu sendiri.
- Architectural pattern memberi panduan yang memuat best practice. Elemen konkret beserta interaksinya adalah arsitektur sistem.
- Banyak sistem berbeda bisa dibangun dari satu pattern. Arsitektur berbasis SOA mewarisi sisi baik dan sisi buruknya.
Konsekuensi: SOA tidak bisa dibeli jadi (off-the-shelf). Kualitas sistem harus dibangun ke dalam arsitekturnya, dan keputusan harus diambil sendiri: desain dan implementasi service, teknologi, serta trade-off.
Mitos #2: Sistem legacy mudah diintegrasikan ke lingkungan SOA
Perlu analisis langsung di awal soal kelayakan teknis dan return on investment supaya tidak ada kejutan di menit terakhir. Pertanyaan yang harus dijawab:
- Apakah secara teknis layak membuat service dari sistem legacy (seluruhnya atau sebagian)?
- Berapa biaya membuka sistem legacy sebagai service?
- Apakah biaya itu ditambah biaya memelihara legacy lebih besar daripada biaya menggantinya dengan sistem baru?
- Perubahan apa yang harus dilakukan pada sistem legacy?
- Seberapa besar perubahan itu memengaruhi pengguna saat ini dan sistem produksi lain?
Mitos #3: SOA hanya soal standar, dan standar saja cukup
Kutipan di slide: “The good thing about standards is that there are so many to choose from.” Mitos ini berasal dari salah paham bahwa SOA dan Web Services itu sama.
Sebagian besar standar Web Services masih berkembang dan bisa ditafsirkan berbeda:
- Standar dasar cukup stabil: WSDL, SOAP, XML.
- Standar tingkat lebih tinggi belum matang atau masih dikembangkan.
- Ada terlalu banyak standar, saling tumpang tindih dan berpotensi bertentangan, sehingga perlu evaluasi cermat: WSCL vs WS-Coordination, SAML vs WS-Security.
Mitos #4: XML dan WSDL menjamin interoperabilitas
| Web Services memungkinkan | Web Services tidak menjamin |
|---|---|
| Syntactic interoperability: XML Schema mendefinisikan struktur dan tipe data; WSDL mendefinisikan interface (operasi, parameter, nilai kembalian); informasi, teknologi, dan dukungan tools tersedia | Semantic interoperability: XML dan WSDL tidak mendefinisikan makna data; WSDL tidak mendefinisikan apa yang dilakukan service; ini area riset aktif dengan masalah yang belum selesai |
Interoperabilitas butuh kesepakatan pada sintaks dan semantik. (Perbandingan syntactic vs semantic interoperability juga ada di 2_SOA dan Web Service.)
Mitos #5: SOA hanya soal teknologi
SOA bukan hanya pergeseran teknologi, tetapi juga perubahan model tata kelola (governance) organisasi. Yang perlu diatur:
| Sisi 1 | Sisi 2 |
|---|---|
| Definisi service | Mekanisme deployment |
| Repositori service | Mekanisme monitoring |
| Kepemilikan (service atau data bersama milik siapa?) | Kebijakan tingkat enterprise |
| Evolusi | Service-level agreement |
| Penyelesaian konflik |
Mitos #6: Mudah membangun aplikasi berbasis service
Relatif mudah membangun service yang bekerja dengan infrastruktur tertentu, tetapi mendesain service yang “bagus” tidak semudah itu.
- Dari sisi implementasi: kemudahan bergantung pada ketersediaan tools infrastruktur SOA; bagian tersulit adalah komposisi (data tidak cocok antar service). (Slide menulis “part s composition”, kemungkinan typo “part is composition”.)
- Dari sisi desain: belum banyak best practice mendesain service; harus mengantisipasi calon pengguna dan pola pemakaian; apa Quality of Service yang tepat dan apakah bisa dijamin; dan “If you build it they will come”: apakah kamu sanggup menanggung risikonya?
Mitos #7: Mudah menyusun service secara dinamis saat runtime
Teknologi saat ini belum cukup maju untuk melakukannya di lingkungan produksi. Ini membutuhkan:
- Ontologi bersama yang dipakai provider dan aplikasi client dalam satu domain.
- Aplikasi yang sangat cerdas: membuat query yang tepat untuk discovery service, mengomposisi service bila tidak ada satu service yang bisa memproses request, dan menyediakan data yang benar untuk memanggil service yang baru ditemukan saat runtime.
(Hubungan dengan discovery dan composition statis vs dinamis ada di 2_SOA dan Web Service.)
Mitos #8: Menguji aplikasi tidak berbeda
Menguji aplikasi yang memakai service maupun service itu sendiri sangat menantang:
- Sistem berbasis SOA terdistribusi secara alami.
- Tidak ada kontrol atas service eksternal yang dipakai aplikasi: service menjadi black box, butuh exception management yang sangat baik (“What if the service disappears?”), dan QoS bisa bervariasi menurut beban jaringan dan service.
- Developer service perlu mengantisipasi pola pemakaian.
Daftar Mitos CMU (2006) dan Mitos Tambahan Erl (2008)
Delapan mitos (CMU, 2006):
- SOA menyediakan arsitektur lengkap sebuah sistem
- Sistem legacy mudah diintegrasikan ke lingkungan SOA
- SOA hanya soal standar dan standar saja cukup
- XML dan WSDL menjamin interoperabilitas antar web services dari organisasi berbeda
- SOA hanya soal teknologi
- Mudah membangun aplikasi berbasis service
- Mudah menyusun service secara dinamis saat runtime
- Menguji aplikasi yang memakai service sama saja dengan menguji aplikasi lain
Mitos lain (Erl, 2008):
- Aplikasi yang memakai Web services otomatis berorientasi service
- SOA hanyalah istilah marketing untuk me-rebrand web service
- SOA hanyalah istilah marketing untuk me-rebrand distributed computing dengan Web services
- SOA menyederhanakan distributed computing
- Aplikasi dengan Web services yang memakai ekstensi WS-* otomatis berorientasi service
- Jika kamu paham Web services, kamu tidak akan kesulitan membangun SOA
- Begitu memakai SOA, semuanya menjadi interoperable
Ringkasan: Gunakan SOA dengan Hati-hati
Pendekatan SOA mungkin cara terbaik mencapai tujuan umum interoperability, agility, dan reuse, tetapi:
- Sebagian besar isu di atas adalah area riset aktif.
- Sebagian solusi butuh waktu untuk matang.
Ingat bahwa:
- Tidak semua hal di sistem berbasis SOA harus berupa service (mungkin tidak masuk akal untuk seluruh sistem).
- Sebagian besar studi kasus menunjukkan bahwa kuncinya adalah governance, yang hampir tidak berhubungan dengan teknologi.
Sumber
- Slide W06a “Myths about SOA”, IF4052 Komputasi Layanan (mitos CMU, 2006; mitos tambahan Erl, 2008).
Flashcard
flashcards Mengapa dikatakan SOA tidak bisa dibeli jadi (off-the-shelf)? :: Karena SOA hanya architectural pattern/style, bukan arsitektur sistem itu sendiri; kualitas sistem dan keputusan (desain dan implementasi service, teknologi, trade-off) harus dibangun dan diambil sendiri ke dalam arsitektur konkret. Sebutkan pertanyaan analisis awal sebelum mengintegrasikan sistem legacy ke SOA :: Apakah layak secara teknis membuat service dari legacy, berapa biaya membukanya sebagai service, apakah biaya itu ditambah biaya memelihara legacy melebihi biaya menggantinya, perubahan apa yang diperlukan, dan seberapa besar dampaknya ke pengguna dan sistem produksi lain. Dari mana asal mitos “SOA hanya soal standar”, dan standar mana yang stabil? :: Dari salah paham bahwa SOA dan Web Services sama. Standar dasar (WSDL, SOAP, XML) cukup stabil, sedangkan standar tingkat tinggi belum matang dan banyak yang tumpang tindih (mis. WSCL vs WS-Coordination, SAML vs WS-Security). Mengapa XML dan WSDL tidak menjamin interoperabilitas penuh? :: Keduanya hanya menjamin syntactic interoperability (struktur, tipe data, interface); keduanya tidak mendefinisikan makna data maupun apa yang dilakukan service, jadi semantic interoperability tidak terjamin. Interoperabilitas butuh kesepakatan sintaks dan semantik. Sebutkan aspek governance yang perlu diatur ketika memakai SOA (mitos “SOA hanya teknologi”) :: Definisi service, repositori service, kepemilikan, evolusi, penyelesaian konflik, mekanisme deployment dan monitoring, kebijakan tingkat enterprise, dan service-level agreement. Apa bagian tersulit dari membangun aplikasi berbasis service menurut slide? :: Dari sisi implementasi: komposisi (data tidak cocok antar service). Dari sisi desain: sedikitnya best practice, kebutuhan mengantisipasi pengguna dan pola pemakaian, menentukan QoS yang tepat, dan risiko “if you build it they will come”. Mengapa komposisi service dinamis saat runtime belum realistis di produksi? :: Butuh ontologi bersama antara provider dan client, serta aplikasi yang sangat cerdas untuk membuat query discovery yang tepat, mengomposisi service saat tidak ada satu service yang cukup, dan menyediakan data yang benar untuk memanggil service yang ditemukan saat runtime. Mengapa pengujian aplikasi berbasis service lebih sulit? :: Sistem terdistribusi, tidak ada kontrol atas service eksternal (black box, perlu exception management, QoS bervariasi menurut beban), dan developer service harus mengantisipasi pola pemakaian. Apa pesan utama ringkasan slide Myths about SOA? :: Gunakan SOA dengan hati-hati: ia bisa jadi cara terbaik mencapai interoperability, agility, dan reuse, tetapi tidak semua harus berupa service dan kunci keberhasilan adalah governance, bukan teknologi.