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
digunakan databaserelasional
system
(standalone)
sekarang
•
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
mengintegrasikan
pembuatan seluruh
sistem
software dan
yang
bersifat
mampu “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- Based 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 operasioperasi 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
Implementasi SOA adalah web service.
untuk
digunakan.
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 merelease
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 Source/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 Score 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://
[:]/<service_name> 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 Enterprise
adalah
Application
Integration (B2Bi).
prioritas Integration
utama (EAI)
sebuah dan
enterprise
dalam
Business-to-Business
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 ancamanancaman 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. WSSecureConversation yang mengelola dan mengautentifikasi pesan, WSFederation 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 SSLprotected 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.
