Modul 2 Model Komponen Java EE dan Langkah-Langkah Pembangunan Aplikasi Java EE

Modul 2 Model Komponen Java EE dan Langkah-Langkah Pembangunan Aplikasi Java EE Setelah menyelesaikan modul ini, anda dapat: •

Menjelaskan prinsip-prinsip dari pembangunan aplikasi berbasis komponen model

•

Menjelaskan model komunikasi secara asynchronous

•

Menjelaskan proses dan peran yang digunakan ketika mengembangkan dan menjalankan aplikasi Java EE

•

Membandingkan beberapa metode dan alat-alat yang dapat digunakan untuk membangun aplikasi Java EE dan komponen terkait

•

Menjelaskan bagaimana mengkonfigurasi dan mengemas aplikasi Java EE

Prinsip Pembangunan Aplikasi Berbasis Komponen Pembangunan aplikasi berbasis komponen merupakan fitur kunci dari platform Java EE. Komponen Java EE dimaksudkan supaya menjadi portabel dan digunakan kembali. Komponen aplikasi Java EE mungkin berasal dari berbagai sumber baik internal maupun eksternal untuk tim pengembangan. Spesifikasi EJB dari awal dirancang untuk mendukung perakitan aplikasi dengan menggunakan komponen dari berbagai vendor. Komponen dapat dibuat secara rinci tanpa pengetahuan detail tentang lingkungan di mana mereka akan digunakan atau dengan komponen lain yang mana mereka akan berinteraksi. Prinsip ini disebut loose coupling. Sistem yang loose coupling lebih mudah untuk ditest dan dipelihara, dan komponen yang loosely coupled lebih mudah untuk digunakan kembali.

Komponen Java EE Komponen Java EE platform yang belum tentu satu class, tetapi umumnya merupakan gabungan lebih dari satu class dan interface yang mendefinisikan sebuah unit fungsi. Java EE model mendefinisikan beberapa jenis komponen, masing-masing yang dirancang untuk memenuhi kebutuhan tertentu. mengilustrasikan jenis komponen utama Java EE di masing-masing kontainer. Java EE komponen termasuk jenis session beans, entity class, message-driven beans, servlets, dan komponen yang didasarkan pada teknologi JSP.

Gambar 2-1 Komponen Java EE

Karakteristik Komponen Java EE Beberapa jenis komponen memiliki subtypes. Komponen juga memiliki beberapa atau semua karakteristik dasar sebagai berikut, tergantung pada jenis komponen: • State and properti

Modul 2 Model Komponen Java EE dan Langkah-Langkah Pembangunan Aplikasi Java EE

Page 2 of 29

• • • •

Dienkapsulasi oleh kontainer Dukungan untuk interaksi komponen local and distributable Transparansi lokasi Referensi ke komponen diperoleh dengan menggunakan sistem penamaan

Informasi berikut menggambarkan framework aplikasi berbasis komponen yang didukung oleh spesifikasi Java EE.

State Komponen dan Properti Komponen Cara komponen yang mengelola state atau mendefinisikan properti dapat memiliki implikasi pada performanya atau bagaimana dapat digunakan dalam framework Java EE. State Komponen Komponen dapat memiliki state. State terkait data yang harus dijaga di sejumlah panggilan method yang dilakukan dari klien yang sama. Namun, ada beberapa keuntungan performance yang dimiliki oleh komponen yang tidak memiliki state. Secara khusus, infrastruktur komponen dapat mengatur pemanggilan method yang dilakukan oleh klien ke instances komponen yang berbeda yang berada di host yang berbeda. Pengaturan ini adalah keuntungan yang di dapat dari fitur load balancing dan fault tolerance. Komponen pada dasarnya dapat dirancang sebagai stateless atau stateful. Jenis komponen lainnya mungkin dapat berbentuk stateless atau stateful. Properti Komponen Properti adalah merupakan fitur dari komponen yang dapat baik diakses dan diubah oleh kliennya atau dapat juga hanya diakses atau diubah oleh kliennya. Properti dapat direpresentasikan oleh instaces variabel. Dalam bahasa pemrograman Java, properti biasanya dimodelkan dengan sepasang method aksesor dan mutator. Misalnya, method getName dan setName mewakili properti nama.

Komponen Dienkapsulasi Oleh Kontainer Enkapsulasi merupakan konsep penting dalam pemrograman berorientasi objek, dan Java EE menggunakan model enkapsulasi lebih dari sekedar hanya untuk model pemrograman. Komponen dienkapsulasi oleh kontainer yang mengatur siklus hidup mereka, serta mengisolasi mereka dari komponen lain dan dari lingkungan runtime.

Kontrak Sebagai Interface Sebuah fitur penting dari model komponen Java EE adalah beberapa komponen yang sudah didefinisikan dan dikontrol melalui interfacenya. Satu komponen hanya dapat berinteraksi dengan komponen lainnya melalui interface dari komponen tersebut.

Membangun Aplikasi dengan Platform Java EE

Page 3 of 29

Meskipun kedua komponen berada dalam Java Virtual Machine (JVM ™) yang sama, adalah sebuah kesalahan jika satu komponen memanggil langsung method pada implementasi komponen lain. Gambar 2-2 menggambarkan bagaimana dua komponen di dalam aplikasi Java EE berinteraksi melalui interface.

Gambar 2-2 Interaksi Komponen-Komponen di Java EE Aplikasi Melalui Interface Satu hal penting yang harus diperhatikan terkait dengan pembatasan ini adalah bahwa infrastruktur komponen dapat menyediakan proxy untuk semua komponen yang ada dalam aplikasi. Asalkan proxy mengimplementasikan interface yang sama seperti yang ada di komponen implementasinya, klien tidak akan terpengaruh oleh kondisi ini. Penggunaan proxy memungkinkan komponen dikelola oleh kontainer, hal ini merupakan salah satu keuntungan yang kita dapat.

Interaksi Komponen Distributed dan Komponen Lokal Untuk beberapa jenis model komponen, Java EE mendukung baik interaksi antar komponen secara lokal maupun distributed. Anda yang harus menentukan apakah interaksi antara dua komponen harus lokal atau distributed. Jika suatu interaksi antara dua komponen adalah lokal, server aplikasi biasanya membuat komponen tersedia satu sama lain di mesin yang memiliki JVM yang sama. Jika suatu interaksi antara dua komponen adalah distributed, server aplikasi harus menyediakan infrastruktur RMI untu dua komponen berkomunikasi. Masing-masing strategi memiliki kelemahan dan kelebihan. Komponen Distributed dan RMI


Page 4 of 29

Untuk mendukung interaksi komponen secara distributed, server aplikasi harus menyediakan infrastruktur RMI untuk dapat mendukung komunikasi. Karena model komponen Java EE didasarkan pada pemisahan yang ketat antara interface dengan implementasinya, ini mudah untuk dicapai dengan memberikan infrastruktur RMI. Seperti yang ditunjukkan dalam Gambar 2-3, Component1 berinteraksi dengan Component2 melalui interface, Interface2. Bila komponen ini distributed, Interface2 akan diimplementasikan oleh stub. Stub berisi logika komunikasi yang memungkinkan untuk membuat panggilan method secara remote. Component2 tidak menyadari secara langsung jika methodnya dipanggil oleh Component1. Sebenarnya, method untuk Component2 dipanggil Component1 melalui perantara skeleton. Stub dan sekeleton sama-sama melaksanakan infrastruktur komunikasi.

Gambar 2-3 RMI Infrastruktur untuk Distributed Komponen RMI infrastruktur harus mengatur masalah yang terkait dengan desain:

Marshalling and unmarshalling argumen dan nilai balikan Serialization merupakan bagian dari proses ini. Namun, serialization saja tidak cukup jika infrastruktur RMI harus tidak bergantung pada bahasa. Namun demikian, objek yang akan didistribusikan antara komponen harus serializable

Passing distributed exceptions Pada saat komponen didistribusikan, kesalahan yang dapat terjadi di dalam aplikasi mungkin bukan hanya kesalahan di sisi logika aplikasi itu sendiri, seperti pemisahan jaringan. Dalam keadaan seperti ini, biasanya, pemanggil akan mendapatkan java.rmi.RemoteException.

Mengirimkan security context and transaction context antara pemanggil dan target Manajemen security dan transaksi akan dibahas pada modul lain dalam materi ini. Untuk saat ini, anda harus memahami bahwa ada informasi yang harus disediakan, bersama dengan pemanggilan method yang berbeda dari argumen dan kembali jenis. Misalnya, komponen target mungkin perlu untuk memastikan bahwa pemanggil memiliki hak akses untuk pemanggilan method.


Page 5 of 29

Protokol RMI yang harus disediakan oleh server aplikasi adalah IIOP, yang merupakan bagian dari spesifikasi CORBA. IIOP membuat aplikasi yang dibuat berdasarkan komponen EJB dapat interoperabel dengan CORBA services. Namun, tidak ada larangan bagi vendor server untuk menyediakan protokol selain IIOP. Misalnya, beberapa vendor menyediakan RMI dengan menggunakan Java Remote Metode Protocol (JRMP) juga. Cara Pemanggilan Komponen Lokal dan Distributed Interaksi antara komponen lokal dan distributed mengikuti konvensi pemanggilan sebagai berikut: Komponen lokal berinteraksi dengan menggunakan cara pemanggilan bahasa pemrograman Java biasa. Argumen dikirim dalam memori yang dipakai bersama, yang berarti bahwa sebuah instance objek yang dikirim sebagai argumen dari komponen yang satu ke komponen yang lain dapat diubah oleh komponen target. Modifikasi pada argumen yang dikirim akan berdampak langsung pada komponen pemanggil. Dengan kata lain, pemanggil dan target akan menggunakan instance yang sama dari argumen. Argumen yang dikirim sebagai bagian dari komponen distributed, dikirim dengan cara menduplikasi instancenya. Argumen yang sudah diserialize selanjutnya oleh pemanggil dikirim melalui jaringan untuk target, yang berarti bahwa target tidak dapat mengubah instance argumen yang dimiliki oleh pemanggil. Ada satu pengecualian pada peraturan diatas. Jika argumen tersebut adalah distributed komponen, maka akan selalu dikirim melalui stub, tanpa memperhatikan apakah kedua komponen lokal satu sama lain. Karena yang dikirim adalah stub, maka objek yang dikirim dapat memanggil method melalui jaringan ke instance objek dari pemanggil. Kelebihan dan Kekurangan dari Distributed Component Model Biaya yang harus dikeluarkan oleh distributed komponen terutama berasal dari RMI overhead. Proses marshalling dan unmarshalling dari argumen dan nilai balikan dapat memperlambat proses. Setiap pemanggilan method memerlukan setup pemanggilan melalui jaringan, dan selanjutnya data dikirim melalui jaringan, yang merupakan resource bersama. Singkatnya, keputusan tentang apakah akan menggunakan interaksi distributed atau lokal harus dipertimbangkan dengan hatihati dalam setiap kasus. Keunggulan distributed komponen adalah transparansi lokasi yang disediakan di modek ini, termasuk peningkatan fault tolerance dan load balancing.

Transparansi Lokasi Transparansi Lokasi adalah salah satu tujuan dari desain distributed komponen model di platform Java EE. Transparansi lokasi berarti bahwa dalam setiap interaksi antar komponen, komponen pemanggil yang tidak perlu memperhatikan fisik lokasi


Page 6 of 29

dari target komponen. Dalam prakteknya, dalam sebuah sistem besar, masingmasing komponen dapat digunakan di lebih dari satu host, yang memiliki manfaat penting sebagai berikut:

Load balancing – Panggilan dapat diputar antar host untuk berbagi beban secara keseluruhan.

Fault tolerance – Jika terjadi kegagalan pada saat memproses panggilan, panggilan dapat diarahkan ke host lain, sementara host yang gagal akan diperbaiki.

Adalah tanggung jawab dari vendor server aplikasi untuk mewujudkan fitur ini. Adalah tanggung jawab anda untuk membuat komponen yang sesuai dengan spesifikasi, yang secara otomatis menghasilkan keunggulan transparansi lokasi.

Naming Service dalam Komponen Model Dalam model komponen Java EE, beberapa komponen dapat berinteraksi satu sama lain hanya dengan interface. Oleh karena itu, komponen yang memerlukan suatu mekanisme untuk mendapatkan referensi dari interface komponen lain tanpa membuat implementasinya. Fasilitas untuk mendapatkan referensi dari interface komponen lain adalah yang disediakan oleh naming service. Server aplikasi menyediakan fasilitas bagi komponen yang ada di dalamnya sebuah pusat repositori komponen yang dapat diakses dengan menggunakan namanya. Gambar 2-4 menunjukkan proses penggunaan naming service untuk mencari informasi rujukan.


Page 7 of 29

Gambar 2-4 Naming Service dalam Komponen Model Tiga langkah dalam Gambar 2-4 akan dijelaskan sebagai berikut: 1. Setelah sebuah aplikasi dideploy ke server aplikasi, semua komponen yang dapat diakses oleh klien terdaftar pada naming service. Pada contoh, komponen yang diberi nama Component2 diterbitkan. Komponen ini mengimplementasikan interface, yang disebut Interface2. 2. Komponen klien, sebut saja Component1, dapat melakukan pemanggilan ke method pada Component2 melalui Interface2. Untuk mendapatkan referensi ke Interface2, Component1 melakukan lookup menggunakan nama alias dari Component2 yang terdaftar di naming service. 3. Naming service menyediakan instance dari komponen yang mengimplementasikan Interface2. Objek yang disediakan tidak selalu merupakan instance dari Component2, objek yang diberikan mungkin proxy untuk Component2, tetapi ini tidak terlihat oleh Component1. Component1 yang kemudian dapat melakukan pemanggilan method pada Component2 menggunakan Interface2.

Penggunaan Java dan Naming Directory Interface ™ (JNDI) API dalam Java EE Komponen Model Aplikasi Java EE menggunakan JNDI API sebagai layanan untuk pencarian nama yang umum untuk mencari komponen, resource eksternal, dan property environtment komponen. JNDI API merupakan ringkasan detail dari protokol penamaan dan implementasinya. Menggunakan JNDI API sebagai media pencarian nama mirip penggunaannya untuk berkomunikasi dengan eksternal naming service, seperti direktori server. Namun, hanya sebagian dari API yang diperlukan bila JNDI API digunakan dalam konteks aplikasi Java EE. Dalam prakteknya, banyak server aplikasi menggunakan infrastruktur CORBAcompliant RMI, dan implementasi yang mendasari JNDI API adalah naming service CORBA. Atau, dalam pelaksanaan mungkin menggunakan LDAP, atau sesuatu yang proprietary. Dalam kebanyakan kasus protokol yang tidak memiliki efek pada pengembang aplikasi, karena API membungkus detailnya. Interface Context dan Objek InitialContext Interface Context (javax.naming.Context) merupakan dasar untuk semua operasi yang terkait dengan naming service. Object InitialContext merupakan implementasi dari interface Context, dan merupakan entry point ke naming service. Pekerjaan yang terkait dengan JNDI API biasanya dimulai dengan membuat instance objek InitialContext.


Page 8 of 29

Namespace yang dapat diakses melalui JNDI bisa berupa hirarki. Pekerjaan lookup pada sebuah instance dari class yang meng-implements pada interface Context akan menghasilkan object atau dalam bentuk subcontext. Subcontext juga mengimplements pada interface Context dan dapat digunakan sebagai dasar untuk melakukan lookup yang baru. Kode 2-1 menunjukkan dua cuplikan kode yang secara praktek memiliki efek yang sama. Kode 2-1 1 2

Melakukan Operasi Lookup

Context c = new InitialContext(); Object o = c.lookup("aaa/bbb");

Atau: 1 2 3

Context c = new InitialContext(); Context subcontext = (Context) c.lookup("aaa"); Object o = subcontext.lookup("bbb");

Semua operasi di JNDI API dapat melempar NamingException, maka exception ini harus ditangani di dalam kode. Mengkonfigurasi Objek InitialContext Pada saat JNDI API digunakan di dalam komponen, kontainer harus menyediakan konfigurasi ke class InitialContext. Anda hanya perlu menggunakan default constructor dari class InitialContext untuk membuat objeck InitialContext sebagai berikut: Context c = new InitialContext(); Bila anda menggunakan JNDI API di luar konteks server aplikasi, anda mungkin diminta untuk memberikan informasi konfigurasi. Informasi ini berbeda antara naming service yang satu dengan yang lainnya, tetapi biasanya terdapat dua buah informasi yang diperlukan:

Nama dari kelas yang meng-implements naming protocol

Universal Resource Locator (URL) yang menentukan lokasi naming service

Informasi ini biasanya diberikan dalam bentuk pasangan nama dan nilainya dalam objek Properties yang dikirim di dalam konstructor objek InitialContext atau disimpan di dalam file properti yang secara otomatis dibaca di konstruktor InitialContext. Kode 2-2 menunjukkan sebuah contoh bagaimana mengkonfigurasi sebuah naming context untuk server aplikasi glassfish.


Page 9 of 29

Kode 2-2 Konfigurasi sebuah Naming Context Properties props = new Properties(); props.setProperty("java.naming.factory.initial", "com.sun.enterprise.naming.SerialInitContextFactory"); props.setProperty("java.naming.factory.url.pkgs", "com.sun.enterprise.naming"); props.setProperty("java.naming.factory.state", "com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl"); // optional. Defaults to localhost. Only needed if web server is running // on a different host than the appserver props.setProperty("org.omg.CORBA.ORBInitialHost", "localhost"); // optional. Defaults to 3700. Only needed if target orb port is not 3700. props.setProperty("org.omg.CORBA.ORBInitialPort", "3700"); InitialContext ic = new InitialContext(props); Perlu diingat bahwa konfigurasi ini hanya diperlukan untuk mengakses ke salah satu komponen EJB dari komponen klien yang berada di luar server aplikasi Java EE. Menggunakan JNDI API sebagai Resource Locator Di dalam sebuah lingkungan komponen, anda dapat menggunakan JNDI API unrtuk mencari objek selain komponen. Misalnya, anda dapat menggunakan JNDI API panggilan menemukan beberapa objek berikut: Koneksi ke relational database Koneksi ke messaging services Tujuan (alamat) dari (pengiriman) message Environment komponen variabel Koneksi ke legacy sistem yang didukung oleh resource adapters Narrowing dan Objek Remote Untuk semua lookup yang menggunakan JNDI API, tipe yang didapat dari method lookup diubah ke tipe yang sesuai. Misalnya, koneksi ke relational database yang di dapat dalam bentuk data objek DataSource (javax.sql.DataSource). Kode 2-3 menunjukkan kode yang diperlukan untuk mencari resource database yang bernama jdbc/bank. Kode 2-3 Looking Up sebuah Data Resource 1 2

Context c = new InitialContext(); DataSource ds = (DataSource)c.lookup("jdbc/bank");

Jika tipe objek yang dikembalikan dari hasil lookup tidak diharapkan, maka pemanggil akan mendapatkan ClassCastException.


Page 10 of 29

Selain itu, untuk remote objek, hasil lookup memerlukan narrowing tipe yang sesuai. Narrowing ini untuk memastikan kompatibilitas dengan berbagai macam jenis infrastruktur RMI. Kode 2-4 menunjukkan proses narrowing ini. Kode 2-4 Narrowing Nilai Balikan sebuah Lookup 1 2 3 4 5

Context c = new InitialContext(); Object o = c.lookup("ejb/BankMgr"); BankMgr bankMgr = (BankMgr) javax.rmi.PortableRemoteObject.narrow (o, BankMgr.class);

Satu hal yang perlu anda ingat bahwa bila klien dari Java EE komponen meminta referensi lokal, bukan referensi remote, hasil lookup JNDI API bukan merupakan remote objek dan tidak memerlukan proses narrowing.

Menggunakan Komponen Context untuk Mencari Komponen Komponen EJB di Java EE memiliki referensi ke sebuah objek EJBContext yang menyediakan akses ke services yang di sediakan oleh kontainer, seperti informasi keamanan, transaksi, dan lookup ke resource. Karena EJBContext objek yang digunakan untuk menyediakan beberapa informasi penting, umumnya sudah ada dalam sebuah komponen EJB. Objek EJBContext yang bekerja dengan cara yang sama dengan JNDI Context dan dapat digunakan di tempat JNDI Context jika dikehendaki. Objek EJBContext melakukan JNDI lookups dalam java:comp/env JNDI Context dan dapat digunakan untuk mencari referensi ke EJB, DataSources, dan referensi ke resource yang lain yang dapat disimpan dalam JNDI. Menggunakan EJBContext menghapus pembuatan objek baru InitialContext yang berulang-ulang dan penanganan exception yang lebih sederhana, dimana hanya di sebabkan oleh runtime exception saja. Objek EJBContext dapat digunakan untuk mencari referensi ke Home dari EJB 2.1. Bahkan untuk mencari referensi ke Remote Home EJB 2.1, penggunaan PortableRemoteOjbect.narrow tidak diperlukan. Kode 2-5 1 2 3 4 5 6/ 7 8

Menggunakan EJBContext untuk melakukan Lookup

import javax.ejb.*; import javax.annotation.*; @Stateful public class MySessionBean implements MyInterface { @Resource private javax.ejb.SessionContext context;


Page 11 of 29

9 10 11 12}

public void myMethod() { BankMgr bankMgr = (BankMgr)context.lookup(“ejb/BankMgr”); }

Menggunakan Dependency Injection untuk Mencari Komponen Dependency injection bukan merupakan konsep baru, sebelumnya nama desain pattern dependency injection adalah inversion of control (sering disingkat sebagai IoC). Ide dibalik dependency injection adalah untuk menghapus penulisan kode lookup yang sering dilakukan oleh developer. Resource lookup di Java enterprise biasanya dilakukan dengan JNDI. Dependency injection menghilangkan beberapa, namun tidak semua, JNDI coding masih diperlukan di beberapa jenis komponen Java EE. Dependency injection memerlukan penggunaan Java annotations. Java annotations adalah fitur baru pada platform Java SE 5. Annotations memberikan cara untuk menanamkan data tentang class, variabel, dan method dalam kode dan juga di file class hasil kompilasi. Data yang ditambahkan ke file kelas dapat diabaikan oleh Java Runtime Environment jika tidak diperlukan. Perangkat lunak, seperti server aplikasi Java EE 5 dapat memeriksa keberadaan annotations menggunakan paket Java reflection. Untuk mengimplementasikan dependency injection, server aplikasi memberikan nilai referensi ke variabel sebelum dapat digunakan. Untuk menjamin server aplikasi memiliki kesempatan untuk dapat melakukan injeksi, komponen harus memiliki lifecycle yang diatur oleh server. Jenis komponen yang disebut juga sebagai managed components, termasuk Servlets, JSPs, dan EJBs. Java class memerlukan developer untuk menulis kode lookup ke JNDI. Dalam versi Java Enterprise sebelumnya, developer dan deployer diperlukan untuk membuat dan mengedit sejumlah besar xml deployment descriptor. Dalam Java EE 5 platform, annotations dan dependency injection menggantikan kebutuhan sebagian besar deployment descriptor. Kode 2-6 Dependency Injection sebagai Alternatif ke lookup 1 2 3 4 5 6 7 8 }

import javax.ejb.*; @Stateful public class MySessionBean implements MyInterface { @EJB private BankMgr bankMgr;


Page 12 of 29

Model Komunikasi Asynchronous Ada dua cara dasar bagaimana sebuah komponen dapat berinteraksi dengan komponen lainnya, synchronous atau asynchronous. Meskipun setiap model interaksi memiliki tempat dalam model pemrograman Java EE, model yang asynchronous, pada beberapa kasus, memberikan keuntungan berbeda.

Perbandingan Interaksi Komponen Synchronous dan Asynchronous Interaksi komponen secara synchronous, apakah lokal atau distributed, mengikuti dasar semantic request-response. Komunikasi antara browser web dan komponen web melalui HTTP menggunakan semantic request-resopnse. Interaksi synchronous yang dicirikan dengan komponen pemanggil akan terblokir sampai proses selesai dikerjakan dan response dikembalikan secara langsung kepada pemanggil. Interaksi synchronous tidak cocok untuk operasi yang memerlukan banyak waktu untuk menyelesaikan pekerjaan. Interaksi asynchronous menggunakan sematik request-notification. Yaitu, pemanggil mengirimkan request dan kemudian melanjutkan proses selanjutnya. Pemanggil tidak akan terblokir sewaktu menunggu adanya response. Sebaliknya, pemanggil akan menerima notifikasi di beberapa waktu kemudian. Semantic requestnotification memungkinkan aplikasi untuk mendukung operasi yang memerlukan waktu yang lama untuk selesai, dan juga mengurangi ketergantungan antara komponen.

Interaksi Komponen Asynchronous Gambar 2-5 menunjukkan sebuah contoh dari aplikasi yang menggunakan interaksi asynchronous antara komponen-komponen untuk mendukung sebuah legacy system.


Page 13 of 29

Gambar 2-5 Interaksi Komponen Asynchronous Langkah-langkah pada Gambar 2-5 dapat digambarkan sebagai berikut: 1. Sebuah komponen yang bertindak sebagai klien mengirimkan order kepada sebuah legacy system yang mengerjakan sejumlah proses. Selanjutnya legacy system, yang kemungkinan memiliki ratusan order yang lain yang juga akan di proses sehingga memerlukan waktu yang panjang untuk memproses order dari klien. 2. Bila legacy sistem sudah selesai memproses order, ia akan memberitahu komponen lain. 3. Komponen ini akan melakukan update ke database terkait dengan informasi status order. 4. Jika klien meminta informasi tentang status order, komponen dapat memeriksa status order pada database. Langkah terakhir ini dapat dilakukan dengan menggunakan interaksi synchronous, atau pesan asynchronous, atau menerima email pemberitahuan.

Asynchronous Messaging J2EE platform 1.3 memerlukan server aplikasi untuk memberikan layanan messaging yang mendukung interaksi komponen secara asynchronous. Selain itu, diawali dengan J2EE platform 1.4, server aplikasi harus menyediakan infrastruktur untuk XML messaging berdasarkan model web service. Komponen menggunakan JMS API untuk mengirim pesan ke komponen lain atau


Page 14 of 29

resource eksternal. Message-driven beans bertindak sebagai konsumen message baik dari komponen lain atau dari resource eksternal.

Kelebihan dan Kekurangan Interaksi Asynchronous Penggunaan komponen asynchronous interaksi menawarkan dua keunggulan:

Mengurangi ketergantungan antara komponen Keuntungan ini dalam jangka panjang dapat mengurangi biaya manajemen perangkat lunak. Mengurangi ketergantungan antara komponen merupakan prinsip standar rekayasa perangkat lunak, karena semakin sedikit ketergantungan antara komponen yang ada, akan semakin mudah untuk mengatur komponen secara bebas. Model interaksi asynchronous menawarkan loose coupling antar komponen.

Mengakomodir proses yang memerlukan waktu yang panjang untuk diselesaikan

Terdapat dua kekurangan sehubungan dengan model interaksi komponen secara asynchronous jika dibandingkan dengan interaksi secara synchronous:

Penanganan infrastruktur yang lebih kompleks

Penggunaan resource jaringan yang kurang efisien


Page 15 of 29

Membangun Aplikasi Java EE Pembangunan aplikasi Java EE biasanya dilakukan oleh sekelompok orang, masingmasing dengan peran dan tanggung jawab masing-masing, seperti sistem arsitek, pembuat komponen, dan assembler aplikasi.

Roles di Java EE Spesifikasi Java EE mendefinisikan beberapa peran yang terlibat dalam pengembangan, deployment, dan manajemen dari sebuah aplikasi enterprise. Meskipun sebagian besar organisasi memiliki strategi untuk membagi pekerjaan di antara anggota tim proyek, spesifikasi Java EE memberikan acuan, sedikit banyak, cara ini adalah yang harus dilakukan. Yang termasuk peran di Java EE:

Pembuat Komponen Aplikasi Pembuat komponen aplikasi membangun komponen Java EE. Komponenkomponen ini antara lain komponen EJB, komponen Web, dan mungkin resource Adapter. Output dari peran ini adalah class yang sudah terkompile dan XML deployment descriptors. Descriptors yang mungkin belum lengkap yang nantinya akan dilengkapi oleh peran yang lain. Output dari proses ini dapat digunakan pada platform yang memenuhi persyaratan Java EE spesifikasi. Pembuat komponen aplikasi menghasilkan komponen yang vendor netral.

Assembler Aplikasi Assembler aplikasi menggunakan komponen yang sudah selesai dibuat oleh pembuat komponen aplikasi, selanjutnya komponen-komponen tersebut dirangkai sehingga menjadi sebuah aplikasi. Komponen itu sendiri di dapat dari berbagai sumber, termasuk sumber dari luar organisasi. Assembler aplikasi menyelesaikan penggabungan antra komponen yang satu dengan yang lainnya dan melakukan konfigurasi komponen-komponen sesuai dengan perannya di dalam aplikasi secara keseluruhan. Assembler aplikasi juga menghasilkan aplikasi yang vendor netral.

Deployer Deployer yang bertanggung jawab untuk mendeploy aplikasi yang sudah dibuat oleh assembler aplikasi ke lingkungan server aplikasi tertentu. Deployer yang bertanggung jawab untuk penggabungan ke resource eksternal, mengkonfigurasi lingkungan runtime aplikasi, dan integrasi aplikasi dengan infrastruktur keamanan.

Sistem Administrator Sistem administrator memelihara dan memonitor lingkungan server aplikasi dan memastikan bahwa kinerja optimal dapat tercapai. Misalnya, peran ini mungkin akat terlibat untuk pembuatan keputusan pada hal yang terkait dengan load balancing dan redundansi.

Tool Provider


Page 16 of 29

Tool provider menyediakan tool yang terkait pengemasan, assembler, dan tool untuk deployment.

dengan

pembangunan,

Produk Provider Produk provider adalah vendor dari server aplikasi, hardware pendukung dan software pendukung lainnya, misalnya sistem operasi, database.

Tahapan Untuk Mengembangkan Aplikasi Java EE Mengembangkan aplikasi Java EE umumnya memerlukan melaksanakan tugas-tugas berikut:

Pembuatan Design Seperti dalam proyek yang lain, desain adalah salah satu langkah yang paling penting. Cukup dengan menggunakan framework aplikasi Java EE dapat menyelesaikan banyak masalah, misalnya bagaimana menerapkan manajemen keamanan atau transaksi di aplikasi. Java EE biasanya melibatkan desain yang lebih tinggi tingkat abstaksi, seperti menentukan komponen apa yang akan digunakan di tier presentasi atau di tier logika bisnis. Seorang sistem arsitek mendesain arsitektur aplikasi dan menentukan komponen interface. Design aplikasi yang bagus akan memudahkan tahapan pembuatan aplikasi yang selanjutnya.

Pembuatan kode Pada tahap ini, pengembang komponen membuat implementasi dari Java EE komponen. Membuat kode, mengkompile, dan mendebug komponen untuk memastikan bahwa mereka memenuhi kontrak interface. Unit testing adalah bagian penting dari setiap proses pembangunan aplikasi. Pembuatan kode dapat dilakukan dalam editor, kompilasi, dan pengujian dapat dilakukan secara manual atau menggunakan tool. Komponen aplikasi Java EE dapat dikembangkan untuk aplikasi tertentu atau mereka mungkin dibuat untuk keperluan umum atau bagian dari library perangkat lunak.

Membuat deployment descriptor Penyedia komponen menggunakan XML deployment descriptor untuk mendaftarkan resource dan komponen lain yang digunakan oleh komponen Java EE, serta nama-nama yang digunakan untuk mengakses ke komponen atau resource tersebut. Komponen yang belum diprogram koneksinya ke resource yang berada di luar dapat digunakan dalam beberapa aplikasi. Akhirnya, aplikasi server dan membuat koneksi ke resource dan menyambungkan referensi antara komponen yang satu dengan komponen yang lain dengan menggunakan informasi yang ada di dalam deployment descriptor. Anda dapat membuat deployment descriptor menggunakan teks editor atau dengan tool dari pihak ketiga atau tool yang sudah di sediakan oleh vendor.

Pengemasan


Page 17 of 29

Kumpulan file class tidak dianggap sebagai komponen sampai dikemas menjadi sebuah komponen. Semua file yang bersangkutan harus bersama-sama dikemas di dalam sebuah arsip file yang sesuai. Pengemasan ini dapat dilakukan secara manual dengan menggunakan tool command-line atau dengan bantuan tool lain.

Assembling Pada tahap ini, komponen aplikasi digabungkan menjadi sebuah aplikasi yang dapat digunakan. Bagian dari proses ini melibatkan memecahkan referensi antara komponen yang dapat disediakan oleh berbagai komponen vendor.

Deployment Aplikasi tersebut harus dideploy ke server aplikasi secara manual atau menggunakan tool yang sudah disediakan oleh vendor. Langkah ini biasanya melibatkan konfigurasi yang vendor spesifik dari komponen aplikasi atau lingkungan runtime, seperti load-balancing. Kebanyakan vendor server menyediakan sebuah tool untuk menyelesaikan tahapan deployment.

Gambar 2-6 mengilustrasikan bagaimana komponen aplikasi digabungkan ke dalam modul-modul aplikasi yang kemudian dideploy sebagai satu kesatuan aplikasi ke dalam sebuah server aplikasi.

Gambar 2-6 Proses Pembangunan Aplikasi Java EE


Page 18 of 29

Perbandingan Beberapa Pilihan Development Anda dapat mengembangkan aplikasi Java EE dan komponen aplikasi menggunakan sejumlah tools dan teknik.

Pilihan Development Anda dapat membuat komponen Java EE menggunakan berbagai perangkat, seperti teks editor untuk pembuatan kode dan mengedit file, command line kompiler, tool untuk deployment dan tool untuk assembly, atau satu lingkungan terpadu yang mengatur seluruh siklus yg berulang pembangunan di bawah atap satu aplikasi. Beberapa pilihan ini disajikan pada bagian ini.

Packaging tools Standalone packaging tool memungkinkan anda untuk mengassembly file class, deployment descriptors, dan file lainnya ke dalam sebuah file EAR yang siap dideploy. Alat ini mungkin juga menjelaskan ketergantungan eksternal dari aplikasi yang harus diselesaikan dalam proses deployment.

Makefiles Makefiles dapat membantu proses pembangunan secara otomatis dengan menempatkan pembangunan repetitif langkah ke file-file script. Make program akan menafsirkan makefiles. Makefiles dapat berisi prosedur dan dependensi. Meskipun makefiles telah digunakan sekitar untuk dekade, mereka dapat kompleks untuk mengatur dan memeliharanya. Karena mereka juga bergantung pada platform, sebuah makefile dari satu platform tidak mungkin untuk dapat digunakan sebagai makefile di platform yang lain.

Apache ANT ANT Java adalah perangkat development yang identik dengan make, tetapi dapat di perluas penggunaannya dengan menggunakan class Java. Karena ANT berbasis teknologi Java, adalah platform independen. ANT dapat diintegrasikan dengan berbagai macam IDE untuk bahasa pemrograman Java.

Integrated Development Environments (IDE) IDE memberikan lingkungan end-to-end untuk coding, pengemasan, dan deployment. Dalam beberapa kasus, IDE memberikan lingkungan end-to-end untuk menyediakan konfigurasi aplikasi Java EE yang spesifik milik vendor tertentu. IDEs biasanya memiliki fitur sebagai berikut: o Sebagai editor o Kemampuan untuk mengatur komponen Java EE secara grafis o Kemampuan untuk melakukan kompilasi dari dalam IDE o Kemampuan untuk melakukan debug pada kode sumber o Kemampuan untuk mengedit deployment descriptors secara grafis o Kemampuan untuk mendeploy ke satu atau lebih server aplikasi


Page 19 of 29

Netbeans™ 6.5 IDE menyediakan semua fitur dan lebih banyak lagi. Netbeans menyediakan fitur-fitur lainnya, seperti eksplorasi database, pembuatan class entity dari struktur data yang ada, kemampuan melakukan refactoring, dan juga dapat diextens dengan menggunakan plug-in, yang memberikan kemampuan lebih luas lagi.

Sistem Pengontrol Source Code Pembangunan proyek-proyek besar dengan beberapa pengembang memiliki beberapa masalah unik yang perlu dipecahkan. Salah satu hal yang penting adalah bagaimana caranya dua atau lebih developer tidak mengedit file yang sama pada saat yang sama, karena modifikasi yang dilakukan oleh satu orang dapat menghilangkan yang lain, yang akan menyebabkan pekerjaan yang sudah dilakukan akan hilang. Akibatnya, pembangunan proyek-proyek besar membutuhkan penggunaan sistem pengontrol source code, yang memungkinkan untuk check-out dan check-in dari source code. Sistem yang baik juga memungkinkan untuk membagi pekerjaan dengan membuat cabang-cabang seperti organisasi, dan memiliki kemampuan untuk membantu dalam menyelesaikan pada saat terjadi konflik dengan memperhatikan ranting organisasi yang ada. Lebih rinci penjelasan tentang sistem pengontrol source code tidak dijelaskan di dalam materi ini. Netbeans menyediakan kemampuan untuk berintegrasi terpadu dengan CVS dan Subversion dengan dukungan instalasi plugin gratis. Gambar 2-7 menggambarkan sistem pengontrol source code yang digunakan.


Page 20 of 29

Gambar 2-7 Sistem Pengontrol Source Code


Page 21 of 29

Konfigurasi dan Pengemasan Aplikasi Java EE Dalam pembangunan proyek besar, sejumlah pengembang atau tim pengembangan dapat berkontribusi untuk membuat komponen-komponen yang mneyusun aplikasi Java EE. Pengembang mempersiapkan komponen individu untuk distribusikan dengan cara komponen tersebut dikemas ke dalam file arsip yang berisi file class yang relevan dan XML deployment descriptors. Format file arsip dan informasi yang terdapat di dalam deployment descriptor tergantung pada jenis komponen. Arsip komponen digabungkan ke dalam modul-modul aplikasi yang kemudian dikemas menjadi super arsip, yang merupakan arsip yang membangun sebuah aplikasi yang menyeluruh. Karena isi dan struktur file arsip yang disesuaikan dengan spesifikasi standar Java EE, anda dapat membuat arsip Java EE komponen menggunakan platform yang sudah memenuhi persyaratan pengarsipan komponen Java EE. Ada empat dasar jenis file arsip yang digunakan dalam proyek pengembangan platform Java EE: File Arsip Web (WAR) File Arsip Java (JAR) File Arsip Resource (RAR) File Arsip Enterprise (EAR) Setiap jenis file arsip secara deklaratif mendefinisikan karakteristik operasi dan persyaratan dari komponen yang diarsip menggunakan deployment descriptor. Komponen aplikasi Java EE biasanya dibuat dalam modul-modul yang dijadikan sebagai dasar untuk puatan file arsip. Sebuah modul Java EE terdiri dari satu atau lebih komponen Java EE untuk jenis kontainer yang sama dan satu komponen deployment descriptor untuk jenis tersebut. Misalnya, EJB komponen dikembangkan sebagai bagian dari modul EJB yang kemudian digunakan untuk membuat file EJB JAR.

File Arsip Web Gambar 2-8 menunjukkan elemen mendasar yang membangun sebuah aplikasi web.


Page 22 of 29

Gambar 2-8 Elemen Aplikasi Web Meskipun pada gambar diatas hanya menunjukkan salah satu ikon untuk setiap jenis elemen atau jenis komponen, mungkin ada ratusan setiap jenis elemen yang ada dalam aplikasi web. Seperti diilustrasikan dalam Gambar 2-9, isi aplikasi web yang dikompresi sebagai file arsip web untuk distribusikan dan penggabungan sebagai bagian dari aplikasi Java EE yang siap dideploy.


Page 23 of 29

Gambar 2-9 Pembuatan File Arsip Web File web arsip menggunakan ekstensi file .war.

File Arsip Java File arsip Java (JAR) menyediakan mekanisme standar untuk pengemasan dan pendistribusian file class Java dan resource terkait. File JAR biasanya diberi nama yang diakhiri dengan ekstensi .jar. Java EE menentukan spesifikasi file JAR sebagai format untuk pengemasan komponen EJB dan klien Java EE. Seperti diilustrasikan dalam Gambar 2-10, file EJB JAR berisi file class Java dan interface yang digunakan untuk membuat suatu komponen EJB, bersama dengan deployment descriptor.


Page 24 of 29

Gambar 2-10 Isi sebuah file JAR komponen EJB Demikian pula, komponen klien Java EE dikemas menjadi file JAR. Tujuan pengemasan kode klien ini adalah untuk memberi kesempatan kepada server aplikasi untuk menambahkan infrastruktur keamanan untuk aplikasi. Ingat bahwa keamanan bukan merupakan tanggung jawab pengembang dalam platform Java EE. Dengan aplikasi berbasis web, keamanan dilakukan di sisi server web, jadi JAR klien tidak diperlukan. Dengan aplikasi Java yang standalone, infrastruktur keamanan aplikasi membatasi akses yang dilakukan oleh klien ke komponen EJB sesuai dengan kebijakan keamanan.

File Arsip Resource Sebuah reource adaptor adalah komponen perangkat lunak yang menjadi media penghubung manajemen transaksi, keamanan, dan resource pooling subsystems yang dimiliki oleh kontainer. Sebuah resource adaptor dapat meminta akses ke sistem, melebihi apa yang akan diizinkan untuk sebuah enterprise bean. Resource adapter dapat membuat panggilan secara native, atau membuat socket di jaringan, membuat dan menghapus thread, dan membaca dan menulis file. Tidak ada tindakan yang diperbolehkan untuk enterprise bean.


Page 25 of 29

Suatu komponen pengembang mengemas resource adapter ke RAR file yang memiliki nama dengan ekstensi .rar. Rar file dapat berisi resource adapter, class Java, dan deployment descriptor.

File Arsip Enterprise Arsip super yang disebut juga dengan arsip enterprise atau file EAR. File-file ini biasanya diberikan nama dengan ekstensi .ear. Struktur file EAR dibuat dengan cara yang sama seperti File Arsip Java. EAR file yang berisi file arsip komponen EJB, file arsip komponen web, file arsip resource adaptor, dan file arsip untuk klien. Gambar 2-11 menggambarkan isi dari sebuah file EAR.

Gambar 2-11 Isi File EAR

Deployment Descriptor


Page 26 of 29

Spesifikasi Java EE mendefinisikan sebuah cara deklaratif untuk menjelaskan interaksi antara komponen dan antara komponen dengan kontainer melalui penggunaan file XML bernama deployment descriptor. Deployment descriptor menyediakan sarana untuk mengkonfigurasi komponen Java EE dan aplikasi tanpa memerlukan akses ke source code komponen. Catatan - Deployment descriptors di Java EE 5 adalah opsional. Pengembang dapat menggunakan annotation di dalam kode untuk mengkonfigurasi komponen. Jika di definisikan di dalam deployment descriptors akan menimpa annotation yang ada di code. Deployment descriptor adalah file XML. Dari format file, konvensi penamaan, dan lokasi di file arsip yang ditetapkan oleh spesifikasi komponen yang relevan. Misalnya, spesifikasi EJB menunjukkan bahwa deployment EJB keterangan harus memiliki file bernama ejb-jar.xml yang terletak di direktori META-Inf di EJB JAR. Suatu komponen atau deployment descriptor sebuah aplikasi dapat menentukan: Strategi manajemen transaksi Manajemen keamanan, siapa boleh mengakses komponen apa di dalam sebuah aplikasi Variabel yang nilainya dapat dikonfigurasi pada saat deployment Pemetaan ke komponen-komponen yang lain Ketergantungan ke resource eksternal Platform Java EE menegaskan bahwa ketika komponen digabungkan ke dalam aplikasi, tidak ada perubahan ke source code yang diizinkan. Bahkan seorang assembler mungkin tidak akan memiliki source code. Oleh karena itu, penggunaan deployment desciptor itu sangat penting untuk hal tertentu.

Deployment Descriptor yang Spesifik milik Vendor Spesifikasi komponen Java EE memperbolehkan vendor server untuk memasukkan file konfigurasi yang spesifik vendor ke dalam file arsip komponen. Sebagai contoh, file konfigurasi yang spesifik vendor mungkin berisi informasi tentang pemetaan name ke eksternal resource, properti load balancing, dan manajemen pengaturan session. Implikasinya adalah bahwa deployer aplikasi perlu menyediakan file XML spesifik untuk satu vendor tertentu, seperti yang diminta oleh platform target. Vendor yang biasanya menyediakan document type definition (DTD) atau XML skema yang menggambarkan format dan elemen data untuk file konfigurasi yang spesifik vendor tertentu. Deployer aplikasi dapat membuat file konfigurasi yang berlaku spesifik vendor menggunakan XML editor dan DTD atau XML skema yang sudah disediakan. Kode 2-7 menunjukkan contoh deployment descriptor komponen EJB yang berisi beberapa informasi yang spesifik untuk Sun ONE Application Server:


Page 27 of 29

Code 2-7 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

Sun Java System Application Server Deployment Descriptor

<sun-ejb-jar> <enterprise-beans> <ejb> <ejb-name>BankMgr <jndi-name>ejb/BankMgr <pass-by-reference>false <principal> NONE NONE <establish-trust-in-target>NONE <establish-trust-in-client>SUPPORTED USERNAME_PASSWORD default <required>false <sas-context> SUPPORTED <steady-pool-size>32 16 <max-pool-size>640 <pool-idle-timeout-in-seconds>600 <max-wait-time-in-millis>0

Efek dari konfigurasi yang spesifik vendor pada portabiliti adalah minimal. Aktivitas deployment adalah bagian kecil dari setiap proyek, dan dapat dengan mudah dilakukan pada setiap server platform.


Page 28 of 29

Ringkasan Pembangunan aplikasi berbasis komponen merupakan fitur kunci dari platform Java EE. Java EE model mendefinisikan beberapa jenis komponen, masing-masing dirancang untuk memenuhi kebutuhan tertentu. Komponen teknologi Java EE memiliki beberapa atau semua karakteristik penting sebagai berikut, tergantung pada jenis komponen: • State and properti • Dienkapsulasi oleh kontainer • Dukungan untuk interaksi komponen local and distributable • Transparansi lokasi • Referensi ke komponen diperoleh dengan menggunakan sistem penamaan Ada dua cara dasar bagaimana komponen dapat berinteraksi dengan komponen lainnya, secara synchronous atau asynchronous. Meskipun setiap model interaksi memiliki tempat dalam model pemrograman Java EE, yang asynchronous model, pada beberapa kasus, memberikan beberapa keuntungan. Pengembangan aplikasi Java EE biasanya dilakukan oleh sekelompok orang, masingmasing dengan peran dan tanggung jawab yang berbeda. Spesifikasi Java EE mendefinisikan beberapa peran yang terlibat dalam pengembangan, deployment, dan manajemen dari sebuah aplikasi enterprise. Mengembangkan aplikasi Java EE biasanya melibatkan beberapa tahapan. Pengembang aplikasi biasanya menggunakan seperangkat tool dan teknik untuk mengembangkan aplikasi Java EE. Komponen aplikasi Java EE dikemas ke dalam file arsip untuk distribusikan dan dirangkai menjadi sebuah aplikasi Java EE. File arsip berisi deployment descriptor yang menjelaskan karakteristik dari setiap komponen yang ada di dalam file arsip.


Page 29 of 29

Modul 2 Model Komponen Java EE dan Langkah-Langkah Pembangunan Aplikasi Java EE

Recommend Documents