Service Oriented Architecture, Masa Depan Kita

Saya tersenyum getir waktu membaca milis JUGI (Java User Group Indonesia) yang sedang ramai membicarakan masa depan Java yang popularitasnya semakin turun. Kalau Anda masih terjebak dalam fanatisme sempit, semacam Java versus PHP, .net Framework, Ruby, dan seabrek alternatif teknologi yang lain, come on, wake up bro!

Memang harus saya akui sebagai fans sejati Java, dunia Java telah memasuki masa jenuhnya, dimana ada banyak sekali pilihan teknologi — terlalu banyak. Anda bisa menulis “Hello World” dengan 30 cara yang berbeda di Java. Mau cara apa? JSP, Struts, JSF, Spring, Hibernate, Ibatis, EJB, Annotation, IceFaces, Seam? Artinya teknologi ini sudah memasuki masa mature-nya, dan siap digantikan oleh teknologi baru yang lebih menggoda.

Oh tidak, saya tidak berpikir sampai di situ saja. Seharusnya kita sudah mulai berpikir bagaimana melakukan integrasi antar sistem terdistribusi dalam platform yang berbeda-beda. Sekarang, setiap perusahaan memiliki sistem terdistribusinya. Semakin lama platform semakin beragam, dan ujungnya biaya maintenance yang semakin mahal. Proses bisnis semakin bergantung dengan keberadaan sistem IT, tetapi biayanya pun semakin mahal karena semakin kompleksnya jejaring antar aplikasi.

Service Oriented Architecture, tidak hanya datang membawa sebuah solusi arsitektur aplikasi yang lebih baik, namun juga sebagai performance management bagi para pembuat keputusan. Dengan sudut pandang per servis yang diberikan, biaya perawatan sebuah sistem IT bisa dibebankan pada setiap pihak yang berhubungan dengan servis yang digunakan.

Melihat tren para vendor besar, tren ke arah SOA juga telah terlihat nyata. Masing-masing memiliki jagoannya masing-masing. Oracle, IBM, dan Weblogic. Ini artinya, dengan investasi besar di SOA, mereka percaya pada SOA sebagai masa depan seperti dulu Oracle berjargon, “Because we believe in Java”. Di dunia open source pun, salah satu vendor terbesarnya, Apache Software Foundation, juga telah membuat tool-tool SOA-nya.

Jadi, apakah kita akan masih berkutat pada fanatisme sempit macam Java versus MS .net? Tantangan ke depan kita adalah bagaimana membuat dua platform ini berkomunikasi dan bekerja sama dengan baik. Salah satu medianya adalah SOA. Sudah saatnya kita ngomong tentang Web Service, BPEL, atau ESB (Enterprise Service Bus). Untuk masa depan.

Eclipse BIRT Ganymede: Loncatan Lebar BIRT

Saya pernah membahas tentang beberapa mesin pembuat laporan berbasis Java (Java reporting engine) dan menahbiskan Actuate sebagai tool reporting yang paling hebat. Tapi sayangnya, lisensi Actuate tidak free alias harus membayar sejumlah uang tertentu agar bisa memakainya. Di sisi open source, saya menganggap Jasper Report dan Eclipse BIRT sebagai tool reporting terbaik yang free.

Fleksibilitas

Bussiness Intelligence Reporting Tool (BIRT) merupakan buah manis kerjasama yang cantik antara Actuate dan Eclipse. Menurut saya, ini adalah terobosan bagaimana sebuah report designer. Tidak memiliki batasan slot-slot (Actuate) atau band-band (Jasper), BIRT menawarkan fleksibilitas tanpa batas. Anda bisa menempatkan record-record berulang dimana saja (tidak harus di band detail — misalnya), cukup memasang pallete List atau Table. Sebaliknya, untuk record-record yang tidak berulang, selama Anda tidak memasukkannya pada pallete List atau Table, ia hanya ditampilkan sekali saja. Fitur ini akan sangat menyederhanakan SQL query statement ke database.

Multiple Data Set

Data Set adalah sebuah himpunan data yang akan ditampilkan dalam report. Sumber data set biasanya adalah melalui SQL query. Nah, di BIRT, kita bisa memakai banyak data set yang bisa ditempatkan di pallete mana saja dan bisa menjadi sub data set dari data set yang lain. Ini sangat memudahkan bagi mereka yang tidak bisa membuat SQL query seperti saya. SQL Query yang kompleks (crosstab segala macem) bisa dipecah menjadi beberapa query sederhana dalam beberapa data set. Menakjubkan sekaligus menyenangkan!

State of the Art: Eclipse Birt Ganymede

Versi ini sangat banyak perbaikan yang besar, utamanya di masalah performance, baik di sisi Report Designer-nya maupun runtime-nya.  Waktu masih memakai Eclipse Birt Europa, saya mengeluh tentang lambatnya respon desainer dan runtime ketika sudah dipasang di production server. Di sini, Eclipse Birt Ganymede, semua sudah diperbaiki. Respon desainer yang tanggap menjadikan lingkungan yang menyenangkan untuk pembuatan report. Ketika dipasang di production server, proses kompilasi dan hasil tampilan jadinya juga tidak terlalu lama.

Bagaimana tentang kualitas hasilnya? Format PDF tetap rapi seperti pendahulunya, dan ada perbaikan besar di format Microsoft Excel (XLS). Salah satu hal yang paling dikeluhkan para programmer adalah tidak adanya report engine yang bagus untuk hasil berformat xls. Bahkan Jasper yang paling terkenal itu pun tidak bisa menampilkan hasil report excel dengan rapi jali. Namun, Eclipse Birt Ganymede menampilkan fitur yang paling menggiurkan dengan hasil format excel yang sangat rapi. Pembuatan dan pembagian cell gridnya masih rapi seperti buatan tangan (biasanya kalau buatan report engine kacau balau) dan yang paling menarik: garis-garis bantu cell-nya masih terlihat. Sangat dekat dengan hasil buatan manual.

Sebagai penutup, saya kira saat inilah Birt telah *benar-benar* bisa digunakan sebagai reporting engine. Kalau Jasper tidak ada perbaikan berarti, bisa dikatakan inilah tool reporting berbasis Java yang terbaik sekarang. Bahkan konon kabarnya, Actuate versi yang terbaru juga menggunakan engine yang sama persis dengan BIRT sebagai basis mesinnya. Maklum, BIRT kan juga bayi-nya Actuate.

Silakan langsung menuju TKP! *ijo-ijonya gan… :beers:

Memperkenalkan: JBoss Seam Framework

ANOTHER JAVA EE FRAMEWORK

Saya rasa, Java Enterprise telah memasuki masa titik jenuhnya. Hal ini ditandai dengan munculnya bermacam-macam framework dengan gaya yang berbeda-beda. Seringkali framework malah justru mempersulit kita dalam membangun sebuah aplikasi Java. Kejenuhan ini adalah keadaan yang sangat rawan ketika sebuah paradigma pemrograman baru masuk dan membawa kemudahan-kemudahan yang segar yang bisa menghajar habis Java Enterprise (RoR — Ruby on Rails, akankah ini adalah pembunuh Java?).

Kemapanan Action Based

Framework awal Java bergaya request-action-response based mengikuti tingkah laku alami dari protokol HTTP. Pemimpin sektor ini adalah Struts mulai dari Struts 1.x, dan ketika Struts ditinggal programmernya, kemapanan Struts dilanjutkan oleh Webwork yang melahirkan Struts 2.x.

Dalam perkembangannya, Struts tidak cukup menjadi sebuah framework. Di ranah Model di dalam trinitas suci paradigma Model-View-Controller, cukup merepotkan melakukan akses database dengan menggunakan generic JDBC biasa. Oleh karena itu, munculah framework iBatis yang memindahkan penulisan SQL dalam file XML sehingga ketika terjadi perubahan query, paket aplikasi tidak perlu dikompilasi ulang dan di-deploy ulang. Disamping itu, akses database juga bisa di-inject langsung ke dalam objek-objek Java Bean dengan menggunakan Object Relational Mapping (ORM). Oleh karena itu, muncul kemudian Java Persistance API (JPA), Enterprise Java Bean 3 (EJB3), dan Hibernate ORM.

Tumpukan stack framework berikutnya adalah sebuah Inversion of Control yang secara sederhana dijelaskan sebagai pengatur lalu lintas data antara Model (Hibernate ORM) dan View (Struts). Ia hidup dalam ranah Controller. Di sini framework yang paling populer adalah Spring Framework.

Masalah Klasik

Nah, sejauh ini, kita sudah memiliki tiga tumpukan framework: Struts, Spring, dan Hibernate. Dari tiga framework ini, sudah bisa ditebak bahwa masalah yang pertama kali muncul adalah, waktu set up aplikasi yang lama.

Sebenarnya, untuk membuat aplikasi enterprise berbasis web, yang perlu kita buat secara berulang-ulang (dan karenanya membosankan adalah):

1. Membuat mapping antara database ke objek Java Bean. Bayangkan jika akan ada 15 tabel yang saling berelasi. Artinya, saya harus membuat 15 file XML yang menjelaskan detail setiap kolom, primary key, tipe kolom, relasi-relasinya dengan tabel lain…. menyakitkan kawan.
2. Tampilan user untuk mekanisme CRUD (Create, Update, Delete) beserta validasinya. Anda pasti mengerti kalau pernah membuat form HTML berisi textfield, combo box, tombol-tombol, kemudian membuat aliran datanya dengan request GET atau POST, membuat query SELECT, UPDATE, dan sekaligus DELETE untuk tiga halaman. Lalu memvalidasinya agar inputan user sesuai dengan spesifikasi tabel di database. Setelah itu, jika ada 15 tabel, Anda harus mengulanginya di 14 tabel lain. Total akan ada 15 * 3 = 45 pekerjaan berulang-ulang membosankan untuk Anda.

Bukankah menyenangkan sekali kalau ada sebuah tools yang melakukan otomatisasi itu semua? Membaca tabel di database dan melakukan reverse engineer. Membuatkan hibernate mapping-nya, membuat class-class Java Bean, membuatkan halaman-halaman CRUD untuk setiap tabel dan membuat validasi berdasarkan spesifikasi tabel secara otomatis dalam satu klik mouse saja?? ;;)

Seam Framework: Datang dari Event-Based Web Programming

Dunia web Java terguncang ketika Microsoft menawarkan .net framework-nya yang mengiming-imingi programmer dengan gaya event-based-nya. Halaman web tidak lagi dipandang sebagai halaman HTML yang mengirimkan request kepada server, tetapi sebagai desktop yang memiliki tombol yang bisa diklik dan memanggil method tertentu ketika sebuah komponen diberi suatu aksi. Lupakan request GET atau request POST, Anda hanya melihat komponen-komponen yang bisa diklik.

Tapestry adalah framework populer Java yang menggunakan gaya component-based ini. Kemudian muncul spesifikasi Java Server Faces yang bagi saya mirip dengan ASP.net. JSF segera populer karena didukung dan disosialisasikan oleh vendor-vendor raksasa macam Sun dan Oracle (dengan Oracle ADF-nya).

Jika Struts berangkat dari Java Server Pages (JSP), maka Seam berangkat dari JSF. Kalau Struts bicara masalah Action dan Form, maka Seam lebih banyak bicara tentang Managed Beans dan Annotations. Secara standar, Seam menyediakan semua hal secara lengkap. Di bagian model, Seam menggunakan implementasi Entity Beans milik EJB3 dengan Hibernate Annotations dan Java Persistance API (JPA). Di sisi View, Seam menggunakan JSF Facelets standar, RichFaces, dan Ajax4JSF. Controller ditangani oleh ia sendiri.

Seam-Gen

Tetapi saya tidak terlalu tertarik kalau Seam hanya menyediakan yang itu-itu saja. Just another suck frameworks, apalagi Seam terlalu tergantung dengan JBoss Application Server yang gendut. Namun demikian, satu hal yang membuat saya tertarik meliriknya adalah satu tool command line kecil bernama Seam-Gen. Tool ini sebenarnya hanyalah satu set prosedur yang berbasis Hibernate Tools yang melakukan code-generation seperti melakukan Reverse Enginner, mapping database ke objek, sekaligus membuatkan halaman-halaman CRUD dalam satu perintah. Jawaban atas impian saya di atas! Dan dengan bantuan JBoss Tools, sebuah plugin Eclipse, pekerjaan ini benar-benar menjadi satu klik saja!

Benar-benar fun! CRUD dan Validasi hanya dalam satu klik? Apakah saya berlebihan kalau saya mengatakan ini benar-benar menyenangkan? Anda harus coba ini.

Silakan kunjungi: Seam Framework untuk download Seam dan ikuti roadmap-nya di Getting Started with Seam.

Bagi Anda yang sama sekali belum pernah coba pemrograman Java EE, mungkin Anda agak kesulitan memahami Seam, jadi saya sarankan untuk memahami konsep-konsep berikut ini terlebih dahulu:

• Java Server Faces
• Object Relational Mapping dengan Hibernate
• Enterprise Java Bean 3
• Java Persistance API

PS: Am I writing in either Bahasa Indonesia or even English?

Di Balik Selubung Search Engine

Fotografi prei dulu. Ini panggilan jiwa saya yang notabene ada di ilmu Computer Science. Ceileh… )

Search engine, dalam disiplin ilmu komputer (Computer Science), masuk dalam kategori information retrieval. Ini adalah ilmu untuk mendapatkan informasi yang diperlukan dengan cepat di dalam bank data yang sangat besar. Ibaratnya seperti mencari jarum dalam tumpukan jerami. Batasan hasil yang didapatkan haruslah: cepat dan tepat. Seperti sebuah buku teks setebal 1000 halaman yang selalu memiliki indeks di bagian akhir halaman sangat membantu untuk mencari sebuah topik spesifik di dalam buku tersebut.

Pembuatan Indeks

Fase pertama dalam information retrieval adalah pembuatan indeks. Indeks, seperti namanya, adalah sebuah kumpulan kata-kata kunci yang disusun sedemikian rupa yang mudah dicari. Bayangkan kalau setumpuk tebal data tidak memiliki indeks. Pencarian informasi akan memakan waktu yang sangat lama karena setiap data harus dilihat satu per satu. Dengan adanya indeks, pencarian akan jauh lebih cepat karena setiap indeks langsung merujuk pada asal sumber.

Ada banyak macam algoritma yang digunakan untuk menyusun indeks dalam sebuah information retrieval. Salah satu contohnya adalah Stop Words untuk text retrieval. Atau jika merujuk Tugas Akhir saya ketika mendapatkan gelar S1, saya menggunakan algoritma histogram parameter fraktal sebuah citra (Lihat kategori Tugas Akhir-ku). Yap, riset saya waktu itu bukan pada ruang lingkup text retrieval, tetapi image retrieval. Pencarian gambar menggunakan gambar contoh. Gambar yang paling mirip dengan gambar contoh dikeluarkan. Kedengaran cerdas bukan? )

Apa itu Stop Words? Google, dalam bagian kecil sistem search engine-nya yang kompleks menggunakan algoritma Stop Words. Algoritma ini menganalisis suatu data teks, menyingkirkan kata-kata yang dianggap tidak penting dan menyisakan kata-kata penting untuk dijadikan indeks. Kata-kata tidak penting ini adalah kata-kata yang paling sering muncul dalam suatu tulisan. Contohnya seperti “di”, “ke”, “dari”, “yang”, “satu”, “dua”, dan seterusnya. Daftar kata-kata yang tidak penting inilah yang dinamakan Stop Words.

Pencarian Data dan Peringkat

Proses selanjutnya tentu saja adalah pencarian informasi terhadap sekian besar data. Karena telah dibuatkan indeks, maka sistem akan melakukan analisis terhadap indeks. Mencari kata-kata yang sesuai dengan apa yang dicari pengguna. Kemudian setiap data yang memiliki indeks yang sesuai ditampilkan kepada pengguna. Tampilan itu lengkap dengan rujukan ke tempat data aslinya untuk memudahkan jika pengguna ingin menampilkan data tersebut secara utuh.

Bagaimana urutan penampilannya? Sistem search engine wajib memiliki fasilitas pengurutan berdasarkan relevansinya. Data yang paling relevan dengan apa yang dicari harus ditampilkan di paling atas. Kemudian berturut-turut ditampilkan secara peringkat dari yang paling relevan hingga yang paling melenceng dari yang dicari.

Algoritma relevansi sendiri bisa sangat rumit. Yang paling sederhana adalah menghitung jumlah kemunculan indeks terhadap kata kunci pencarian. Semakin banyak sebuah indeks data mengandung kata kunci pencarian, semakin relevan dia.

Google memiliki algoritma relevansi yang sangat kompleks bernama Google Page Rank. Banyak faktor yang dipertimbangkan Google agar sebuah halaman muncul dalam halaman pertama pencarian, seperti misalnya jumlah link, kesesuaian dengan kata kunci, kesesuaian isi, dan masih banyak lagi bahkan termasuk kelakuan pengguna. Anda dan saya, meskipun mencari dengan kata kunci yang sama — katakanlah “gadis berjilbab” — akan mendapatkan hasil yang berbeda, tergantung kebiasaan kita dalam melakukan pencarian.

Saya sendiri dalam Tugas Akhir S1 saya menghitung relevansi ini dengan algoritma pengukuran jarak. Bukan hanya jarak tempuh saja yang memiliki perhitungan matematis, tetapi juga jarak kemiripan. Ada jarak kartesian (cartesian distance) dan jarak manhattan (manhattan distance). Keduanya memiliki rumus matematika yang cukup membuat kepala pusing ketika coba dituliskan dalam kode program.

Implementasi Pustaka

Secara praktis, implementasi algoritma information retrieval sudah banyak dikembangkan. Spesifik untuk text retrieval, Apache Lucene adalah pustaka (library) yang secara praktis menyediakan fasilitas untuk membuat sistem information retrieval berbasis teks. Disini telah disediakan berbagai Analyzer untuk mengolah tumpukan data menjadi indeks. Salah satunya adalah algoritma Stop Words yang sederhana. Hanya diperlukan daftar Stop Words dalam bahasa tertentu dan dimasukkan dalam Lucene, sebuah sistem information retrieval yang cukup canggih sudah bisa dibuat. Terima kasih Lucene!

Memperkenalkan: XML-RPC

XMLRPC adalah akronim dari eXtensible Markup Language – Remote Procedure Call. Sebuah spesifikasi XML yang menjelaskan mengenai mekanisme pemanggilan prosedur jarak jauh dengan menggunakan XML. Bisa dikatakan, XMLRPC adalah salah satu bentuk webservice yang disederhanakan dari standar yang konvensional. Dua sistem yang benar-benar terpisah dan berbeda platform serta lingkungan bisa saling berkomunikasi lewat sarana file XML.

Protokol komunikasi yang digunakan adalah protokol standar yang paling populer di dunia: HTTP. Request yang dikirim lewat HTTP harus menggunakan method POST. Prosedur yang akan dipanggil beserta parameternya dibungkus dalam file XML dalam spesifikasi XMLRPC. Demikian pula return value-nya, sebelum dikirim akan dibungkus dulu dalam bentuk XML dan ditransfer diatas lalu lintas protokol HTTP di internet.

Gambaran besar secara sederhana bisa dijelaskan dalam gambar di bawah ini:

Spesifikasi yang dibuat oleh tim XMLRPC sudah cukup lengkap, misalnya bagaimana cara mengirim parameter dan mengembalikan return value. Termasuk pula data type standar XMLRPC juga disertakan.

Implementasi spesifikasi XMLRPC telah diterapkan secara luas di berbagai lingkungan pemrograman. Di Java sendiri, tim dari Apache telah membuat library yang compliance dengan spesifikasi XMLRPC. Hal ini memudahkan kita untuk tidak perlu repot-repot berurusan di level rendah seperti pembuatan parser untuk mengolah data dari XML. Semua telah dibungkus dalam level yang lebih tinggi dalam bentuk class-class library. Misalnya, setiap objek java.util.Date akan  dikonversi menjadi tipe data standar XMLRPC secara otomatis. Dan banyak lagi kemudahan-kemudahan yang lainnya.

Saat ini, beberapa layanan populer telah mendukung XMLRPC. Yang paling mencolok tentu saja adalah layanan blogging. Kini setiap mesin blog saling berkomunikasi satu sama lain (trackback, pingback) dengan menggunakan standar XMLRPC. Dengan XMLRPC ini, beberapa layanan baru untuk mengelola blog di luar software standar muncul. Contohnya adalah WordPress API dan Blogger API. Kini kita bisa menulis posting blog dengan software berbasis desktop (Microsoft Word 2007 bisa melakukannya) tanpa harus terkoneksi dulu ke internet.

Akankah XMLRPC akan berkembang sebagai alternatif dari standar yang sudah ada macam SOAP,  UDDI, dan WSDL? Kita tunggu saja.

Tentang Konsep Inheritance, Overloading, dan Overriding

Ada trinitas suci dalam “agama” pemrograman berorientasi objek (OOP — Object Oriented Programming), yaitu Inheritance, Overloading (Polymorphism), dan Overriding. Tiga terminologi ini adalah roh OOP. Seorang programmer OOP paling tidak harus menguasai konsep ini, kalau tiga konsep ini belum dipegang, akan sulit menguasai bahasa OOP.

Pada artikel ini, saya mencoba menjelaskan tentang apa yang saya pahami mengenai tiga terminologi tersebut. Bagi yang belum pernah mencoba/mengenal bahasa OOP, saya sarankan membaca konsep dasar pemrograman OOP terlebih dahulu. Bagi yang sudah mahir mengenai OOP di C++, saya harus katakan bahwa bahasa OOP milik Java sangat sederhana. Java tidak mengenal konsep multiple inheritance atau konsep method virtualization (semua method di Java adalah virtual) dengan alasan penyederhanaan sehingga OOP Java tidak serumit OOP C++. Dan tentu saja, kalau ada konsep yang pemahaman saya ternyata salah, mohon kiranya saya diberi tahu, hehehe…

Silakan baca-baca atau download di sana.