Coupling in systems: Platform, Temporal and Spatial

Sebagai pembuka dari bagian ini tentu saja kita perlu meminimalisir afferent dan efferent coupling tetapi tidak secara otomatis. Kita harus mempunyai konteks yang tepat untuk setiap coupling. Zero coupling tidak akan mungkin dilakukan.

Sekarang kita masuk ranah coupling pada distributed system. Ada 3 jenis coupling pada system yaitu : Platform, Temporal dan Spatial.

Platform Coupling adalah interoperability. Hal ini berhubungan dengan fallacy dimana network homogeneus. Contohnya adalah satu bagian dari system ditulis dengan .net dan yang lain ditulis dengan java. Bagaimana cara 2 component dari system tersebut agar dapat berkomunikasi. Jangan sampai .NET memberikan service nya di publish dalam bentuk .NET remoting dan Java dengan Java RMI. Karena hal tersebut sangat tidak compatible diluar dari Bahasa tersebut.

Jadi kita harus berhati-hati juga dengan binary serialization yang hanya spesifik dari satu bahasa.

Salah satu dari 4 tenet Service Orientation adalah kita harus mensharing contract atau schema dan bukan kelas yang spesifik ke Bahasa ata platform. Karena hal tersebut lebih compatible.

Temporal coupling berhubungan dengan coupling yang tergantung oleh waktu atau runtime. Jika kita memiliki 2 bagian dari code yang saling berhubungan satu sama lain dan tipe komunikasi adalah synchronous dan blocking. Artinya client tidak dapat melakukan pekerjaan sampai pemanggilan method atau fungsi tersebut selesai. Atau service mengembalikan suatu return value.

Hal ini berarti runtime dari client ( Service A ) bergantung ke runtime dari server ( Service B) atau temporal coupling. Semakin lambat service B memberikan response, semakin lambat pula service A berfungsi.

JIka kita melakukan nya dengan fire and forget, one way asynchronous messaging dengan message queue kita akan mendapatkan decoupling secara temporal.

Spatial coupling lebih erat hubungannya dengan fallacy mengenai topology.

Jika suatu mesin crash apakah kita akan mendapatkan fasilitas failover ke mesin yang lain tanpa kita perlu mengubah file konfigurasi. Jadi service A tidak coupling secara spatial ke mesin tertentu. Kita bias saja memiliki load balancer atau clustered. Kita harus kembali lagi menilik bahwa apakah kita perlu cluster atau tidak.

Sekarang kita akan membahas mengenai solusi yang ada mengenai aspek coupling yang kita bahas sebelumnya.

Platform coupling dapat di atasi dengan banyak cara. Salah satunya adalah dengan web services dimana semua orang secara langsung dengan cepat memilihnya. REST, SOAP, WSDL dsb. XML. Pertama kita kita bisa melihat kembali mengenai reprensentasi di wire. Yaitu menggunakan text based dengan XML. XML juga bisa memiliki schema atau XSD. Kita juga bisa menggunakan JSON. Jika kita menggunakan schema maka client mengetahui tipe data dan struktur data yang ada di server. Kita juga mendapatkan produktifitas dari developer dengan hal tersebut. Developer dapat menghasilkan kelas dari XSD tersebut dengan tools.

Hal ini adalah yang dilakukan oleh banyak tools dengan membaca WSDL dan XSD dan mengenerate kelas kelas yang dibutuhkan. Jika kita tidak memiliki schema dari XML tersebut maka mau tidak mau kita harus menggunakan XPath.

Kekurangan dengan tooling adalah jika representasi object atau struktur data di server berubah, maka kita harus mengenerate ulang kelas proxy dan juga struktur data yang ada. Kita memiliki masalah dengan versioning, meskipun kita mungkin tidak menggunakan data struktur tersebut.

Sekarang ini lebih banyak lagi pilihan untuk format wire. Seperti protobuf, avro dan thrift. Semua memberikan kemudahan dari sisi produktifitas dan juga interoperability.

Mengenai transport kebanyakan orang langsung berpikir ke HTTP. Sementara masih banyak metode lain seperti SMTP, UDP, TCP dsb. Hal ini dapat juga digunakan sebagai salah satu alternative. Contohnya apabila kita memiliki masalah dengan komunikasi one to many maka kita akan sulit jika menggunakan HTTP. Kita dapat menggunakan UDP untuk menyelesaikan permasalahan tersebut. Selalulah terbuka untuk opsi yang standard dan sudah diakui oleh umum. Jangan terpaku dengan HTTP.

Bahkan kita dapat menggunakan email atau SMTP untuk komunikasi one to many. Jadi sebelum mengambil kesimpulan bahwa selamanya HTTP menjadi best practice kita harus menganalisa dan menelaah semua tools yang ada dan datang dengan solusi yang terbaik untuk masalah ini.

Temporal coupling biasanya berhubungan dengan service yang membutuhkan data dari service lain. Sehingga coupling tersebut menjadi tinggi. Kita melihat hal yang buruk dengan hal ini. Jika server nya bermasalah dan lambat maka client akan terpengaruh dan akan terjadi efek domino terhadap keseluruhan system.

Orang juga banyak yang terperangkap ke model long polling dengan model multi threading. Hal ini menjadi cukup sulit untuk di maintain.

Jadi cara yang lebih baik untuk mengatasi temporal coupling adalah mengubah arah dari data flow. Ketimbang Service A melakukan remote call terhadap Service B. Service B melakukan publish event ke Service A. Kita menggunakan mekanisme publish subscribe dalam hal ini. Ketika data berubah maka service B akan melakukan publish terhadap data-data yang berhubah saja.

Keuntungannya dari model ini terdapat jika data tidak begitu sering berubah. Tetapi jika data sering sekali berubah dan jarang sekali diakses maka kita akan mendapatkan overhead untuk implementasi nya. Kita juga tidak dapat menggunakan pub sub pada setiap situasi. Jangan sampai salah menggunakan pub sub dimana data diminta harus selalu konsisten. Pub Sub adalah pola komunikasi yang berguna tetapi bukan merupakan best practice yang dapat di implementasikan di semua kasus.

Pendekatan di atas juga memiliki sedikit masalah yaitu kemungkinan service client akan menggunakan data yang tidak up to date. Hal ini harus diperhatikan setiap kali kita menggunakan mekannisme publish subsribe. Hal ini harus di diskusikan dengan business. Apakah mereka bisa menerima atau tidak.

Bahkan jika kita tetap bersikeras melakukan remote call secara asynchronous. Data kemungkinan bisa saja stale atau tidak konsisten karena data tersebut tetap berbeda lokasi atau tempat. Sehingga dalam hal ini business menyatakan bahwa design kita salah dengan menempatkan nya di lokasi yang berbeda. Seharusnya kita mendesign nya dalam satu kesatuan. Pemisahan boundary harus mendapat restu dari orang-orang business. Karena salah satu cara untuk menjaganya konsisten adalah membuatnya terletak di dalam satu box atau satu tempat.

Syncrhonous blocking remote call tidak akan memberikan garansi konsistensi 100%.

Gambar di atas menunjukkan bahwa service 1 dan service 2 berada di boundary yang salah. Jika A dan B harus terletak pada tempat yang sama maka service X dapat menampung keduanya dan service Y menampung data yang lain. Sehingga dalam satu service konsistensinya terjaga.

Kembali ke pub sub. Ada beberapa batasan yang harus dipahami jika kita menggunakan pub sub. Yaitu kita harus dapat menggunakan stale data untuk pengambilan keputusan. Harus memiliki pembagian yang baik antara subscriber dan publisher. Hanya ada 1 publisher yang berhak mempublish satu event tertentu.

Sebagai subscriber kita harus dapat mengambil keputusan event yang mana harus di terima dan di simpan. Publisher juga sebagai menyedia data harus dapat memberikan rentang waktu sampai kapan event tersebut dapat diakui sebagai valid. Jadi masing-masing event memiliki expired date. ex: ProductPriceUpdated { Price, ValidTo: 1/1/15}

Bagaimana cara kita mendesign event ? Hindarilah request/command structure. contoh SaveCustomerRequested. Gunakanlah past tense untuk mendeskripsikan event. Karen event adalah sesuatu yang sudah terjadi di masa lampau. Subscriber hanya bisa menerima event tanpa bisa merollback event tersebut. Ex: OrderAccepted. Dan hal tersebut adalah kenyataan di domain business.

Spatial coupling. Application layer seharusnya tidak perlu tahu menahu dimana service yang lain berada di network. Kita memiliki pattern service agent yang ada di client side. Komunikasi di tangani oleh service agent dan memberikan abstraksi tersebut.

Routing merupakan logical kemudian fisikal. Jadi kita harus mendesain service apa yang menerima message tertentu dan event tertentu. Contohnya CreateReport command dan MarkAsFraud ditangani oleh service yang berbeda. Cluster, load balancer dan competing consumer merupakan detail dari implementasi.

Message type sama dengan logical destination. Contohnya AddCustomerMessage, message ini di kirim oleh client ke satu logical server dan kemungkinan multiple fisikal server dibalik load balancer atau competing consumer. Contoh lain nya adalah OrderCanceledEventMessage, di publish oleh satu logical server dan multiple fisikal server dapat mempublish event yang sama.

Jadi buatlah message atau event anda tidak menyalahi Single Responsiblity Principle. Sehingga kita tidak perlu melakukan routing berdasarkan content.

Kita dapat menyimpulkan sekarang bahwa coupling bukan hanya merupakan slogan belaka, tetapi melibatkan 5 aspek. 5 aspek tersebut adalah efferent, afferent, temporal, spatial dan platform. Jadi kita harus membuat trade off. Karena kita tidak dapat secara sempurna melakukan bebas coupling 100%.Tapi kita bisa membuat coupling yang beralasan selama kita berada di jalur yang benar.