Archive

Archive for the ‘Messaging’ Category

Getting started with ActiveMQ

July 12, 2010 Leave a comment

Setelah nyaman menggunakan NServiceBus sebagai ESB saya kemudian berpikir apakah MSMQ tersebut dapat digantikan dengan transport yang lain? Selama ini saya hanya menggunakan NServiceBus dengan MSMQ bawaan dari windows. Bagaimana jika kita ingin running aplikasi tersebut di Linux. Hal itu tentu bakalan menjadi masalah. Padahal aku udh kecantol sekali dengan NServiceBus ini.

Ternyata pembuat NServiceBus tersebut sudah memperhitungkan hal tersebut. Di dalam Roadmap dijelaskan bahwa langkah selanjutnya adalah improved pluggability.
Read more…

Advertisements
Categories: Messaging, NServiceBus

[DDDD] Perubahan pada Repository

April 3, 2009 Leave a comment

Sebagian besar orang menggap bahwa repository merupakan abstraksi dari collection dimana object tinggal disana. Perubahan yg dilakukan pada DDDD adalah object2 yg tinggal pada repository bertanggung jawab untuk mengetahui perubahan statenya.

Contoh nyatanya adalah Order yg berinteraksi dengan Repository. Order hidup di dalam repository. Order akan memberikan perubahan2 yg terjadi pada dirinya semenjak dia dibuat. Repository kemudian menanyakan perubahan itu dan bertanggung jawab terhadap apa yg akan dilakukan perubahan tersebut. Salah satu yg dapat dilakukan oleh repository adalah melewatkannya ke pipeline atau langsung melakukan processing ke database.
Read more…

Event Sourcing

April 3, 2009 Leave a comment

Event Sourcing
Pada pattern ini semua event yg terjadi itu dicapture dalam object dan kemudian disimpan sebagai log. Log ini berfungsi untuk proses auditing atau dapat digunakan untuk mengembalikan state dari aplikasi ke kondisi semula. Agar dapat membangun semuanya dari kondisi nol dari log maka sequecen nya harus dipertahankan.
Kegunaan log yg lain adalah untuk memperbaiki kesalahan yg dilakukan pada masa lalu. Klo di dunia accounting dinamakan dengan reversal adjustment atau retroactive change.

Jadi pada suatu aplikasi kita memiliki dua data untuk di kelola. Salah satu nya adalah application state. Data yg satu ini pasti ada di setiap aplikasi apapun. Application state ini menggambarkan keadaan aplikasi yg terkini atau current state. Yang kedua adalah event log. Event log menyimpan perubahan2 state yg terjadi pada aplikasi tersebut.
Read more…

SOA vs REST

March 6, 2009 1 comment

SOA berdasarkan kepada konsep MEST atau MESsage Transfer. Message mengandung statement of intent dan data yg berhubungan dengannya. Contohnya adalah ChangeCustomerAddressMessage (message tersebut sudh menunjukkan maksudnya) dan di dalam object tersebut terkandung data yg berhubungan dengan maksud tersebut.

REST berfokus terhadap Resource. Jadi jika kita ingin merubah alamat dari Customer maka kita harus tahu URI dari Customer tersebut dan menyertakan method PUT dan datanya.

PUT http://example.com/customer1

PUT adalah method dan http://example.com/customer1 adalah URI
Read more…

Service Autonomy 2

March 6, 2009 Leave a comment

Autonomous = Otonomi = Mampu berdiri sendiri.

Autonomous service brarti service yg mandiri. Yg ingin dicapai sebenarnya dari prinsip tersebut adalah loosely couple. Misalkan service A membutuhkan service B maka meskipun Service B tidak tersedia Service A tetap dapat menjalankan fungsinya sesuai dengan service agreementnya. Sesuai dengan janjinya
Jadi caranya adalah menghilangkan request response collaboration pada level service. Jadi jika kita memiliki 2 software entities dimana kita harus melakukan request response brarti keduanya berada pada satu service. Tetapi harus digaris bawahi kata harus. Semua emang bisa dilakukan dengan Req/Resp tetapi ada bagian2 yg sebenarnya tidak.

Component Orientation dan Object Orientation membagi solusi menjadi bagian2. Jadi kita harus menemukan boundary yg tepat. Sehingga bagian2 yg sebenarnya dapat terpisah tidak couple. Read more…

REST design

March 6, 2009 Leave a comment

Jika kita ingin membuat aplikasi web kita menjadi scalable maka kita harus dapat mengamati data yg kita sediakan dan bagaimana penggunaan user terhadap data tersebut. Nah jika kita dapat menganalisanya maka kita dapat menentukan mana data yg dapat dicache dan tidak. Karena memang protocol HTTP mendukung teknik tersebut dan bahkan di design untuk hal tersebut. Jadi kita tidak perlu membebani server terlalu berat karena ada bagian2 data yg dicache.

Kita dapat memberikan tanda bahwa page atau request tersbut dapat dicache atau tidak dari HTTP Header. Kita dapat mensetnya. Jadi apabila suatu URI dicache maka kali berikutnya dia dibutuhkan dia akan mengambil dari cache. Read more…

REST == Architecture Style

March 6, 2009 1 comment

Nah dengan demikian kita membuat implementasi detail tidak kelihatan. Nah jadi dimana code yg menangani URL trsebut di server ?? Bagaimana caranya ?? Nah klo misalnya udh familiar dengan web development. Maka kita biasa membuat URL seperti ini

http://www.acme.com/phonebook/UserDetails?id=12345

Nah kita dapat melakukan URL Rewriting sehingga lebih menceriminkan resource dan lebih clean

http://www.acme.com/phonebook/UserDetails/12345

Read more…