Home > Messaging, SOA > Service Autonomy

Service Autonomy

Salah satu prinsip dari Service Orientation adalah Autonomy. Dapat berdiri sendiri. Peranan publisher subscriber ini mutlak diperlukan untuk mencapai autonomy.

Untuk para pemula di SOA biasanya langkah pertama adalah membuat semua operasi menjadi web service. Yg sama aja hasiilnya dengan RPC. Interaksi antar service terjadi secara synchronous, blocking, request/response. Masalhnya klo misalnya salah satu service tidak ada, service lain yg tergantung terhadapnya tidak akan dapat melakukan pekerjaannya.

Hasilnya jelas berbeda jika interaksi antar service dilakukan secara publish/subscribe. Ga ada masalah dengan blocking request. Subcriber dapat mencahce data yg dipublish ke dia (mw di memory atau berdurasi tergantung dengan fault tolerance requirement) jadi misalnya service yg lain ga ada. Ga masalah sama dia. Karena dia punya data sendiri. Bisa ambil dari situ.

Akan lebih jelas dengan contoh :
Kita ambil contoh untuk aplikasi e-commerce. Ada Sales service yg responsibilitynya untuk menjual produk. Service yg lain namanya Merchandising responsibiltnya untuk menyediakan catalog terhadap product dan harganya. Sales subscribe ke PriceUpdated event yg dipublish oleh Merchandising. Dan menyimpan (cache) harga tersebut pada databasenya. Nah ketika customer melakukan order terhadap produk dari site tersebut, Sales tidak perlu memanggil Merchandising untuk mengambil harga dari produk tersebut. Jadi Sales hanya menggunakan data yg disave sebelumnya. Jadi misalnya nanti Merchandising tidak ada atau offline. Sales tetap dapat menerima order.

Tapi gimana klo harga yg disimpan di cache tersebut sudah out of date. Nah ini issue baru lagi mengenai kesegaran dari data. Masalah tersebut tergantung lagi dengan bisnisnya dan requirement dari system tersebut. Jadi harus ditentukan diawal mengenai masalah kapan2 saja harga bisa berubah. Jadi jika nanti ditentukan bahwa harga berubah untuk periode lebih besar dari X, brarti barang tersebut jangan dijual dulu. Nilai dari X bisa berbeda2 sesuai dengan produknya. Jadi ini tanggung jawab dari arsitek untuk mencari requirement2 tersebut dan harus dijelaskan juga kepada bisnis customernya apa2 saja tradeoffnya.

Dengan metode publish subscribe ini aka nada tambahan logic lagi dan complexity akan meningkat. Selalu ada efek dari setiap pilihan arsitektur.

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: