BAB II LANDASAN TEORI
2.1
Saham Surat berharga atau sering juga disebut sekuritas merupakan secarik kertas yang
menunjukkan hak pemodal (yaitu pihak yang memiliki kertas tersebut) untuk memperoleh bagian dari prospek atau kekayaan organisasi yang menerbitkan sekuritas tersebut, dan berbagai kondisi yang memungkinkan pemodal tersebut menjalankan haknya, http://www.fxstreet.com/stock_exchange/ Efek merupakan istilah baku yang digunakan Undang-Undang Pasar Modal No.8 Tahun 1995 untuk menyatakan surat berharga atau sekuritas. Pada dasarnya surat berharga di pasar modal dapat diklasifikasikan ke dalam dua bentuk yaitu : 1. Surat berharga yang bersifat penyertaan dan umumnya surat berharga ini dikenal dengan saham. Saham dapat didefinisikan sebagai tanda penyertaan atau pemilikan seseorang atau badan dalam suatu perusahaan atau perseroan terbatas. Wujud saham adalah selembar kertas yang menerangkan bahwa pemilik kertas tersebut adalah pemilik perusahaan yang menerbitkan surat berharga tersebut. 2. Surat berharga yang bersifat utang atau surat berharga pendapatan tetap (fixed income) dan umumnya dikenal dengan obligasi.
Provider adalah seseorang atau suatu organisasi yang bertugas untuk menyediakan servis atau jasa maupun barang.
6
Provider saham adalah suatu badan yang menyediakan servis untuk memperoleh suatu bagian/share dari suatu perusahaan kepada para calon pemegang saham.
2.2
J2EE J2EE adalah sebuah platform programming (bagian dari Java platform) untuk
mendevelop dan menjalankan aplikasi arsitektur multi-tier yang terdistribusi, berdasarkan pada besarnya komponen-komponen modular yang dijalankan di aplikasi server. J2EE platform dirancang dengan spesifikasi. (Eric A., Jennifer B., Stephanie B., Debbie B., Ian E., Dale G., Kim H., Eric J. (2004). The J2EE Tutorial. Sun Microsystems Inc, California, Ebooks) J2EE secara tidak formal juga disebut sebagai bahasa standar karena para provider (vendor-vendor) harus menyetujui requirementrequirement yang ada untuk dapat mengatakan bahwa produk mereka adalah J2EE compliant. J2EE terdiri dari beberapa spesifikasi standard API, yakni berupa: -
Java Database Connectivity (JDBC): API yang mengatur koneksi antara aplikasi dengan database.
-
Remote Method Invocation over the Internet Inter-ORB Protocol (RMI-IIOP): Menyediakan
implementasi Java RMI diatas IIOP. Hal ini menjembatani
batasan antara aplikasi RMI dan aplikasi CORBA. -
Enterprise Java Beans (EJB): Spesifikasi sebuah komponen framework untuk aplikasi multi-tier terdistribusi. API ini menyediakan standardisasi untuk mendefinisikan komponen-komponen pada server side, dan spesifikasi infrastruktur runtime untuk hosting components pada server side.
7
-
Java Servlets: Java Servlet API menyediakan abstraksi object-oriented untuk membangun aplikasi web yang dinamis.
-
JavaServer Pages (JSP): API ini berupa perluasan untuk peningkatan aplikasi web J2EE dengan menyediakan template-driven untuk pengembangan aplikasi web.
-
Java Message Service (JMS): JMS menyediakan API Java untuk message queuing, dan publikasi dan pelangganan tipe-tipe dari message oriented middleware services.
-
Java Naming and Directory Interface (JNDI): API ini membuat standardisasi pengaksesan pada beberapa tipe berbeda pada penamaan dan direktori servis (naming and directory services) sekarang ini. API ini dirancang bebas dari spesifikasi maupun implementasi penamaan dan direktori manapun. J2EE juga menyediakan sebuah JNDI service provider interface (SPI) untuk implementasi penamaan dan service direktori.
-
Java Transaction API: API ini berguna untuk implementasi aplikasi distribusi secara transactional.
-
JavaMail: API ini menyediakan framework platform independence dan protocol independence untuk membangun aplikasi Java berdasarkan mail.
2.3
System Architecture Ketika membicarakan tentang pengembangan (development) aplikasi enterprise,
maka diperlukan konsep arsitektur n-tier. Berikut ini akan dijelaskan beberapa dari arsitektur sebuah sistem:
8
2.3.1 Arsitektur 2-Tier Dalam arsitektur 2-tier, beban pemrosesan dikenakan pada PC client sedangkan server hanya sebagai pengatur lalu lintas antara aplikasi dan data. Sebagai hasilnya, bukan hanya performansi dari aplikasi berkurang dikarenakan resource dari PC, tetapi juga lalu lintas jaringan cenderung meningkat juga. Keika keseluruhan aplikasi diproses di suatu PC, aplikasi dipaksa untuk memroses multiple requests untuk data sebelum ditampilkan pada user. Pemrosesan multiple requests pada database inilah yang menyebabkan beratnya lalu lintas pada jaringan.
Application
DB
Gambar 2.3.1.1 Arsitektur 2-Tier Masalah lain pada arsitektur 2-tier adalah dalam hal maintenance. Bahkan untuk perubahan terkecil pada aplikasi dapat melibatkan perubahan pada aplikasi user, sehingga diperlukan pengupdate-an setiap instalasi client. Ditambah lagi, jika beberapa user belum siap untuk melakukan perubahan sedangkan yang lain bersikeras untuk melakukan perubahan secepatnya. Hal ini dapat menyebabkan instalasi aplikasi client dengan versi yang berbeda-beda.
9
2.3.2 Arsitektur 3-Tier Untuk mengatasi masalah diatas, maka komunitas software mengembangkan arsitektur 3-tier. Aplikasi ini dipecah menjadi 3 bagian layer, dengan beberapa kumpulan interface yang telah ditetapkan. Tier pertama disebut presentation layer yang berupa GUI (Graphical User Interface) sebagai tampilan dari aplikasi. Tier tengah disebut dengan business layer yang terdiri dari aplikasi atau business logic. Tier ketiga disebut dengan data layer yang mengandung data-data yang diperlukan bagi aplikasi. Tier tengah (application logic) pada dasarnya berupa code yang dipanggil user (melalui presentation layer) untuk mengambil data yang diinginkan. Presentation layer menerima data tersebut dan menampilkannya berdasarkan format-format tertentu. Pemisahan application logic dari user interface menambah fleksibilitas rancangan sebuah aplikasi. User interface yang berbeda dapat dibangun dan diinstall tanpa harus melakukan perubahan pada application logic, yang disediakan oleh application logic berupa kumpulan interface yang telah ditetapkan untuk presentation layer.
10
User Interface
Application Logic
DB
XML Document
Others
Gambar 2.3.2.1 Arsitektur 3-Tier
2.3.3 Arsitektur n-Tier Dalam arsitektur n-tier, application logic dipisahkan berdasarkan fungsi daripada berdasarkan fisik. Arsitektur n-tier dipecah menjadi bagian-bagian berikut ini: -
User Interface yang menangani interaksi user dengan aplikasi; hal ini dapat berupa web browser yang dijalankan lewat firewall, aplikasi desktop, maupun peralatan wireless.
-
Presentation logic yang mendefinisikan apa yang akan ditampilkan user interface dan bagaimana request user ditangani.
-
Business logic berupa aturan-aturan bisnis dari aplikasi, biasanya melalu interaksi dengan data-data aplikasi.
11
-
Infrastructure services yang menyediakan fungsionalitas tambahan yang diperlukan oleh komponen aplikasi, seperti messaging, dukungan transactional, dll.
-
Data layer dimana data-data enterprise berada.
Browser FireWall
Application Client
Presentation Logic Service Business Logic
DB
XML Document
Gambar 2.3.3.1 Arsitektur n-Tier
12
Others
Aplikasi berbasiskan aristektur ini telah menerapkan pattern Model-ViewController (MVC). Yang dimaksud ini adalah data (model) dipisahkan dari bagaimana informasi itu ditampilkan (view) diantara aplication/business logic (controller) yang mengatur arus/aliran informasi. Karena itu, aplikas yang dirancang berdasarkan 3 komponen fungsionalitas ini (model, view, dan controller) saling berinteraksi satu sama lain.
2.3.4 Arsitektur Enterprise Sejauh ini aplikasi yang difokuskan berupa suatu kesatuan arsitektur aplikasi, tetapi bagaimanapun, aplikasi Enterprise dapat terdiri dari aplikasi-aplikasi yang berbeda – kemungkinan dengan arsitektur berbeda – dimana kesemuanya itu tidak dapat berkomunikasi satu sama lain. Dalam sebuah Enterprise, diperlukan suatu perpaduan secara keseluruhan. Daripada perubahan sebuah aristektur (arsitektur aplikasi Enterprise pada dasarnya berupa n-tier), lebih ditekankan pada perubahan pandangan. Untuk mengubah sistem n-tier menjadi sistem enterprise, hanya memerlukan perpanjangan middle tier dengan dimungkinkannya beragam application objects daripada hanya sebuah single application. Tiap-tiap application objects harus memiliki interface yang memungkinkan mereka bekerja sama satu sama lain. Sebuah interface dapat dianggap sebagai kontrak. Tiap objek menggambarkan interfacenya dengan penerimaan parameter-parameter tertentu dan pengembalian hasil tertentu. Application objects berinteraksi satu sama lain dengan menggunakan interface-interface mereka.
13
HTML Form (Browser)
Java Applet (Browser)
Any System Capable of Presenting Data
Interface
Interface
Interface
Application Component
Application Component
Application Component
Database MiddleWare
DB
XML Documents
Remote System
Gambar 2.3.4.1 Arsitektur Enterprise
Dengan arsitektur enterprise, maka dapat dimiliki berbagai aplikasi-aplikasi dengan menggunakan kumpulan komponen-komponen umum diantara suatu organisasi. Hal ini membuat standardisasi dari business practices dengan membuat suatu kumpulan fungsi-fungsi bisnis untuk pengaksesan pada keseluruhan organisasi. Jika terjadi perubahan pada aturan bisnis, maka perubahan hanya dilakukan pada business object, dan jika perlu, interface-interfacenya dan objek-objek yang mengakses interface tersebut. 14
2.4 Penerapan MVC Arsitektur dasar dalam penerapan aplikasi Enterprise sebagian besar pada umumnya menerapkan pattern MVC (Model View Controller). Berikut ini akan dijelaskan tentang MVC secara mendalam serta framework-framework untuk penerapannya: 2.4.1
Model Model
merupakan
representasi
informasi/data
dimana
suatu
aplikasi
dioperasikan. Pada umumnya data/informasi dari perusahaan akan disimpan secara permanen agar bisa digunakan ulang. Umumnya penyimpanan data tersebut ditaruh dalam Relational Database. Relational Database atau yang biasa kita sebut RDBMS telah menjadi bagian terpenting dalam bidang enterprise dalam hal penyimpanan data (Persistence). Akan tetapi, dalam era bahasa pemrograman modern sekarang yang berbasis OOP (Object Oriented Programming), kita mengalami kesulitan dalam hal pemrosesan data baik pengambilan maupun manipulasi data berdasarkan object, khususnya untuk struktur data yang complex (Perancangan Objek yang kompleks). Masalah ini sering disebut dengan Object/Relational Paradigm Mismatch antara Relational ke dalam Objek. Mengingat akan RDBMS yang masih mendominasi industry komputerisasi, hampir selama 15 tahun terakhir para developer telah lama berdiskusi tentang pemacahan pada Paradigm Mismatch tersebut. Paradigm Mismatch yang dibicarakan tersebut mengarah ke antara Object Modeling dan Relational Modeling, atau mungkin Object-Oriented programming dan SQL. Salah satu solusi pada paradigm mismatch tersebut dikenal dengan istilah ORM (Object Relational Mapping) yang menjadi layer perantara/jembatan antara Relational Database dan Object Oriented Programming. 15
Sebelum mengetahui lebih banyak tentang apa itu ORM, maka kita akan membahas lebih lanjut mengenai Paradigm Mismatch yang telah disebutkan diatas.
2.4.1.1 The Paradigm Mismatch Paradigm Mismatch ini dapat kita pecahkan menjadi beberapa bagian yang dapat kita contohkan pada kasus berikut ini: Andaikan kita ingin mendesign dan mengimplementasi aplikasi e-commerce. Dalam aplikasi ini, kita akan memerlukan sebuah class untuk mewakili informasi user dari sistem tersebut, dan class lain untuk mewakili informasi tentang billing details dari user tersebut yang ditampilkan pada gambar 2.4.1.1.1
Gambar 2.4.1.1.1
UML Class diagram sederhana untuk entity user dan billing details.
Pada diagram diatas, User mempunyai banyak BillingDetails dan dapat dinavigasi hubungan antara class-class tersebut dalam dua arah. Berikut ini adalah koding representasi dari class-class tersebut: public class User { private String username; private String address; private Set billingDetails; // accessor methods (get/set pairs), business methods, etc. ... }
16
public class BillingDetails { private String accountNumber; private String accountName; private String accountType; private User user; //methods, get/set pairs... ... }
Design SQL Schema untuk kasus ini adalah sebagai berikut: create table USER ( USERNAME VARCHAR(15) NOT NULL PRIMARY Key, NAME VARCHAR(50) NOT NULL, ADDRESS VARCHAR(100) ) Create table BILLING_DETAILS ( ACCOUNT_NUMBER VARCHAR(10) NOT NULL PRIMARY Key, ACCOUNT_NAME VARCHAR(50) NOT NULL, ACCOUNT_TYPE VARCHAR(2) NOT NULL, USERNAME VARCHAR(15) FOREIGN KEY REFERENCES USER )
Hubungan antara dua entitas diwakili dengan foreign key, USERNAME, dalam BILLING_DETAILS. Pada pemodelan objek sederhana diatas, Paradigm mismatch belum terlihat sama sekali; hal ini dapat dituliskan koding JDBC secara langsung untuk menambah, mengupdate, mendelete informasi tentang user dan billing details. Berikut ini adalah permasalahan-permasalahan yang akan timbul pada contoh diatas dalam Paradigm mismatch: a. The problem of granularity Granularity berhubungan dengan besar relatif suatu objek yang dikerjakan. Ketika berbicara tentang Java Object dan table-table database, permasalahannya adalah
17
Persisting Object (objek yang akan disimpan) menunjuk ke kumpulan table-table dan kolom-kolom dalam database yang terbatas. Contohnya, jika kita merubah tipe data Address yang tadinya hanya berupa String menjadi Sebuah class dimana memiliki attribut street, city, state, country, dan zipcode secara terpisah. Berikut ini adalah gambaran class diagram tersebut:
Gambar 2.4.1.1.2 User memiliki class Address.
Apakah kita mesti membuat table ADDRESS yang baru untuk menyimpan informasi address tersebut? Tidak perlu. Pada umumnya informasi address tersebut ditaruh dalam table USER di kolom tersendiri. Desain ini terlihat lebih bagus, karena kita tidak memerlukan table join untuk mengambil user dan alamatnya dalam sebuah query. Solusi yang paling bagus adalah membuat tipe data SQL secara user-defined untuk mewakili address dan menggunakan sebuah kolom dengan tipe data baru tersebut daripada beberapa kolom baru. Hal pemilihan antara beberapa kolom baru atau sebuah kolom berisi tipe data SQL baru seperti inilah yang disebut Problem of Granularity. Pemilihan tipe data SQL baru atau biasa disebut user-defined column types (UDT) sebenarnya merupakan pendekatan yang paling bagus. Sayangnya, UDT tidak portable antara berbagai database management system sekarang. Untuk itu penggunaan tipe data baru bukan merupakan pendekatan yang tepat untuk industri sekarang ini. Solusi terbaik untuk masalah ini adalah membuat beberapa kolom baru dengan tipe data
18
yang telah ada pada SQL (misalnya boolean, numeri, dan string). Pertimbangan akan granularity tersebut, maka table USER biasanya akan didefinisi sebagai berikut:
create table USER ( USERNAME VARCHAR(15) NOT NULL PRIMARY KEY, NAME VARCHAR(50) NOT NULL, ADDRESS_STREET VARCHAR(50), ADDRESS_CITY VARCHAR(15), ADDRESS_STATE VARCHAR(15), ADDRESS_ZIPCODE VARCHAR(5), ADDRESS_COUNTRY VARCHAR(15) )
b. The Problem of subtypes Dalam Java, kita mengimplementasi inheritance dengan menggunakan superdan subclasses. Hal inilah yang akan menimbulkan permasalahan dalam subtypes. Sebagai contohnya, marilah kita memperluas aplikasi e-commerce diataas dengan menambahkan bahwa aplikasi ini tidak hanya menerima bank account billing, tetapi juga dengan credit dan debit cards. Pendekatan yang paling umum untuk menangani perubahan ini adalah dengan menggunakan inheritance untuk class BillingDetails. Kita akan menggunakan BillingDetails sebagai class abstrak dengan beberapa class-class turunan konkrit: CreditCard, DirectDebit, Cheque, dan lain-lain. Masingmasing dari subclass ini akan mewakili data-data yang berbeda (begitu juga dengan fungsi-fungsi yang akan mempengaruhi data-data tersebut).
19
Gambar 2.4.1.1.3 Penggunaan inheritance untuk strategi billing yang berbeda.
Dalam hal ini SQL tidak menyediakan fasilitas langsung untuk inheritance. Kita tidak dapat mendeklarasi bahwa tabel CREDIT_CARD_DETAILS merupakan subtype dari table BILLING_DETAILS dengan cara seperti ini contohnya, CREATE TABLE CREDIT_CARD_DETAILS EXTENDS BILLING_DETAILS ( ... ). Selain inheritance, hal ini juga merupakan masalah dimana jika dalam rancangan object kita menggunakan polymorphism.
c. The Problem of identity Walaupun problem of identity mungkin tidak terlihat jelas pada saat pertama kali, kita akan sering menemukannya pada pengembangan dan perluasan dari contoh aplikasi e-commerce tadi. Masalah dapat dilihat ketika kita ingin membandingkan dua objek (contohnya, dua Users) apakah sama atau tidak. Ada tiga cara untuk mengatasi masalah ini, dua cara didalam ruang lingkup Java dan satu didalam database SQL. Dalam ruang lingkup Java identitas/kesamaan objek dapat ditentukan melalui:
20
-
Object identity (secara garis besar sama dengan alamat memory, dibandingkan dengan a==b)
-
Equality yang ditentukan oleh method equals() (juga disebut kesamaan nilai).
Dalam persepsi SQL, kesamaan baris dalam database ditentukan oleh nilai dari primary key. Pada kenyataannya, equals() dan == dalam java tidak menunjukkan identitas yang sama dengan primary key. Umumnya, beberapa objek yang memiliki identitas berbeda dapat menunjuk ke baris yang sama dalam database. Dalam table USER pada aplikasi e-commerce diatas, kita menggunakan kolom USERNAME sebagai primary key. Akibatnya hal ini membuat kita sulit untuk mengganti username: bukan saja kita harus mengupdate USERNAME pada kolom USER, tetapi berikut juga dengan kolom foreign key pada table BILLING_DETAILS. Jadi di aplikasi selanjutnya kita akan menggunakan surrogate key. Surrogate key adalah sebuah kolom primary key yang tidak mengandung arti sama sekali pada user. Sebagai contohnya kita akan mengubah definisi tabel yang telah dibuat sebagai berikut:
create table USER ( USER_ID BIGINT NOT NULL PRIMARY KEY, USERNAME VARCHAR(15) NOT NULL UNIQUE, NAME VARCHAR(50) NOT NULL, .... )
create table BILLING_DETAILS ( BILLING_DETAILS_ID BIGINT NOT NULL PRIMARY KEY, ACCOUNT_NUMBER VARCHAR(10) NOT NULL UNIQUE, ACCOUNT_NAME VARCHAR(50) NOT NULL, ACCOUNT_TYPE VARCHAR(2) NOT NULL, USER_ID BIGINT FOREIGN KEY REFERENCES USER )
21
Kolom USER_ID dan BILLING_DETAILS_ID mengandung nilai yang bakal digenerate oleh sistem. Kolom-kolom tersebut digunakan untuk kepentingan pada relational data model.
d. Problems relating to associations Dalam object model, asosiasi merupakan hubungan antara entity. Pada contoh ecommerce diatas, User, Address, dan BillingDetails saling mempunyai hubungan. Tidak seperti Address, BillingDetails berdiri sendiri. Objek BillingDetails disimpan dalam tabel tersendiri. Dalam bahasa pemrograman OOP, asosiasi menggunakan object references dan kumpulan dari object references (bisa diwakili oleh class Collection dalam Java). Sedangkan dalam dunia relational, asosiasi diwakili oleh kolom foreign key, dengan nilai primary key dari beberapa tabel. Objek references merupakan directional dimana assosiasi dari satu objek ke objek lain. Jika sebuah asosiasi ingin dapat dinavigasi dari dua arah, maka kita harus mendefinisinya dua kali di masing-masing class. Contohnya:
public class User { private Set billingDetails; ... } public class BillingDetails { private User user; ... }
22
Disisi lain, foreign key pada dasarnya tidaklah directional. Faktanya, directional tidak memiliki arti apa-apa pada relational data model, karena kita dapat menciptakan data asosiasi dengan table joins dan projection. Untuk asosiasi many-to-many dalam Java, dapat kita lihat di contoh berikut ini:
public class User { private Set billingDetails; ... } public class BillingDetails { private Set user; ... }
Tabel asosiasi dalam relational selalu merupakan one-to-many atau one-to-one. Kita dapat melihat hubungan tersebut pada definisi foreign key. Berikut ini adalah hubungan asosiasi one-to-many (atau many-to-one jika dilihat dari arah berlainan): USER_ID BIGINT FOREIGN KEY REFERENCES USER Berikut ini adalah hubungan asosiasi one-to-one: -
USER_ID BIGINT UNIQUE FOREIGN KEY REFERENCES USER
-
BILLING_DETAILS_ID
BIGINT
PRIMARY
KEY
FOREIGN
KEY
REFERENCES USER Jika kita ingin membuat hubungan asosiasi many-to-many dalam relational database, maka kita harus membuat sebuah tabel baru, yang disebut link table. Tabel ini tidak akan muncul dalam object model. Sebagai contohnya, kita akan membuat hubungan many-to-many antara user dan informasi billing dari user. Link table yang akan didefinisikan adalah sebagai berikut:
23
CREATE TABLE USER_BILLING_DETAILS ( USER_ID BIGINT FOREIGN KEY REFERENCES USER, BILLING_DETAILS_ID BIGINT FOREIGN KEY BILLING_DETAILS PRIMARY KEY (USER_ID, BILLING_DETAILS_ID) )
REFERENCES
e. The problem of object graph navigation Ada perbedaan mendasar jika kita mengakses objek dari Java dan mengakses data pada relational database. Dalam Java, untuk mengakses informasi billing dari user, kita dapat memanggil method aUser. getBillingDetails().getAccountNumber().
Cara
ini merupakan yang paling alami untuk mengakses data dalam object-oriented yang disebut dengan walking of object graph. Akan tetapi, hal ini bukan merupakan cara yang efisien dalam mengakses data pada SQL database. Satu hal yang paling utama yang dilakukan untuk peningkatan performance dalam pengaksesan data adalah dengan minimalisasi jumlah request ke database. Cara yang paling nyata untuk dilakukan adalah dengan minimalisasi jumlah query pada SQL (Cara lain, yaitu dengan stored procedure atau JDBC batch API). Oleh karena itu, pengaksesan data efisien melalui SQL memerlukan joins dari tabel-tabel yang diperlukan. Jumlah tabel yang dimasukkan ke dalam join menentukan seberapa dalam object graph yang dapat kita navigasi. Contohnya, jika kita ingin mengakses seorang User dan tidak tertarik pada BillingDetails, maka kita dapat menggunakan query yang sederhana, yaitu: select * from USER u where u.USER_ID = 123 Disisi lain, jika kita ingin mengambil informasi User yang sama beserta BillingDetails yang dipunyainya maka kita menggunakan query yang berbeda: select * from USER u 24
left outer join BILLING_DETAILS bd on bd.USER_ID = u.USER_ID where u.USER_ID = 123 Seperti yang dapat dilihat diatas, kita harus mengetahui berapa besar/dalam object graph yang akan kita akses sebelum kita mengambil nilai User pada awal pertama kali, sebelum kita mulai menavigasi object graph yang ada. Disisi lain, umumnya solusi yang dapat dilakukan adalah dengan men-fetch data dari objek yang berhubungan hanya ketika objek itu pertama kali diakses. Akan tetapi, hal ini menimbulkan ketidakefesiensi pada pengambilan data dari relational database, karena diperlukan satu eksekusi tiap node dari object graph yang ada (n+1 problem). Hal ini merupakan masalah performance dalam pengaksesan data.
f. The cost of mismatch Solusi keseluruhan dari masalah mismatch dapat menghabiskan waktu dan usaha yang signifikan. Pada pengamalaman umumnya, hampir 30 persen dari koding aplikasi Java yang ditulis adalah untuk menangani SQL/JDBC yang monoton dan konversi manual antara object/relational paradigm mismatch. Meskipun dari semua upaya ini, hasil akhirnya juga tidak kelihatan sesuai. Kita telah banyak melihat kebanyakan project-project gagal dikarenakan masalah kompleksitas dan fleksibilitas dari layer abstraksi database mereka. Salah satu kendala utama adalah didalam object modeling. Relational dan object modeling harus mencakup entitas bisnis yang sama. Akan tetapi pemodelan objectoriented berbeda dengan pemodelan relational. Cara umumnya adalah membelokkan struktur object-model sampai menyesuai dasar teknologi relational. Hal ini dapat
25
digunakan dengan sukses, akan tetapi hal ini mengakibatkan kehilangan beberapa keuntungan dari orientasi objek.
2.4.1.2 Alternatif-alternatif pada Persistence Layer Persistence Layer adalah kumpulan komponen dan class-class yang bertanggung jawab dalam hal penyimpanan data ke, dan pengambilan data dari, satu atau lebih tempat penyimpanan data (database). Pada layer ini disertakan model dari entitas business domain (walaupun hanya sebagai model metadata). Berikut ini akan dijelaskan alternatif-alternatif yang dapat digunakan pada persistence layer:
a. Hand-coding sebuah persistence layer dengan SQL/JDBC Pendekatan paling umum dari para developer java adalah dengan berinteraksi secara langsung ke database dengan SQL dan JDBC. Lagipula, para developer telah familiar dengan relational database managements systems (RDBMS), mengerti SQL, dan tahu bagaimana cara bekerja dengan tabel-tabel dan foreign keys. Lebih dari itu, mereka dapat menggunakan design pattern DAO (Data Acess Object) untuk menyembunyikan kompleksitas JDBC code dan nonportable SQL dari business logic. Pattern DAO merupakan salah satu design yang bagus. Akan tetapi, upaya untuk koding manual untuk setiap domain class mesti dipertimbangkan, khususnya ketika kita harus mendukung multiple SQL dialect. Upaya ini biasanya menghabiskan sebagian besar upaya dalam development suatu aplikasi. Dan lagi jika terjadi perubahan, maka solusi hand-coded membutuhkan lebih banyak perhatian dan upaya maintenance yang lebih. 26
b. Menggunakan Serialization Java mempunyai mekanisme built in untuk persistence: Serialization menyediakan kemampuan untuk menulis kumpulan graph of object (application state) ke dalam byte-stream, dimana akan disimpan ke dalam file ataupun database. Serialization juga digunakan oleh Java dalam Remote Method Invocation (RMI) untuk menggunakan pass-by-value pada objek yang kompleks. Kegunaan lain pada RMI adalah mereplekasi application state diantara node-node dalam mesin-mesin cluster. Kenapa kita tidak menggunakan serialization buat persistence layer? Sayangnya penggunaan serialized graph dari objek-objek yang saling berhubungan hanya bisa diakses secara keseluruhan; tidak mungkin dapat mengambil sebagian data tanpa mesti deserialized keseluruhan stream. Hasil yang berupa byte-stream dipertimbangkan tidak sesuai untuk proses searching maupun aggregasi. Selain itu, tidaklah mungkin kita dapat mengakses atau mengupdate sebuah objek maupun subgraph dari object graph secara bebas. Loading dan overwriting keseluruhan object graph dalam setiap transaksi merupakan satu-satunya pilihan untuk mendukung concurrency yang tinggi. Seperti yang dibahas diatas, serialization tidak sesuai sebagai mekanisme persistence layer bagi web yang memerlukan concurrency yang tinggi dan aplikasi enterprise. Serialization dapat dianggap sebagai mekanisme persistence layer yang bagus untuk aplikasi desktop.
c. Menggunakan EJB entity beans Dalam tahun terakhir ini, Entity beans dalam Enterprise Java Bean (EJB) telah direkomendasikan sebagai dalam hal persistence data. Akan tetapi, penggunaan Entity Bean merupakan bencana pada prakteknya. Kecacatan design dalam spesifikasi EJB 27
mencegah bean-managed-persistence (BMP) entity beans dari penggunaan secara efisien. Solusi yang lebih diterima adalah container-managed persistence (CMP) . Akan tetapi CMP, tidak menyelesaikan masalah pada object/relational mismatch. Berikut ini adalah alasan-alasannya: -
CMP beans didefinisikan secara satu-persatu dengan tabel-tabel yang ada sehingga tidak dapat memanfaatkan keuntungan Java yang kaya akan segala jenis pendeklarasian. CMP membuat domain model kita menjadi normal form yang pertama.
-
Walaupun EJB dapat mengambil keuntungan dari inheritance, entity beans tidak mendukung adanya polymorphism yang menjadi salah satu keunggulan OOP.
-
EJB tidak portable, karena kemampuan engine CMP berbeda tiap vendor, dan mapping metadata yang dimiliki sangatlah bergantung pada vendor-vendor tertentu.
-
EJB bukan serializable. Kita harus menggunakan tambahan data transfer object (DTO, atau disebut value objects) ketika kita ingin mentransfer data ke remote client tier.
-
Model pada EJB tidaklah mengikuti aturan style dari Java dan membuat penggunaan code kembali (reuse code) menjadi sulit jika diterapkan di containercontainer tertentu.
28
d. Object-oriented database systems Sejak kita menggunakan Java, tentunya sangatlah ideal jika kita dapat menyimpan dan mengambil data dalam database tanpa harus mengubah struktur object model sama sekali. Pada pertengahan tahun 1990 , object-oriented database management system (OODBMS) telah diperkenalkan. Seperti dengan ANSI SQL, sebuah standar query interface untuk relational database. Ada standarisasi pada produk object database juga. Object Data Management Group (ODMG) mendefinisikan API, query language, metadata language, dan host binding seperti C++, SmallTalk, dan Java. Kebanyakan produk-produk object database menyediakan dukungan dari standar ODMG. Akan tetapi, pada saat ini belum ada implementasi keseluruhan yang telah diterapkan. Walaupun telah beberapa tahun sejak pengeluarannya, bahkan pada versi 3.0, spesifikasinya masih terasa belum matang dan masih kurang beberapa feature-feature yang penting, khususnya dalam lingkungan Java. ODMG juga telah tidak aktif lagi. Pada akhir-akhir ini, spesifikasi Java Data Objects (JDO) (dipublish pada April 2002) telah memungkinkan adanya kemungkinan baru. Kesimpulannya adalah bahwa OODBMS masih belum terlalu matang untuk dipakai dan diadaptasi untuk beberapa tahun kedepan sehingga relational database masih merupakan pilihan yang tepat sebagai tempat penyimpanan data (persistence).
2.4.1.3. Object relational mapping (ORM) Untuk sekarang ini, kita akan menunjukkan dan membahas solusi alternatif yang dirasakan yang terbaik saat ini untuk object persistence. Solusi ini merupakan object/relational mapping (ORM) atau kadang-kadang disebut object mapping secara singkat. Berikut ini akan dijelaskan lebih rinci mengenai apa itu ORM. 29
2.4.1.3.1. Apa itu ORM? Secara garis besar, object/relational mapping konversi secara otomatis (dan transparan) dari object dari aplikasi java ke tabel-tabel dalam relational database, dengan menggunakan metadata yang menggambarkan mapping-an antara object-object dengan tabel-tabel yang ada. (Bauer, Christian and Gavin King. (2005). Hibernate In Action. Manning Publications Co, Greenwich, Ebooks) Hal ini mengakibatkan pengurangan performance dalam aplikasi yang memakai ORM. Akan tetapi, jika ORM diimplementasikan sebagai middleware, maka tersedia banyak optimalisasi yang tidak mungkin dilakukan pada hand-coded persistence layer. Overhead lain yang terjadi (pada saat development) adalah penetapan dan manajemen metadata yang menentukan transformasi data antara object dengan tabel. Tetapi sekali lagi, cost yang dihasilkan akan lebih kecil daripada cost yang melibatkan masalah maintenance pada solusi hand-coded. Solusi ORM mencakup 4 hal berikut ini: -
API yang melakukan operasi dasar CRUD pada object dari persistence class.
-
Bahasa atau API untuk menentukan query-query yang menunjuk ke class-class dan property-propertynya.
-
Fasilitas untuk menentukan mapping metadata.
-
Teknik implementasi ORM untuk berinteraksi dengan object transactional untuk melakukan dirty checking, lazy association fetching, dan fungsi-fungsi optimalisasi yang lain.
30
Penggunaan istilah ORM adalah dimana suatu persistence layer mengenerate SQL secara otomatis yang dihasilkan dari deskripsi metadata. Kita tidak menggolongkan suatu persistence layer dimana masalah object/relational mapping diselesaikan secara manual oleh developer dengan menggunakan SQL dan JDBC ke dalam istilah ORM. ORM dapat diimplementasikan dengan berbagai cara. Mark Fussel [Fussel 1997], seorang peneliti dalam bidan ORM, mendefinisikan 4 level dari qualitas ORM sebagai berikut:
a. Pure Relational Keseluruhan aplikasi, termasuk user interface, di desain disekitar relational model dan operasi-operasi relational yang berdasarkan SQL. Pendekatan ini, selain dari ketidakefesiensi untuk system yang besar, dapat merupakan pilihan yang tepat untuk aplikasi sederhana dimana low level of code reuse dapat ditoleransi. Direct SQL dapat dioptimasi di setiap aspek, tetapi akibatnya dapat menimbulkan kurangnya portability dan maintainability yang signifikan, terutama jika dijalankan dalam waktu yang lama. Aplikasi pada kategori ini sering memakai stored procedure yang menangani beberapa proses dari business layer dan ke dalam database.
b. Light Object Mapping Entitas-entitas direpresentasikan sebagai class-class yang di map secara manual ke tabel-tabel relational. Hand-coded SQL/JDBC disembunyikan dari business logic dengan menggunakan design pattern tertentu. Pendekatan ini sangatlah menyebar luas dan berhasil untuk aplikasi dengan jumlah entitas yang kecil, atau aplikasi biasa. Stored procedure masih dimungkinkan pada aplikasi seperti ini. 31
c. Medium Object Mapping Aplikasi ini dirancang dengan object-model. SQL dihasilkan pada saat build time dengan menggunakan code generation tool, atau pada saat runtime dengan menggunakan framework. Hubungan antara object-object ini didukung oleh mekanisme persistence, and query-query biasanya ditentukan dengan menggunakan object-oriented expression language. Object-object di-cache oleh persistence layer. Kebanyakan produk-produk ORM yang bagus paling tidak telah mendukung fungsionalitas ini. Pendekatan ini cocok untuk aplikasi berukuran medium dengan beberapa transaksi complex, terutama ketika portabilitas antara beberapa produk database dinilai penting. Aplikasi-aplikasi ini biasanya tidak menggunakan stored procedure.
d. Full Object Mapping Full Object Mapping mendukung penerapan object-modeling secara keseluruhan: composition, inheritance, dan polymorphism. Persistence Layer ini mengimplementasi transparent persistence dimana class-class persistence tidak mewarisi base-class apapun maupun implement interface tertentu. Strategi fetching yang efesien (lazy dan eager fetching) dan strategi caching telah diimplementasi secara transparan dalam aplikasi ini. Pendekatan Full Object Mapping inilah yang akan digunakan dalam aplikasi kita nantinya.
2.4.1.3.2 Permasalahan-permasalahan umum ORM Berikut ini adalah permasalahan-permasalahan ORM, dimana permasalahan fundamentalnya akan diselesaikan dengan tool full object/relational mapping dalam lingkungan Java: 32
a. Bagaimana bentuk sebuah persistent class? Apakah merupakan JavaBeans? Atau class-class tersebut merupakan instance dari komponen spesifik seperti EJB? Sebagaimana transparant sebuah persistence tool? Apakah kita harus memakai model programming dan konvensi-konvensi untuk business domain class? b. Bagaimana metadata di definisi? Karena transformasi object/relational ditentukan oleh metadata, format dan definisi metadata menjadi masalah penting. Apakah tool ORM harus menyediakan tool graphis untuk memanipulasi metadata? Atau ada pendekatan lain yang lebih baik bagi definisi metadata? c. Bagaimana kita me-map hirarki inherintance? Ada beberapa strategi disini. Akan tetapi bagaimana dengan hubungan polymorphism, abstract class, dan interface? d. Bagaimana identitas dan persamaan object berhubungan dengan identitas database (primary key)? Bagaimana me-map instance dari class-class tertentu ke baris-baris pada tabel-tabel tertentu? e. Bagaimana persistence logic berinteraksi pada saat runtime dengan object-object dari business domain? Ini adalah problem yang umum, dan tersedia banyak penyelesaian termasuk source generation, runtime reflection, runtime bytecode generation, dan buildtime bytecode enhancement. f. Bagaimana lifecycle suatu objek persistence? Apakah lifecycle suatu objek bergantung pada lifecycle dari objek lain yang berhubungan? Bagaimana kita menerjemahkan lifecycle sebuah objek ke lifecyle sebuah baris pada database? g. Fasilitas apa yang disediakan untuk pengurutan (sorting), pencarian (searching), dan agregasi (aggregation)? Suatu aplikasidapat mengerjakan fungsi ini dalam memory. Tetapi penggunaan relational database yang efisien membutuhkan fungsi ini dikerjakan dalam database. 33
h. Bagaimana kita mengambil data dengan asosiasi secara efesien? Cara akses yang efesien ke data relational dapat dilakukan dengan table joins. Aplikasi objectoriented biasanya diakses melalui navigasi object graph.
2.4.1.3.3 Mengapa ORM? Implementasi penggunaan ORM adalah kompleks-kurang kompleks dari sebuah aplikasi server, akan tetapi lebih kompleks dari framework aplikasi web seperti Struts atau Tapestry. Tujuan utama dari ORM adalah menghindari developer dari penggunaan SQL yang terlalu merepotkan. Berikut ini adalah beberapa keuntungan dari pemakain ORM pada framework Hibernate:
a. Productivity Kode yang berhubungan dengan persistence dapat menjadi bagian kode yang membosankan dalam aplikasi Java. Dalam ORM, pengerjaan ini telah dihilangkan, sehingga developer dapat lebih memfokuskan pada business problem. Dengan demikian maka waktu development dapat menjadi singkat secara signifikan.
b. Maintainability Lines of code (LOC) yang lebih sedikit membuat sistem lebih mudah dimengerti karena code lebih ditekankan pada business logic. Yang paling penting, sebuah sistem dengan code yang lebih dikit akan lebih mudah di refactor. Object/relational peristence yang secara otomatis dilakukan oleh ORM membuat pengurangan yang besar terhadap
34
LOC. Tetapi tentu saja, penggunaan LOC tidak bisa dipakai untuk menilai kompleksitas aplikasi terhadap keseluruhan. Dalam sistem dimana hand-coded persistence yang dipakai sebagai persistence layer, terjadi hubungan keterikatan antara representasi relational dengan object model. Hal ini mengakibatkan perubahan disatu sisi mengakibatkan perubahan disisi lain juga sehingga menyulitkan maintainabilitas. ORM (Hibernate) menyediakan buffer antara kedua model tersebut, sehingga memudahkan perubahan-perubahan dari tiap model yang hanya berakibat perubahan kecil terhadap yang lainnya.
c. Performance Pada kenyataannya, hand-coded-persistence akan lebih cepat jika dibandingkan dengan automated persistence. Akan tetapi, hal ini dapat dipertanyakan jika dipertimbangkan dengan batas waktu dan anggaran. Dalam pengerjaan persistence, dapat dilakukan banyak optimalisasi. Beberapa (seperti query hints) dapat dilakukan lebih mudah dengan hand-coded SQL/JDBC. Kebanyakan optimalisasi, bagaimanapun juga, lebih mudah dilakukan dengan automated ORM. Dalam projek dengan batas waktu tertentu, hand-coded persistence biasanya memerlukan optimasi pada saat tertentu. Akan tetapi Hibernate (ORM) dapat dioptimalisasi pada setiap saat. Dan lagi, automated persistence sangat meningkatkan produktivitas developer sehingga kita dapat menghabiskan waktu lebih lama pada optimalisasi beberapa hambatan yang tersisa. Dan yang terakhir, orang-orang yang mengimplementasi software ORM memiliki lebih banyak waktu untuk menyelidiki optimalisasi performance. Contoh kasusnya
dapat
dilihat
pada
penerapan 35
pooling
instance
PreparedStatement
meningkatkan performance secara signifikan pada JDBC Driver DB2, akan tetapi menurun di JDBC Driver InterBase. Dan kasus lainnya, berupa pengupdatean kolomkolom yang hanya berubah nilainya dapat mempercepat aplikasi pada database-database tertentu, tetapi juga dapat memperlambat aplikasi pada database-database lainnya. Dalam hand-coded persistence, hal ini akan menjadi sulit dilakukan.
d. Vendor Independence Sebuah ORM memisahkan aplikasi dari database SQL dan dialek SQL. Pada umumnya tiap-tiap vendor memiliki dialek-dialek SQL tersendiri, sehingga dengan bantuan ORM, kita dapat meningkatkan portabilitas pada suatu aplikasi. Dan juga, ORM memudahkan portabilitas antara berbagai platform sehingga menghindarkan kita dari vendor lock-in. ORM juga membantu kemudahan dalam tahap development dengan pemakaian database yang ringan pada saat develop tetapi pada saat produksi memakai database yang berbeda.
2.4.1.3.4 Hibernate Hibernate adalah suatu produk ORM yang Open Source yang merupakan penerapan Full Object Mapping pada jenis ORM yang telah dibahas sebelumnya. (Bauer, Christian and Gavin King. (2005). Hibernate In Action. Manning Publications Co, Greenwich, Ebooks). Hibernate merupakan suatu proyek yang menargetkan suatu solusi yang lengkap untuk permasalahan dalam hal mengatasi masalah data persistence dalam Java. Hibernate merupakan perantara interaksi antara aplikasi Java dengan relational database, dimana membuat developer hanya memfokuskan diri pada business logic dan permasalahan bisnis tanpa harus mengurusi operasi CRUD secara low level. 36
2.4.2 View View merupakan bagian layer yang me-render model dalam interaksi yang sesuai dengan keinginan user, khususnya berupa user interface. MVC sering ditemukan pada aplikasi web, dimana view berupa halaman HTML dan code yang mengumpulkan data dinamis untuk halaman tersebut. Framework yang akan dipakai untuk aplikasi ini adalah Java Server Faces (JSF) dimana JSF ini akan mengatur tampilan user interface dalam web aplikasi ini dengan mengenerate HTML secara dinamis sesuai data yang akan diambil dari model. Untuk perpisahan antara tampilan dan logika dari aplikasi, maka JSF menyediakan custom tags untuk perwakilan setiap komponen-komponen tampilan pada HTML.
2.4.3 Controller Controller adalah bagian layer yang merespon event-event, khususnya user action, dan melakukan pemanggilan perubahan pada model maupun view. Dalam hal ini layer controller yang dibuat akan memakai framework JSF dimana arah navigasi beserta logika bisnis akan dibuat dengan bantuan framework JSF ini. Pada framework JSF ini, controller yang akan digunakan adalah berdasarkan Dependency Injection atau terkadang disebut juga Inversion of Control, dimana telah disediakan sekumpulan service yang merupakan abstraksi dari logika-logika bisnis yang telah dibuat dimana implementasi logika-logika bisnis tersebut disembunyikan dalam service tersebut. Hal ini merupakan penerapan pattern MVC yang baik karena jika terjadi perubahan pada sistem, maka implementasi logika bisnis tersebut yang berubah, sedangkan service yang telah diberikan tetap sama. Hal ini memisahkan antara bagian layer view dan controller.
37
2.5 HTTP (Hyper Text Transfer Protocol) Saat
menjadi
protokol(protocol)
penghubung
formal.
Aturan
antara
negara,
diplomatis
di
diplomat desain
perlu
untuk
mengikuti menghindari
kesalahpahaman dan menjaga negosiasi menjadi gagal. Ini juga mirip dengan computer yang perlu berbicara, dan mereka juga mengikuti protocol formal. Protokol mendefinisikan bagaimana data dikirimkan dan bagaimana decode saat sampai. Aplikasi web menggunakan Hypertext Transfer Protocol (HTTP) untuk menggerakan data antara browser yang ada pada computer anda dan aplikasi yang berjalan pada server. Banyak aplikasi server berkomunikasi menggunakan protocol selain http. Beberapa dari hal tersebut memelihara keberlangsungan koneksi antara computer. Aplikasi server mengetahui siapa saja yang terhubung setiap saat dan dapat memberitahu saat koneksi terputus. Karena mereka tahu status dari setiap koneksi dan identitas dari setiap orang yang menggunakannya, ini di kenal dengan protocol stateful. Sebaliknya, HTTP diketahui sebagai stateless protocol. Sebuah server HTTP dapat menerima request apapun dari client manapun dan akan selalu emnyediakan beberapa tipe respon, walaupun respon tersebut hanya berupa jawaban tidak. Tanpa overhead dari negosiasi dan menahan koneksi, stateless protocols dapat mengatasi request dalam jumlah besar. Ini salah satu alsan mengapa internet dapat menghubungkan jutaan computer. Kesederhanaan adalah alasan lain HTTP menjadi standar universal. Sebuah request HTTP mirip sebuah dokumen yang berisi teks. Ini memudahkan untuk aplikasi untuk membuat HTTP request. Bahkan sebuah HTTP request dapat dikirimkan menggunakan Telnet. Saat ada respon dari HTTP, ini berupa teks biasa yang dapat dibaca oleh developer. 38
Baris pertama di HTTP request berisi method yang diikuti dengan lokasi sumber request, dan versi dari HTTP tersebut. Baris awal dapat diikuti tidak sama sekali atau banyak HTTP request header. HTTP header menyediakan informasi tambahan ke server, berupa tipe browser dan versinya, tipe dokumen yang dapat diterima, dan cookies. Dari tujuh metode request, get dan post adalah yang paling populer. Setelah server menerima dan melayani request, maka akan memberi HTTP reponse. Baris pertama dari respon disebut baris status dan membawa versi HTTP protocol, status numerik, dan penjelasan singkat status tersebut. Berikutnya, server akan mengembalikan HTTP response header yang bekerja mirip dengan request header. Seperti yang disebutkan, HTTP tidak melindungi informasi status antar request. Server mencatat request, mengirim respon, dan melayani request selanjutnya. Walaupun sederhana dan efisien, sebuah stateless protocol bermasalah bagi aplikasi dinamis yang perlu melacak usernya. Cookies dan penulisan ulang URL adalah dua cara yang paling umum untuk melacak user di antara request. Cookie adalah sebuah paket informasi khusus pada komputer user. Penulisan ulang URL menyimpan referansi khusus di halaman alamat dimana user dapat dilacak oleh server Java. Dengan sendirinya, sebuah web standar HTTP tidak dinamis. Biasanya menggunakan request untuk menemukan sebuah file dan mengembalikan file sebagai respon. Tipe file tersebut berupa Hypertext Markup Language (HTML) [W3C, HTML] yang dapat ditampilkan oleh web browser. Halaman HTML mencakup hypertext link ke halaman web lainnya dan juga menampilkan gambar dan video. User mengklik sebuah link untuk request selanjutnya, dan proses yang baru pun dimulai. Web server standar menangani static content dan gambar dengan baik namun diperlukan bantuan untuk menyediakan respon dinamis. 39
2.6. Common Gateway Interface (CGI) Standar pertama yang digunakan untuk menghasilkan dynamic content adalah Common Gateway Interface (CGI). CGI menggunakan fitur system operasi standar, seperti environment variable dan standar input output, untuk membuat sebuah bridge, atau gateway, diantara web server dan aplikasi lainnya pada host machine. Aplikasi lain dapat request yang dikirimkan oleh web server dan membuat sebuah respon. Ketika sebuah web server menerima sebuah request yang ditujukan untuk program CGI, web server menjalankan program dan menyediakan program dengan informasi dari request yang masuk. Program CGI menjalankan dan mengirimkan output kembali ke server. Web server menyampaikan respon ke browser. Seperti halnya HTTP, CGI fleksibel dan mudah untuk diimplementasikan, dan sejumlah besar program CGI-aware telah ditulis. Kekurangan utama dari CGI yaitu harus menjalankan sebuah duplikat program CGI-aware yang baru untuk setiap request. Proses ini memakan biaya yang besar yang dapat menurunkan kapasitas situs ketika ribuan request harus dilayani dalam satu menit. Kekurangan lainnya yaitu tidak multiplatform.
2.7 Java Servlets Sun Java Servlet memecahkan dua masalah utama dari program CGI. Pertama, servlet memberikan kinerja lebih baik dan sumber yang lebih bermanfaat daripada program CGI. Kedua, dapat dijalankan di mana saja asalkan system operasi tersebut memiliki Java Virtual Machine (JVM). Servlet terlihat seperti sebuah web server kecil. Servlet menerima request dan render sebuah respon. Tetapi tidak seperti web server biasa, servlet application
40
programming interface (API) secara khusus dirancang untuk membantu membuat aplikasi dinamis. Servlet sendiri hanyalah sebuah class Java yang sudah dicompile dalam byte code, seperti objek Java lainnya. Servlet mempunyai akses ke API of HTTP-specific services, tetapi tetap saja sebuah objek Java yang dijalankan pada sebuah aplikasi. Agar web server dapat mengakses servlet, servlet dihubungkan dengan container. Container dihubungkan dengan web server. Setiap servlet dapat menyatakan pola URL yang ditangani. Apabila ada request yang sesuai dengan pola, web server meneruskan request tersebut ke container, dan container invoke servlet. Tidak seperti program CGI, sebuah servlet tidak diciptakan setiap ada request baru tetapi dibuat sebuah thread baru untuk setiap request. Java thread lebih murah daripada proses server yang digunakan oleh program CGI. Pengguna Servlet dapat menggunakan metode init()
untuk
menangani
sumber
seperti
koneksi database atau EJB Home Interfaces. Untuk memperoleh sumber seperti ini memakan waktu beberapa detik lebih lama, kurangnya keamanan karena multithreaded.
2.8 Java Server Pages (JSP) Untuk membuat sebuah Java-Server Pages, developer mulai dengan membuat halaman HTML dan syntax HTML yang sama seperti sebelumnya dan halaman HTML tersbut di save dengan extension .jsp. Agar menjadi dinamis, developer dapat memasukkan script JSP. Scripting element adalah tag yang mengencapsulate yang dikenal JSP.
41
Ketika client me request halaman JSP, container menerjemahkan halaman tersebut ke source code untuk Java servlet dan mengcompile ke file Class Java. Saat runtime, container juga dapat memeriksa tanggal modifikasi terakhir dari file JSP. Jika file JSP telah diubah sejak terakhir dicompile, container akan menerjemahkan kembali dan membuat ulang halaman tersebut.
2.9 JSP Tags Scripting element adalah salah satu dari dua cara untuk mengenerate dynamic JSP content. Scriptlet cepat dan mudah tetapi perlu campuran Java code dengan HTML. JSP tags dicampur dengan HTML markup dan dapat digunakan sebagai HTML tags biasa. Sebuah tag JSP mewakilkan sejumlah statement Java. Code program disembunyikan dalam sebuah file class Java. Untuk menggunakan code yang sama pada halaman lainnya, developer hanya cukup memasukan tag markup. Bila tag code berubah, semua tag secara otomatis menggunakan versi yang baru. Halaman JSP yang menggunakan tag tidak perlu di revisi. Tag JSP dapat digunakan kembali lebih baik dari scriptlet dan mempermudah penggunaan. Sejumlah prebuilt JSP tags library dapat menampilkan fungsi yang berguna bagi developer. JSP Standard Tag Library (JSTL) yang baru merupakan library yang berisi banyak tag yang dapat digunakan kembali.
2.10 Java Beans JavaBeans adalah class Java yang disesuaikan dengan pola desain yang memudahkan penggunaan development tools dan komponen lainnya. JavaBean adalah komponen software reuseable yang dituliskan dalam Java. Untuk dianggap sebagai JavaBean, class harus kongkrit dan public, dan memiliki noargument constructor.. 42
JavaBean mengutamakan internal fields sebagai properties dengan menyediakan public method yang mengitkui pola desain yang konsisten. Mengetahui bahwa nama property mengikuti pola ini, classs java lainnyadapat menggunakan introspection untuk menemukan dan manipulasi JavaBean properties. Pola desain JavaBean menyediakan akses ke internal state melalui 2 cara : accessors digunakan untuk membaca kondisi JavaBean; mutators digunakan untuk merubah kondisi JavaBean. Mutator selalu diawali dengan lowercase token. Karakter pertama pada nama property harus uppercase. Nilai kembalinya(The return value) selalu void—mutator hanya merubah nilai property; dan tidak menerimanya. Mutator untuk property sederhana hanya mengambil satu parameter dalam signature, dapat berupa bermacammacam tipe. Mutator sering dijuluki setter setelah prefixnya. Pola desain yang serpa digunakan untuk membuat accessor method signature. Accessor method selalu selalu diawali dengan lowercase token get, diikuti dengan nama property. Karakter pertama pada nama properti harus uppercase. Return value akan sesuai dengan parameter metode dalam corresponding mutator. Accessors untuk property yang sederhana tidak dapat menerima parameter pada method signature. Accessors sering disebut getters. Bila accessor mengembalikan nilai logical, ada berbagai pola. Dibandingkan menggunakan lowercase token get, sebuah logical property dapat menggunakan prefix is, diikuti dengan nama properti. Karakter pertama dari nama property harus uppercase. Return value akan selalu logical value. Logical accessors tidak dapat menerima parameter dalam method signature.
43
Canonical method signatures memegang peran penting saat menggunakan JavaBeans. Komponen lainnya dapat menggunakan Java Reflection API untuk menemukan properti JavaBean dengan mencari metode yang di awali dengan set, is, atau get. Bila komponen menemukan signature pada JavaBean, maka method dapat digunakan untuk meng-akses atau merubah property bean. Sun memperkenalkan JavaBeans untuk menangani komponen GUI, tapi seakarang digunakan di setiap aspek dalam pembuatan Java, termasuk aplikasi web. Data dinamis untuk halaman dapat dikirimkan sebagai JavaBean, dan JSP tag dapat menggunakan property bean untuk mengatur output.
2.11 Java Server Faces Dinilai dari website iklan lowongan pekerjaan, ada 2 teknik yang populer dalam pengembangan aplikasi web. ¾ Cara “Rapid Development”, yang menggunakan “Visual Development” seperti Microsoft Asp.NET. ¾ Cara “Hard Core Coding”, menulis program yang banyak dengan tujuan menunjang back end dengan peforma tinggi seperti J2EE (The Java 2 Enterprise Edition). Dalam menulis buku ini, team penulis menghadapi pilihan yang sulit. J2EE adalah platform yang menarik. J2EE sangat “scalable”, dapat digunakan di banyak macam platform, dan di dukung oleh banyak vendor. Di lain pihak, ASP.NET dapat membuat tampilan(interface) yang menarik tanpa program yang membosankan. Tentu saja programmer ingin keduanya : hasil peforma tinggi dan program user interface yang mudah.
44
Janji dari Java Server Faces adalah membawa pengguna program Rapid user interface pada server-side dalam Java. (Kito D. Mann. (2005). JavaServer Faces In Action. Manning Publications Co, Greenwich, Ebooks) Java Server Faces (JSF) adalah framework web aplikasi yang mempermudah development user interface untuk aplikasi J2EE. JSF menggunakan JavaServer Pages (JSP) untuk teknologi tampilannya, akan tetapi JSF dapat juga menyediakan untuk teknologi tampilan yang lain, seperti XUL. (David, Cay. (2005). Core JavaServer Faces. Prentice Hall, New Jersey, Ebooks) Jika Anda telah mengenal Client-side dari Java, Anda dapat berpikir bahwa adalah sebuah “swing untuk aplikasi server-side”. Jika Anda memiliki pengalaman Java Server Page (JSP), Anda dapat menemukan bahwa JSF menyediakan banyak komponen-komponen dasar yang pengembang JSP harus mengembangkan sendiri. Jika Anda telah mengenal framework server-side seperti “Struts”, Anda akan menyadari bahwa JSF menggunakan arsitektur yang serupa. (Ted H., Cedric D., George F., David W. (2003). Struts In Action. Manning Publications Co, Greenwich, Ebooks). JSF memiliki ini : ¾ Seperangkat komponen User Interface yang tinggal digunakan. ¾ Sebuah contoh program event-driven. ¾ Sebuah contoh komponen yang memungkinkan pengembang orang ketiga untuk memberikan komponen tambahan. JSF memiliki semua code yang perlu untuk event handling dan pengaturan komponen. Programmer aplikasi dapat mengabaikan detil-detilnya dan hanya berkonsentrasi pada pengembangan logika bisnisnya. 45
Dalam teknisnya, JSF terdiri dari: -
Kumpulan API untuk merepresentasikan komponen UI dan mengatur state mereka, menangani event dan validasi input, definisi navigasi halaman, dan mendukung internationalization dan accessibility.
-
Kumpulan komponen-komponen umum.
-
Dua library custom tag JavaServer Pages (JSP) untuk menampilkan tampilan JavaServer Faces dalam halaman JSP.
-
Sebuah server-side event model.
-
State Management.
-
Managed Beans (JavaBeans yang diciptakan lewat dependency injection).
Berikut ini adalah custom tag yang umum digunakan dalam JSF: Tabel 2.11.1 JSF Core Tags Tag view subview facet attribute param actionListener valueChangeListener convertDateTime convertNumber validator validateDoubleRange validateLength validateLongRange loadBundle selectitems selectitem verbatim
Description Membuat tampilan top-level Membuat subview dari tampilan Menambahkan sebuah facet pada komponen Menambahkan sebuah atribut (key/value) pada komponen Menambahkan parameter pada komponen Menambahkan action listener pada komponen Menambahkan valuechange listener pada komponen Menambahkan konverter waktu/tanggal pada komponen Menambahkan konverter angka converter pada komponen Menambahkan validator pada komponen Validasi range double untuk nilai komponen Validasi panjang karakter untuk nilai komponen Validasi range long untuk nilai komponen Meload resource bundle, properti-properti disimpan dalam java.util.Map Menentukan item-item (banyak) untuk sebuah pilihan atau banyak pilihan dalam suatu komponen Menentukan item (satu) untuk sebuah pilihan atau banyak pilihan dalam suatu komponen. Menambahkan markup pada JSF
46
Tabel 2.11.2 JSF HTML Tags Tag form inputText inputTextarea inputSecret inputHidden outputLabel outputLink outputFormat outputText commandButton commandLink message messages graphicImage selectOneListbox selectOneMenu selectOneRadio selectBooleanCheckbox selectManyCheckbox selectManyListbox selectManyMenu panelGrid panelGroup dataTable column
Description Form pada HTML Textfield pada HTML TextArea pada HTML Field password pada HTML Field tersembunyi Label untuk penglihatan pada komponen lain HTML anchor Seperti outputText, tetapi bersifat majemuk Berupa hasil keluaran text biasa Tombol submit, reset atau pushbutton (button yg dapat ditekan) Menghubungkan link seperti pushbutton Menampilkan pesan yang baru dibuka untuk sebuah komponen Menampilkan semua pesan Menampilkan sebuah image Single-select listbox Single-select menu Radio button pada HTML Checkbox untuk boolean Multiple checkbox Multiselect listbox Multiselect menu Table HTML Dua komponen atau lebih dimana terletak menjadi satu Sebuah feature-rich table control Kolom dalam sebuah dataTable
Tabel 2.11.3 Basic HTML Tag Attributes Attributes id binding
Component Types A (25) A (25)
rendered
A (25)
styleClass
A (23)
value
I, O, C (19)
valueChangeListener I (11)
47
Description identifier untuk sebuah komponen. Referensi pada komponen agar dapat digunakan dalam backing bean. Sebuah boolean; jika false menghentikan proses rendering. Nama class pada Cascading stylesheet (CSS). Sebuah nilai komponen, terutama berupa value binding. Sebuah method binding yang
converter validator
I, O (15) I (11)
required
I (11)
merespon pada perubahan nilai. Nama class Converter. Nama class validator yang dibuat dan tercantum pada komponen. Sebuah boolean; jika benar, membutuh kan sebuah nilai untuk dimasukkan dalam field yang diasosiasi.
Keterangan - A = semua tag - I = tag input - O = tag output - C = commands - (n) = jumlah tag yang memiliki attribut.
Tabel 2.11.4 HTML Pass-Through Attributes Attribute accesskey (14) accept (1) accept-charset (1)
alt (4) border (4) charset (3) coords (2) dir (18) disabled (11) hreflang (2) lang (20) maxlength (2) readonly (11) rel (2) rev (2)
Description Sebuah key, terutama dikombinasikan dengan sebuah system-defined metakey, yang memberikan fokus ke elemen. Tipe content list yang dipisahkan secara koma untuk sebuah form. Comma atau space-separated list dari encoding karakter. atribut accept-charset ditentukan dengan atribut HTML pada JSF yang dinamakan acceptcharset. Pilihan text untuk elemen nontextual seperti sebuah image atau applets. Pixel value untuk sebuah luas elemen border. Karakter encoding untuk link resource Koordinasi untuk sebuah elemen persegi, bulat atau polygon. Petunjuk untuk text. Nilai yang valid adalah ltr (left to right) dan rtl (right to left). Menonaktifkan elemen input atau button. Base language dari sebuah resource dengan href atribut; hreflang hanya bisa digunakan dengan href. Base language dari sebuah element atribut dan text. Nomor maksimal dari karakter untuk text fields. Read-only state dari sebuah input field; text dapat di select tetapi tidak dapat di edit. Hubungan antara dokumen dengan sebuah link specified dengan atribut href. Mengembalikan link dari anchor specified dengan href kepada dokumen. Nilai dari sebuah atribut adalah space-
48
separated list dari link-types. rows (1) Jumlah baris dalam text area. h:dataTable memiliki atribut baris, tetapi bukan sebuah atribut HTML pass-through. shape (2) Shape dari sebuah region. Valid values:default, rect, circle, poly. size (4) Ukuran dari field input. Style (23) Inline style information. tabIndex (14) Nilai numeric yang menentukan index tab. target (3) Nama dari sebuah frame dari dokumen yang sedang dibuka. title (22) Sebuh judul, digunakan untuk pengaksesan, yang menggambarkan sebuah elemen. Visual browser biasanya membuat tooltips untuk title value. type (4) Type dari sebuah link; contohnya : “stylesheet”. width (3) Luas dari sebuah elemen. (n) = jumlah tag yang memiliki attribut tersebut.
Tabel 2.11.5 DHTML Event Attributes Attribute onblur (14) onchange (11) onclick (17) ondblclick (18)
Description Element kehilangan focus. Nilai elemen berubah. Pengeklikan mouse pada element. Pengeklikan mouse secara double (dua kali) pada elemen. onfocus (14) Elemen menerima focus. onkeydown (18) Key di tekan. onkeypress (18) Key ditekan dan dilepaskan secara berurutan. onkeyup (18) Key dilepas. onmousedown (18) Penekanan mouse pada elemen. onmousemove (18) Mouse bergerak dari elemen. onmouseout (18) Mouse menjauh dari daerah elemen. onmouseover (18) Mouse bergerak pada sebuah elemen. onmouseup (18) Mouse button dilepaskan. onreset (1) Form di-reset. onselect (11) Teks diseleksi dalam field input. onsubmit (1) Form di-submit. (n) = jumlah tag yang memiliki attribut tersebut.
49
2.12 Web Service Berikut ini menggambarkan tentang apa itu web service dan apa yang dapat dilakukan: -
Berupa bahasa, development tool, dan platform yang independent.
-
Berdasarkan standardisasi industri.
-
Berupa loosely coupled, aplikasi berbasiskan service dimana menyediakan API untuk
berkomunikasi
menggunakan
protokol
yang
telah
ada
untuk
mempermudah konektivitas dan mengurangi kompleksitas. -
Memperbolehkan otomatisasi dan komunikasi langsung terhadap mesin ke mesin tanpa melibatkan sistem.
-
Memperbolehkan
penemuan
dari
web
service
yang
telah
dipublish
memanfaatkan mekanisme umum untuk melakukan pencarian dan publishing service. Standardisasi sebuah aplikasi supaya dapat disebut web service adalah mengandung beberapa definisi standar berikut ini: -
Extensible Markup Language (XML), untuk representasi data dengan bebas. XML tidak
hanya
digunakan
untuk
mendefinisikan
data,
tetapi
juga
untuk
mendreskripsikan protocol. -
HyperText Transfer Protocol (HTTP), untuk transportasi dalam internet maupun intranet. HTTP ini menyediakan mekanisme transportasi data dan tipe komunikasi dari request maupun response.
-
Simple Object Access Protocol (SOAP), yang menyediakan mekanisme untuk definisi request maupun response dan memperbolehkan komunikasi dalam format Remote Procedure Call (RPC). 50
-
Universal Description, Discovery and Integration (UDDI), yang menyediakan pencarian service melalui registry umum dari providers.
Web Services Description Language (WSDL), yang menyediakan detail informasi yang diperlukan untuk pemanggilan service tertentu. (Henry B., Meeraj M., Sean R., Andre T. (2002). Beginning Java Web Services. Wrox Press Ltd, Birmingham, Ebooks). Berdasarkan teknologi-teknologi yang terlibat dalam web service (HTTP, XML, SOAP, WSDL, dan UDDI), maka web service dapat didefinisikan sebagai komponen software yang menyediakan API yang transparan dan konsisten untuk pemanggilan service-service dengan menggunakan mekanisme transportasi message-oriented, yang dapat secara dinamis ditempatkan dan dipanggil, dengan menggunakan XML untuk representasi dan transformasi data.
2.12.1 Karakteristik Web Service Web service mempunyai beberapa karakteristik seperti: -
XML-based Dengan menggunakan XML sebagai layer representasi data untuk semua protokol web service dan teknologi yang dibuat. Teknologi ini dapat saling beroperasi pada sistem utama yang berbeda-beda. Sebagai transportasi data, XML mengeliminasi semua protokol-protokol pada networking, operating system, ataupun ikatan platform.
-
Loosely coupled Sebuah konsumer web service tidak terikat oleh web service itu secara langsung; interface pada web service dapat diubah setiap waktu tanpa harus 51
mempertimbangkan kemampuan client untuk dapat berinteraksi dengan service tersebut. Sebuah sistem tightly coupled membuat logika client dan server terikat satu sama lain, sehingga jika salah satu interface berubah, maka yang lain mesti diupdate juga. Penggunaan arsitektur loosely coupled cenderung membuat sistem software lebih mudah diatur dan mempermudah penyatuan antara sistem yang berbeda. -
Coarse-grained Teknologi object-oriented seperti Java menampilkan service mereka melalui method-method individual. Sebuah method individual sangat berguna untuk operasi yang menyediakan setiap kapabilitas yang berguna untuk level corporate. Membangun program Java dari awal memerlukan penciptaan beberapa coarsegrained method yang akan diubah menjadi coarse-grained service yang digunakan oleh client maupun service yang lain. Teknologi web service telah menyediakan secara alami pendefinisian coarse-grained service yang mengakses bagian-bagian dari business logic.
-
Ability to be synchronous or asynchronous Sinkronisasi menunjuk pada ikatan client dengan eksekusi dari service. Dalam pemanggilan synchronous, client memblokir dan menunggu suatu service menyelesaikan operasinya sebelum melanjutkan operasi yang lain. Operasi asynchronous
memperbolehkan
sebuah
client
memanggil
service
dan
menjalankan fungsi-fungsi yang lain tanpa harus menunggu penyelesaian service tersebut. Client asynchronous menerima hasilnya pada beberapa saat kemudian, sedangkan client synchronous menerima hasilnya ketika service itu selesai
52
beroperasi. Kemampuan asynchronous adalah salah satu kunci dalam membuat sistem yang loosely coupled. -
Supports Remote Procedure Call (RPC) Web service mengijinkan pemanggilan procedure, functions, dan methods pada remote object dengan berdasarkan protokol XML. Remote procedure menampilkan parameter input dan output dimana harus didukung oleh suatu web service. Component development seperti Enterprise Java Beans (EJB) dan .NET telah berkembang menjadi bagian dari arsitektur enterprise pada saat sekarang ini. Kedua teknologi ini adalah terdistribusi dan dapat diakses melalui berbagai mekanisme RPC. Suatu web service mendukung RPC dengan menyediakan servicenya sendiri, serupa dengan komponen-komponen tradisional, ataupun dengan menerjemahkan pemanggilan yang datang ke dalam pemanggilan sebuah komponen EJB maupun .NET.
-
Supports document exchange Salah satu keunggulan XML adalah cara umumnya dalam merepresentasikan bukan hanya data, tetapi juga dokumen-dokumen kompleks. Dokumen ini dapat berupa dokumen sederhana, seperti representasi dari sebuah alamat, atau dapat berupa dokumen yang kompleks, seperti representasi dari sebuah buku yang berisi alamat-alamat yang ada. Web service mendukung transparansi penukaran antara dokumen untuk mempermudah intergritas bisnis.
2.12.2 Teknologi-Teknologi Utama pada Web Service Ada tiga teknologi utama yang telah membangun standardisasi internasional pada teknologi web service. Teknologi-teknologi tersebut adalah: 53
-
Simple Object Acces Protocol (SOAP) SOAP menyediakan standardisasi struktur untuk transportasi dokumen-dokumen XML diatas berbagai standard protocol Internet, seperti SMTP, HTTP, dan FTP. SOAP juga mendefinisikan encoding dan standardisasi binding untuk pemanggilan RPC non-XML dalam XML untuk transportasinya.
SOAP
menyediakan struktur yang sederhana untuk melakukan RPC: penukaran dokumen. Dengan adanya standardisasi pada mekanisme transportasi, beragam client dan server dapat saling beroperasi satu sama lain. Client .NET dapat memanggil EJB melalui SOAP, dan client Java dapat memanggil komponen .NET melalui SOAP juga. -
Web Service Description Language (WSDL) WSDL adalah teknologi XML yang menggambarkan interface dari web service dengan cara yang standar. WSDL men-standardisasi bagaimana suatu web service merepresentasikan parameter input dan output dari pemanggilan secara external, struktur dari fungsi, sifat pemanggilan (hanya in, in/out, dll) dan binding protocol service. WSDL memperbolehkan client-client yang berbedabeda secara otomatis mengerti bagaimana cara berinteraksi dengan web service.
-
Universal Description, Discovery, and Integration (UDDI) UDDI menyediakan registry web service internasional untuk pengiklanan, pencarian, dan tujuan integrasi. Analis bisnis dan teknologi menggunakan UDDI untuk menemukan web service-web service yang tersedia dengan pencarian berupa nama, identifiers, kategori, ataupun spesifikasi yang diimplementasi oleh web service. UDDI menyediakan struktur untuk merepresentasikan bisnis,
54
hubungan bisnis, web service, spesifikasi metadata, dan access point web service. Secara individual, salah satu dari teknologi ini hanya berupa perkembangan. Masing-masing menyediakan standard bagi langkah berikutnya untuk kemajuan web service, gambarannya, ataupun penemuannya. Namun, tujuan utama web service adalah otomatisasi integrasi bisnis: sebuah software dapat menemukan, mengakses, integrasi, dan memanggil service baru dari perusahaan yang tak dikenal secara dinamis tanpa campur tangan manusia. Integrasi dinamis ini memerlukan kombinasi dari SOAP, WSDL, dan UDDI untuk menyediakan infrastruktur yang standar, dan dinamis untuk memudahkan bisnis yang dinamis kedepannya.
Berikut ini adalah diagram yang menunjukkan hubungan antara ketiga teknologi diatas:
Application SOAP Client
HTTP Request
SOAP Processor
HTTP Response
Discrete Business Logic
WSDL
Service UDDI Registry Gambar 2.12.2 Hubungan SOAP, UDDI, dan WSDL
55
Hubungan antara ketiga teknologi (SOAP, WSDL, dan UDDI) dapat digambarkan sebagai berikut: Aplikasi yang bertindak sebagai client dari web service perlu untuk mencari lokasi aplikasi lain atau potongan business logic yang terletak disuatu tempat pada jaringan. Client melakukan query pada UDDI registry untuk service dengan berdasarkan nama, kategori, indentitas, ataupun dukungan spesifikasi. Ketika telah ditemukan, client mendapatkan informasi tentang lokasi dokumen WSDL dari UDDI registry. Dokumen WSDL mengandung informasi tentang bagaimana cara melakukan kontak dengan web service dan format dari request dalam XML schema. Client membuat SOAP message dengan menuruti XML schema yang ditemukan dalam WSDL dan mengirim request ke host (dimana service itu berada).
56
