Business and Application Logic Domains
Sebelum masuk ke desain, penting memahami pemisahan domain logika:
- Business logic — direpresentasikan sebagai business processes (kumpulan task, keputusan, dsb.).
- Application logic — logika yang terikat pada aplikasi tertentu (Application A, B, C).
Service Interface Layer (Abstraction) — di antara business process layer dan application layer, terdapat lapisan service interface yang merepresentasikan service secara abstrak (lingkaran-lingkaran yang terhubung ke physical service encapsulation di layer aplikasi). Lapisan inilah yang membuat business process bisa “melihat” service tanpa peduli detail implementasi aplikasi di baliknya.
SOA Delivery Lifecycle
Ada dua pendekatan siklus hidup pengiriman (delivery) SOA:
Top-Down (mulai dari nol)
- Define relevant ontology
- Align relevant business models
- Perform service-oriented analysis
- Perform service-oriented design
- Develop services
- Test service operations
- Deploy services
Bottom-Up (mulai dari aplikasi yang sudah ada)
- Model application services
- Design application services
- Develop application services
- Test services
- Deploy services
SOA Analysis
Tujuan: menentukan service apa yang perlu dibangun, dan logika/proses/rutin apa yang perlu dienkapsulasi tiap service.
Langkah-langkah:
- Definisikan set awal kandidat service.
- Kelompokkan kandidat operasi service ke dalam konteks logis — konteks ini merepresentasikan kandidat service.
- Definisikan batas (boundary) service awal agar tidak tumpang tindih dengan service yang sudah ada/direncanakan.
- Identifikasi logika terenkapsulasi yang punya potensi reuse.
- Pastikan konteks logika terenkapsulasi sesuai dengan tujuan penggunaannya.
- Definisikan model komposisi awal yang sudah diketahui.
Define Service Candidates
| Top-Down | Bottom-Up |
|---|---|
| 1. Definisikan business requirements 2. Identifikasi sistem otomasi 3. Model kandidat service | Memakai BPM (task-centric) — turunkan business service untuk mendukung (sub-)proses dalam proses bisnis Memakai Entity Model (entity-centric) — turunkan primitif yang dilakukan entitas tertentu |
Service Candidates: contoh task-centric services (Invoice Submission Service, Order Fulfillment Service, TLS Subscription Service) vs entity-centric services (Accounts Payable Service, Vendor Profile Service, Purchase Order Service, Ledger Service).
Delapan Prinsip Desain SOA (SLAR ASDC)
Sumber utama: SOA — Concepts, Technology, and Design (Thomas Erl). Delapan prinsip umum ini sering disingkat mnemonic SLAR-ASDC atau 4A3M2S1E/AMSE untuk pattern-nya (lihat 6_SOA Design Patterns).
Poster ringkasan 8 prinsip desain SOA (Thomas Erl) — tiap kolom = satu prinsip dengan definisi, ilustrasi, dan bab rujukan.
1. Reusable (Reusability)
Prinsip: terlepas dari ada tidaknya kesempatan reuse langsung, service didesain untuk mendukung potential reuse di masa depan.
Diagram: service interface layer menghubungkan satu layanan (lingkaran) ke banyak bagian business process layer — service didesain fleksibel walau baru dipakai satu kali.
2. Shares a Formal Contract
Prinsip: agar service dapat berinteraksi, mereka tidak perlu berbagi apa pun selain kontrak formal yang mendeskripsikan tiap service & mendefinisikan syarat pertukaran informasi (terms of information exchange).
3. Loosely Coupled (Service Loose Coupling)
Prinsip: service harus didesain berinteraksi tanpa butuh dependensi ketat lintas-service (tight, cross-service dependencies). Underlying logic tetap dihubungkan lewat kontrak, tapi tidak saling terikat erat secara internal.
4. Abstracts Underlying Logic (Service Abstraction)
Prinsip: satu-satunya bagian service yang terlihat dari luar adalah apa yang diekspos lewat kontrak service. Logika di baliknya, di luar apa yang dinyatakan kontrak, tidak terlihat dan tidak relevan bagi requestor.
5. Composable (Service Composability)
Prinsip: service boleh mengomposisi service lain. Ini memungkinkan logika direpresentasikan dalam berbagai tingkat granularitas dan mempromosikan reusability serta pembentukan abstraction layers.
6. Autonomous (Service Autonomy)
Prinsip: logika yang diatur (governed) suatu service berada dalam batas eksplisit (explicit boundary). Service punya kontrol dalam batas itu dan tidak bergantung pada service lain untuk menjalankan governance-nya.
7. Stateless (Service Statelessness)
Prinsip: service tidak seharusnya dituntut mengelola informasi state, karena ini bisa menghambat kemampuannya tetap loosely coupled. Service didesain memaksimalkan statelessness, bahkan jika berarti pengelolaan state didelegasikan ke tempat lain (mis. lewat token seperti JWT alih-alih menyimpan sesi user).
8. Discoverable (Service Discoverability)
Prinsip: service harus mengizinkan deskripsinya ditemukan dan dipahami oleh manusia maupun service requestor lain yang mungkin dapat memanfaatkan logikanya (mis. lewat service registry).
Ringkasan Tabel 8 Prinsip
| Prinsip | Tujuan Utama | Contoh Implementasi |
|---|---|---|
| Standardized Service Contract | Integrasi lebih mudah, “berbicara bahasa yang sama” | Protokol konsisten (REST/SOAP) + format data standar (XML/JSON) |
| Service Loose Coupling | Fleksibilitas, maintainability, fault tolerance | Service independen via message broker (RabbitMQ, Kafka) |
| Service Abstraction | Information hiding, kompleksitas internal tidak terekspos | Composability |
| Service Reusability | Mengurangi duplikasi, plug & play | Service generik, tidak spesifik konteks tertentu |
| Service Autonomy | Reliabilitas & kinerja, independen dari service lain | Resource sendiri untuk tiap service |
| Service Statelessness | Skalabilitas & maintainability | JWT untuk otentikasi tanpa menyimpan session state |
| Service Discoverability | Mudah dicari & ditemukan tanpa proses manual | Service registry |
| Service Composability | Bisa dikombinasikan untuk proses bisnis lebih besar | Desain service agar bisa jadi bagian dari proses yang lebih besar |
Flashcard
flashcards Sebutkan 8 prinsip desain SOA (SLAR ASDC) :: Standardized Service Contract, Loosely Coupled, Abstracts underlying logic, Reusable, Autonomous, Stateless, Discoverable, Composable. Apa yang membedakan prinsip Loose Coupling dan Abstraction? :: Loose Coupling fokus pada minimnya dependensi antar-service (interaksi tanpa tight cross-service dependency); Abstraction fokus pada disembunyikannya logika internal — hanya kontrak yang terlihat dari luar. Apa arti “service didesain untuk potential reuse” pada prinsip Reusability? :: Terlepas ada/tidaknya kesempatan reuse langsung saat ini, service tetap didesain agar mampu dipakai ulang di masa depan. Mengapa service sebaiknya Stateless? :: Karena penyimpanan state dapat menghambat kemampuan service tetap loosely coupled; state sebaiknya didelegasikan ke tempat lain (mis. token JWT) demi skalabilitas & maintainability. Apa perbedaan pendekatan Top-Down dan Bottom-Up dalam SOA Delivery Lifecycle? :: Top-Down mulai dari nol (define ontology → align business model → analysis → design → develop → test → deploy); Bottom-Up mulai dari aplikasi yang sudah ada (model → design → develop → test → deploy application services). Apa tujuan utama fase SOA Analysis? :: Menentukan service apa yang perlu dibangun dan logika/proses apa yang perlu dienkapsulasi tiap service. Apa perbedaan task-centric service dan entity-centric service dalam Define Service Candidates? :: Task-centric diturunkan dari BPM (mendukung sub-proses bisnis, mis. Order Fulfillment Service); entity-centric diturunkan dari Entity Model (primitif terkait entitas tertentu, mis. Vendor Profile Service). Apa arti prinsip Service Autonomy? :: Logika yang diatur service berada dalam batas eksplisit; service punya kontrol penuh dalam batas itu dan tidak bergantung pada service lain untuk governance-nya. Apa arti prinsip Service Composability? :: Service boleh mengomposisi service lain sehingga logika bisa direpresentasikan dalam berbagai granularitas, mempromosikan reusability dan abstraction layers.