Hehe, alhamdulillah, seneng juga bisa nyobain nexenta alpha 5 walau hanya di vmware. Sempat kaget nggak nemu pkgadd, malah nemu apt-get. Dan pertama bingung juga waktu mau install package dasar -> GCC karena kalo install satu-satu dependancy nya kan nggak mungkin (bisa kriting). Akhirnya nemu repository yg harus ditambahin di /etc/apt/sources.list yaitu :
deb http://gnusolaris.org/apt-obsolete elatte-unstable main contrib non-free
deb-src http://gnusolaris.org/apt-obsolete elatte-unstable main contrib non-free
Terus, kepentok juga ketika menghadapi proxy kantor yg make ISA Server, dimana harus masukin username/password domain. Solusinya, make ini : http://ntlmaps.sourceforge.net/
Happy nexenta-ing ... :)
Sekarang mau coba me linux kan nih solaris, terus mau coba zoning di solaris, trus mau coba....WAAA IYAAAA, laptopnya mau dituker ama kantor beberapa hari lagi :( mosok install ulang rek :(( semoga vmware bisa dikopi doang .vmx nya, hopefully ....
originally posted 6/26/06
Sunday, June 3, 2007
ESB #1 (Revised)
Baru dapet chm tentang ESB(Enterprise Service Bus), karangan Dave Chappel dari mas Ari. Nih ulasan bab pertamanya :
Bab pertama ngejelasin tentang apa itu ESB(Enterprise Service Bus). Tahun-tahun sebelumnya kita mengenal istilah Service Oriented Architecture (SOA), Enterprise Application Integration (EAI), Business-to-Business (B2B), dan web services. Semua teknologi ini intinya sama, yaitu improvisasi hasil bisnis dari integrasi sistem-sistem yang telah ada sebelumnya. Sedangkan konsep ESB lebih kepada "..loosely coupled, highly distributed integration network that can scale beyond the limits of a hub-and-spoke EAI broker" . Jadi ketika bicara tentang ESB, maka didalamnya akan meliputi :
1. Messaging
2. Web Services
3. Transformasi data
4. Intelligent Routing yang mampu meneruskan message dari node satu ke yang lain tanpa melalui mekanisme broadcast.
Lebih lanjut dijelaskan dalam halaman berikutnya, tentang konsep-konsep apa saja yang telah diakomodir oleh generasi integrasi sebelumnya (SOA, EAI, B2B) sebagai berikut :
1.It must adapt to suit the needs of general-purpose integration projects across a variety of integration situations, large and small. Adaptability includes providing a durable architecture that is capable of withstanding evolutions in protocols, interface technology, and even process modeling trends.
2.It must link together applications that span the extended enterprise using a single unified approach and a common infrastructure.
3.It must extend beyond the boundaries of a single corporate IT data center and into automating partner relationships such as B2B and supply-chain scenarios.
4.It must have simplicity of design and low barriers to entry, enabling the everyday IT professional to become a self-empowered integration architect.
5.It must provide an SOA across the pervasive integration that enables integration architects to have a broad, abstract view of corporate application assets and automated business processes.
6.It needs the flexibility and ability to react to and meet the needs of changing business requirements and competitive pressures.
Gambar berikut menunjukkan lebih jelas tentang posisi ESB dan teknologi integrasi pendahulunya.
1. Traditional EAI Brokers.
Arsitektur EAI Broker seperti ini memiliki keunggulan dimana semua fungsi-fungsi yang disediakannya (termasuk manajemen routing dan bisnis rule) dapat diatur secara terpusat. Tetapi buku ini mengatakan bahwa arsitektur ini kurang cocok untuk level integrasi antar departemen atau unit bisnis yang berbeda. Lebih lanjut dijelaskan dalam bab 2 mengenai ini.
2. Application Server.
Application server dapat menghubungkan protokol-protokol yang berbeda dengan baik, namun hasilnya adalah sebuah aplikasi yang saling bergantung satu sama lain, yaitu antara integration logic dan application logic.
3. Message Oriented Middleware.
Menyediakan konektivitas yang baik, loosely coupled, dengan gaya asinkron, antar aplikasi. Hal ini memungkinkan beberapa aplikasi yang kecepatan responsenya berbeda, menjadi tidak saling menunggu satu sama lain. Namun, arsitektur MOM ini membutuhkan pemrograman low-level yang cukup lumayan, sehingga bisa jadi waktu development akan lama. Belum lagi masalah perbedaan fisik network yang menyebabkan beberapa infrastruktur MOM tertentu menjadi tidak bisa diandalkan.
4. Yang terakhir, ESB.
Disini, kita tidak lagi bicara tentang pemrograman, tetapi lebih ke arah bagaimana sebuah service di konfigurasi. Di ESB juga terdapat pemisahan arsitektur yang jelas antara business logic(proses bisnis aplikasi) dengan integration logic(routing dan transformasi format data).
Berikut karakteristik dari ESB :
Pervasiveness.
An ESB can be adapted to suit the needs of general-purpose integration projects across a variety of integration situations. It is capable of building out integration projects that can span an entire organization and its business partners.
Highly distributed, event-driven SOA.
Loosely coupled integration components can be deployed on the bus across widely distributed geographic deployment topologies, yet are accessible as shared services from anywhere on the bus.
Selective deployment of integration components.
Adapters, distributed data transformation services, and content-based routing services can be selectively deployed when and where they are needed, and can be independently scaled.
Security and reliability.
All components that communicate through the bus can take advantage of reliable messaging, transactional integrity, and secure authenticated communications.
Orchestration and process flow.
An ESB allows data to flow across any applications and services that are plugged into the bus, whether local or remote.
Autonomous yet federated managed environment.
An ESB supports local autonomy at a departmental and business unit level, and is still able to integrate in a larger managed integration environment.
Incremental adoption. An ESB can be used for small projects.
Each individual project can build into a much larger integration network, which can be remotely managed from anywhere on the bus.
XML support.
An ESB can take advantage of XML as its "native" datatype.
originally posted 7/4/06
Bab pertama ngejelasin tentang apa itu ESB(Enterprise Service Bus). Tahun-tahun sebelumnya kita mengenal istilah Service Oriented Architecture (SOA), Enterprise Application Integration (EAI), Business-to-Business (B2B), dan web services. Semua teknologi ini intinya sama, yaitu improvisasi hasil bisnis dari integrasi sistem-sistem yang telah ada sebelumnya. Sedangkan konsep ESB lebih kepada "..loosely coupled, highly distributed integration network that can scale beyond the limits of a hub-and-spoke EAI broker" . Jadi ketika bicara tentang ESB, maka didalamnya akan meliputi :
1. Messaging
2. Web Services
3. Transformasi data
4. Intelligent Routing yang mampu meneruskan message dari node satu ke yang lain tanpa melalui mekanisme broadcast.
Lebih lanjut dijelaskan dalam halaman berikutnya, tentang konsep-konsep apa saja yang telah diakomodir oleh generasi integrasi sebelumnya (SOA, EAI, B2B) sebagai berikut :
1.It must adapt to suit the needs of general-purpose integration projects across a variety of integration situations, large and small. Adaptability includes providing a durable architecture that is capable of withstanding evolutions in protocols, interface technology, and even process modeling trends.
2.It must link together applications that span the extended enterprise using a single unified approach and a common infrastructure.
3.It must extend beyond the boundaries of a single corporate IT data center and into automating partner relationships such as B2B and supply-chain scenarios.
4.It must have simplicity of design and low barriers to entry, enabling the everyday IT professional to become a self-empowered integration architect.
5.It must provide an SOA across the pervasive integration that enables integration architects to have a broad, abstract view of corporate application assets and automated business processes.
6.It needs the flexibility and ability to react to and meet the needs of changing business requirements and competitive pressures.
Gambar berikut menunjukkan lebih jelas tentang posisi ESB dan teknologi integrasi pendahulunya.
1. Traditional EAI Brokers.
Arsitektur EAI Broker seperti ini memiliki keunggulan dimana semua fungsi-fungsi yang disediakannya (termasuk manajemen routing dan bisnis rule) dapat diatur secara terpusat. Tetapi buku ini mengatakan bahwa arsitektur ini kurang cocok untuk level integrasi antar departemen atau unit bisnis yang berbeda. Lebih lanjut dijelaskan dalam bab 2 mengenai ini.
2. Application Server.
Application server dapat menghubungkan protokol-protokol yang berbeda dengan baik, namun hasilnya adalah sebuah aplikasi yang saling bergantung satu sama lain, yaitu antara integration logic dan application logic.
3. Message Oriented Middleware.
Menyediakan konektivitas yang baik, loosely coupled, dengan gaya asinkron, antar aplikasi. Hal ini memungkinkan beberapa aplikasi yang kecepatan responsenya berbeda, menjadi tidak saling menunggu satu sama lain. Namun, arsitektur MOM ini membutuhkan pemrograman low-level yang cukup lumayan, sehingga bisa jadi waktu development akan lama. Belum lagi masalah perbedaan fisik network yang menyebabkan beberapa infrastruktur MOM tertentu menjadi tidak bisa diandalkan.
4. Yang terakhir, ESB.
Disini, kita tidak lagi bicara tentang pemrograman, tetapi lebih ke arah bagaimana sebuah service di konfigurasi. Di ESB juga terdapat pemisahan arsitektur yang jelas antara business logic(proses bisnis aplikasi) dengan integration logic(routing dan transformasi format data).
Traditional Integration Broker Architecture
ESB Architecture
Berikut karakteristik dari ESB :
Pervasiveness.
An ESB can be adapted to suit the needs of general-purpose integration projects across a variety of integration situations. It is capable of building out integration projects that can span an entire organization and its business partners.
Highly distributed, event-driven SOA.
Loosely coupled integration components can be deployed on the bus across widely distributed geographic deployment topologies, yet are accessible as shared services from anywhere on the bus.
Selective deployment of integration components.
Adapters, distributed data transformation services, and content-based routing services can be selectively deployed when and where they are needed, and can be independently scaled.
Security and reliability.
All components that communicate through the bus can take advantage of reliable messaging, transactional integrity, and secure authenticated communications.
Orchestration and process flow.
An ESB allows data to flow across any applications and services that are plugged into the bus, whether local or remote.
Autonomous yet federated managed environment.
An ESB supports local autonomy at a departmental and business unit level, and is still able to integrate in a larger managed integration environment.
Incremental adoption. An ESB can be used for small projects.
Each individual project can build into a much larger integration network, which can be remotely managed from anywhere on the bus.
XML support.
An ESB can take advantage of XML as its "native" datatype.
originally posted 7/4/06
JBoss Vs BES
Finally, I know why I got this error :
javax.naming.NameNotFoundException: OracleDS not bound ...
Padahal di browse di Jboss console ada loh OracleDS. Udah kucoba ngeganti dengan java:OracleDS, java:/OracleDS, java:comp/env/OracleDS, semua nggak bisa....
Ternyata ada konfigurasi yg harus ditambahin di oracle-ds.xml, selama ini kalo lookup langsung OracleDS tuh, dia akan nyari di JVM yang sama. Pantesan, lha aku jalaninnya dengan debug di eclipse, jelas beda JVM ama JBoss nya. Setelah browsing, akhirnya nemu link yang bilang, bahwa ada konfigurasi yang harus ditambahin di oracle-ds.xml nya, yaitu ini :
false
Dengan begini, dia akan lookup JNDI name ke localhost:1099 dan dapet deh OracleDS. Happy ending deh...
Sekarang latihan bikin MDB di JBoss setelah sebelum nya sukses di BES. BES ? apa itu ? Borland Enterprise Server, J2EE nya Borland. Entah kenapa jatis partneran ma ni produk, kukira produk mereka hanya borland Delphi ama JBuilder, hehehe.
Sekilas tentang BES 6.5, nggak ada yg amazing yah, standar2 aja, masih J2EE 1.3 compliant. Ngga bisa dibandingin ama webmethods Integration Server karena emang beda. BES lebih ke J2EE App.Server, sedangkan webMethods lebih ke Middleware, EAI Broker. Tapi fitur yg menarik di JBoss (dan satu-satunya yg menarik buatku) adalah SonicMQ nya. Sebanding dengan webMethods Broker.
Semangat !!!
originally posted 7/4/06
javax.naming.NameNotFoundException: OracleDS not bound ...
Padahal di browse di Jboss console ada loh OracleDS. Udah kucoba ngeganti dengan java:OracleDS, java:/OracleDS, java:comp/env/OracleDS, semua nggak bisa....
Ternyata ada konfigurasi yg harus ditambahin di oracle-ds.xml, selama ini kalo lookup langsung OracleDS tuh, dia akan nyari di JVM yang sama. Pantesan, lha aku jalaninnya dengan debug di eclipse, jelas beda JVM ama JBoss nya. Setelah browsing, akhirnya nemu link yang bilang, bahwa ada konfigurasi yang harus ditambahin di oracle-ds.xml nya, yaitu ini :
Dengan begini, dia akan lookup JNDI name ke localhost:1099 dan dapet deh OracleDS. Happy ending deh...
Sekarang latihan bikin MDB di JBoss setelah sebelum nya sukses di BES. BES ? apa itu ? Borland Enterprise Server, J2EE nya Borland. Entah kenapa jatis partneran ma ni produk, kukira produk mereka hanya borland Delphi ama JBuilder, hehehe.
Sekilas tentang BES 6.5, nggak ada yg amazing yah, standar2 aja, masih J2EE 1.3 compliant. Ngga bisa dibandingin ama webmethods Integration Server karena emang beda. BES lebih ke J2EE App.Server, sedangkan webMethods lebih ke Middleware, EAI Broker. Tapi fitur yg menarik di JBoss (dan satu-satunya yg menarik buatku) adalah SonicMQ nya. Sebanding dengan webMethods Broker.
Semangat !!!
originally posted 7/4/06
Why Telco? *Narsis
Kalo ditanya, kenapa bahagia di industry telco. Simply karena di sektor ini kayaknya teknologi berkembang terus, hampir tiap waktu (terlepas dari..apakah teknologinya sekarang akan kepake ato nggak, e.g: 3G ). Alasan lain, karena kayaknya di sektor inilah, orang-orang IT bener-bener *dianggap*. Industri lainnya mungkin adalah perbankan sama perminyakan. Sedangkan di industri lainnya, orang IT ada yang hanya jadi IT Support, they deserve more than that! Mereka asset berharga perusahaan ... tentunya kalo perusahaan tahu gimana cara membuat mereka usefull.
Satu argumen dengan apa yg kumaksud *bener-bener dianggap*, artinya setelah mereka bikin aplikasi, jadi, mereka nggak ditinggalin gitu aja dan cuman buat support aplikasi itu. Jarang ada inovasi teknologi baru, kerjanya ya bikin Sistem Informasi. Kalo gitu ceritanya, gimana orang IT bisa berkembang, ya nggak ? Beda ama orang IT yg di 3 industri tadi, setelah aplikasi baru, jadi, mereka mungkin support, tapi mereka selalu dapet update teknologi terbaru. Mereka belajar banyak hal baru.
Bicara tentang industri telko, menurutku dibagi jadi 2 bagian besar, bagian *kasar*, dan bagian *lunak*. Bagian *kasar* (ada quote nya loh, gak kasar beneran) itu bagiannya temen2 elektro jurusan telkom, sama mungkin arus lemah. Disitu ada BTS, BSC, MSC, dan lain sebagainya. Kalo bagian *lunak* nih bagiannya orang informatika, sama mungkin orang elektro jurusan komputer. Disini ada yang namanya Billing, CRM, midleware, SMS Gateway, SMSC, USSD, Smart Card , HLR, dst.
Bicara tentang bagian lunak, Billing nih jantungnya perusahaan telko. Disini semua tagihan dicatat. Tiap kali suatu service/layanan selesai diberikan (misal : telepon, sms, gprs) akan dibuat suatu file bernama CDR, yang nantinya akan di rating oleh mesin billing, yang nantinya (kalo postpaid) akan ditagihkan tiap bulan. Rating ini dilakukan tiap hari, untuk tiap event, untuk semua pelanggan. Jadi nggak usah dibayangin betapa sibuknya mesin billing ini tiap hari.
Di front desk, ada customer care yang berhubungan langsung dengan pelanggan menggunakan aplikasi CRM. Aplikasi CRM ini biasanya dibangun diatas sebuah platfor terintegrasi. Kenapa begitu ? iya dong, customer care kan harus bisa njawab semua pertanyaan pelanggan yang berkaitan ama service yg di deliver. Contoh nyata nya, kita dateng ke gallery, trus nanya ... mbak, tagihan bulan lalu yg harus saya bayar berapa ya ? mbak, hp saya kok nggak bisa dihubungi sejak kemarin ya ? mbak saya mau aktivasi MMS gimana caranya ya ? mbak saya mau terminate nomer saya bisa nggak ? mbak, saya mau pindah dari prepaid ke postpaid, dst dsb. Dari gambaran diatas, bisa dilihat bahwa aplikasi CRM ini terhubung ke Billing, ke HLR (buat mengetahui kondisi service number anda di network), dan ke aplikasi2 proprietary lainnya. Ruwet ? yep, banget.
Dari situ, diperlukan sebuah, sesuatu, sesosok (halah..) mesin yang berfungsi mengintegrasikan semua sistem-sistem back end tadi. Aplikasi ini banyak disebut dengan istilah midleware. Salah satu implementasinya dalam bentuk ESB disini. Bayangannya, mesin ini punya konektor spesifik buat masing-masing back end system tadi (Service Engine) yang di ekspos dalam macam-macam bentuk protokol (Binding Components) seperti http, webservice, JMS, dst. Jadi misalnya, aplikasi CRM ingin mendapatkan data dari Billing, maka dia tidak harus connect langsung ke Billing menggunakan API API yg disediakan spesifik oleh billing, tapi dia bisa connect ke midleware menggunakan http, webservice, atau apapun yg disediakan oleh midleware. Tampak lebih rumit step nya ? nggak juga. Bayangin kalo sebuah operator memiliki beberapa sistem billing yang mempunyai API berbeda-beda, tentu sang CRM harus membuat konektor yg berbeda-beda pula. Bayangkan juga kalo yang harus memakai system billing tidak hanya aplikasi CRM, tentu untuk masing-masing aplikasi itu harus dibuat konektor ke billing. Arsitekturnya jadi bintang ruwet. Midleware menyederhanakan hal ini. Kita hanya harus membuat satu konektor untuk masing-masing system, kemudian konektor tadi di ekspose sebagai service yg bisa diakses melalui Binding Components. Untuk referensi bisa dibuka situs ini.
Lalu ada sms gateway. Contoh paling simple kegunaannya nih ketika registrasi kartu pra bayar. Kirim sms ke 4444, ketik daftar#bla bla bla. Contoh lain yaa kalo ada acara AFI atau Indonesian Idol gitu lah. Sms gateway ini sesuai namanya - gateway -, berfungsi sebagai penghubung dua hal atau lebih yang berbeda. Kalau kita kirim sms, akan diterima dan diteruskan oleh SMSC. Nah, kalau untuk kasus diatas, registrasi kartu pra bayar, logikanya kan ada proses insert ke database. Nah, proses insert ini bukan bagiannya SMSC karena dia cuma meneruskan sms saja. Oleh karena itu, dibuatlah gateway yang menghubungkan antara SMSC, sehingga ujungnya tuh sms bisa kecatet dan masuk ke database. Atau untuk kasus AFI/Indonesian Idol, dari SMSC akan meneruskan ke Content Provider, yang nyediain layanan ini.
Pengembangan lebih lanjut dari layanan yang disediakan SMSC ini adalah WAP PUSH dan MMS. Contoh layanan WAP PUSH ini mungkin adalah detikportal.com yang diakses via HP. Sedangkan untuk MMS mungkin penjelasannya begini, ketika kita dapet kiriman MMS, maka kita akan dapat sms yang berisi link yang bisa di klik untuk di download. Untuk referensi bisa buka disini.
Sekian dulu bloggingnya ... waktunya ishoma :D
logger.info("written @grhaXL, 9th floor" );
originally posted 7/12/06
Satu argumen dengan apa yg kumaksud *bener-bener dianggap*, artinya setelah mereka bikin aplikasi, jadi, mereka nggak ditinggalin gitu aja dan cuman buat support aplikasi itu. Jarang ada inovasi teknologi baru, kerjanya ya bikin Sistem Informasi. Kalo gitu ceritanya, gimana orang IT bisa berkembang, ya nggak ? Beda ama orang IT yg di 3 industri tadi, setelah aplikasi baru, jadi, mereka mungkin support, tapi mereka selalu dapet update teknologi terbaru. Mereka belajar banyak hal baru.
Bicara tentang industri telko, menurutku dibagi jadi 2 bagian besar, bagian *kasar*, dan bagian *lunak*. Bagian *kasar* (ada quote nya loh, gak kasar beneran) itu bagiannya temen2 elektro jurusan telkom, sama mungkin arus lemah. Disitu ada BTS, BSC, MSC, dan lain sebagainya. Kalo bagian *lunak* nih bagiannya orang informatika, sama mungkin orang elektro jurusan komputer. Disini ada yang namanya Billing, CRM, midleware, SMS Gateway, SMSC, USSD, Smart Card , HLR, dst.
Bicara tentang bagian lunak, Billing nih jantungnya perusahaan telko. Disini semua tagihan dicatat. Tiap kali suatu service/layanan selesai diberikan (misal : telepon, sms, gprs) akan dibuat suatu file bernama CDR, yang nantinya akan di rating oleh mesin billing, yang nantinya (kalo postpaid) akan ditagihkan tiap bulan. Rating ini dilakukan tiap hari, untuk tiap event, untuk semua pelanggan. Jadi nggak usah dibayangin betapa sibuknya mesin billing ini tiap hari.
Di front desk, ada customer care yang berhubungan langsung dengan pelanggan menggunakan aplikasi CRM. Aplikasi CRM ini biasanya dibangun diatas sebuah platfor terintegrasi. Kenapa begitu ? iya dong, customer care kan harus bisa njawab semua pertanyaan pelanggan yang berkaitan ama service yg di deliver. Contoh nyata nya, kita dateng ke gallery, trus nanya ... mbak, tagihan bulan lalu yg harus saya bayar berapa ya ? mbak, hp saya kok nggak bisa dihubungi sejak kemarin ya ? mbak saya mau aktivasi MMS gimana caranya ya ? mbak saya mau terminate nomer saya bisa nggak ? mbak, saya mau pindah dari prepaid ke postpaid, dst dsb. Dari gambaran diatas, bisa dilihat bahwa aplikasi CRM ini terhubung ke Billing, ke HLR (buat mengetahui kondisi service number anda di network), dan ke aplikasi2 proprietary lainnya. Ruwet ? yep, banget.
Dari situ, diperlukan sebuah, sesuatu, sesosok (halah..) mesin yang berfungsi mengintegrasikan semua sistem-sistem back end tadi. Aplikasi ini banyak disebut dengan istilah midleware. Salah satu implementasinya dalam bentuk ESB disini. Bayangannya, mesin ini punya konektor spesifik buat masing-masing back end system tadi (Service Engine) yang di ekspos dalam macam-macam bentuk protokol (Binding Components) seperti http, webservice, JMS, dst. Jadi misalnya, aplikasi CRM ingin mendapatkan data dari Billing, maka dia tidak harus connect langsung ke Billing menggunakan API API yg disediakan spesifik oleh billing, tapi dia bisa connect ke midleware menggunakan http, webservice, atau apapun yg disediakan oleh midleware. Tampak lebih rumit step nya ? nggak juga. Bayangin kalo sebuah operator memiliki beberapa sistem billing yang mempunyai API berbeda-beda, tentu sang CRM harus membuat konektor yg berbeda-beda pula. Bayangkan juga kalo yang harus memakai system billing tidak hanya aplikasi CRM, tentu untuk masing-masing aplikasi itu harus dibuat konektor ke billing. Arsitekturnya jadi bintang ruwet. Midleware menyederhanakan hal ini. Kita hanya harus membuat satu konektor untuk masing-masing system, kemudian konektor tadi di ekspose sebagai service yg bisa diakses melalui Binding Components. Untuk referensi bisa dibuka situs ini.
Lalu ada sms gateway. Contoh paling simple kegunaannya nih ketika registrasi kartu pra bayar. Kirim sms ke 4444, ketik daftar#bla bla bla. Contoh lain yaa kalo ada acara AFI atau Indonesian Idol gitu lah. Sms gateway ini sesuai namanya - gateway -, berfungsi sebagai penghubung dua hal atau lebih yang berbeda. Kalau kita kirim sms, akan diterima dan diteruskan oleh SMSC. Nah, kalau untuk kasus diatas, registrasi kartu pra bayar, logikanya kan ada proses insert ke database. Nah, proses insert ini bukan bagiannya SMSC karena dia cuma meneruskan sms saja. Oleh karena itu, dibuatlah gateway yang menghubungkan antara SMSC, sehingga ujungnya tuh sms bisa kecatet dan masuk ke database. Atau untuk kasus AFI/Indonesian Idol, dari SMSC akan meneruskan ke Content Provider, yang nyediain layanan ini.
Pengembangan lebih lanjut dari layanan yang disediakan SMSC ini adalah WAP PUSH dan MMS. Contoh layanan WAP PUSH ini mungkin adalah detikportal.com yang diakses via HP. Sedangkan untuk MMS mungkin penjelasannya begini, ketika kita dapet kiriman MMS, maka kita akan dapat sms yang berisi link yang bisa di klik untuk di download. Untuk referensi bisa buka disini.
Sekian dulu bloggingnya ... waktunya ishoma :D
logger.info("written @grhaXL, 9th floor" );
originally posted 7/12/06
My (Outdated) Mac OS.X 10.4.1
I think this picture will describe enough for us ...
Cool eh ? Sayang ini baru versi 10.4.1, yg terbaru versi 10.4.7
Cool eh ? Sayang ini baru versi 10.4.1, yg terbaru versi 10.4.7
Hongkong Survival day#1
Finally, got chance to go abroad outside Indonesia. This is my first journey, to Hongkong. We will be here in 4 days, 2 days training, and 2 days for having fun, he he he. Start from subuh at 04.00 AM to the airport. After clearing customs, we proceed to our plane. We ride China Airlines. As you might guess, all languages, writings, newspapers were in chinese. Dunno, maybe my face looks like a chinese guy. Everytime the stewardess served us, they always said Xiexie to me, but to my friend next to me, they said Thankyou :)).
There, we stay at ChaterHouse hotel. Small and warm place. It's weird in hongkong that all building were Ruko, so the first floor used for Shop/Store, and the next floor will be their homeplace as apartment.
Oya, We spent first day with visiting police station. My friend seems to have problem with his passport, so we go to police station and ask for a memo to gave to Immigration office. But finally, in night, somebody from airport called us, he has the passport, thank god :)
That's all, training start...
:)
tobe continued..
originally posted 2/15/07
There, we stay at ChaterHouse hotel. Small and warm place. It's weird in hongkong that all building were Ruko, so the first floor used for Shop/Store, and the next floor will be their homeplace as apartment.
Oya, We spent first day with visiting police station. My friend seems to have problem with his passport, so we go to police station and ask for a memo to gave to Immigration office. But finally, in night, somebody from airport called us, he has the passport, thank god :)
That's all, training start...
:)
tobe continued..
originally posted 2/15/07
Hongkong survival day #2-1
Eventually, we're lucky. My friend's passport were found. So, yesterday, after finishing the training, we go to the airport to get the passport back.We ride MTR train from Admiralty station to Hongkong central station. After that we changed to Airport Express train.It only took 30 minutes from downtown hongkong to reach airport.That fast ? yep.
Ok, the instructor are coming, the training will be start any minutes, I'll stop the blogging and continue later...
# the beauty of java, and the beast of garbage collecting #
originally posted 2/16/07
Ok, the instructor are coming, the training will be start any minutes, I'll stop the blogging and continue later...
# the beauty of java, and the beast of garbage collecting #
originally posted 2/16/07
Hongkong survival day #2-2
Hongkong is a nice city. I love the mass transportation railway,it's so clean, and of course, definitely fast. Everything is well organized here. I rarely seen any traffic jam in here although the street is not as wide as in Indonesia. Public transportation leave and arrive in time. In this case, who needs private vehicle ?
The training was great too. I have a lot question about tuning that answered here, especially in jvm tuning.
Btw, you can see my photo here :
http://picasaweb.google.com/lintang.jp/HongkongSurvival
That's for now, catch up with you later.. :)
originally posted 2/16/07
The training was great too. I have a lot question about tuning that answered here, especially in jvm tuning.
Btw, you can see my photo here :
http://picasaweb.google.com/lintang.jp/HongkongSurvival
That's for now, catch up with you later.. :)
originally posted 2/16/07
Hongkong International Airport
It's good to have your laptop travels with you. Like this, in airport, we dont have to be boring while we wait for the plane. Fast connection, provided by PCCW, one of Hongkong's telco operator. Thankyou PCCW.
First, open YM! messenger, and then open up my office mail....
Tadaaa, next assignment, 1. MiTV Malaysia on Monday..(WTF!) 2. STC Saudi Telecom, is this for real ????
Ok, the plane is boarding, we should get to the plane...
BTW, the picture from our journey will be uploaded soon. For yesterday's photo, you can see it here :
http://picasaweb.google.com/lintang.jp
originally posted 2/17/07
First, open YM! messenger, and then open up my office mail....
Tadaaa, next assignment, 1. MiTV Malaysia on Monday..(WTF!) 2. STC Saudi Telecom, is this for real ????
Ok, the plane is boarding, we should get to the plane...
BTW, the picture from our journey will be uploaded soon. For yesterday's photo, you can see it here :
http://picasaweb.google.com/lintang.jp
originally posted 2/17/07
Tukang jual pisang goreng
Yesterday is my 12th day in Malaysia. My company has a join project with ECM for our client, Mi3G. Yesterday, we went to Subang HiTech to install the production server.When break time, we went to street corner to find some snack, and there we met a lady who sell pisang goreng and another gorengan. She's from Indonesia. She'd been here for 16 year, what a quite long story. Well, that's not the part that amaze me. From just selling pisang goreng, she can pay her working permit every 6 month for about 2000RM. First time she created the working permit, she must pay around 4000RM. What a number. Then suddenly I realized that, hey, Allah AlMighty is the most fair judge. Everybody that worked hard and always wish for Allah's bless and ridho should have it's own destiny.
Ok, keep fight, the solaris machine and the lucene are waiting ...
Bismillah.
originally posted 4/5/07
Ok, keep fight, the solaris machine and the lucene are waiting ...
Bismillah.
originally posted 4/5/07
Solaris, SNMP, and OpenNMS
These day, I explore about SNMP. After wikipedia-ing in here, I try to install one of the recomended software called OpenNMS. After tried the live demo, it looks cool. So I decided to download it in here.
I followed all the installation step guide from here. I also need to download and install the pre requisites package such as rrdtool, and the postgresql. Fortunately, blastwave.org has great tools called pkg-get, yeap, sounds familiar with you Debian users ? I also thought that only Nexenta OS has this such-thing tools, but now, all solaris distro can use this tools I guess, well, at least I tried that one and it works for Solaris in both Sparc and Intel machine.
Ok, back to the tools. If we followed the step exactly, and goes to this step : install -dis, I got an error said that fail to load the iplike.so because libgcc_so.1 not found. That's some problem I usually got on linux box. If this is linux box, I just have to locate it, insert the path to /etc/ld.so.conf, and run the /sbin/ldconfig as root. But this is solaris box, cant do that, so, after googling, I found the crle command. I tried that to point the location for shared object files. Still no works. Howcome ? Dont ask me, it just doesnt work:p, So...again, googling, and found same problem in here. So the problem will be solved by just copying the .so files to /usr/lib ? And, it works. This is weird, I alredy put the /usr/lib within the crle command like this :
Ah, no idea, so I run the install -dis again, and this time it works.....
Next, playing around with OpenNMS and try to setup the weblogic snmp agent to send trap message to the OpenNMS poller. We'll see....
originally posted 4/11/07
I followed all the installation step guide from here. I also need to download and install the pre requisites package such as rrdtool, and the postgresql. Fortunately, blastwave.org has great tools called pkg-get, yeap, sounds familiar with you Debian users ? I also thought that only Nexenta OS has this such-thing tools, but now, all solaris distro can use this tools I guess, well, at least I tried that one and it works for Solaris in both Sparc and Intel machine.
Ok, back to the tools. If we followed the step exactly, and goes to this step : install -dis, I got an error said that fail to load the iplike.so because libgcc_so.1 not found. That's some problem I usually got on linux box. If this is linux box, I just have to locate it, insert the path to /etc/ld.so.conf, and run the /sbin/ldconfig as root. But this is solaris box, cant do that, so, after googling, I found the crle command. I tried that to point the location for shared object files. Still no works. Howcome ? Dont ask me, it just doesnt work:p, So...again, googling, and found same problem in here. So the problem will be solved by just copying the .so files to /usr/lib ? And, it works. This is weird, I alredy put the /usr/lib within the crle command like this :
-bash-3.00# crle -l /usr/local/lib:/usr/sfw/lib:/lib:/usr/lib/:/opt/opennms/lib:/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/
Ah, no idea, so I run the install -dis again, and this time it works.....
Next, playing around with OpenNMS and try to setup the weblogic snmp agent to send trap message to the OpenNMS poller. We'll see....
originally posted 4/11/07
Webservices with spring
These few days, I had a task to create a webservice client. Sounds interesting and challenging, because usually if we depends on weblogic's control, we can make any webservices client much much easier, just a few click, and tadaaa. The problem is, the webservice client will become stand alone module, so, I can't use any java controls since those controls will be managed by weblogic container during runtime.
Then I turn to find another simple and fast way to create webservice client. But, before that of course, since the remote system is not ready yet, I have to create some dummy web service first. Weblogic 9.2 having strange behaviour. First, we create webservice project from the Eclipse-based-IDE. After that, we generate the wsdl files. But, dont ever try to validate it :D because it will fail. Just pass and use those webservice to create weblogic client. That's strange, fail to validate, but it works :D
Ok, dont waste time, since I already had the webservice simulator works no matter how :p I began to create the webservice client. Coding from scratch ? no, it's painful, and I need to do it fast. I turn out to spring and axis which offers it's integration. This is my bean config sample :
[code]
org.apache.axis.client.ServiceFactory
http://localhost:7001/AggregatedInfoFeederSimulator/AggregatedInfo?WSDL
http://com/ericsson/aggregateinfo/sub/services
AggregatedInfoService
AggregatedInfoSoapPort
com.ericsson.mi3g.sub.aggregatedinfo.wsclient.RemoteInfoPortIntf
com.ericsson.mi3g.sub.aggregatedinfo.wsclient.RemoteInfoServiceIntf
[/code]
I'm using AggregatedInfoJaxRpcProxyFactoryBean, this is a class that extends JaxRpcPortProxyFactoryBean. We need to extend it to override the postProcessJaxRpcService(Service service) method that will be used to register which deserializer would be used to object that I pull from webservice. First time I try to run, the method is not being called at all, I'm curious. But after googling, I found out that we need to import the right class for the arguments. It should be javax.xml.rpc.encoding.Service;
Ok, the webservice client is done, now it's time to develop the database persistence part. I'm using Ibatis. Ibatis is cool, and I prefer this to hibernate if we need to do the complex query. In telco apps, there are no such simple query, right ? also, we need to be ready if someday the query changed, new field added, depends on requirement.
The database persistence done. Now, create the ant script to run this module, since I had lots of CLASSPATH to include. I can't put it all in bash script and change all the path when it's moved out to production. So, this is my ant script :
I also add quartz, since this module will run daily. Quartz is a enterprise scheduler written in java. Here's my configuration :
run
5000
172800000
And that's it, I'm done.
logger.info("from cyberjava with love....");
Originally posted 4/19/07.
Then I turn to find another simple and fast way to create webservice client. But, before that of course, since the remote system is not ready yet, I have to create some dummy web service first. Weblogic 9.2 having strange behaviour. First, we create webservice project from the Eclipse-based-IDE. After that, we generate the wsdl files. But, dont ever try to validate it :D because it will fail. Just pass and use those webservice to create weblogic client. That's strange, fail to validate, but it works :D
Ok, dont waste time, since I already had the webservice simulator works no matter how :p I began to create the webservice client. Coding from scratch ? no, it's painful, and I need to do it fast. I turn out to spring and axis which offers it's integration. This is my bean config sample :
[code]
[/code]
I'm using AggregatedInfoJaxRpcProxyFactoryBean, this is a class that extends JaxRpcPortProxyFactoryBean. We need to extend it to override the postProcessJaxRpcService(Service service) method that will be used to register which deserializer would be used to object that I pull from webservice. First time I try to run, the method is not being called at all, I'm curious. But after googling, I found out that we need to import the right class for the arguments. It should be javax.xml.rpc.encoding.Service;
Ok, the webservice client is done, now it's time to develop the database persistence part. I'm using Ibatis. Ibatis is cool, and I prefer this to hibernate if we need to do the complex query. In telco apps, there are no such simple query, right ? also, we need to be ready if someday the query changed, new field added, depends on requirement.
The database persistence done. Now, create the ant script to run this module, since I had lots of CLASSPATH to include. I can't put it all in bash script and change all the path when it's moved out to production. So, this is my ant script :
I also add quartz, since this module will run daily. Quartz is a enterprise scheduler written in java. Here's my configuration :
And that's it, I'm done.
logger.info("from cyberjava with love....");
Originally posted 4/19/07.
Subscribe to:
Posts (Atom)
