> > On 6/6/07, Arie Kusuma Atmaja < [EMAIL PROTECTED]> 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]
