Daily log menggunakan Log4J

Jika anda menggunakan Log4J andan menginginkan log file selalu berganti setiap hari, maka ada beberapa solusi yang bisa digunakan.

Pertama, menggunakan class org.apache.log4j.DailyRollingFileAppender sebagai appender. Class tersebut telah ada dalam library Log4J, jadi kita bisa langsung menggunakannya.

Atau menggunakan solusi dari http://minaret.biz/tips/datedFileAppender.html

Kedua solusi tersebut berbeda, jadi anda harus memilih mana yang paling sesuai dengan kebutuhan.

Kirim SMS menggunakan MMAP.

Bisnis content untuk telepon selular di Indonesia saat ini sangat besar. Hal ini 
membuat perusahaan content provider semakin banyak tumbuh. Perusahaan content 
provider bekerja sama dengan operator selular untuk dapat menjakau konsumennya. Di 
Indonesia protokol yang digunakan oleh content provider untuk menerima atau 
mengirimkan SMS kebanyakan dibuat sendiri oleh operator dan tidak standar. 


Operator-operator biasanya menggunakan protokol sendiri dengan alasan kesederhanaan 
dan kemudahan. Operator yang menggunakan protokol standar untuk menerima dan mengirim 
SMS biasanya menggunakan protokol SMPP. Artikel ini membahas secara singkat tentang 
protokol MMAP/SMAP yang merupakan alternatif protokol untuk menerima atau mengirim 
SMS antar operator dan content provider.

-= Definisi =-

MMAP (Mobile Messaging Access Protocol) mendefinisikan seatu cara untuk melakukan 
pertukaran pesan bergerak (mobile message) menggunakan SOAP. MMAP hanya 
mendefinisikan bagain bagaimana koneksi antara dua entitas dan suatu mobile message 
dipertukarkan, oleh karenanya MMAP disebut SOAP access framework. MMAP dapat 
digunakan untuk melakukan pertukan data XML yang anda buat sendiri, tetapi biasanya 
MMAP digunakan sebagai pembungkus protokol SMAP. Format MMAP mengikuti standar SOAP 
1.2 dan biasanya menggunakan HTTP sebagai transport protokolnya. MMAP menggunakan 
tidak menggunakan model SOAP RPC tetapi menggunakan SOAP messaging model (document 
model).


-= SMAP =-

SMAP adalah suatu set XML elemen untuk mengirimkan, menerimana dam me-manage suatu 
pesan singkat (SMS). SMAP hanya mendefinikan suatu set XML dokumen (elemen) tapi 
tidak mendefinisikan bagaimana XML dokumen tersebut dipertukarkan. SMAP dapat 
dimasukan (embed) dalam MMAP sehingga menjadi protokol yang lengkap untuk pertukaran 
data SMS.

-= Menggapa menggunakan MMAP/SMAP? =-

Dibandingkan dengan protokol yang dibuat sendiri (proprietary protocol), MMAP 
merupakan standar terbuka sehingga memudahkan untuk dikuti semua operator dan content 
provider. 

Dibandingkan SMPP yang merupakan binary protokol, MMAP lebih mudah dipelajari dan 
dibuat implementasinya karena MMAP berbasiskan SOAP (teks). Hal ini juga membuat MMAP 
mudah di-debug.

-= Alasan untuk belum menggunakan MMAP? =-

Dibanding proprietary protocol, tentu saja MMAP/SMAP lebih lengkap dan lebih rumit 
untuk diimplementasikan. Selain itu, library untuk MMAP/SMAP yang gratis sejauh ini 
belum ada. Hal ini berbeda dengan SMPP, library untuk SMPP yang gratis banyak 
terdapat di internet sehingga akan memudahkan developer untuk menggunakan protokol 
SMPP.


-= Penggunaan MMAP/SMAP =-

Ilustrasi penggunakan MMAP dan SMAP dapat dilihat pada gambar dibawah ini.

 -------------------------------
| ,---------.      ,---------.  |
| | Message |      |         |  |            ,----------.
| | center  |<---->| SMS     |  |  MMAP/SMAP |          |
| | (SMSC)  |      | Gateway |  |<---------->| Aplikasi |
| `---------'      | Function|  |            |          |
|                  |         |  |            `----------'
|                  `---------'  |
|  Mobile message service       |
 -------------------------------

- Mobile center adalah elemen yang bertanggung jawab untuk meneruskan pesan ke tujuan 
misalnya nomor telepon selular seseorang.

- SMS gateway function adalah elemen yang memberikan layanan koneksi terhadap 
aplikasi atau elemen lain yang akan menggirimkan pesan. SMS gateway function tersebut 
bisa jadi telah ada dalam message center (SMSC) sehingga bukan merupakan elemen 
terpisah dari message center.

- Aplikasi merupakan elemen yang membutuhkan layanan untuk dapat mengirim atau 
menerima pesan. Aplikasi pada diagram diatas biasanya adalah aplikasi eksternal yang 
dibuat oleh rekanan dari operator misalnya content provider. Karena MMAP/SMAP 
merupakan standar terbuka dan gratis, content provider dapat dengan mudah 
menggunakannya untuk mengirimkan atau menerima pesan (content) kepada pelanggannya.

-= Struktur MMAP =-

MMAP memiliki 2 bagian yaitu:

1. MMAP header
MMAP header berisi informasi application context misalnya, session, kontrol akses 
(username dan password), billing, dan parameter-parameter lain yang bisa ditambahan. 
MMAP header berada pada SOAP header. Contoh MMAP header:

       <MMAP:MMAPHeader soap:mustUnderstand="1"
             xmlns:MMAP="http://www.smsforum.net/schemas/mmap/v1.0"
             xsi:schemaLocation="http://www.smsforum.net/schemas/mmap/v1.0
             http://www.smsforum.net/schemas/mmap/v1.0/mmap.xsd">
           <MMAP:ApplicationContext bodyType="Request" sourceOperationReference="123"/>
      <MMAP:AccessControl>
          <MMAP:ApplicationIdentity>testApp</mmap:ApplicationIdentity>
          <MMAP:Authentication>
              <MMAP:Password>secret</mmap:Password>
          </MMAP:Authentication>
      </MMAP:AccessControl>           
           <MMAP:ServiceContext serviceName="test"/>
      </MMAP:MMAPHeader>

2. Request/response MMAP data.
MMAP data berada pada SOAP body yang membawa informasi standar untuk operasi request 
dan response.

Fungsi MMAP sebagai access framework yang hanya menspesifikasikan operasi untuk 
me-maintain koneksi atau session saja, tergambar dari semua XML data elemen yang 
dimilikinya berikut ini:

BindRequest,
BindResponse/BindBackResponse,
BindBack request,
UnbindRequest,
UnbindResponse,
BatchRequest, 
BatchResponse,
BatchResult request,
EnquireLink request,
EnquireLinkResponse,
SuccessResponse,
ErrorResponse

Dibawah ini adalah contoh suatu SOAP message yang menunjukan tempat bagian MMAP 
berada:

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.w3.org/2003/05/soap-envelope
    http://www.w3.org/2003/05/soap-envelope">
    <soap:Header>
       <!-- MMAP header disini -->
    </soap:Header>
    <soap:Body>
       <!- MMAP data element disini -->
  </soap:Body>
</soap:Envelope>

-= Mode Operasional MMAP =-

Ada 4 mode operasional hubungan antar aplikasi dengan message service pada MMAP, 
yaitu:
 
1. Mode Immediate.
Pada mode ini aplikasi tidak menyimpan session untuk koneksifitas dengan mobile 
message service. Mobile message service hanya mengirimkan respon hanya jika diminta. 
Mode ini dapat digunakan untuk mengirimkan pesan saja.  Pesan berada di SOAP body 
element dan operasi MMAP tidak diperlukan pada mode ini.

2. Mode client-session.
Pada mode ini aplikasi menyimpan (maintain) session dengan message service dengan 
cara mengirimkan bind request. Setiap SOAP message yang kirim berisi sebuah 
application context yang mengidentidikasikan session yang dimiliki client.

Proses ini diawali dengan client menggirimkan BindRequest ke message service. Pada 
element BindRequest, sessionType parameter pada elemen SessionControl berisi 
"client". Message service meresponse dengan membawa informasi session ID pada MMAP 
header dan elemen BindResponse pada SOAP body.

Setelah melakukan proses bind, maka client dapat melakukan pengiriman pesan. Mode ini 
diakhiri client dengan mengirimkan UnbindRequest ke message service dan message 
service akan mengirimkan UnbindResponse pada client.

3. Mode Peer-to-peer
Pada mode ini, aplikasi dan message service melakkan session dua arah (bi-directional 
session) sehingga komunikasi dapat dilakukan secara asynchronous. Message service 
akan memberikan respon segera setelah menerima pesan dari client. Respon tersebut 
hanya mengindikasikan bahwa message service telah menerima pesan. Setelah pesan 
diproses makan message service akan mengirimkan respon lagi kepada client.

Proses ini diawali dengan client menggirimkan BindRequest ke message service. Berbeda 
dengan mode client-session, pada mode ini sessionType parameter berisi "peer". 
Kemudian message service akan meresponse dengan BindResponse dan informasi session IF 
pada MMAP header. Selain merespon BindRequest, message service dengan segera juga 
akan mengirimkan BindBackRequest ke client. Client atau aplikasi akan merespon 
BindBackRequest dengan BindBackResponse dan menginformasikan session ID pada MMAP 
header.

Mode ini diakhiri dengan pengiriman UnbindRequest dari client ke message service dan 
sebaliknya.

4. Mode batch
Pada mode ini, message service menerimana satu set MMAP request untuk diproses.

Aplikasi mengirimkan BatchRequest ke message service dan direspon dengan BatchReponse 
yang menunjukkan request telah diterima. Kemudian message service akan memproses 
setiap operasi yang ada dalam batch request. Setelah selesai semua operasi, message 
service akan mengirimkan BatchResult request yang berisi status hasil tiap-tiap 
proses. Client menerima BatchResult result dan meresnponse dengan SuccessResponse.

-= Contoh =-

Berikut ini adalah contoh pesan MMAP/SMAP lengkap untuk mengirimkan SMS menggunakan 
mode immediate:

 <?xml version="1.0" encoding="UTF-8"?>
 <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.w3.org/2003/05/soap-envelope
   http://www.w3.org/2003/05/soap-envelope">
  <soap:Header>
   <MMAP:MMAPHeader soap:mustUnderstand="1"
     xmlns:MMAP="http://www.smsforum.net/schemas/mmap/v1.0"
     xsi:schemaLocation="http://www.smsforum.net/schemas/mmap/v1.0
     http://www.smsforum.net/schemas/mmap/v1.0/mmap.xsd">
    <MMAP:ApplicationContext bodyType="Request" sourceOperationReference="123"/>
    <MMAP:ServiceContext serviceName="test"/>
   </MMAP:MMAPHeader>
  </soap:Header>
  <soap:Body>
   <smap:SubmitRequest xmlns:smap="http://www.smsforum.net/schemas/smap/v1.0"
     xsi:schemaLocation="http://www.smsforum.net/schemas/smap/v1.0
     http://www.smsforum.net/schemas/smap/v1.0/smap.xsd">
    <smap:ShortMessage>
     <smap:Header>
      <smap:Destination>
       <smap:Number>+12345679</smap:Number>
      </smap:Destination>
     </smap:Header>
     <smap:Body>
      <smap:Text>Hello world</smap:Text>
     </smap:Body>
    </smap:ShortMessage>
   </smap:SubmitRequest>
  </soap:Body>
 </soap:Envelope>

-= Penutup =-

Penjelasan yang lebih detail tentang MMAP dapat dibaca pada dokumen spesifikasinya 
yang dapat di download dari:

    http://smsforum.net/doc/download.php?id=smppv34 (versi 3.4)
    http://smsforum.net/doc/download.php?id=smppv50 (versi 5.0)

Untuk implementasi MMAP/SMAP, situs tersebut juga menyediakan file XML schema untuk 
MMAP maupun SMAP yang dapat didownload secara terpisah.

Format file presentasi pada MMS

Beberapa handphone saat ini sudah memiliki fitus pembuatan presentasi sederhana. Presentasi tersebut dapat berisi teks, gambar maupun suara dan kemudian dapat dikirimkan ke handphone lain menggunakan MMS (Multimedia Messaging Service).

Teknologi presentasi pada MMS merupakan standard yang dibuat oleh OMA (Open Mobile Alliance). Teknologi ini menggunakan SIML (dibaca seperti kata smile) yaitu sepesifikasi (rekomendasi) dari W3C.

SMIL adalah singkatan Synchronized Multimedia Integration Language, dari namanya kita tahu teknologi ini menyatukan beberapa atau banyak multimedia resource.Format SMIL seperti HTML, merupakan suatu file teks dengan link yang merujuk ke suatu sumber (resource) tertentu. Resource tersebut bisa teks file, audio, gambar maupun video. Tentu saja untuk mepresentasikan suatu file SMIL dibutuhkan program (client) yang dapat membaca dan memproses file tersebut. Pada komputer destop, program seperti RealPlayer merupakan salah satu contoh SMIL client.

SIML yang digunakan pada MMS adalah subset dari versi asli SMIL karena terbatasnya kapabilitas dari suatu handphone atau mobile device. Oleh karena itu kita hanya bisa membuat presentasi yang sederhana pada handphone.

Contoh suatu file SIML:

<smil>
<body>
<par dur="10000ms">
<text src="deskripsi.txt"></text>
<audio src="deskripsi.rm"></audio>
<img src="deskripsi.jpg"></img>
</par>
</body>
</smil>
</code>

Akses CVS dengan SSH tunneling

Dalam tulisan ini saya akan menjelaskan bagaimana menggunakan koneksi SSH untuk mengakses repository CVS dengan menggunakan CVS client. Tulisan ini berdasarkan pengalaman yang telah saya lakukan. Mesin untuk CVS server yang saya gunakan adalah Linux dan mesin yang saya gunakan sebagai client adalah Windows.

Pertama saya install CVS server di mesin Linux kemudian membuat repository. Kemudian setup cvs pserver yaitu membuat configurasi xinetd untuk membuka service untuk cvspserver.

Dengan menggunakan PuTTYgen saya membuat public key dan private key. Dari program tersebut saya dapatkan text untuk dimasukan ke file authorized_key di server, seperti ini:

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIBMFXliQrC16kZwFH1YOl/n3leI5aK13gFYiPFKFSBCFikNzJL5Su9PrJB0fJ7ZgSHKc/2
s+tWaXvfS6yWsGTQ81T49YidfQu/M14QgHTvpe23h8NaBRr+HuxDil0euUnolOcFchXraS5APe+yrqNIKSotGAxpfyPDpXTAZsAgdhQ== 
rsa-key-20061115

dan sebuah file yang disave bernama cvsadmin_private_key.ppk

Di server Linux saya dimana CVS diinstall, saya buat user cvsadmin kemudian pada home direktori user cvsadmin saya buat direktori .ssh/ kemdian di direktory tersebut saya but file authorized_key dengan isi seperti contoh diatas.

Kemudian saya buat kofigurasi untuk SSH daemon (sshd) di /etc/ssh dengan cara mengkopi konfigurasi yang sudah ada kemudian memodifikasinya. File konfigurasi yang baru ini saya beri nama sshd_config_ext.

Bagian penting dari isi file configurasi tersebut (tidak semua dicantumkan disini) adalah:

Port 4321
Protocol 2
PasswordAuthentication no
AllowTcpForwarding yes
AllowUsers cvsadmin

Saya menggunakan port 4321 yang tidak biasa dipakai untuk service ssh. Authentication menggunakan password saya set 'no' untuk meningkatkan keamanan karena authentication yang saya buat akan menggunakan key pair yang telah dibuat menggunakan PuTTYgen.

Setelah itu saya jalankan sshd dengan menggunakan file configurasi tesebut:

    /usr/sbin/sshd -f /etc/ssh/sshd_config_ext

Di sisi client untuk koneksi ke server CVS menggunakan tunneling, saya menggunakan program PuTTY. Saya buat session baru untuk koneksi ke server CVS. Saya lakukan setting SSH connection pada bagian 'Auth' dengan menspesifikasikan file private key yaitu file cvsadmin_private_key.ppk yang telah saya buat sebelumnya.

Saya juga set SSH connection pada bagian 'Tunnels' dengan menambahkan port forwarding rule. Saya isi source port dengan 2401 yaitu port yang digunakan untuk CVS pserver di server Linux dan saya isi destination dengan '127.0.0.1:2401' yaitu mesin destop saya yang akan saya gunakan untuk development. 2401 adalah standar port untuk CVS pserver.

Hasil yang saya dapatkan setelah menambahkan seting port forwarding tersebut adalah:

L2401 127.0.0.1:2401

Dengan membuat session tersebut di PuTTY, setiap saya melakukan koneksi menggunakan session tersebut maka di lokal mesin saya akan dibukan port 2401. Port tersebut seolah-olah adalah port 2401 di mesin CVS. Koneksi ke mesin CVS sebenarnya tidak menggunakan port 2401 tetapi port 5000 dengan protokol SSH. Inilah tunneling.

Akhirnya setelah saya berhasil melakukan login (koneksi) menggunakan session pada PuTTY, saya dapat menggunakan CVS saya. Yang saya lakukan pada CVS client, dalam hal ini saya menggunakan Eclipse development tool, saya buat koneksi CVS pserver ke localhost port 2401.

Dengan cara seperti ini transaksi dengan CVS server menjadi aman. Server CVS juga dapat dipindah-pindah tanpa perubahan apapun di CVS client.

Menangani Client: Jangan debat lewat email.

Menangani client memang tidak mudah. Kita perlu memperlakukannya seperti raja karena client adalah sumber pendapatan bagi vendor. Jika client senang terhadap vendor maka loyalitas mereka terhadap vendor pun akan semakin besar sehingga dapat memberikan keuntungan bagi vendor.

Ada pengalaman penting yang saya dapatkan untuk menangani client beberapa hari lalu yaitu jangan debat dengan client lewat email. Komunikasi lewat email memang cukup efektif karena bersifat self-documented dan tidak memerlukan respon yang cepat dibanding komunikasi langsung lewat telepon misalnya. Tapi email kurang bisa mencerminkan nada bicara dan perasaan kita. Emoticon tidak banyak membantu dan dalam hal email resmi, penggunaan emoticon dirasakan kurang etis.

Menanggapi email dari client yang mengarah ke debat apalagi dengan 'nada' yang tidak enak dibaca, sebaiknya tidak dengan emosi dan tidak ditanggapi lagi dengan email. Kontak langsung dengan telepon untuk menjelaskan duduk persoalan dengan nada yang ramah akan lebih baik. Perlakukan client seperti raja, dan jika anda vendor anggaplah anda sebagai patih yang memohon petunjuk pada raja. Setidaknya beberapa hari ini cara tersebut berhasil buat saya.

Over-the-air Provisioning Aplikasi MIDP

Provisioning dapat diartikan sebagai membuat sesuatu tesedia. Over-the-air (OTA) provisioning memberikan pengertian proses tersedianya aplikasi MIDP (MIDlet) pada device hingga siap digunakan yang ditransfer lewat sebuah jaringan nirkabel (wireless network). Proses OTA provisioning untuk MIDlet mencakup proses mendapatkan aplikasi (discovery), download, install/update maupun penghapusan (removal).

Pada sisi pengguna, OTA provisioning mempermudah pengguna untuk melakukan verifikasi dan installasi MIDlet. Pada sisi penyedia layanan OTA provisioning memberikan kemampuan untuk memberikan informasi content, melakukan proses pembiayaan (charging) dan lain-lain.

OTA provisioning untuk aplikasi MIDP awalnya merupakan rekomendasi praktis bukan suatu spesifikasi. Rekomendasi tersebut dibuat setelah spesifikasi MIDP 1.0 namun kemudian rekomendasi ini masuk dalam spesifikasi MIDP 2.0 dengan beberapa pembaruan atau tambahan.

Arsitektur sebuah OTA provisioning aplikasi MIDlet terdiri dari:

- Provisioning server

Provisioning server adalah HTTP/Web server yang menyimpan file dan pemroses status hasil provisioning. File yang disimpan adalah file metadata atau java application descriptor (JAD) dan aplikasi MIDP (content) yang berupa file JAR. Content dapat juga disimpan di tempat lain misalnya pada suatu repository server atau content management system (CMS). Provisioning server berinteraksi dengan network elemen misalnya WAP gateway yang menghubungkannya dengan device pengguna. Server ini juga dapat berinteraksi dengan sistem lain misalnya charging/billing server, Authentication Authorization server dan lain-lain.

- Client atau AMS

Application Management Software (AMS) biasa digunakan sebagai istilah untuk software pada sebuah device yang bertanggung jawab untuk mengatur suatu aplikasi misalnya mendownload, menyimpan (install), menjalankan (execution) atau bahkan membuang aplikasi. AMS biasa juga disebut Java Application Manager (JAM) untuk menunjukan software yang bertanggung jawab mengatur aplikasi MIDP pada device.


Proses OTA provisioning dimulai dengan content discovery yaitu proses mendapatkan content dari web server. Pengguna biasanya mendapatkan content dari suatu website atau halaman WAP yang menggandung link ke file descriptor (JAD). Contoh link pada halaman WML:

<a href="http://www.javanensis.net/sample.jad">MIDlet sample</a>


Jika pengguna mengklik link tersebut, AMS (browser) akan mendownload file JAD menggunakan HTTP GET request ke web server.

Web server akan meresponse request dengan memberikan file JAD. File tersebut harus diberikan dengan MIME type "text/vnd.sun.j2me.app-descriptor" pada HTTP response header.

Dibawah ini contoh suatu file JAD yang didapat dari web server:

Manifest-Version: 1.0
Created-By: 1.3.1 (Sun Microsystems Inc.)
MIDlet-Version: 1.0.3
MIDlet-Name: Sample MIDlet
MIDlet-Vendor: Javanensis
MIDlet-1: System Viewer, /icons/system.gif, net.javanensis.sample,SystemViewer
MIDlet-2: Bluethoot Test, , net.javanensis.sample.BluethootTest
MIDlet-Description: Contoh aplikasi MIDP
MIDlet-Jar-Size: 86445
MIDlet-Jar-URL: http://www.javanensis.net/contents/sample.jar
MIDlet-Install-Notify: http://www.javanensis.net/MidpOtaProvisioing.do?file=sample.jar
MIDlet-Delete-Notify: http://www.javanensis.net/MidpOtaProvisioing.do?file=sample.jar
MIDlet-Delete-Confirm: Anda yakin akan menghapus aplikasi 'Sample MIDlet'?


Setelah mendapatkan file descriptor, AMS biasanya melakukan verifikasi dan konfirmasi. Dari informasi yang ada pada file descriptot AMS bisa melakukan verifikasi apakah aplikasi yang akan diinstall sesuai dengan device, atau apakah ukuran file mencukupi untuk diinstall. Sebelum proses dilanjutkan, AMS dapat pula memberikan informasi yang tertera pada file descriptor kepada user dan meberikan konfirmasi kepada user untuk melanjutkan proses download dan install atau menghapus aplikasi jika aplikasi telah ada.

Jika user memilih untuk melanjutkan proses download maka AMS akan mendownload MIDlet (file JAR) dari alamat URL yang tertera pada file descriptor bagian "MIDlet-Jar-URL". Proses download file JAR adalah proses HTTP download. AMS akan melakukan HTTP request ke web server, dan web server akan mengirimkan response yang berisi file dengan MIME type pada HTTP header adalah "application/java-archive"

Setelah proses pengambilan file selesai, AMS akan melakukan installasi di tempat (directory) yang telah ditentukan.

Bila proses installasi selesai, AMS akan memberitahukan ke provisioning server apakah proses tersebut berhasil atau tidak. Pemberitahuan hasil proses provisioning dilakukan AMS dengan mengirimkan HTTP POST request yang bersisi kode status dan pesan ke URL yang tertera pada "MIDlet-Install-Notify" dalam file descriptor.
Contoh pengiriman status:

POST /MidpOtaProvisioing.do?file=sample.jar HTTP/1.1
Host: www.javanensis.net
Content-Length: 13

900 Success


Bila user memilih hapus aplikasi karena aplikasi telah ada. Status proses penghapusan dapat juga dikirimkan oleh AMS ke URL yang tertera pada "MIDlet-Delete-Notify"

Code Description (Status Message)
------ ---------------------------------------------------------
900 Success
901 Insufficient Memory
902 User Cancelled
903 Loss of Service
904 JAR size mismatch
905 Attribute Mismatch
906 Invalid Descriptor
907 Invalid JAR (MIDP 2.0)
908 Incompatible Configuration or Profile (MIDP 2.0)
909 Application authentication failure (MIDP 2.0)
910 Application authorization failure (MIDP 2.0)
911 Push registration failure (MIDP 2.0)
912 Deletion Notification (MIDP 2.0)
913 Required package not supported by the device (MIDP 2.0)

Contoh proses diatas adalah proses yang biasa. Dibelakang layar sebuah provisioning server, penyedia layanan dapat menambahakan proses-proses yang diperlukan misalnya:

- Klasifikasi berdasarkan device pada saat user melakukan discovery
- Autentikasi user menggunakan Basic HTTP Authentication atau menggunakan cookies
- Charging (pembiayaan) pada user
- Tracking

Proses OTA provisioning MIDP ini diadopsi pada cakupan yang lebih luas yaitu Spesifikasi provisioning untuk aplikasi klien J2EE (JSR 124) dan OMA download.

== Spesifikasi provisioning untuk aplikasi klien J2EE

JSR 124 didesain tidak hanya untuk aplikasi MIDP, tapi masih mirip dengan OTA provisioning aplikasi MIDP. JSR 124 lebih kompleks karena menspesifikasikan cara untuk mengirimkan content termasuk packaging, publishing, authentication, policies, adapter, plug-in, konfigurasi device serta API untuk mengakses content repository.
Descriptor yang digunakan pada JSR 124 berupa XML.

== OMA Download OTA

Proses OMA download juga mirip dengan OTA provisioning aplikasi MIDP. OMA download tidak dikhususkan untuk men-download MIDlet atau tipe media spesifik lainnya, tetapi merupakan framework untuk mendownload media object apapun. OMA download juga menambahakan kemampuan untuk menghindari dari pengkopian ilegal suatu content dengan menambahkan spesidikasi Digital Rigth Management (DRM). Content descriptor yang digunakan OMA download berupa XML kecuali untuk aplikasi MIDP descriptor tetap menggunakan file JAD.

Contoh descriptor pada OMA download OTA:

<media xmlns="http://www.openmobilealliance.org/xmlns/dd">
<type>image/gif</type>
<objecturi>http:/foo.bar.com/pic-dir/picture.gif
</objecturi>
<size>1234</size>
<installnotify-uri>http:/foo.bar.com/status</installnotify-uri>
</media>


== Links

MIDP 1.0 OTA recommendation http://java.sun.com/products/midp/OTAProvisioning-1.0.pdf
MIDP 2.0 specification http://www.jcp.org/jsr/detail/118.jsp
J2EE Client Provisioning http://www.jcp.org/jsr/detail/124.jsp, http://java.sun.com/j2ee/provisioning
Deploying Wireless Java Applications http://wireless.java.sun.com/midp/articles/deploy
OMA Download OTA v.1.0 http://www.openmobilealliance.org/release_program/download_v10.html

20061031