kalau di PHP, CGI, Perl, yang di-cluster itu web server instancenya. kalau
kita bicara clustering di J2EE, kita bicara clustering service layer-nya
(yaitu spring container), karena biasanya clustering web server instance
dilakukan di level proxy (baik itu apache http, tomcat proxy, atau
proxy).
On Dec 26, 2007 8:34 AM, Joshua Jackson <[EMAIL PROTECTED]> wrote:
>
> On 12/26/07, Jecki Sumargo <[EMAIL PROTECTED]> wrote:
> > Jelas ada hubungannya. Source code yang bagus menandakan
> > arsitekturnya, desainnya bagus. Dengan desain yang bagus ini akan
> > meyakinkan user yang akan memakai fr
On 12/26/07, Jecki Sumargo <[EMAIL PROTECTED]> wrote:
> Jelas ada hubungannya. Source code yang bagus menandakan
> arsitekturnya, desainnya bagus. Dengan desain yang bagus ini akan
> meyakinkan user yang akan memakai framework tersebut. Dan juga kalau
> kita ketemu masalah / mau nambahin sesuatu ja
On Dec 18, 2007 5:18 PM, Joshua Jackson <[EMAIL PROTECTED]> wrote:
>
> On 12/18/07, Jecki Sumargo <[EMAIL PROTECTED]> wrote:
> > Bahhh.. g malah reluctant sama JBoss. G lebih percaya sama developer
> > Spring. Coba sekali-kali baca source code JBoss dan bandingkan dengan
> > source code Spring.
On Dec 19, 2007 2:09 PM, Endy Muhardin <[EMAIL PROTECTED]> wrote:
>
> On Dec 19, 2007 12:33 PM, Arif Rachim <[EMAIL PROTECTED]> wrote:
> > Mungkin balik lagi seperti kata mas endy, ini tergantung selera ...
> > ada banyak jalan menuju roma, hanya saja saya berfikir untuk menjari
> > jalan terefi
Mendingan tunggu EJB3.1 aja kalau memang alasannya gitu. Ini bakalan
masuk spec JEE6. Lebih simple lagi dibandingkan EJB3.0.
http://developers.sun.com/learning/javaoneonline/2007/pdf/TS-4247.pdf
Cheers,
On 12/21/07, Endy Muhardin <[EMAIL PROTECTED]> wrote:
> On Dec 19, 2007 2:32 PM, Joshua Jackso
On Dec 19, 2007 2:32 PM, Joshua Jackson <[EMAIL PROTECTED]> wrote:
> Terakhir itu kapan mas? Semenjak jaman EJB2.1 ? :-d
> Sekarang sih emang dah beda banget.
Ya bener ... jamannya EJB 2.
Gw udah lihat modelnya, sempat ngasi training pula di Jatis tentang
hal tersebut,
kalo gak salah akhir 2004.
hibernate emang kotor :P
ada AOP tuh, yang adalah ilmu untuk mengotor-ngotori. ya gak rif?
berani kotor itu bagus... hehe
On Dec 18, 2007 5:08 PM, Jecki Sumargo <[EMAIL PROTECTED]> wrote:
> On Dec 18, 2007 4:37 PM, Arif Rachim <[EMAIL
> PROTECTED]>
> wrote:
> > > Jelas-jelas cache ada hubungan
Maas maf, ngomong2 yang dibahas ini kalo aplikasinya web-based yah?
On Dec 18, 2007 4:54 PM, Endy Muhardin <[EMAIL PROTECTED]> wrote:
> On Dec 18, 2007 4:37 PM, Arif Rachim <[EMAIL
> PROTECTED]>
> wrote:
> > > Jelas-jelas cache ada hubungannya. Cache menjadi salah satu alternatif
> > > solusi
:D
On Dec 18, 2007 5:20 PM, Samuel Franklyn <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
>
>
> Arif Rachim wrote:
> >> Tapi ini dengan asumsi bahwa server itu reliable dan
> >> dalam kendali kita. Nah dalam kenyataannya kalau contextnya
> >> "shopping cart" dan bukan JavaEE maka "shopping cart"
> >> i
On 12/19/07, Endy Muhardin <[EMAIL PROTECTED]> wrote:
> Terakhir saya tau sih, ini medan tempur yang lumayan berdarah-darah
> tanpa hasil signifikan.
Terakhir itu kapan mas? Semenjak jaman EJB2.1 ? :-d
Sekarang sih emang dah beda banget.
> Sticky session, session propagation, state synchronizati
On Dec 19, 2007 12:33 PM, Arif Rachim <[EMAIL PROTECTED]> wrote:
> Mungkin balik lagi seperti kata mas endy, ini tergantung selera ...
> ada banyak jalan menuju roma, hanya saja saya berfikir untuk menjari
> jalan terefisien aja.
>
> Yes "We choose different battlefield to fight" :)
Sepertiny
> Kalau saya tidak salah tangkap, pendekatan seperti inilah yang mau
> diabstraksi sama SFSB.
> Bener gak mas Arif ??
> Sehingga tujuannya developer gak harus mikir lagi urusan replikasi
> HttpSession.
> Dan appserver bisa propagate dengan efisien.
Nahhh benar banget ... we are in the same pa
On Dec 18, 2007 5:30 PM, Arif Rachim <[EMAIL PROTECTED]> wrote:
> :) oke sekarang kita udah sepakat ya bahwa httpSession dan cache
> memang berbeda. Sebenernya gw aga rancu implementasi cache yang
> dimaksud dengan middle tier ini seperti apa. Kalau gw tidak salah
> mengerti quote statementnya
Joshua Jackson wrote:
> On 12/18/07, Samuel Franklyn <[EMAIL PROTECTED]> wrote:
>> Joshua Jackson wrote:
>> Salah. Source code bagus memungkinkan source code tersebut
>> dipelihara sendiri sama developer pemakai framework.
>> Ini penting mengingat kalau kita pakai framework open source
>> maka tang
On 12/18/07, Samuel Franklyn <[EMAIL PROTECTED]> wrote:
> Joshua Jackson wrote:
> Salah. Source code bagus memungkinkan source code tersebut
> dipelihara sendiri sama developer pemakai framework.
> Ini penting mengingat kalau kita pakai framework open source
> maka tanggung jawab sepenuhnya ada di
> Balik lagi ke kegunaan dari HttpSession yaitu untuk menyimpan state
> dari user. Tadi contoh yang lu kasih menyimpan semua state dari
> shopping cart ke HttpSession (full object graph). Alternatif lainnya
> yang disimpan hanya key yang bisa dipakai untuk retrieve data dari
> cache. Karena ca
Joshua Jackson wrote:
> On 12/18/07, Jecki Sumargo <[EMAIL PROTECTED]> wrote:
>> Bahhh.. g malah reluctant sama JBoss. G lebih percaya sama developer
>> Spring. Coba sekali-kali baca source code JBoss dan bandingkan dengan
>> source code Spring.
>
> Apa hubungannya source code bagus? Source code b
On Tue, 2007-12-18 at 17:52 +0800, Arif Rachim wrote:
> > saya rasa nggak pak, karna berfikir "reliability" itu sangat penting
> dan
> > jadi bargaining point buat implementasi suatu applikasi yang
> imbasnya ke
> > pengguna, bukan hanya sekedar seperti apa hebatnya technology yang
> dipakai.
>
>
On 12/18/07, Jecki Sumargo <[EMAIL PROTECTED]> wrote:
> Bahhh.. g malah reluctant sama JBoss. G lebih percaya sama developer
> Spring. Coba sekali-kali baca source code JBoss dan bandingkan dengan
> source code Spring.
Apa hubungannya source code bagus? Source code bagus gak nambahin
added value b
> Cache ... dalam kasus yang lain umumnya adalah object yang tidak
> dibuat atas nama klien, dia lebih bersifat buffer, atau bisa juga kita
> katakan pool. Setiap ada request dari user untuk object tertentu cache
> bisa membuffer sehingga tidak perlu lagi request sampai masuk kedalam
> database.
k
> Hubungannya gini.
> Untuk memaintain state/conversation, appserver perlu menyimpan data.
> Ada beberapa cara untuk menyimpan data ini:
> 1. di internal app server -> httpSession
> 2. di database
> 3. di client -> cookie
> 4. di 3rd-party cache
>
> Kalau kita bicara cache, memang mungkin r
On Dec 18, 2007 4:37 PM, Arif Rachim <[EMAIL PROTECTED]> wrote:
> > Jelas-jelas cache ada hubungannya. Cache menjadi salah satu alternatif
> > solusi selain HttpSession. Banyak library cache yang mendukung
> > distributed cache jadi ini harus dipertimbangkan sebagai alternatif
> > dari HttpSess
On 12/18/07, Endy Muhardin <[EMAIL PROTECTED]> wrote:
> On Dec 18, 2007 4:37 PM, Arif Rachim <[EMAIL PROTECTED]> wrote:
> > > Jelas-jelas cache ada hubungannya. Cache menjadi salah satu alternatif
> > > solusi selain HttpSession. Banyak library cache yang mendukung
> > > distributed cache jadi i
On 12/18/07, Arif Rachim <[EMAIL PROTECTED]> wrote:
> > > IMO cache itu tidak dapat digantikan, untuk kasus diatas tidak ada
> > > hubungannya. Saya mengerti maksud mas endy ... kita menitik beratkan
> > > di cache maksudnya kalau di request kita hanya menyimpan id saja, maka
> > > pada saat re
On Dec 18, 2007 4:37 PM, Arif Rachim <[EMAIL PROTECTED]> wrote:
> > Jelas-jelas cache ada hubungannya. Cache menjadi salah satu alternatif
> > solusi selain HttpSession. Banyak library cache yang mendukung
> > distributed cache jadi ini harus dipertimbangkan sebagai alternatif
> > dari HttpSess
> saya rasa nggak pak, karna berfikir "reliability" itu sangat penting dan
> jadi bargaining point buat implementasi suatu applikasi yang imbasnya ke
> pengguna, bukan hanya sekedar seperti apa hebatnya technology yang dipakai.
Saya berusaha menjelaskan dalam konteks java. Coba saya tanya ke kamu
> > IMO cache itu tidak dapat digantikan, untuk kasus diatas tidak ada
> > hubungannya. Saya mengerti maksud mas endy ... kita menitik beratkan
> > di cache maksudnya kalau di request kita hanya menyimpan id saja, maka
> > pada saat request tersebut diproses kita load object tersebut maka
> >
Jecki Sumargo wrote:
> On Dec 18, 2007 3:49 PM, Arif Rachim <[EMAIL PROTECTED]> wrote:
>>
>> IMO cache itu tidak dapat digantikan, untuk kasus diatas tidak ada
>> hubungannya. Saya mengerti maksud mas endy ... kita menitik beratkan
>> di cache maksudnya kalau di request kita hanya menyimpan id s
saya rasa nggak pak, karna berfikir "reliability" itu sangat penting dan
jadi bargaining point buat implementasi suatu applikasi yang imbasnya ke
pengguna, bukan hanya sekedar seperti apa hebatnya technology yang
dipakai.
Implementasi dalam konteks Java EE akan maksimal dengan kondisi dideploy
di
Arif Rachim wrote:
>> Tapi ini dengan asumsi bahwa server itu reliable dan
>> dalam kendali kita. Nah dalam kenyataannya kalau contextnya
>> "shopping cart" dan bukan JavaEE maka "shopping cart"
>> itu di hosting dan reliabilitas hosting tidak dalam kendali kita.
>> Itu lah sebabnya kenapa osC
On Dec 18, 2007 3:49 PM, Arif Rachim <[EMAIL PROTECTED]> wrote:
>
> > Beberapa orang, termasuk saya, memilih untuk menghindari medan tempur
> > appserver clustering, dan memilih 'bertarung' di external cache
> > (seperti memcached).
> >
> > IMO, pendekatan saya lebih sederhana, less magic, dan
> Tapi ini dengan asumsi bahwa server itu reliable dan
> dalam kendali kita. Nah dalam kenyataannya kalau contextnya
> "shopping cart" dan bukan JavaEE maka "shopping cart"
> itu di hosting dan reliabilitas hosting tidak dalam kendali kita.
> Itu lah sebabnya kenapa osCommerce simpan
> shoppi
Arif Rachim wrote:
>
> Terus kenapa kita tidak simpan saja kedalam database, salah satu
> alasannya karena menyimpan kedalam database akan overkill, shopping
> cart lifecyclenya pendek, jadi tidak efisien juga kalau harus disimpan
> kedalam database setiapkali user mengupdate shopping cart tsb :)
> Beberapa orang, termasuk saya, memilih untuk menghindari medan tempur
> appserver clustering, dan memilih 'bertarung' di external cache
> (seperti memcached).
>
> IMO, pendekatan saya lebih sederhana, less magic, dan lebih mudah
> didebug kalau ada apa2.
> Pindah appserver, no problem, kare
On 12/18/07, fachim <[EMAIL PROTECTED]> wrote:
>
> Sangat menarik diskusinya, walaupun masih terbatas pada pro dan contra pada
> komponen persistence, web services dan session bean (statefull ato stateless)
>
> Mungkin bagi saya dan teman2 yang baru mengenal component JEE, ada
> message-driven be
Sangat menarik diskusinya, walaupun masih terbatas pada pro dan contra
pada komponen persistence, web services dan session bean (statefull ato
stateless)
Mungkin bagi saya dan teman2 yang baru mengenal component JEE, ada
message-driven beans yang menggunakan JMS API.
kapan baiknya atau pada keada
On Dec 18, 2007 11:34 AM, Samuel Franklyn <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
>
> Arif Rachim wrote:
> >> Skenario diatas kan berasumsi bahwa kita pakai
> >> ORM dengan Spring. Sehingga yang disimpan dalam
> >> session adalah sebuah obyek user yang kompleks
> >> yang didalamnya tersimpan obyek
On Dec 18, 2007 9:55 AM, Joshua Jackson <[EMAIL PROTECTED]> wrote:
>
> Yah gw bilang kan mem-webservice-kan 'existing' business logic, dimana
> business logic ini sudah running dan gak boleh diutak-utik. Kalau mau
> contract first itu kalau project-nya masih baru di kickstart duonks.
> Tapi teu
Arif Rachim wrote:
>> Skenario diatas kan berasumsi bahwa kita pakai
>> ORM dengan Spring. Sehingga yang disimpan dalam
>> session adalah sebuah obyek user yang kompleks
>> yang didalamnya tersimpan obyek roles dan entah
>> obyek apalagi. Tapi kalau kita nggak pakai ORM
>> tapi cuma iBatis at
> Skenario diatas kan berasumsi bahwa kita pakai
> ORM dengan Spring. Sehingga yang disimpan dalam
> session adalah sebuah obyek user yang kompleks
> yang didalamnya tersimpan obyek roles dan entah
> obyek apalagi. Tapi kalau kita nggak pakai ORM
> tapi cuma iBatis atau JDBC maka apa yang kit
Sekarang masalahnya Remote object itu clusterable dengan mudah tidak? :))
Kalau tidak mendingan tetap jadi Local object aja :))
On 12/18/07, Bustanil Arifin <[EMAIL PROTECTED]> wrote:
>
> Yup, saya demen ama Spring karena dua hal di bawah ini. Kalau saya membangun
> aplikasi di atas spring saya m
Yup, saya demen ama Spring karena dua hal di bawah ini. Kalau saya membangun
aplikasi di atas spring saya merasa nyaman... :)
Saya paling takut kehilangan easy remoting-nya EJB 3 karena clientnya pake
SWT/JFace, tapi setelah baca-baca tutorialnya mas Endy saya jadi agak tenang
hehe...
> What you
> Gak juga.
> Remoting di Spring sederhana kok, gw udah pernah nulis:
> http://endy.artivisi.com/blog/java/remoting-dengan-spring/
>
> Satu method bisa diekspos melalui berbagai metode, hanya dengan
> menambah konfigurasi.
> Apanya lagi yang sulit dari itu?
Saya melihat memang konfigurasi re
On 12/18/07, Endy Muhardin <[EMAIL PROTECTED]> wrote:
> > What you will lose:
> > 1. Easy remoting and clustering configuration. Yeah yeah di Spring
> > juga bisa remoting dengan banyak framework seperti Jencks, Lingo,
> > Hessian, Burlap dsb, tapi gak semudah dengan EJB3. Dan Session bean
> >
Arif Rachim wrote:
> Spring itu berdiri diatas WebContainer,artinya untuk memantain session
> applikasi web app kita mengandalkan HttpSession untuk memantain
> session. Sedangkan keunggulan EJB - EJB container sekarang (bukan 2
> atau 1 tahun lalu) adalah di Session Clusteringnya.
>
> HttpSession
Pertanyaan yang saya maksud adalah no.1 mas Endy, di sisi persistence saya
tetap akan menggunakan JPA.
Maaf saya agak bingung dengan yang mas Endy maksud dengan "Kalo yang #1,
kerugiannya paling cuma kehilangan "transaction span
over remote methods .Di Spring, transaction gak bisa mencakup lebih d
Spring itu berdiri diatas WebContainer,artinya untuk memantain session
applikasi web app kita mengandalkan HttpSession untuk memantain
session. Sedangkan keunggulan EJB - EJB container sekarang (bukan 2
atau 1 tahun lalu) adalah di Session Clusteringnya.
HttpSession faillover di JEE, akan mengkopi
On Dec 18, 2007 8:49 AM, Joshua Jackson <[EMAIL PROTECTED]> wrote:
>
> Ini analisa ngawur gw berdasarkan pengalaman:
>
> What you will lose:
> 1. Easy remoting and clustering configuration. Yeah yeah di Spring
> juga bisa remoting dengan banyak framework seperti Jencks, Lingo,
> Hessian, Burlap
Ini analisa ngawur gw berdasarkan pengalaman:
What you will lose:
1. Easy remoting and clustering configuration. Yeah yeah di Spring
juga bisa remoting dengan banyak framework seperti Jencks, Lingo,
Hessian, Burlap dsb, tapi gak semudah dengan EJB3. Dan Session bean
cluster config masih lebih muda
On Dec 17, 2007 8:11 PM, Bustanil Arifin <[EMAIL PROTECTED]> wrote:
>
> Hi all,
> Saya mo tanya jika misalnya aplikasi saya yang menggunakan EJB 3, saya ganti
> menggunakan Spring framework. What will I lose and what will I gain?
>
Pertanyaannya agak rancu juga.
Apakah maksudnya:
1. Sekarang pakai
setahu saya untuk membuat instance ejb3 itu pakai spring
saya malah melihat ini barang complement kok
MVC - Spring -> JPA -> EJB3
It could be nothing to loose. as far as you define correctly the
persistence part of your application to Spring's persistance. EJB 3 adopt
its model.
but i dont understand, did u use a framework for web client/viewer part?
Spring MVC is known really gud on this.
regards,
fachim
> Hi all,
> Say
Hi all,
Saya mo tanya jika misalnya aplikasi saya yang menggunakan EJB 3, saya ganti
menggunakan Spring framework. What will I lose and what will I gain?
Thanks before.
54 matches
Mail list logo
