Messaging itu kompleks? Setuju banget.. Ngga mau pake SOAP karena terlalu canggih, yang dibutuhin engga sedetil itu. Akhirnya, mutusin buat bikin webservis sendiri, tapi engga semulus yang dibayangin, mikirin concurency, state diantara aplikasi yang ngirim request, etc..etc..etc..
Bwah! On 06/06/07, Andry S Huzain <[EMAIL PROTECTED]> wrote: > > > > > On 6/6/07, Arie Kusuma Atmaja < [EMAIL > > PROTECTED]<ariekusumaatmaja%40gmail.com>> > wrote: Andry S > > Huzain wrote: > > > > Apakah Ribet =~ /Enterprise/ > > > > ?????? > > > > bahasa manusia mode on: > > > > apakah ribet identik dengan enterprise ???? > > Nggak mesti. > > Enterprise Application itu adalah aplikasi yang harus ada/jalan/survive > atau > client kehilangan duit. Ini "postulat" saya. > > Misalnya aplikasi ybs, yang notabene pake teknologi messaging + > distributed > object tapi crash karena gagal nulis log akibat kekurangan disk space, > maka > itu bukan aplikasi enterprise (reliability). > > Misalnya ada aplikasi pake PHP doank, tapi survive di peak hour saat > dihantam slashdot dan diggmob, maka menurut saya itu sudah aplikasi kelas > enterprise (scalability). > > Ruby ActiveRecord yang simple itu, yang sering dihina oleh OR/M fanboys, > ternyata finder method-nya sudah kebal SQL Injection. ActiveRecord yang > simple itu, buat saya sudah kelas enterprise (security). > > Untuk mencapai reliability, scalability, dan security memang kadang harus > dengan solusi yang ribet karena memang masalah yang hendak dipecahkan > bukan > masalah sederhana. > > Messaging itu kompleks. > Coba deh anda bayangkan bagaimana bikin aplikasi messaging tanpa messaging > server apapun (pake FTP misalnya). Riilnya, bayangkan anda bikin program > untuk mesin ATM secara manual. KIta harus ngatur gimana transaksinya, > bagaimana concurency-nya, lalu security, stability (nasabah ga ingin > ngeliat > error "whoops, we get an error!" di layar ATM saat transfer duit, kan?). > Cara paling "gampang" ya pake messaging. Kalau nggak tau alasan kenapa ada > messaging, ya memang kerasa banget kalo messaging itu ribet dan segede > gajah > (over Bruce Tate). > > Distributed object itu juga kompleks. > Bayangkan kita bikin manual pake socket.c doank. > Anda harus memanage kapan sih sebuah remote object (selanjutnya saya sebut > server object) bisa aman di-destroy oleh GC. Lalu harus dimanage dari > mana? > Dari sisi client object mestinya, karena client object yang > meng-instantiante server object. Masalahnya, GC yang dipake bersih-bersih > server object mestinya kan GC yang juga ada di komputer server kan? Nah > loh.., > > Karena ini (dan 2 alasan lain) Fowler bersabda "never distribute your > objects". Okay, saya faham. > Sayangnya, ada banyak kasus dimana saya ketemu "distributed object". > Aplikasi yang melibatkan "parameterized" business rules antar departemen > (dan juga region) biasanya kandidat yang bagus untuk distributed object. > > "Law of Simplicity #9: Some things can never be made simple", begitu John > Maeda bilang. > > Lawan simplitas tentu saja over-engineering. > Microsoft Enterprise Library (.NET) dan Apache Common-Logging (Java) itu > dua > contoh klasik over-engineering. (ga yakin? ayo kita debat hehe.. ). > > Dilapangan, yang akan sering yang kita temui bukan pada tataran arsitektur > seperti dua contoh yang saya sebutkan, tapi masih di tataran "tools". > Misalnya: pake EJB1.x/2.x/3.x tapi concurrent klien yang mau dilayani ga > lebih dari 10. Atau pake remoting objects tapi deployment server jadi satu > dengan komputer klien. Justifikasi si programmer biasanya "nembak semut > dengan meriam nggak apa-apa, yang penting semutnya mati". > > Sekelompok orang sepertinya sadar akan hal ini. Lalu muncullah konsep > YAGNI. > Sekte2 juga bermunculan. Sebut saja NoFussButStuff Symposium, Agile > Alliance, dan Pragmatic Programmers. Beberapa juga ambil aksi paranoid "no > enterprisey word!". Suka-suka anda saja mau ikut sekte yang mana.... > > Kembali ke enterprise 'thingy'. > Jadi ga mesti bahwa ribet == enterprise. Meski harus disadari bahwa untuk > mencapai sebuah aplikasi yang stabil, reliable, scalable, dll tadi memang > dibutuhkan solusi yang nggak selalu simple. > > Seperti reply yang panjang ini. > Saya butuh panjang dan mendetail dengan beberapa contoh nyata karena ide > yang ingin saya sampaikan cuma simple di puncak gunung es saja. > > -- > http://andryshuzain.com > > [Non-text portions of this message have been removed] > > > -- in03ng a.k.a inung a.k.a nursamsi a.k.a nur syamsi Y! in03ng [Non-text portions of this message have been removed]
