Tag-Archive for » Analogy «
Dari tulisan sebelumnya,
Service di katakan mengkapsulkan/membungkus logika yang menjadi suatu pekerjaan yang akan dijalankan oleh suatu proses, juga terdiri dari beberapa langkah.
Service juga di katakan memiliki relasi dengan service lainnya dan di perantarai oleh service description
Pada artikel ini saya ingin topik lanjutan dr ebook Thomas Erl yang saya baca , yaitu sbb:
Services Communicate
Setelah service berkomunikasi dengan mengirimkan message, mk service tersebut kehilangan kontrol akan message tsb (what happens to the message thereafter).
Karena hal inilah, message perlu seperti service dapat bebas berdiri sendiri / (autonomous).
Karena hal itu, sebuah message dapat dilengkapi dengan kecerdasan untuk bs mengurus bagian processing logic nya sendiri.
Service yang menyediakan service description dan ber komunikasi via messages membentuk sebuah arsitektur dasar/sederhana.
Sejauh ini, arsitekture tesebut, tampak sama dengan arsitektur lama yang disalurkan, yang mensuport messaging dan pembagian interface dr processing logic
Perbedaannya adalah 3 komponen inti yang di design yaitu :
- Services
- Descriptions
- Messages
Design Services
Aspek2 dr prinsip Service-Oriented untuk design dan definisi:
- Service yang bersifat bebas(loosely Coupled) , service yang memelihara sebuah relasi dimana ketergantungan diminimalisasikan
- Service Contract, service yang melekat pada sebuah persetujuan komunikasi, yang umumnya didefinisikan oleh satu atau lebih service description dan oleh document-document berkaitan
- Service autonomy yang memiliki control penuh akan logika yang dikapsulkan.
- Service abstraction diluar dr apa yg dideskripsikan di service contract, service menyembunyikan logika dari manapun.
- Service reusability, service ini dibagi kedalam beberapa service dengan maksud untuk dapat digunakan ulang
- Service composability, koleksi dari service-service dapat di
kordinasikan dan dirakit menjadi gabungan service. - Statelessness Service,
Service meminimalkan ketahanan akan informasi spesifik untuk sebuah aktivitas - Kemampuan menemukan Service (Service discoverability) ,
service yang didesign untuk mengeluarkan deskripsi sehingga service yang dicari dapat ditemukan dan ditafsirkan via discovery mechanisms yang tersedia.
Built Services
Seperti yang sudah disebutkan di post saya sebelumnya, syarat service oriented dan macam2 abstrak model SOA sudah ada sebelum WEb Service “tiba” -> diluncurkan 🙂
Bagaimanapun juga tidak ada 1 pun kemajuan teknologi yang sangat lengkap dan sukses ,dalam mendaftarkan SOA tanpa web service.
Tapi sekarang ini semua perusahaan platforms sekarang mendukung pembuatan dari solusi service oriented dan kebanyakan melakukannya dengan memahami bahwa SOA menyediakan dukungan didasari dengan menggunakan web service.
Oleh karena itu, sementara ini kita benar2 mengakui bahwa untuk dapat mencapai SOA tidak memerlukan web service.
CMIIW 😀
Sincerely yours,
Rudy Yulianto
umumnya di suatu perusahaan yang berorientasi kepada pelayanan menyediakan pelayanan, dimana pelayanan tsb bisa digunakan oleh banyak konsumennya.
umumnya bisnis di perusahaan ini meliputi komunitas bisnis –> mungkin mksdnya ‘proses bisnis’
Masuk akal, jika komunitas bisnis dari perusahaan tsb, tidak di pakai oleh sebuah bisnis outlet (jika di artikan sebagai ‘saluran’ atau ‘bagian yang lbh kecil’)
Dengan menguraikan komunitas bisnis menjadi lebih khusus (menjadi 1 outlet ), mk kita mencapai sebuah lingkungan dimana ada bbrp outlet yang dapat dijalankan(didistribusikan).
penggabungan outlet dengan architecture, mk dalam konotasi teknis disebut “Service-Orientation”.
Sehingga “Service-Oriented Architecture” adalah syarat yang mewakili model dimana ada automation logic dibagi menjadi lebih kecil, menjadi unit-unit logika–> dalam SOA dikenal sebagai SERVICE.
Umumnya unit-unit tersebut mencakup bagian/potongan besar dari business automation logic.
Masing-masing unit tersebut bisa di jalankan (didistribusikan).
Dengan pembagian ini, kita dapat menghindari sebuah model yang memiliki hubungan/koneksi yang padat, dmn dpt menghasilkan ketergantungan juga.
Dengan mengizinkan bisnis2 mengurus service2 nya sendiri,secara tidak langsung kita juga mengizinkan service2 tersebut, untuk berkembang dan bertumbuh secara tidak bergantung dengan service lainnya. 😀
Meskipun kita mengizinkan service2 tsb untuk berkembang di antara outlet, kita kita msh perlu memastikan mereka setuju untuk mengikuti perjanjian dasar. Contoh analogy nya : kita membuat code untuk 1 fungsi , berdasarkan parameter yang ada di fungsi tsb, contoh lainnya, keseragaman pekerja berbicara dengan bahasa yang sama kepada para pelanggan.
Kesamaannya, SOA mengizinkan setiap unit logika2 (proses bisnis) untuk tidak terisolasi/tergantung dengan lainnya.
Unit2 logika ini, perlu menyesuaikan dengan prinsip2(standarisasi) yang mengizinkan mereka untuk di kembangkan secara bebas (tidak tergantung 1 dengan yang lainnya)
CMIIW 😀
Sincerely yours,
Rudy Yulianto