Menurut Developing Enterprise Java Applications with J2EE and UML

��

��

BAB 1

ENTERPRISE

1.1. Definisi Enterprise

Menurut kamus “enterprise” berarti:

� Keberanian berusaha, kegiatan memulai usaha

� Perusahaan, firma.

Menurut Developing Enterprise Java Applications with J2EE and UML

by Khawar Zaman Ahmed, Cary E. Umrysh, istilah enterprise mengacu

pada suatu organisasi atau individu sebagai suatu kesatuan, yang

bekerja bersama-sama untuk mencapai beberapa tujuan umum.

Enterprise berkaitan erat dengan B2B (Business to Business) dan

B2C (Business to Customer). Kata enterprise biasa digunakan untuk

menyebut perusahaan dalam skala besar, seperti Microsoft, Intel,

Yahoo!, atau Ebay.

1.2. Elemen Enterprise

Enterprise / Perusahaan mempunyai delapan elemen yaitu :

1. Masyarakat Keuangan

2. Pemerintah

3. Masyarakat Global

4. Pemasok

5. Pelanggan

6. Pesaing

7. Pemegang saham/Pemilik Global

8. Serikat Buruh

1.3. Kebutuhan Enterprise

Enterprise/Perusahaan mempunyai beberapa kebutuhan pokok yaitu :

� Information sharing and processing

��

��

� Asset management and tracking

� Resource planning

� Customer or client management

� Protection of business knowledge

1.4. Arsitektur Enterprise

Definisi Arsitektur adalah Suatu cara di mana komponen-komponen

dalam sebuah komputer atau sistem komputer system diorganisasikan

dan diintegrasikan

Dari definisi itu komponen-komponen pembentuk sistem sangat

penting untuk kesuksesan sebuah arsitektur.

Pemahaman terhadap komponen-komponen penyusun arsitektur

tersebut diperlukan agar kita bisa memahami arsitektur, karakteristik

sistem dan keterkaitannya dengan sistem lainnya. Kita perlu

mengintegrasikan sistem dalam suatu perusahaan sehingga terjadi

komunikasi antar elemen - elemennya.

Sangatlah penting untuk mengerti system dasar suatu organisasi

dan mencatat bagaimana komponen-komponen tersebut bekerja tetapi

tidak harus mengetahui detail bagaimana cara membentuk komponen

– komponen tersebut.

1.5. Enterprise Software

Menurut Wikipedia.org:

Enterprise Software is software that solves an enterprise problem

(rather than a departmental problem) and usually enterprise software is

written using Enterprise Software Architecture.

Dari definisi diatas dapat diartikan bahwa Aplikasi Enterprise adalah

aplikasi / perangkat lunak yang dapat digunakan untuk menyelesaikan

masalah perusahaan dan elemen – elemennya dan biasanya dibuat

dengan Arsitektur Perangkat Lunak Enterprise.

Berikut adalah gambaran dari arsitektur aplikasi enterprise :

��

��

Gambar 1.1. Arsitektur Aplikasi Enterprise

��

��

BAB 2

APLIKASI ENTERPRISE

2.1. Kebutuhan Aplikasi Enterprise

Kebutuhan dari aplikasi enterprise adalah sebagai berikut :

• Mengintegrasikan customer support dan in house product

knowledge melalui WEB.

• Dengan menghubungkan semua mesin-mesin server dan data

melalui internet secara online, marketing perusahaan itu akan

bertambah baik karena bisa menjangkau pelangganpelanggan dari

mana-mana.

• Perusahaan akan menghemat biaya sales manajemen dan

mempermudahnya, disamping itu dapat meraih pasar baru.

• Enterprise software dapat membantu pekerjaan para pekerja di

perusahaan sehingga mempermudah, mempercepat pekerjaan,

mengefisiensikan pekerja, sekaligus memperkecil biaya

pengeluaran perusahaan.

Contoh penerapana aplikasi enterprise adalah pengelolaan gaji

karyawan, daftar pasien rumah sakit, data pengiriman barang, analisis

keuangan, pencatatan kredit, asuransi, pajak, pengelolaan eksport dan

import, dan masih banyak lagi yang lain.

2.2. Karakteristik Aplikasi Enterprise

Ciri – ciri aplikasi enterprise :

• Butuh persistent data, karena data digunakan secara bersama oleh

banyak aplikasi, bahkan digunakan untuk jangka waktu yang lama.

Walaupun sangat mungkin terjadi perubahan sistem perusahaan,

data tidak boleh berubah.

• Enterprise application menghandle data yang sangat besar.

Dulu digunakan konsep file system (standalone) sekarang

digunakan databaserelasional

��

��

• Pengguna enterprise application banyak dan beraneka ragam

o Bagaimana cara menghadle concurrent access -> transaction

management tool

o Butuh log dan recovery

• Memiliki banyak macam user interface di masing-masing client

• Bagaimana agar seluruh data yang ada dapat direpresentasikan ke

seluruh user dengan semudah mungkin dan bermacam-macam

user interface tergantung kebutuhannya.

• Butuh terintegrasi dengan aplikasi lain.

• Mampu memisahkan business logic dengan presentasi

2.3. Kesulitan Aplikasi Enterprise

• Hardware yang masih mahal, yang mungkin juga tidak (belum)

berkembang sesuai keadaan dan kebutuhan sekarang.

• Kesulitan mencari pekerja yang dapat memiliki kemampuan kerja

yang baik, dan dapat mengikuti perkembangan teknologi.

• Kesulitan dalam pembuatan software yang mampu

mengintegrasikan seluruh sistem dan bersifat “Distributed

Software”. (Distribution)

• Adanya multiple vendor juga mempersulit pembuatan program.

(Vendor Diverse)

• Contohnya: Perusahaan A menggunakan SQL Server dan klien

perusahaan A menggunakan Oracle. Dalam hal ini dibutuhkan

suatu software yang mampu mengatasi “lintas vendor”.

• Adanya kebutuhan keamanan sistem dan integritas data.(Security)

Misalnya:

o Mampu menghandle “system failure” dengan “system failure

recovery”

o Rollback transaction untuk transaksi yang salah atau batal

o Transaction locking yang mampu mengatasi keamanan data.

Contohnya pada saat ada transaksi yang hampir bersamaan.

o Mampu menghandle “multi user situation”

��

��

• Menjaga kekonsistensian data walau ada error, delay, dan

transaksi yang jauh.

2.4. Kesuksesan Aplikasi Enterprise

Untuk mengukur kesuksesan dari aplikasi enterprise dapat dilihat dari

beberapa hal, antara lain:

1. Response time : adalah total waktu yang dibutuhkan sistem untuk

memproses sebuah request dari luar sistem tersebut. Mungkin

sebuah aksi UI, seperti penekanan tombol, atau sebuah

pemanggilan server API.

� Min Response time

2. Responsiveness : adalah seberapa cepat sistem mengenali

sebuah request sebagai tantangan untuk diproses.

� User bisa frustasi walapun response time baik

� Walaupun belum selesai proses, sistem harus tetap

memberikan respon. Misalnya gunakan timer atau progressbar,

atau informasi lain.

3. Latency : adalah waktu minimum yang dibutuhkan untuk

mendapatkan segala bentuk response, walaupun tujuan tidak ada

yang biasanya ditemui pada remote systems. Jika dilakukan di

lokal, maka response akan cepat namun pada remote system, hal

itu akan lama. Latency adaah alasan agar kita meminimalisasi

remote call.

4. Throughput : adalah berapa hasil yang diperoleh dalam suatu

satuan waktu tertentu. Jika kita mengukur copy file, throughput

diukur dalam berapa bytes per second. Untuk enterprise

applications pengukuran berdasarkan transactions per second

(tps), tapi masalahnya bergantung pada kompleksitas transaksi.

5. Load adalah statement dari berapa tingkat tekanan stress sebuah

sistem, misalnya diukur dengan berapa banyak user yang sedang

terhubung saat itu. Biasanya diukur dengan parameter lain,

��

��

misalnya dengan: response time untuk beberapa request adalah

0.5 seconds dengan 10 users dan 2 seconds dengan 20 users.

6. Load sensitivity adalah ekspresi tentang bagaimana response

time bervariasi dengan load. Misalnya sistem A memiliki response

time 0.5 seconds untuk 10 sampai 20 users dan system B memiliki

response time 0.2 seconds untuk 10 users yang naik menjadi 2

seconds untuk 20 users. Pada contoh di atas, system A memiliki

load sensitivity yang lebih rendah daripada sistem B.

7. Efficiency adalah performa dibagi dengan resources. Sebuah

sistem yang memiliki 30 tps pada 2 CPU akan lebih efisien

dibanding dengan sebuah sistem yang memiliki 40 tps pada CPU

yang sama.

8. Capacity adalah indikasi maximum dari throughput atau load yang

efektif.

9. Scalability adalah ukuran bagaimana penambahan resources

(biasanya hardware) mempengaruhi performance. Sebuah scalable

system memperbolehkan kita untuk menambah hardware dan

mendapatkan peningkatan performa, seperti penambahan server.

Vertical scalability atau scaling up, berarti menambahkan lebih

banyak tenaga terhadap single server, seperti penambahan

memory. Horizontal scalability atau scaling out, berarti

menambahkan lebih banyak servers.

2.5. Evolusi Aplikasi Enterprise

Dahulu sistem bersifat “Centralized Approach”.

Yaitu sistem dimana bersifat stand alone, dan terpusat.

• Single system for all processing needs

• Sehingga: physical limitations of scalability, single points of failure,

limited accessibility from remote locations

Bersifat single-tier : presentasi, logic business, code, dan data menjadi

satu kesatuan, tidak dipisah-pisah.

Kekurangan single-tier:

��

��

o Menyebabkan perubahan terhadap salah satu komponen diatas

tidak mungkin dilakukan, karena akan mengubah semua bagian.

o Tidak memungkinkan adanya re-usable component dan code.

Sekarang sistem bersifat “Distributed Approach”

• Yaitu sistem dimana bersifat tersebar dan multiproses.

• Sistem ini bersifat On Demand Software dan Software as Service

On Demand Software: berarti software tersebut mampu mendukung

sistem terdistribusi sehingga dapat diakses melalui Internet

Software as a Service berarti software tersebut berlaku sebagai server

dan memberikan pelayanan kepada customer melalui Internet.

Bersifat multi-tier : presentasi, logic business, dan data terpisah pisah

menjadi lapisan-lapisan tersendiri

Multitier

• Multi-tier bisa terdiri dari 2-tier, 3-tier, … n-tier.

• Contoh multi-tier adalah aplikasi client-server (2-tier) dimana

business logic (di server) dan presentasi (di client) terpisah dalam

beberapa lapisan (tier).

• Konsekuensi : tantangan untuk mengupdate software aplikasi untuk

jumlah client yang banyak dengan biaya minimun dan gangguan

yang kecil

Kelebihan N-Tier

• Cepat dan dapat menurunkan biaya pengembangan. Aplikasi baru

dapat dibuat lebih cepat menggunakan kembali data access

component dan data bisnis yang ada.

• Perubahan pada suatu komponen tertentu tidak mempengaruhi

komponen lain. Perubahan pada satu tier tidak berpengaruh pada

tier lain.

• Perubahan lebih dapat di-manage. Lebih mudah untuk mengganti

salah satu komponen bisnis dengan yang baru dalam business-tier

��

��

(business logic) daripada menggantu ratusan application client

diseluruh dunia.

Gambar 2.1. Gambaran Tier

1.6. Perbedaan Enterprise Software dan Component- B ased

Software

OOP dirasa kurang untuk menangani permasalahan yang besar

karena sifat “strongly coupled” nya. Waktu itu OOP hanya merupakan

sebatas metode yang sulit diaplikasikan langsung dalam proyek skala

besar

Hal ini dapat diatasi dengan menggunakan component based software.

Software Component didesain dengan level yang lebih tinggi dari

hanya sekedar obyek, memiliki abstraksi/interface dan service-service

yang lengkap. (Ingat kembali OOP �)

Software Component bersifat loosely coupled. Contoh Software

Component: JavaBeans dari Sun Microsystem dan DCOM & ActiveX

dari Microsoft.

��

��

BAB 3

TEKNIK ARSITEKTUR ENTERPRISE

3.1. Layering

Layering salah satu teknik umum di mana para software designers

menggunakan hal itu untuk memecah sebuah sistem yang rumit ke

dalam bagian-bagian yang lebih sederhana. Contoh: Networking:

lapisan layer OSI dan TCP/IP.

Ketika sistem dibagi dalam layer-layer, maka principal subsystems

dalam software diatur dalam layer, di mana setiap layer bergantung

pada lower layer. The higher layer menggunakan various services

yang didefinisikan oleh lower layer, tetapi lower layer tidak perlu

mengetahui the higher layer. Each layer biasanya menyembunyikan

lower layernya dari layer atasnya, sehingga layer 4 menggunakan

services dari layer 3, yang menggunakan services dari layer 2, tetapi

layer 4 tidak tahu menahu tentang 2.

Kelebihan Layering

• Kita hanya tahu bahwa aplikasi tersebut terdiri dari satu single layer

saja tanpa harus tahu layer-layer yang lain. Sebagai contohnya kita

dapat mengetahui bagaimana membuat FTP service pada TCP

tanpa harus tahu bagaimana cara kerja Ethernet Card secara fisik.

• Dapat mengganti layer-layer dengan aplikasi lain yang

mengimplementasikan servis dasar yang sama. Sebuah FTP

service yang mungkin berbeda-beda dapat tetap berjalan tanpa

harus mengganti Ethernet, PPP, atau kabel-kabel.

• Dapat meminimalisasi ketergantungan antar layer-layer. Jika kita

mengganti kabel jaringan, kita tidak perlu juga mengganti FTP

service.

��

��

• Layer sangat mendukung standarisasi. TCP / IP adalah standard

karena mereka mendefinisikan bagaimana layer-layer mereka

harus beoperasi.

• Sesudah layer terbentuk, kita dapat menggunakannya untuk

bermacam-macam servis lainnya. Contoh, TCP/IP digunakan oleh

FTP, telnet, SSH, dan HTTP. Semua protokol-protokol inipun

memiliki lower-level protokolnya masing-masing juga.

Kelemahan Layering

� Penggunaan Layer menyebabkan dan menambah tingkat

kompleksitas proses. Karena terdiri dari beberapa layer, maka

setiap layer harus memiliki fungsinya masing-masing, dan suatu

proses harus melewati masing-masing layer tersebut terlebih

dahulu baru dapat menghasilkan output. Jadi masing-masing layer

harus memiliki kemampuan memproses yang berlainan.

� Layer mengenkapsulasi fungsi-fungsinya masing-masing sehingga

tidak dapat mengetahui detail fungsi suatu layer.

� Layer bekerja secara bersama-sama menjadi satu kesatuan

sehingga seluruh layer harus bekerja secara optimal. Penambahan

suatu layer juga akan mempengaruhi efisiensi sistem secara

keseluruhan.

Prinsip Layer

� Presentation logic : mengatur bagaimana menghandle interaksi

antara user dan software. Bisa berupa simple command-line atau

text-based menu system, tapi sekarang bisa berupa rich-client

graphics UI atau HTML-based browser UI. Tanggungjawab utama

responsibilities dari presentation layer adalah untuk menampilkan

informasi ke user dan untuk menginterpretasikan perintah dari user

ke dalam aksi terhadap domain dan data source.

� Data source logic : mengatur komunikasi dengan sistem lain yang

mengerjakan tugas untuk kepentingan applikasi. Bisa berupa

��

��

transaction monitors dan messaging systems. The biggest piece of

data source logic adalah database yang bertanggungjawab untuk

menyimpan persistent data.

� Domain logic / business logic . Mengatur kejelasan aturan bisnis

suatu aplikasi. Misalnya melakukan kalkulasi berdasarkan input dan

data yang tersimpan, validasi dari data yang datang dari layer

presentasi, dan menggambarkan secara tepat mana data source

logic yang dibutuhkan, tergantung pada perintah yang diterima dari

layer presentasi.

Evolusi Layer (tier)

Tahun 1990an: Client-Server (Two-layer systems)

o Di sisi client, terdapat user interface dan aplikasi lain, dan di sisi

server biasanya ada relational database. Contoh client tool

adalah VB, Powerbuilder, dan Delphi.

o Problem: business rules, validations, calculations

o Biasanya ditulis di client, tapi jika sudah semakin kompleks?

o Bisa ditulis sebagai stored procedure di dalam database, tapi

jika ganti database?

Sekarang, three-layer system: presentation layer untuk UI, domain

layer/logic layar untuk your domain logic, dan data source/database.

Implementasinya bisa dibuat dalam bentuk subrutin-subrutin untuk

masing-masing layer, atau class-class, atau bahkan service, dan

database terdistribusi.

3.2. Businness Logic

3.1.1. Transaction Script

Adalah sebuah prosedur/routine yang mengambil input dari

presentation layer dan memprosesnya dengan berbagai validasi dan

kalkulasi, menyimpan data dalam database, dan melakukan beragam

operasi dari sistem yang lain.

��

��

Transaction script biasanya berupa script yang digunakan untuk

menghandle berbagai aksi yang mungkin dilakukan oleh user dan

berbagai transaksi bisnis lainnya. Tidak harus dijadikan satu script, tapi

dapat dipisah-pisah, dalam bentuk procedure-procedure, fungsi-fungsi,

atau bahkan class.

Contoh: script untuk checkout barang, menambah barang ke shopping

cart, untuk menampilkan status delifery, dan lain-lain.

Gambar 3.1. Transaction Script

Kelebihan Transaction Script

• Berupa prosedur yang simpel dan muda dimengerti oleh para

developer.

• Mudah digunakan dan digabungkan dengan data source layer

menggunakan database gateway.

• Mudah ditentukan batas transaksinya. Dimulai dari opening

transaction dan diakhiri dengan penutupannya.

3.1.2. Domain Model

Adalah suatu sistem pengorganisasian bisnis logik dengan

pendekatan sistem berorientasi obyek, sehingga kita diharuskan

membangun sebuah model dari domain permasalahan yang kita

��

��

hadapi. Misalnya suatu obyek shipment akan juga berisi logika untuk

menghitung ongkos pengiriman dan biaya antar. Semua logika

tersebut dimasukkan dalam method/routine obyek tersebut..

Perbedaan antara Domain Model dan Transaction Script adalah

pada pendekatan yang dilakukan. Transaction Script beorientasi

method/fungsi/rutin di mana seluruh logic user dijadikan satu dalam

fungsi-fungsi tanpa memperhatikan domain permasalahan, sedangkan

pada Domain Model logic user dibuat dalam obyek-obyek yang

berkaitan dengan domain permasalahan.

Gambar 3.2. Calculating Revenue Domain Model.

3.1.3. Table Module

Table Module sama seperti Domain Model karena Table Module

juga memiliki kelas-kelas seperti layaknya Domain Model, namun

Domain Model memiliki 1 instance untuk setiap kelasnya di dalam

database. Sedangkan Table Module hanya memiliki 1 instance saja

untuk seluruh kelas dan didesain untuk bekerja dengan Record Set.

Semua query yang dilakukan harus melalui Record Set dan akan

membuat obyek dari kelas dan mengirimkannya ke Record Set

sebagai suatu argument. Client dapat menggunakan semua operasi-

operasi pada suatu kelas untuk melakukan banyak hal.

��

��

Gambar 3.3. Table Module.

3.3. Pengelompokan Businness Logic

Pendekatan umum untuk menghandle bisnis logic adalah membagi

bisnis logic ke dalam 2 bagian.

��

��

o Service Layer : digunakan jika menggunakan Domain Model

atau Table Module. Service Layer beraksi seperti API Service.

o Domain Layer : digunakan jika menggunakan Transaction Script

3.4. Mapping to Relational Database

Dari segi arsitektur: bagaimana domain logic berhubungan dengan

database

• Karena SQL tidak terlalu seragam, maka jalan terbaik adalah

memisahkan akses SQL dari domain logic dan

menempatkannya dalam kelas yang terpisah. Satu kelas untuk

satu tabel.

• Kelas-kelas ini akan membentuk Gateway ke dalam tabel-tabel

tanpa harus tahu tentang SQL

• Model Pengaksesan data: per 1 record dan sekaligus

seluruh/beberapa record dalam 1 tabel oleh 1 query

3.5. Web Presentation

Template View dan Transform View: memperbolehkan kita untuk

menulis presentasi/tampilan dan program dalam struktur halaman

secara langsung dan embedded sehingga halaman tersebut memiliki

konten dinamis sesuai yang diinginkan. Contoh: PHP, JSP & ASP

Classic. Mudah dibuat tapi kode dan tampilan tidak terpisahkan!

Transform View menggunakan sebuah transformasi dari program.

Contohnya XSLT, dan semua View tersebut bersifat single stage.

��

��

Gambar 3.4. Web Presentation

Model View Controller (MVC)

Model ini membagi user interface menjadi tiga elemen :

Gambar 3.5. Model View Controller

View merpresentasikan tampilan dari UI, Controller menghandle

semua perubahan terhadap informasi. Controller mengambil inputan

user, memanipulasi model, dan menyebabkan view untuk

mengupdatenya.sedangkan UI adalah kombinasi dari view dan

controller. Model mengatur business policies, dan interaksi dengan

database

��

��

Page Controller

Sebuah object yang menangani sebuah request untuk suatu

halaman tertentu atau suatu aksi terhadap suatu website.

Gambar 3.6. Page Controller

Front Controller

Adalah sebuah controller yang menangani semua request untuk

sebuah Website, serta merupakan sebuah single handler object,

memiliki method-method umum, yang dapat dimodifikasi pada saat

runtime. Kemudian handler akan melakukan perintah berdasarkan

request yang ada

Gambar 3.7. Front Controller

��

��

Gambar 3.8. Front Controller Detail

Template View

Template View merender informasi ke dalam HTML dengan

menempelkan tanda-tanda dalam halaman HTML. Ketika halaman

melayani sebuah request, maka tanda-tanda tersebut akan diganti

dengan hasil dari komputasi seperti misalnya dari database query.

Gambar 3.9. Template View

��

��

Transform View

Sebuah view yang memproses domain data elemen demi elemen dan

mengubahnya ke dalam HTML, Proses transformasi hanya pada

elemen atau bagian yang diperlukan saja.

Contoh: ditransformasikan ke dalam XML

Two Step View

Mengubah domain data ke dalam HTML dalam 2 langkah:

pertama dengan membentuk semacam logical page, kemudian

merender halaman logical tersebut ke dalam HTML.

Application Controller

Menghandle layar navigasi dan aliran aplikasi. Menggunakan

interface.

3.6. Concurrency Problems

Jika ada dua atau lebih proses/thread yang mengakses data yang

sama

• Lost updates: yang terakhir update yang akan mengupdate.

• Inconsistent read: jika ada 2 atau lebih pembacaan, tapi salah satu

ada yang menyimpan, maka data menjadi tidak konsisten

• Semua menyebabkan data tidak benar

• Harus ada mekanisme: isolation dan perlu memperhatikan

immutable data:

o Optimistic locking: semua dapat copy dari data, jika salah satu

proses sudah mengupdate data, maka proses lain masih

dibiarkan mengakes data sampai proses tersebut hendak

mengupdate data, dan pada saat itu, akan dilakukan blocking.

(conflict detection). Deteksi dilakukan dengan version checker.

o Pessimistic locking: semua dapat copy dari data, jika sudah ada

proses yang mengupdate data, maka semua proses lain

��

��

langsung diblok, semua proses lain harus menunggu (conflict

prevention) dan dapat menyebabkan deadlock

Cara mencegah dan mengatasi deadlock

• Atomicity: setiap langkah dalam suatu sekuens harus bergantian

dan bersifat uninterrupable, jadi suatu kejadian harus selesai

terlebih dahulu baru kejadian berikutnya.

• Consistency: sumber daya sistem harus konsisten,noncorrupt

sampai selesai transaksi.

• Isolation: hasil dari individual transaction tidak bolehdiketahui oleh

proses lain, sampai berhasil di commit.

• Durability: hasil apapun yang sudah dicommit harus bersifat

permanen. Harus bisa mengatasi jika terjadi crash.

Request-Response Web Server

• Process-per-session : satu session satu proses, boros resource,

tapi simple

• Process-per-request : banyak session ditangani oleh satu proses,

tidak perlu multithreading, tapi yang perlu diperhatikan adalah

semua resource yang sudah selesai dipakai pada suatu request

harus dapat direlease setelah request selesai.

• Thread-per-request : setiap request dihandle oleh satu thread

dalam satu process, thread membutuhkan request yang lebih

sedikit dibandiongkan dengan process, sehingga kita dapat

menghandle lebih banyak request dalam satu thread.

Kelemahannya: tidak ada mekanisme isolasi data antar thread yang

ada.

Stateless & Stateful Server

Stateless server berarti server tersebut tidak pernah menyimpan

suatu data dari sebuah request yang diajukan kepadanya setelah

proses response berakhir, stateful server butuh untuk menjaga

��

��

semuastatenya sementara sedang menunggu seoranguser

menyelesaikan requestnya.

3.7. Session

Kita membutuhkan server object yang berguna untuk

menyimpan suatu data dari user dalam suatu waktu tertentu, yaitu

session, Seorang user memiliki session yang berbeda-beda. Session

berbeda dengan record data, session yang sudah dicommit baru

disebut dengan record data.

Cara Menyimpan Session

• Client session state: menyimpan data di client. Ex: hidden field,

URL encoding, dan cookies. Kelemahan: butuh transfer data dari

client ke server, keamanan, dan integritas. Hanya mungkin

digunakan untuk data-data kurang penting dan kecil ukurannya.

• Server session state: menyimpan data di memori server pada saat

request terjadi. Ex: session object dengan session_id. Harus ada

mekanisme session_timeout. Sulit menangani system crash.

• Database session state: menyimpan data di database. Kompleks

tapi mampu menangani sistem crash.

��

��

BAB 4

ARSITEKTUR SOFTWARE

4.1. Arsitektur Software

Arsitektur software merupakan struktur statis dari sebuah

software. Struktur statis mengacu pada bagaimana elemen-elemen

dari software berhubungan antara satu dengan lainnya. Struktur

dinamis dari sebuah software, yang berarti relasi antar elemen dapat

berubah selama masa hidup software tersebut dan mengetahui

bagaimana keadaan pada saat sebuah software saat sedang berjalan.

Komposisi (atau Dekomposisi) dari software. Mengacu pada

bagian penting dari software, seperti subsystem dan modules.

Komponen-komponen dan interaksi diantara mereka. Layer-layer dan

interaksi diantara mereka.

4.2. Middleware

Software yang berfungsi sebagai lapisan konversi atau penerjemah

diantara komponen aplikasi dengan tujuan untuk mengurangi

kekompleksitasan aplikasi terdistribusi.

Contoh Arsitektur yang menggunakan Middleware: Client/Server

Contoh:

Http server, di mana client (browser) meminta dokumen, sedangkan

server mengirimkan dokumen yang diminta

Gambar 4.1. Software

��

��

4.3. Karakteristik Client/Server

• Service : Menyediakan layanan terpisah yang berbeda.

• Shared resource : Server dapat melayani beberapa client pada saat

yang sama dan mengatur pengaksesan resource

• Asymmetrical Protocol : antara client dan server merupakan

hubungan one-to-many. Client memulai komunikasi dengan

mengirim request ke server. Server menunggu permintaan dari

client.

• Transparency Location : proses server dapat ditempatkan pada

mesin yang sama atau terpisah dengan proses client. Client/server

akan menyembunyikan lokasi server dari client.

• Mix-and-match : tidak tergantung pada platform

• Message-based-exchange : antara client dan server berkomunikasi

dengan mekanisme pertukaran message.

• Encapsulation of service : message dari client memberitahu server

apa yang akan dikerjakan tanpa harus tahu detail service.

• Integrity : kode dan data server diatur secara terpusat, sedangkan

pada client tetap pada komputer tersendiri.

4.4. Service Oriented Architecture (SOA)

SOA adalah sebuah konsep Software Architecture yang

mendefinisikan penggunaan layanan untuk mendukung kebutuhan

pengguna software. SOA bersiftat loosely coupled (tingkat

ketergantungannya rendah), high interoperable (mudah dioperasikan),

reusable (dapat digunakan kembali), dan interoperability (antar

platform). SOA menggunakan definisi interface yang mengenkapsulasi

semua implementasi yang ada. SOA bersifat behind the scence, SOA

tidak terlihat secara langsung oleh client, SOA dihadapkan pada client

melalui client UI. SOA merupakan suatu service yang “hanya

menunggu” (listen) secara terus-menerus untuk digunakan.

Implementasi SOA adalah web service.

��

��

4.4.1. Beberapa Istilah dalam SOA

Service : Suatu fungsi yang menerima satu atau lebih request dan

mengembalikan satu atau lebih response yang terdefinisi dengan baik

dengan

menggunakan interface yang standar. Service tidak boleh tergantung

pada suatu fungsi atau proses lain.

Stateless : Tidak tergantung pada kondisi apapun. Service menerima

semua informasi yang dibutuhkan untuk menyediakan response dari

suatu request. Pengguna service akan menggunakan service yang

diperoleh untuk digunakan dalam application logic mereka.

Provider : Fungsi yang menyediakan service dan meresponse sebuah

request.

Consumer : Fungsi yang membutuhkan response dari service yang

dihasilkan oleh provider.

Binding : Hubungan antara provider dan consumer bersifat dinamis

dan hubungan itu dibuat pada saat runtime berdasarkan mekanisme

binding.

4.4.2. Kelebihan SOA

• Bersifat Standard

• SOA bersifat lebih interoperability dibandingkan dengan RPC,

DCOM, CORBA (Common Object Request Broker Architecture),

EJB (Enterprise Java Bean), dan RMI (Remote Metho Invocation).

• SOA dapat didefinisikan sebagai function, object, dan method.

• Karena sifat platform independence-nya maka perusahaan dapat

menggunakan software dan hardware yang lebih bebas sesuai

dengan pilihan mereka.

• Tidak tergantung pada satu vendor tertentu saja.

• SOA mendukung pengembangan yang terus menerus, distribusi,

dan maintenance yang bertahap.

��

��

• Perusahaan dapat menggunakan software yang telah mereka

punyai dan menggunakan SOA untuk membuat aplikasi tanpa

harus mengganti aplikasi yang sudah ada.

• Biaya pelatihan rendah.

4.4.3. Hubungan antar Service (Coupling)

Tight Coupling : tingkat ketergantungan tinggi. Disatu sisi permorfa

baik namun akan membuat kesulitan pada maintenance problems.

Loose Coupling : tingkat ketergantungan rendah. Service provider

mendefinisikan dan mempublikasikan service mereka menggunakan

bahasa yang standar. Interface mendefinisikan method-method yang

dapat diinvoke oleh service consumer. Dengan ketergantungan rendah

maka pengubahan implementasi tidak akan mempengaruhi

keseluruhan sistem.

Binding

Binding adalah hubungan yang terjadi antara 2 atau lebih service.

Static binding : diasumsikan definisi service dan interface tidak sering

berubah. Hal ini dilakukan jika konsumen service sudah mengetahui

dengan jelas method-method yang ada di service.

Contoh: penggunaan RMI di Java.

Broker binding : konsumen service mengirimkan request ke service

broker (perantara) terlebih dahulu, kemudian akan diteruskan ke

service provider. Service consumer tidak perlu tahu dimana provider

dan bagaimana implementasi service.

Contoh: penggunaan client stub pada CORBA.

Dynamic binding : diasumsikan konsumen service memanggil provider

secara langsung. Diasumsikan juga bahwa definisi service dan

interface yang disediakan oleh provider berubah secara cepat.

Sehingga untuk setiap pemanggilan, konsumen harus mengkontak

service directory untuk merequest definisi yang diminta. Berdasarkan

informasi yang diperoleh dari service directory, konsumen melakukan

��

��

bind ke service provider. Dynamic binding melakukan lookup dan

binding.

Contoh:

- Penggunaan DII (Dynamic Invocation Interface)pada CORBA.

- Web Service

4.4.4. SOA’s Invocation

� Gunakan pemanggilan synchronous service ketika sebuah

response secara segera/cepat harus segera diberikan. Konsumen

service akan diblok selama menunggu response dari service.

� Pada model asynchronous, konsumen mengirim request dan

meneruskan proses lainnya. Service provider merespond ketika

proses telah selesai dilakukan, waktu yang dibutuhkan tergantung

pada waktu server load.

� Pada kenyataannya, untuk multiple applications, asyncrhronous

service akan lebih baik, karena proses tidak terhenti, adanya

garansi pertukaran message.

��

��

BAB 5

PERKEMBANGAN SOFTWARE

Pada awalnya semua perusahaan software di dunia mempunyai

tipe bisnis yang sama yaitu :

• Mempertahankan serta menutup hasil kekayaan intelektual.

• Software hanya dikembangkan oleh karyawannya sendiri

• Dikirim dalam format yang telah dienkripsi

• Berlisensi hanya untuk computer yang dipakai user

Pada jaman sekarang ini, kebanyakan software dikembangkan dengan

platform opensource.

5.1. Sejarah Open Source

Opensource mulai dikenal sejak tahun 1960, dengan ide yang cukup

sederhana yaitu :

• Programmer dapat melihat source code

• Programmmer dapat mendistribusikan ulang code

• Programmer dapat memodifikasi source code

• Sehingga programmer dapat meningkatkan, memperbaiki bug, dan

mengubah program yang ada dengan tetap mencantumkan lisensi.

Open Source menganggap bahwa di dalam open source model,

program akan menjadi lebih baik karena para programmer dapat saling

bantu.

Pada tahun 1988 terjadi open source movement yang dipicu oleh

Mozilla source code yang “dilepas” oleh Netscape, yang hanya “free for

academics only”. Keudian berdiri The Open Source Initiative (OSI) oleh

Eric S. Raymond and Bruce Perens. Open Source Definition digunakan

oleh Open Source Initiative untuk mengidentifikasikan sebuah lisensi

software open source atau bukan. Definisi ini berdasarkan Debian Free

Software Guidelines.

��

��

Open source berarti bahwa source code program tersedia bagi seluruh

user, biasanya tersedia dengan gratis dan Open source berbeda

dengan freeware dengan perbedaan bahwa Open source menyertakan

source code dan Freeware hanya gratis, belum tentu menyertakan

source code, bahkan dapat juga freeware untuk suatu batasan waktu

tertentu saja.

5.2. Kriteria Open Source

• Free Redistribution: software dapat diberikan dan dijual secara

bebas.

• Source Code Available: source code harus disertakan atau dapat

diperoleh dengan bebas, misalnya di website tertentu.

• Obsfucator tidak diijinkan.

• Derived Works: pendistribusian kembali dari source yang telah

dimodifikasi diperbolehkan.

• Integrity of The Author's Source Code: pengubahan source harus

tetap menyertakan nama pembuat asli dari source code. Jika ada

modifikasi harus disertakan tanggal, waktu, oleh, dan versi.

• No Discrimination Against Persons or Groups: siapapun

diperbolehkan dalam open source, tidak ada perbedaan.

• No Discrimination Against Fields of Endeavor: user komersial juga

boleh ikut.

Contoh: Microsoft juga boleh ikut.

• Distribution of License: hak yang berkenaan dengan program harus

dipakai oleh semua pengguna program tanpa harus ada

penandatanganan lisensi dengan pihak ketiga.

• License Must Not Be Specific to a Product: program tidak bisa

dilisensi dari sebagai bagian dari distribusi yang lebih besar. Jadi

perbagian sottware kecil juga harus dapat didistribusikan sendiri.

• License Must Not Restrict Other Software: lisensi tidak boleh

menuntut program lain juga harus menjadi open source juga.

��

��

5.3. Lisensi Opensource

Contoh lisensi open source: Apache

License, BSD license, GNU General Public

License, GNU Lesser General Public License, MIT License, Eclipse

Public

License and Mozilla Public License.

5.4. Lambang Open Source (www.opensource.org)

Gambar 5.1. Lambang Opensource

Contoh Open Source Project yang terkenal di dunia:

o Sourceforge.net : http://www.sourceforge.net dengan lebih dari

70.000 projectnya.

o Freshmeat.net : http://www.freshmeat.net dengan lebih dari 30.000

projectnya.

o Apache Software Foundation : http://www.apache.org

o MySQL, PHP, dan Perl

5.5. Free Software

Richard Stallman mendefinisikan free software sebagai software

berdasarkan Four Freedoms untuk usernya:

• Kebebasan untuk menjalankan program, untuk tujuan apapaun

(freedom 0).

• Kebebasan untuk belajar bagaimana program bekerja dan

mengadaptasinya untuk kebutuhan kita sendiri (freedom 1). Akses

ke source code merupakan prasyarat untuk freedom 1.

• Kebebasan untuk mendistribusikan kembali kopi dari program

sehingga dapat membantu yang lain (freedom 2).

��

��

• Kebebasan untuk menambahkan kemampuan program dan me-

release pengubahan tersebut ke publik, sehingga seluruh

komunitas publik mendapatkan keuntungan darinya. (freedom 3).

Akses ke source code merupakan prasyarat untuk freedom 3.

Richard Stallman adalah pendiri Free Software Foundation dan yang

mempublikasikan GPL (General Public License). Pada tahun 1995

Free Software Foundation mengeluarkan istilah “copyleft”:

• Copyleft is a license that permits people to freely copy, modify, and

redistribute software so long as they do not keep others from also

having the right to freely copy, modify, and redistribute the software.

• Copyleft provisions in a license require that anyone modifying the

software can distribute only their modified versions under the terms

of the open source license they originally received with the

software.

• You can actually sell Copyleft software, but you must also offer the

source for free, either with the product or available for free (or for

the cost of copying/shipping) to anyone on request.

(from http://c2.com/cgi/wiki?CopyLeft)

5.6. Keuntungan Open Source

• Access to Source Code: bisa melihat, mengubah

• Community: besar dan saling mendukung

• Cost: gratis

• License: license untuk melihat, mengubah, dan mendistribusikan

ulang.

5.7. Open Source vs Close Source

Open source menitikberatkan pada source code yang diperbolehkan

untuk dilihat dan diubah.

• Open source memberikan software gratis dan installation support

(contoh: Linux).

��

��

• Open source kadang juga membuat versi komersial sehingga user

dapat memilih. Contoh: Open Office dan Star Office

• Masalah security: “Many Eyes make Bugs Shallow”

• Open Source mungkin banyak bug, tapi cepat difix karena banyak

dukungan.

• Jika closed source: harus bayar dan “bagaimana bug bisa

diketahui?”

5.8. Open Source vs Free Software

Open Source adalah source code bias dilihat dan diubah, Free

Software adalah mendistribusikan software dengan bebas, dengan

atau tanpa source code.

5.9. Open Source Participants

Partisipan Open Source dibagi menjadi 2 jenis:

• Core: developer yang mengubah/membuat source code

(programmer)

• Peripheral: user yang menggunakan software, report bug dan

suggest fixes.

Partisipan opensource biasanya terdiri dari:

• Project leaders: yang terdiri dari Core, hanya memanage.

• Volunteer developers: terdiri dari Core, melakukan coding:

• Senior members

• Peripheral developers

• Occasional contributors

• Maintainers

• Everyday users: yang melakukan testing, identify bugs, deliver bug

reports.

• Posters (Periphery): yang berpartisipasi secara dalam newsgroups

and discussions, tetapi tidak coding.

��

��

5.10. Open Source Development Tools

• Source code revision control: dibutuhkan karena usernya sangat

banyak dan terpencar-pencar.

• CVS (Concurrent Versions System): agar pengubahan dapat

terkontrol, tidak tercampur, dapat dikemabalikan ke previous

version

• SVN (The Subversion Revision Control System): Enhanced CVS

• Testing Tools: testing sebelum diintegrasikan.

• Tinderbox: mampu mendeteksi error, kenapa error dan siapa

pembuat error

• Bug/Error/Defect tracking tools: mendeteksi dan melaporkan error,

bug yang ada, mencatat sudah fix atau belum.

• GNU GNATS

• Buggzilla

• Communication: jika project sudah selesai dan dibubarkan

komunikasi terjadi melalui: web (sourceforge.net, freshmeat.net,

GNU mailman)

5.11. Commercial vs Open Source

Tabel 5.1. Perbandingan Komersial dengan Opensource

��

��

5.12. Model dan Metode Software Engineering Open So urce/Free

Software

5.12.1. Bazaar Model

Pada tahun 1997, essay “The Cathedral and the Bazaar” oleh Eric S.

Raymond mengusulkan sebuah model developing Open Source

Software (OSS) yang disebut Bazaar model.

• Traditional model seperti layaknya membangun kathedral :

dikerjakan oleh orang yang sesedikit mungkin.

• Bazaar model : dikerjakan secara bersama-sama dengan “great

bubbling, different agendas, and approaches”.

Menurut Gregorio Robles, Bazaar Model harus:

• Users should be treated as co-developers: user juga developer

sehingga dapat mengakses source code.

• Linus's law : "Given enough eyeballs all bugs are shallow."

• Early Releases: agar dapat langsung dilihat dengan cepat oleh

user.

• Frequent Integration

• Several Versions: minimal ada 2 versi, versi development dan

stable

• High Modularization: sehingga mudah dikerjakan secara bersama.

• “Dynamic decision making” structure.

5.12.2. Open Source Maturity Model

Adalah sebuah proses formal untuk mengakses tingkat kematangan

dari open source software. Software Maturity adalah konsep yang

mengetahui kematangan produk, apakah sudah siap digunakan,

seperti “how scalable, manageable, and supportable”.

Macam-macam Pengguna :

• Early Adopter: User tipe ini beranggapan bahwa teknolongi baru

akan membawa manfaat bagi perkembangan perusahaannya.

��

��

Sehingga teknologi tersebut akan langsung diterapkan walaupun

memiliki strategi yang berbeda dengan yang sudah ada.

• Pragmatis: User tipe ini hampir sama dengan user bertipe early

adopter, yang berbeda hanyalah teknologi baru diterapkan untuk

mendukung strategi yang sudah ada bukan mengganti strategi

yang ada seperti pada early adopter.

Tabel 5.2. Perbandingan Produk Immature dan Mature

��

��

5.12.3. Penilaian Mature

OSMM menilai kematangan suatu produk dalam 3 fase:

• Menilai setiap kematangan elemen produk dan memberikan nilai

kematangan.

• Mendefinisikan bobot untuk setiap elemen berdasarkan pada

permintaan organisasi.

• Menghitung seluruh nilai kematangan produk tersebut.

��

��

Tabel 5.3. Fase – fase Element Maturity

Fase 1: Assessment Element Maturity

Mengidentifikasikan elemen kunci produk dan menilai tingkat

kematangannya.

• Elemen kunci suatu produk adalah sebagai berikut:

• Product software

• Support

• Documentation

• Training

• Product integration

• Professional services

Setiap elemen dinilai dan diberikan nilai kematangan melalui 4 tahap

proses:

• Define organizational requirements, Bertujuan untuk mendefinisikan

persyaratan organisasi.

• Locate resources, Bertujuan untuk menempatkan sumber daya.

• Assess element maturity, Bertujuan untuk menilai kematangan

elemen.

• Assign element maturity score on a scale of 1 to 10, Bertujuan

untuk memberikan nilai untuk setiap elemen.

��

��

Fase 2: Assign Weighting Factors

OSMM memberikan bobot untuk setiap elemen untuk merefleksikan

pentingnya elemen tersebut.

Tabel 5.4. Assign Weighting Factors

Fase 3: Calculate the Product's Overall Maturity Sc ore

Bertujuan untuk seluruh nilai kematangan produk tersebut.

Tujuan OSMM

• Didesain untuk untuk membuat penilaian dengan cepat terhadap

kematangan suatu produk open source.

• Didesain agar grup yang kecil dapat memberikan penilaian dalam

waktu yang singkat.

Tabel 5.5. Maturity Score

��

��

Tabel 5.6. Contoh JBoss

Tabel 5.7. Recommended OSMM Scores

Analisis

• Dari tabel diatas dapat dilihat bahwa nilai minimum untuk early

adopter lebih rendah dibandingkan dengan pragmatist. Hal itu

dikarenakan user tipe early adopter lebih berani menanggung

resiko yang besar daripada user tipe pragmatist. Sehingga untuk

user tipe pragmatist diberikan nilai minimum yang cukup tinggi

menggingat user tipe ini kurang berani atau lebih berhati-hati dalam

menerapkan produk atau software yang baru.

• Untuk penggunaan experimentation diberikan nilai minimum yang

rendah, nilai minimum menengah diberikan untuk penggunaan pilot

dan nilai minimum yang tertinggi diberikan untuk penggunaan

production.

��

��

BAB 6

REMOTE METHOD INVOCATION

6.1. Pengenalan RMI

RMI adalah salah satu bagian dari J2SE yang digunakan untuk

membangun aplikasi terdistribusi menggunakan bahasa Java. RMI adalah

kumpulan kelas dalam Java yang digunakan untuk menangani

pemanggilan (invocation) method secara jarak jauh (remote) dalam suatu

jaringan atau Internet. Idenya memisahkan obyek-obyek secara

terdistribusi dalam mesin-mesin yang berbeda. RMI menggunakan prinsip

pemrograman berorientasi obyek dimana obyek satu dapat saling

berkomunikasi dengan obyek lainnya. Untuk membangun aplikasi RMI

dibutuhkan Interface. RMI terdiri dari RMI client dan server.

RMI server biasanya akan membuat beberapa remote obyek dan

referensi-nya yang dapat diakses oleh RMI client menggunakan suatu

URL dan menunggu RMI client meminta ke server. Sedangkan RMI client

akan membuat koneksi ke server dan meminta pemanggilan ke beberapa

remote obyek berdasarkan referensi yang diterimanya.

RMI client akan menggunakan remote obyek sebagai lokal obyek. Setiap

remote obyek yang dibuat oleh RMI server didaftarkan terlebih dahulu ke

dalam RMI registri agar ketika client membutuhkannya dapat meminta

dengan mudah ke RMI registry.

Gambar 6.1. Arsitektur RMI

��

��

RMI Server akan mendaftarkan remote obyeknya ke RMI Registry melalui

bind dengan nama unik.

RMI Client yang akan melakukan suatu pemanggilan method dari remote

obyek, harus meminta referensi obyek ke RMI Registry berdasarkan nama

kelas obyek tersebut.

Dalam RMI harus ada pendefinisian interface (behaviour) dan

implementasi interface (berupa kelas), RMI hanya dimiliki oleh bahasa

Java saja.

RMI memungkinkan membuat dua kelas yang menerapkan /

mengimplementasikan satu interface yang telah didefinisikan. Satu kelas

menerapkan method dari interface (yang ada di server) dan satu kelas lagi

bertindak sebagai proxy untuk remote service (server object) yang

berjalan di client.

6.2. Stub & Skeleton

Merupakan interface antara aplikasi dan RMI system. Stub bertindak

sebagai client side proxy Skeleton bertindak sebagai server side proxy

Selama remote invocation stub bertanggung jawab untuk: Meminta lokasi

remote server obyek pada remote reference layer Marshalling :

merangkaian argumen pada output stream Memberitahu remote reference

layer bahwa semua data parameter telah terkirim, sehingga pemanggilan

method sesungguhnya dapat dilakukan oleh server Unmarshalling:

rangkaian nilai yang diterima dari remote Obyek Memberitahu remote

reference layer bahwa pemanggilan telah lengkap

Skeleton bertanggung jawab untuk: Marshalling: nilai kembalian atau

exception kepada stub client Mengirimkan panggilan method pada server

object sesungguhnya

6.3. Remote Reference

• Menemukan lokasi remote obyek

• Membuat panggilan point to point dan rekoneksi secara otomatis,

��

��

• Mengaktifkan proses server baru jika belum pernah diaktifkan

sebelumnya Memelihara replikasi (panggandaan) jika diperlukan

6.4. Transport Layer

• Memelihara tabel yang berisi obyek-obyek pada JVM

• Membuat dan memelihara dua koneksi antara 2 JVM menggunakan

TCP/IP

• Transport Layer hanya tersedia di level virtual machine (pada

java.net)

• Menerima dan merespon setiap pemanggilan dari atau ke server

dan client

6.5. RMI Registry

Tool RMI registry menggunakan rmiregistry dengan port default 1099

Ketika server membuat remote method dengan cara membuat lokal obyek

yang menerapkan method dari interface tersebut, maka obyek akan

diekspor ke RMI, dan diregisterkan ke RMI Registry dengan public name.

RMI Registry akan membuat layanan listen yang menunggu permintaan

dari client.

Di sisi Client, RMI Registry diakses menggunakan static class naming.

Class ini menyediakan metode lookup() untuk melakukan query ke

registry. Metode lookup menerima URL yang menyatakan nama server

dan nama service yang diminta dan kemudian mengembalikan remote

reference obyek yang diminta. Format URL RMI:

rmi://<hostName>[:<name_service_port>]/<service_nam e>

RMI registry is a running process on a host machine

��

��

BAB 7

CORBA

7.1. Pengertian CORBA

CORBA (Common Object Request Broker Architecture) adalah cara lain

untuk melakukan pemrograman jaringan terdistribusi dan open system,

dimana obyek yang dipanggil tidak hanya berasal dari program yang

dibuat dengan bahasa Java saja tetapi juga bisa dibuat dengan bahasa

lain.

Corba di buat oleh OMG (Object Management Group – www.omg.org),

suatu organisasi yang mengurusi teknologi berbasis obyek. OMG berdiri

tahun 1989 dan jugan mengurusi tentang UML.

Corba dikatakan merupakan standar sistem terdistribusi (distributed

sistem standard) karena dengan menggunakan corba, sistem secara

keseluruhan dapat saling terhubung dan berkomunikasi antar platform

(sistem operasi dan hardware) yang berbeda.

Corba juga dikatakan sebagai open system karena teknologi corba

merupakan suatu standar yang terbuka bagi siapa saja yang ingin

menerapkannya. Dengan corba kita dapat membangun aplikasi yang

dapat saling berkomunikasi walau satu sama lain menggunakan bahasa

pemrograman dan platform yang berbeda.

CORBA memiliki Interface Definition Interface yang mendukung mapping

ke suatu bahasa pemrograman tertentu.

CORBA menyediakan API untuk berkomunikasi antar obyek secara

remote.

Beberapa yang sudah menerapkan spesifikasi corba adalah:

• Borland (VisiBroker): C++ dan Java Mapping

• IONA (Orbix) : C++, Java, dan SmallTalk Mapping

• Sun Microsystem (JavaIDL)

��

��

7.2. Arsitektur CORBA

Gambar 7.1. Arsitektur CORBA

7.3. ORB

Bertindak sebagai broker (perantara) antara client dan server yang

berjalan pada tiap mesin yang berisi API untuk mencari obyek dan

menerima request. ORB mengkomunikasikan hubungan antar obyek

menggunakan sistem IIOP (Internet Inter-ORB Protocol) ORB tersedia

untuk beberapa platform yang berbeda-beda. ORB mencari obyek,

merequest remote method melalui interface CORBA, dan

mengembalikannya ke client. Menangani secara menyeluruh terhadap

suatu permintaan (request) dari client ke object atau sebaliknya

(response) dari obyek ke client. ORB harus tersedia di sisi server dan

client.

Pada sisi client, ORB memiliki fungsi:

Menghubungkan ke interface repository / IR (penyedia definisi interface).

Membantu client dalam menyusun suatu permintaan (invocation) ke object

server secara dinamis dengan menggunakan DII (Dynamic Invocation

Interface).

Pada sisi server, ORB berfungsi:

��

��

Selain bertanggung jawab untuk mengirimkan response dari server ke

client yang dituju, ORB juga membantu untuk memulai dan menghentikan

operasi terhadap object server yang diminta.

7.4. Langkah Pengembangan CORBA

Gambar 7.2. Langkah membangun CORBA

Langkah pertama: mendefinisikan interface yang berisi layanan-layanan

yang tersedia oleh obyek server menggunakan bahasa IDL.

Langkah kedua: mengkompilasi bahasa IDL ke bahasa Java. Kita

gunakan IDL-to-Java compiler. Yaitu : idlj. Hasil dari kompilasi ini

dihasilkan client stub dan skeleton server.

Untuk menghasilkan aplikasi client, kita perlu menuliskan aplikasi client

dan dikompilasi dan dilink bersama dengan library CORBA serta client

stub yang dihasilkan dari IDL compiler.

Dari sisi server : dari definisi yang sudah didefinisikan perlu dibuat sebuah

kelas sebuah kelas yang merupakan implementasi dari interface tersebut.

Sehingga sebuah aplikasi server dihasilkan dari kompilasi dan linking

antara kode program aplikasi server, implementasi obyek dan skeleton.

��

��

BAB 8

WEB SERVICES

8.1. Pengantar Web Services

Saat ini web services menjadi sangat populer di enterprise karena

kemampuannya dalam mengintegrasikan aplikasi-aplikasi yang berbeda

platform. Web Services adalah sebuah komponen layanan aplikasi yang

dapat diakses melalui protokol terbuka yang memanfaatkan Web melalui

Simple Object Access Protocol (SOAP) dengan bahasa Web Services

Description Language (WSDL) dan teregistrasi dalam Universal Discovery

Description and Integration (UDDI).

Web services mendukung komunikasi antar aplikasi dan integrasi aplikasi

dengan menggunakan XML dan Web. XML (eXtensible Markup

Language) adalah sebuah standar untuk mendefinisikan data dalam

format yang sederhana dan fleksibel. Mengapa web services menjadi

sangat populer saat ini? Jawabannya adalah karena web services mampu

mengintegrasikan aplikasi yang berbeda platform secara lebih sederhana

dan mampu memperbaiki kelemahan dari middleware konvensional.

Web services adalah komponen yang independen terhadap platform

ataupun bahasa. Web services menggunakan web protokol (HTTP) yang

sangat mendukung heterogenoitas dan interoperabilitas serta

memudahkan integrasi. Selain itu web services mendukung koneksi

loosely coupled, sehingga sebuah perubahan pada satu aplikasi tidak

akan memaksa perubahan pada aplikasi yang lain. Sebuah web services

memiliki interface berupa web API (Application Programming Interface)

yang dapat dipanggil oleh suatu aplikasi untuk mengakses aplikasi yang

mengimplementasikan layanan web services.

Interoperabilitas adalah prioritas utama sebuah enterprise dalam

Enterprise Application Integration (EAI) dan Business-to-Business

Integration (B2Bi).

��

��

EAI dan B2Bi adalah permasalahan yang dihadapi oleh enterprise untuk

mengintegrasikan berbagai macam aplikasi yang sudah ada. Web

services dapat diimplementasikan sebagai komponen yang mendukung

komunikasi antar aplikasi dalam enterprise.

Web services saat ini semakin banyak digunakan oleh enterprise untuk

memudahkan akses pada produknya, meningkatkan layanan ke

konsumen dan ke business partner melalui internet atau corporat extranet

. Sebagai contoh mengintegrasikan dan mengotomasikan proses bisnis,

supply chain, dan costumer relationship. Saat sebuah enterprise ingin

mengintegrasikan sistem bisnisnya dengan partnernya menggunakan

internet, informasi yang dialirkan harus dipastikan dalam kondisi aman.

Oleh karena itu keamanan menjadi isu yang sangat penting untuk

keperluan tersebut. Dalam beberapa kasus, layanan keamanan berbasis

Operating System dan Internet Information Services (IIS) dapat

diandalkan. Akan tetapi lingkungan implementasi yang heterogen selalu

menimbulkan celah-celah ancaman keamanan baru. Ancaman terhadap

keamanan web services antara lain unauthorized access, parameter

manipulation, network eavesdropping, disclosure of configuration data,

dan message replay. Jika nilai informasi yang dibawa oleh web services

tinggi, maka web services tersebut harus diamankan dari ancaman-

ancaman diatas.

8.2. Web Services Security Specification

Saat web services menggunakan secure connection seperti Secure

Sockets Layer (SSL) atau Transport Layer Security (TLS) membangun

koneksi end to end yang aman tidak akan sulit. Akan tetapi jika terdapat

perantara pada komunikasi tersebut, maka dibutuhkan protokol yang

memiliki tingkat keamanan yang tinggi. Berikut adalah spesifikasi dari

keamanan web services. Spesifikasi berikut termasuk message security

model (WS-Security) yang memberikan dasar bagi spesifikasi yang lain .

Kemudian diatasnya terdapat lapisan khusus yang menangani masalah

policy, yaitu WS-Policy, WS-Trust dan WSPrivacy.

��

��

WS-Policy mendeskripsikan kemampuan dan batasan dari keamanan,

WS-Trust mendeksripsikan framework yang digunakan, dan WS-Privacy

mendeskripsikan model privasi untuk web services.Lapisan tersebut

memberikan fondasi untuk keamanan WS-Security.

Diatas lapisan policy terdapat lapisan yang memberikan fondasi, yaitu

WSSecureConversation, WS-Federation, dan WS-Authorization. WS-

SecureConversation yang mengelola dan mengautentifikasi pesan, WS-

Federation yang mengelola relasi dan lingkungan yang heterogen, dan

WS-Authorization yang mengelola otorisasi data.

��

��

BAB 9

KEAMANAN WEB

9.1 Pendahuluan

Pembahasan tentang web programming belum lengkap apabila belum

mempelajari tentang keamanan dalam aplikasi. Fasilitas yang melimpah,

fungsi yang sangat banyak tidak akan berarti apabila aplikasi kita gagal

dalam hal pengamanan data.

Pada bab ini, kita akan mempelajari bagaimana mengamankan

komunikasi antara server dan client melalui SSL. Kita juga akan

mempelajari tentang 10 celah keamanan pada aplikasi web dan

mempelajari bagaimana cara menanggulanginya.

9.2 SSL

SSL telah menjadi standar de facto pada komunitas untuk mengamankan

komunikasi antara client dan server. Kepanjangan dari SSL adalah Secure

Socket Layer; SSL adalah sebuah layer protocol yang berada antara layer

TCP/IP standar dengan protocol di atasnya yaitu application-level protocol

seperti HTTP. SSL mengijinkan server untuk melakukan autentikasi

dengan client dan selanjutnya mengenkripsi komunikasi.

9.3. Celah keamanan pada aplikasi web

Open Web Application Security Project (OWASP) adalah project open

source yang dibangun untuk menemukan penyebab dari tidak amannya

sebuah software dan menemukan cara menanganinya.

Ada 10 celah kemanan aplikasi web yang ditemukan dan rekomendasi

mereka tentang menanganinya sebagai sebuah standard keamanan

minimal dari aplikasi web.

��

��

Berikut ini adalah 10 celah tersebut dan cara agar kita dapat mengatasi

masalah tersebut.

I. Unvalidated input

Semua aplikasi web menampilkan data dari HTTP request yang dibuat

oleh user dan menggunakan data tersebut untuk melakukan operasinya.

Hacker dapat memanipulasi bagianbagian pada request (query string,

cookie information, header) untuk membypass mekanisme keamanan.

Berikut ini tiga jenis penyerangan yang berhubungan dengan masalah ini:

• Cross site scripting

• Buffer overflows

• Injection flaws

Ada beberapa hal yang dapat dicatat ketika menangani validasi pada

aplikasi kita. Pertama, adalah tidak baik pada aplikasi web untuk percaya

pada client side scripting. Script tersebut biasanya menghentikan form

submission apabila terdapat sebuah input yang salah. Akan tetapi, cript

tersebut tidak dapat mencegah hacker untuk membuat HTTP requestnya

sendiri yang erbebas dari form. Menggunakan client side validation masih

bisa membuat aplikasi web yang

mudah diserang.

Kedua, beberapa aplikasi menggunakan pendekatan "negative" (negative

approach) pada alidasinya : Aplikasi mencoba mendeteksi jika terdapat

elemen yang berbahaya pada request arameter. Masalah dari jenis

pendekatan ini adalah hanya bisa melindungi dari beberapa erangan yaitu

: hanya serangan yang dikenali oleh validation code yang dicegah. Ada

banyak ara dimana hacker dapat membypass keamanan dari unvalidated

input; Masih ada kemungkinan imana cara yang baru tidak dikenali oleh

��

��

aplikasi dapat membypass validasi dan melakukan erusakan. Adalah cara

yang lebih baik untuk menggunakan pendekatan "positive" (positive

pproach) yaitu : membatasi sebuah format atau pola untuk nilai yang

diijinkan dan memastikan nput tersebut sesuai dengan format tersebut.

II. Broken Access Control

Banyak aplikasi yang mengkategorikan user-usernya ke dalam role yang

berbeda dan level yang erbeda untuk berinteraksi dengan content yang

dibedakan dari kategori-kategori tersebut. Salah atu contohnya, banyak

aplikasi yang terdapat user role dan admin role : hanya admin role yang

iijinkan untuk mengakses halaman khusus atau melakukan action

administration.Masalahnya adalah beberapa aplikasi tidak efektif untuk

memaksa agar otorisasi ini bekerja.

Contohnya, beberapa program hanya menggunakan sebuah checkpoint

dimana hanya user yang terpilihyang dapat mengakses : untuk proses

lebih lanjut, user harus membuktikan dirinya erotorisasi dengan

menggunakan user name dan password. Akan tetapi, Mereka tidak

menjalankan pengecekan dari checkpoint sebelumnya : dimana apabila

user berhasil melewati halaman login, mereka dapat bebas menjalankan

operasi.

Masalah lain yang berhubungan dengan access control adalah:

• Insecure Ids – Beberapa site menggunakan id atau kunci yang

menunjuk kepada user atau fungsi. ID dapat juga ditebak, dan jika

hacker dapat mudah menebak ID dari user yang terautorisasi,

maka site akan mudah diserang.

• File permissions – Kebanyakan web dan aplikasi server percaya

kepada external file yang menyimpan daftar dari user yang

terotorisasi dan resources mana saja yang dapat dan/atau tidak

dapat diakses. Apabila file ini dapat dibaca dari luar, maka hacker

��

��

dapat memodifikasi dengan mudah untuk menambahkan dirinya

pada daftar user yang diijinkan.

Filter atau komponen tadi dapat menjamin hanya user yang terotorisasi

dapat mengakases. Untuk melindungi dari insecure Ids, kita harus

mengembangkan aplikasi kita agar tidak percaya pada kerahasiaan dari

Ids yang dapat memberi access control. Pada masalah file permission,

file-file tersebut harus berada pada lokasi yang tidak dapat diakses oleh

web browser dan hanya role tertentu saja yang dapat mengaksesnya.

III. Broken Authentication dan Session Management

Authentication dan session management menunjuk kepada semua aspek

dari pengaturan user authentikasi dan management of active session.

Berikut ini beberapa hal yang perlu diperhatikan :

• Password strength – Aplikasi kita harus memberikan level minimal

dari keamanan sebuah password, dimana dapat dilihat dengan cara

melihat panjang dari password dan kompleksitasnya. Contohnya

sebuah aplikasi dimana terdapat user baru yang akan mendaftar :

aplikasi tidak mengijinkan password dengan panjang 3-4 karakter

atau katakata simpel yang dapat mudah ditebak oleh hacker.

• Password use – Aplikasi kita harus membatasi user yang mengakses

aplikasi melakukan login kembali ke sistem pada tenggang waktu

tertentu. Dengan cara ini aplikasi dapat dilindungi dari serangan brute

force dimana hacker bisa menyerang berulang kali untuk berhasil

login ke sistem. Selain itu, log in yang gagal sebaiknya dicatat

sebagai informasi kepada administrator untuk mengindikasikan

kemungkinan serangan yang terjadi.

• Password storage – password tidak boleh disimpan di dalam aplikasi.

Password harus disimpan dalam format terenkripsi dan disimpan di

file lain seperti file database atau file password. Hal ini dapat

��

��

memastikan bahwa informasi yang sensitif seperti password tidak

disebarkan ke dalam aplikasi.

Issue lain yang berhubungan : password tidak boleh dalam bentuk

hardcoded di dalam source code.

• Session ID Protection – server biasanya menggunakan session Id

untuk mengidentifikasi user yang masuk ke dalam session. Akan

tetapi jika session ID ini dapat dilihat oleh seseorang pada jaringan

yang sama, orang tersebut dapat menjadi seorang client.

Salah satu cara yang dapat digunakan untuk mencegah terlihatnya

session ID oleh seseorang pada suatu jaringan yang sama adalah

menghubungkan komunikasi antara sever dan client pada sebuah SSL-

protected channel.

IV. Cross site scripting

Cross site scripting terjadi ketika seseorang membuat aplikasi web melalui

script ke user lain. Hal ini dilakukan oleh penyerang dengan

menambahkan content (seperti JavaScript, ActiveX, Flash) pada request

yang dapat membuat HTML output yang dapat dilihat oleh user lain.

Apabila ada user lain yang mengakses content tersebut, browser tidak

mengetahui bahwa halaman tersebut tidak dapat dipercaya.

Cara yang bisa digunakan untuk mencegah serangan cross site scripting

adalah dengan melakukan validasi data masuk dari user request (seperti

header, cookie, user parameter, ...). Cara negative approach tidak

digunakan : mencoba untuk memfilter active content merupakan cara yang

tidak efektif.

��

��

V. Buffer overflows

Penyerang dapat menggunakan buffer overflows untuk merusak aplikasi

web. Hal ini dilakukan karena penyerang mengirimkan request yang

membuat server menjalankan kode-kode yang dikirimkan oleh penyerang.

Kelemahan buffer overflow biasanya sulit dideteksi dan sulit dilakukan

oleh hacker. Akan tetapi penyerang masih bisa mencari kelemahan ini dan

melakukan buffer overflow pada sebagian aplikasi web.

Terima kasih atas desain dari Java environment, dimana aplikasi yang

berjalan pada J2EE server aman dari jenis serangan ini.

Untuk memastikan keamanan, cara yang paling baik adalah melakukan

pengawasan apabila terdapat patch atau bug report dari produk server

yang digunakan.

VI. Injection flaws

Salah satu kelemahan yang populer adalah injection flaw, dimana hacker

dapat mengirimkan atau menginject request ke operating system atau ke

external sumber seperti database.

Salah satu bentuknya adalah SQL injection. Berikut ini salah satu contoh

dari SQL injection :

Gambar 9.1. Contoh SQL Injection

URL diatas akan memproses pencarian dengan kata kunci 'jedi'.

Implementasi dimana tidak ada validasi input adalah seperti SQL code

berikut ini :

��

��

Gambar 9.2. Contoh Eksekusi SQL Injection

dimana value adalah nilai dari parameter searchString yang ada pada

HTTP request.

Bagaimana jika, hacker melakukan input dari URL seperti ini :

Gambar 9.3. Contoh SQL Injection Http

SQL query yang terbentuk adalah seperti ini :

Gambar 9.4. Contoh Eksekusi SQL Injection Http

Statement awal pasti akan diterima dimana terdapat klausa AND TRUE.

Dan statement selanjutnya yaitu DROP DATABASE juga akan diekseskusi

yang akan memberikan kerusakan pada aplikasi.

Serangan ini bisa mungkin terjadi karena input yang tidak divalidasi. Ada

dua cara yang bisa dilakukan untuk mencegah serangan ini yaitu:

• Daripada menggunakan statement SELECT, INSERT, UPDATE dan

DELETE statement, bisa dibuat fungsi yang melakukan hal serupa.

Dengan menggunakan fungsi diharapkan ada pengamanan

terhadap parameter. Selain itu dengan adanya fungsi, parameter

��

��

yang masuk harus sama dengan tipe data dari parameter yang

dideklarasikan.

• Hak akses dalam aplikasi juga harus dibatasi. Contohnya, jika

aplikasi hanya bertujuan untuk melihat data, tidak perlu diberikan

hak akses untuk melakukan INSERT, UPDATE atau DELETE.

Jangan menggunakan account admin pada aplikasi web untuk

mengakases database. Hal ini juga dapat meminimailkan serangan

dari hacker.

VIII. Insecure storage

Aplikasi web biasanya perlu menyimpan informasi yang sensitif seperti

password, informasi kartu kredit, dan yang lain. Dikarenakan item-item

tersebut bersifat sensitif item-item tersebut perlu dienkripsi untuk

menghindari pengaksesan secara langsung. Akan tetapi beberapa metode

enkripsi masih lemah dan masih bisa diserang.

Berikut ini beberapa kesalahan yang sering terjadi :

• Kesalahan untuk mengenkripsi data penting

• Tidak amannya kunci, certificate, dan password

• Kurang amannya lokasi penyimpanan data

• Kurangnya penghitungan dari randomisasi

• Kesalahan pemilihan algoritma

• Mencoba untuk menciptakan algoritma enkripsi yang baru

Berdasarkan skenario berikut ini : Terdapat sebuah aplikasi, dimana

terdapat password pada user object. Akan tetapi, aplikasi menyimpan user

object ke dalam session setelah user login. Permasalahan yang akan

muncul pada skenario ini adalah password dapat dilihat oleh seseorang

yang dapat melihat session dari user tersebut.

Salah satu cara yang dilakukan untuk menghindari kesalahan

penyimpanan informasi yang sensitif adalah : tidak membuat password

��

��

sebagai atribut dari kelas yang mewakili informasi user; Daripada

mengenkripsi nomor kartu kredit dari user, akan lebih baik untuk

menanyakannya setiap kali dibutuhkan.

Selain itu, menggunakan algoritma enkripsi yang sudah ada akan lebih

baik daripada membuat algoritma sendiri. Anda cukup memastikan

algoritma yang akan digunakan telah diakui oleh public dan benar-benar

dapat diandalkan.

IX. Denial of Service

Denial of Service merupakan serangan yang dibuat oleh hacker yang

mengirimkan request dalam jumlah yang sangat besar dan dalam waktu

yang bersamaan. Dikarenakan request-request tersebut, server menjadi

kelebihan beban dan tidak bisa melayani user lainnya.

Serangan DoS mampu menghabiskan bandwidth yang ada pada server.

Selain itu dapat juga menghabiskan memory, koneksi database, dan

sumber yang lain.

Pada umumnya sangat sulit untuk melindungi aplikasi dari serangan ini.

Akan tetapi masih ada cara yang dapat dilakukan seperti membatasi

resource yang dapat diakses user dalam jumlah yang minimal. Merupakan

ide / cara yang bagus untuk membuat load quota yang membatasi jumlah

load data yang akan diakses user dari sistem.

Salah satu contoh adalah pada implementasi bulletin board : adanya

pembatasan user pada saat melakukan search, dimana operasi ini hanya

dapat dilakukan setiap 20 detik. Dengan cara ini dapat dipastikan bahwa

user tidak bisa menghabiskan koneksi dari database.

��

��

Solusi yang lain adalah mendesain aplikasi web dimana user yang belum

terotorisasi hanya memiliki akses yang sedikit atau tidak memiliki akses ke

content web yang berhubungan dengan database.

X. Insecure Configuration Management

Biasanya kelompok (group) yang mengembangkan aplikasi berbeda

dengan kelompok yang mengatur hosting dari aplikasi. Hal ini bisa

menjadi berbahaya, dikarenakan keamanan yang diandalkan hanya dari

segi aplikasi : sedangakan dari segi server juga memiliki aspek keamanan

yang perlu diperhatikan. Adanya kesalahan dari konfigurasi server dapat

melewati aspek keamanan dari segi aplikasi.

Berikut ini adalah kesalahan konfigurasi server yang bisa menimbulkan

masalah :

• Celah keamanan yang belum dipatch dari software yang ada pada

server – administrator tidak melakukan patch software yang ada

pada server.

• Celah keamanan server dimana bisa menampilkan list dari direktori

atau juga serangan berupa directory traversal.

• File-file backup atau file contoh (sample file), file-file script, file

konfigurasi yang tertinggal / tidak perlu.

• Hak akses direktori atau file yang salah.

• Adanya service yang seperti remote administration dan content

management yang masih aktif.

• Penggunaan default account dan default password.

• Fungsi administrative atau fungsi debug yang bisa diakses.

• Adanya pesan error yang informatif dari segi teknis.

• Kesalahan konfigurasi SSL certificate dan setting enkripsi.

• Penggunaan self-signet certificates untuk melakukan autentikasi.

• Penggunaan default certificate.

• Kesalahan autentikasi dengan sistem eksternal.

Documents

Menurut Developing Enterprise Java Applications with J2EE and UML