P. 1
arsitektur-referensi-teknologi-komponen

arsitektur-referensi-teknologi-komponen

|Views: 126|Likes:
Dipublikasikan oleh Mazter Chip

More info:

Published by: Mazter Chip on Mar 18, 2011
Hak Cipta:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

11/21/2012

pdf

text

original

DIREKTORAT JENDERAL

BINA ADMINISTRASI KEUANGAN DAERAH
DEPARTEMEN DALAM NEGERI
REPUBLIK INDONESIA
MODEL KOMPONEN
Versi 1.0
3
DOKUMEN
Direktorat Jenderal Bina Administrasi Keuangan Daerah
Departemen Dalam Negeri Republik Indonesia
1
Dokumen ini disusun oleh Direktorat Jenderal Bina Administrasi
Keuangan Daerah – Departemen Dalam Negeri Republik
Indonesia. Isi dokumen ini bisa berubah se�aktu��aktu Isi dokumen ini bisa berubah se�aktu��aktu
tanpa pemberitahuan resmi. Karena itu agar selalu melakukan Karena itu agar selalu melakukan
pengecekan untuk mendapatkan informasi aktual tentang
dokumen ini.
Distribusi dokumen ini bisa dilakukan dengan bebas tanpa
ke�ajiban apapun dan juga tanpa disertai dengan garansi dalam
bentuk apapun.
Sistem
Informasi
Pengelolaan
Keuangan
Daerah
DOKUMEN 3
MODEL KOMPONEN
Versi 1.0
Direktorat Jenderal Bina Administrasi Keuangan Daerah
Departemen Dalam Negeri Republik Indonesia
ARSITEKTUR REFERENSI
SIPKD
Direktorat Jenderal Bina Administrasi Keuangan Daerah
Departemen Dalam Negeri Republik Indonesia
2
ARSITEKTUR REFERENSI SIPKD
MODEL KOMPONEN
Abstrak
SIPKD merupakan sistem informasi terdistribusi. Salah satu cara
mengimplementasikan SIPKD secara komplit dan terintegrasi
adalah dengan menggunakan sistem basis data tersentralisasi.
Antara server basis data dengan aplikasi pengguna bisa dipasang
sistem server aplikasi yang mengurusi semua logik bisnis
pengelolaan keuangan daerah. Karena dari naturnya sistem
pengelolaan keuangan daerah terbagi dalam beberapa modul
seperti perencanaan, penganggaran, penatausahaan, dan akuntansi;
maka pemasangan sistem server aplikasi dengan berorientasi
pada teknologi komponen akan sangat cocok. Dokumen Model
Komponen ini akan memberikan gambaran, bagaimana jika sisi
server aplikasi pengelolaan keuangan daerah diimplementasikan
dengan teknologi komponen seperti Enterprise Java Beans (EJB).
Walaupun contoh metodologi dalam dokumen ini berorientasi pada
arsitektur EJB tetapi pada dasarnya realisasi dengan arsitektur lain
seperti Common Object Request Broker Architecture (CORBA)
adalah sangat mungkin.
Kata Kunci: Model Komponen, Teknologi Komponen, Sistem
Server Aplikasi, Enterprise Java Beans (EJB), Common Object
Request Broker Architecture (CORBA), Logik Bisnis.
Fasilitator:
Direktorat Jenderal Bina Administrasi Keuangan Daerah
Departemen Dalam Negeri Republik Indonesia
Donasi:
Asian Development Bank (ADB)
Direktorat Jenderal Bina Administrasi Keuangan Daerah
Departemen Dalam Negeri Republik Indonesia
3
Arsitektur Referensi SIPKD
Dokumen 3
Model Komponen
DAFTAR ISI
1 PENDAHULUAN ����������������������������������������������� 5
2 TEKNOLOGI KOMPONEN �������������������������������� 9
2.1 Komponen Server Aplikasi ������������������������������������� 12
2.2 Enterprise Java Beans ������������������������������������������� 16
3. TEKNOLOGI KOMPONEN DAN PROSES BISNIS 20
3.1 Session Façade ���������������������������������������������������� 21
3.2 Multi Vendor/Developer ���������������������������������������� 22
3.3 Rancangan Komponen dan Objek ����������������������������� 25
4 SIPKD DAN TEKNOLOGI KOMPONEN �������������� 31
DAFTAR SINGKATAN ���������������������������������������������� 33
DAFTAR GAMBAR
Gambar 1 � Integrasi SIPKD dengan SIMBADA dan SIMPEG 7
Gambar 2 � Integrasi sistem aplikasi le�at akses langsung
terhadap sistem basis data ������������������������������ 8
Gambar 3 � Komponen dalam Kontainer ��������������������������� 12
Gambar 4 � Contoh skenario penggunaan teknologi
komponen pada server aplikasi SIPKD �������������� 13
Gambar 5 � Sistem objek terdistribusi ������������������������������� 15
Gambar 6 � Contoh komunikasi antara aplikasi klien dengan
komponen EJB �������������������������������������������� 18
Gambar 7 � Pemetaan model proses bisnis ke model komponen 20
Direktorat Jenderal Bina Administrasi Keuangan Daerah
Departemen Dalam Negeri Republik Indonesia
4
Arsitektur Referensi SIPKD
Dokumen 3
Model Komponen
Gambar 8 � Session Façade �������������������������������������������� 21
Gambar 9 � Pemetaan agregasi proses bisnis ke dalam
komponen dengan session façade ��������������������� 22
Gambar 10 � Server Aplikasi SIPKD dengan komponen/modul
dari vendor yang berbeda ����������������������������� 23
Gambar 11 � Contoh n�lapisan logik bisnis dengan EJB ���������� 26
Gambar 12 � Contoh n�lapisan logik bisnis dengan teknologi
objek ����������������������������������������������������� 28
Gambar 13 � Penamaan objek sesuai dengan komponen ���������� 29
Gambar 14 � Membungkus objek dalam komponen ��������������� 30
Gambar 15 � Lapisan logik SAPKD dengan teknologi komponen 31
Direktorat Jenderal Bina Administrasi Keuangan Daerah
Departemen Dalam Negeri Republik Indonesia
5
Arsitektur Referensi SIPKD
Dokumen 3
Model Komponen
1 PENDAHULUAN
SIPKD merupakan sistem yang cukup kompleks. Tapi juga tentunya
cukup banyak orang lebih suka memandang SIPKD dengan
kacamata pragmatis yang sederhana. Orang bisa memandang
aplikasi penunjang SIPKD sebagai sistem aplikasi standalone yang
terdiri dari sistem basis data yang dilengkapi dengan aplikasi grafs
sehingga pengguna bisa mengelola data untuk berbagai modul
yang direalisasikan dalam bentuk menu seperti perencanaan,
penganggaran, penatausahaan, dan akuntansi keuangan.
Tapi tidak bisa dipungkiri bah�a SIPKD melibatkan puluhan
satuan kerja pemerintah daerah yang masing�masing mengelola
perencanaan, penganggaran, penatausahaan, dan akuntansi
keuangan daerah. Walaupun seluruh proses pengelolaan keuangan
daerah pada tiap satuan kerja bisa dilakukan dengan bantuan
sistem aplikasi standalone, artinya dengan menginstal sistem basis
data pada tiap komputer satuan kerja secara terpisah. Lalu data
pengelolaan keuangan daerah seluruh satuan kerja diintegrasikan
dengan cara mengekspor data di tiap satuan kerja ke dalam fle
dan mengimpornya di komputer tertentu seperti di biro keuangan.
Tapi sesungguhnya bisa dipastikan bah�a orang mendambakan
implementasi SIPKD dengan cara yang lebih canggih dan
terintegrasi dengan sempurna. Orang sesungguhnya menginginkan
arsitektur client-server secara terdistribusi tetapi tetap terintegrasi
dengan sistem basis data tersentralisasi. Sehingga dengan cara
ini, setiap kali data diinput di masing�masing satuan kerja maka
secara otomatis seluruh data terintegrasi di sisi server tanpa harus
ada aksi ekspor/impor yang melelahkan dan mungkin memancing
terjadinya kegagalan.
Direktorat Jenderal Bina Administrasi Keuangan Daerah
Departemen Dalam Negeri Republik Indonesia
6
Arsitektur Referensi SIPKD
Dokumen 3
Model Komponen
Ketika orang memutuskan untuk membangun SIPKD dengan
arsitektur client-server secara terdistribusi maka dengan sendirinya
menuntut beberapa persyaratan sehingga arsitektur client-server
secara terdistribusi dapat terealisasi dengan baik. Persyaratan
pertama yang akan langsung terpikirkan adalah tersedianya
infrastruktur jaringan komputer lengkap yang menghubungkan
seluruh satuan kerja di daerah. Pada setiap satuan kerja misalnya
dipasang tiga atau lebih komputer khusus untuk menangani
pengelolaan keuangan daerah. Selain seluruh komputer penunjang
SIPKD pada masing�masing satuan kerja tersambung le�at
Local Area Network (LAN), seluruh komputer tersebut juga telah
tersambung ke komputer server SIPKD. Komputer server SIPKD
ini merupakan komputer dengan spesifkasi yang mencukupi untuk
melayani seluruh koneksi dan transaksi data dari seluruh satuan
kerja.
Selain jaringan komputer lengkap, membangun SIPKD dengan
arsitektur client-server secara terdistribusi juga menuntut arsitektur
sistem aplikasi yang memadai. Orang bisa memulai dengan arstektur
client-server 2-tier (dua lapis). Tapi bisa juga menggunakan
arsitektur yang lebih menjamin skalabilitas dan realibilitas seperti
menggunakan arsitektur client-server 3-tier atau n�tier.
Bagi sebagian orang (atau mungkin banyak orang), membangun
SIPKD dengan arsitektur 3�tier atau n�tier merupakan langkah
berlebihan, karena bahkan untuk membangun SIPKD dengan
arsitektur 2�tier saja tidak terasa mudah. Tapi pilihan ini jangan
dianggap enteng. Seringkali pemilihan arsitektur yang tidak tepat
akan menyebabkan kerugian pada masa yang akan datang seperti
terjadinya degradasi performansi sistem tatkala komputer di
Direktorat Jenderal Bina Administrasi Keuangan Daerah
Departemen Dalam Negeri Republik Indonesia
7
Arsitektur Referensi SIPKD
Dokumen 3
Model Komponen
sisi klien (pengguna) berkembang menjadi cukup banyak; atau
kemudian disadari bah�a integrasi SIPKD dengan sistem lainnya
seperti Sistem Pengelolaan Barang Daerah dan Sistem Penggajian
Pega�ai menjadi tidak mulus atau tidak mungkin kecuali dengan
menggunakan cara semi manual seperti aksi ekspor/impor data
lewat fle.
Penganggaran
Penatausahaan Akuntansi
Pelaporan
SIPKD
SIMBADA
SIMPEG
Remote Interface
Gambar 1 - Integrasi SIPKD dengan SIMBADA dan SIMPEG
Gambar 1 memperlihatkan contoh integrasi SIPKD dengan
sistem lain seperti SIMBADA (Sistem Informasi Manajemen
Barang Daerah) dan SIMPEG (Sistem Informasi Manajemen
Kepega�aian). Integrasi yang diperlihatkan oleh Gambar 1 adalah
integrasi pada tingkat sistem aplikasi dengan cara komunikasi
le�at antarmuka komunikasi aplikasi yang disebut dengan remote
interface. Komunikasi antaraplikasi ini akan dengan sangat baik Komunikasi antaraplikasi ini akan dengan sangat baik
jika direalisasikan dengan teknologi komponen.
Sebagian orang akan mengintegrasikan SIPKD dengan sistem lain
seperti SIMBADA dan SIMPEG le�at cara dengan abstraksi yang
lebih rendah seperti akses langsung terhadap sistem basis data
Direktorat Jenderal Bina Administrasi Keuangan Daerah
Departemen Dalam Negeri Republik Indonesia
8
Arsitektur Referensi SIPKD
Dokumen 3
Model Komponen
Gambar 2 - Integrasi sistem aplikasi lewat akses
langsung terhadap sistem basis data
SIMBADA SIPKD
Basisdata
SIPKD
Basisdata
SIMBADA
Integrasi sistem aplikasi dengan cara akses langsung terhadap sistem
basis data seperti diperlihatkan pada Gambar 2 akan menimbulkan
masalah otorisasi akses terhadap basis data dari sistem aplikasi lain,
seperti misalnya akses dari sistem aplikasi SIMBADA terhadap
sistem data base SIPKD secara langsung. Selain itu cara seperti
demikian juga telah melanggar prinsip transparansi komunikasi
antarsistem aplikasi.
Realisasi SIPKD secara terdistribusi dengan menggunakan
teknologi komponen pada sisi server memungkinkan terbentuknya
SIPKD dengan abstraksi sistem yang lebih baik. Walaupun
penggunaan teknologi komponen menuntut keahlian lebih dari
pihak pengembang sistem aplikasi, tetapi pada akhirnya akan
melahirkan sistem aplikasi kelas enterprise dengan arsitektur yang
matang.
Pada bagian berikut dokumen ini akan diulas konsep teknologi
komponen untuk sisi server aplikasi dan metodologi penerapannya
pada suatu sistem aplikasi terdistribusi seperti Sistem Aplikasi
Pengelolaan Keuangan Daerah (SAPKD).
Direktorat Jenderal Bina Administrasi Keuangan Daerah
Departemen Dalam Negeri Republik Indonesia
9
Arsitektur Referensi SIPKD
Dokumen 3
Model Komponen
2 TEKNOLOGI KOMPONEN
Ketika kita mendengar kata komponen hampir bisa dipastikan bah�a
rata�rata orang menginterpretasikan komponen sebagai bagian yang
membangun sesuatu yang lebih besar atau lebih lengkap. Di dunia
perangkat lunak, kata komponen sudah tidak asing lagi dan banyak
sekali digunakan baik secara konseptual maupun dalam realisasi
suatu sistem perangkat lunak. Para pengembang perangkat lunak
langsung akan ingat pada teknologi seperti ActiveX atau Java Beans
ketika mendengar kata komponen perangkat lunak. Tetapi teknologi
komponen yang akan dibahas dalam dokumen ini bukan teknologi
komponen pembangun antarmuka pengguna (GUI, Gaphic User
Interface) seperti ActiveX atau Java Beans. Teknologi komponen
yang akan dibahas dalam dokumen ini adalah teknologi komponen
untuk sisi server aplikasi yang di dalamnya pengelolaan logik
bisnis dilakukan.
Sebelum kita melanjutkan, mungkin sebagian orang akan langsung
teringat pada teknologi objek ketika mendengar istilah teknologi
komponen. Pengembangan perangkat lunak dengan orientasi
objek telah cukup memasyarakat dan terkenal saat ini. Bahasa
pemrograman berorientasi objek seperti Java dan C++ merupakan
perangkat utama dalam mengembangkan perangkat lunak dengan
orientasi objek. Dalam hal ini para programmer memandang segala
sesuatu dalam sistem sebagai objek. Dari banyak objek yang saling
berelasi akhirnya ter�ujudlah sistem aplikasi yang diinginkan.
Lalu apa perbedaan antara objek dengan komponen ketika kita
memahami bah�a komponen juga bagian pembangun dari sistem
aplikasi perangkat lunak?
Model Objek akan dibahas dalam dokumen terpisah dari dokumen
Direktorat Jenderal Bina Administrasi Keuangan Daerah
Departemen Dalam Negeri Republik Indonesia
10
Arsitektur Referensi SIPKD
Dokumen 3
Model Komponen
Model Komponen ini. Tetapi di sini kita akan menyinggung sedikit
konsep teknologi objek untuk membedakannya dengan teknologi
komponen. Sebelum kita membahas perbedaan�perbedaan antara
objek dengan komponen di dunia perangkat lunak, kita akan
menyinggung dulu persamaan di antara keduanya. Objek dan
komponen sama�sama memiliki persamaan seperti berikut:
Memiliki identitas yang unik
Menerapkan konsep enkapsulasi, yaitu membungkus data
(atribut) dan aktivitas secara transparan. Hanya aktivitas
yang bersifat publik (biasanya disebut interface) yang bisa
dikenal dari luar objek/komponen yang memilikinya
Memiliki kemampuan me�ariskan sifat�sifat yang
dimilikinya kepada objek/komponen turunannya
Bisa memiliki nama aktivitas yang sama tetapi dengan
efek atau hasil yang berlainan (polymorfk)
Dengan ciri dan kemampuan yang dimiliki oleh objek dan
komponen seperti di atas, pengembangan sistem perangkat
lunak dengan teknologi objek bisa sangat modular dan bisa
menggunakan objek atau komponen yang telah ada sebagai dasar
untuk membangun objek atau komponen lainnya. Dengan demikian
penulisan ulang kode program untuk berbagai keperluan yang
mirip akan terhindarkan. Tetapi yang paling pokok dari konsep
objek dan komponen adalah tingkat abstraksi yang tinggi dalam
memandang sistem le�at pengelompokan dan relasi antarkelompok,
penglokalisasian atribut dan aktivitas pada tiap kelompok (konsep
enkapsulasi); sehingga pada pengembangan sistem perangkat
lunak yang besar dan terdistribusi akan lebih mudah ditangani
dan terkendali.
Direktorat Jenderal Bina Administrasi Keuangan Daerah
Departemen Dalam Negeri Republik Indonesia
11
Arsitektur Referensi SIPKD
Dokumen 3
Model Komponen
Setelah membahas persamaan antara objek dengan komponen,
lalu di mana letak perbedaan antara keduanya? Perbedaaan utama
antara objek dengan komponen adalah pada kemandiriannya. Objek
biasanya me�akili satuan terkecil dari suatu sistem. Kadangkala
objek bisa juga menjadi cukup besar dan terdiri dari objek lainnya
(misalnya memiliki beberapa atribut yang berperan sebagai
referensi terhadap objek lainnya). Tetapi suatu objek masih terlalu
kecil untuk bisa melaksanakan suatu pekerjaan secara utuh dan
mandiri tanpa bantuan objek lainnya. Lain lagi dengan komponen,
biasanya suatu komponen telah merupakan kumpulan kode program
yang diperuntukan bagi penyelesaian suatu pekerjaan utuh secara
mandiri. Artinya suatu komponen software telah memiliki tugas
tertentu yang bisa ia selesaikan sendiri. Suatu komponen software
tidak tergantung pada komponen software lainnya, �alaupun
beberapa komponen bisa dikombinasikan untuk membentuk
menyelesaikan rangkaian kerja tertentu. Karena itu, komponen
software bisa dikembangkan sendiri-sendiri dengan spesifkasi
yang tidak tergantung pada spesifkasi komponen lainnya. Tinggal
ketika akan dikombinasikan dengan komponen lainnya perlu dilihat
apakah masing�masing komponen memiliki antarmuka komunikasi
yang cocok dan diperlukan.
Walaupun komponen itu mandiri dalam melaksanakan tugasnya,
tetapi biasanya komponen memerlukan lingkungan untuk bisa
hidup. Lingkungan ini biasanya berupa sistem perangkat lunak yang
menyediakan fasilitas tertentu sehingga komponen bisa hidup di
dalam sistem tersebut. Lingkungan seperti tersebut biasanya disebut
kontainer komponen. Seringkali komponen yang ada dalam suatu
kontainer tidak tampak dari luar kontainer tersebut. Kontainer hanya
bisa memperlihatkan referensi tidak langsung atas komponen�
Direktorat Jenderal Bina Administrasi Keuangan Daerah
Departemen Dalam Negeri Republik Indonesia
12
Arsitektur Referensi SIPKD
Dokumen 3
Model Komponen
komponen yang ada di dalamnya, sehingga suatu komponen
bisa dihidupkan, diaktifkan atau dimatikan kembali secara tidak
langsung dari luar kontainer atas permintaan pengguna.
KONTAINER Antar Muka Luar
Komponen
Antarmuka
Komponen
Aplikasi
Pengguna
Gambar 3 - Komponen dalam Kontainer
Dari Gambar 3 di atas, kita sudah bisa langsung membayangkan
dalam kepala kita, bah�a berbagai modul dalam pengelolaan
keuangan daerah seperti perencanaan, penganggaran, penatausahaan,
dan akuntansi keuangan masing�masing bisa di�akili oleh satu
komponen. Jika kemudian dibangun sistem lain seperti SIMBADA
atau SIMPEG maka tinggal membangun komponen yang diperlukan
dalam SIMBADA/SIMPEG dan membiarkannya berkomunikasi
le�at antarmuka masing�masing dengan komponen SAPKD
yang telah ada lebih dulu! Bahkan kita tidak perlu mengetahui
secara detail, bagaimana pengolahan data dalam sistem basis data,
karena hal tersebut dilakukan oleh komponen untuk kita secara
transparan.
2.1 Komponen Server Aplikasi
Dokumen Model Komponen ini tidak akan membahas komponen
perangkat lunak untuk sisi klien berupa komponen antarmuka grafs
Direktorat Jenderal Bina Administrasi Keuangan Daerah
Departemen Dalam Negeri Republik Indonesia
13
Arsitektur Referensi SIPKD
Dokumen 3
Model Komponen
seperti ActiveX Control atau Java Beans. Tema dalam dokumen Tema dalam dokumen
ini adalah komponen perangkat lunak pada sisi server aplikasi.
Bagaimana membangun aplikasi server sistem pengelolaan
keuangan daerah dengan teknologi komponen.
Gambar 4 - Contoh skenario penggunaan teknologi komponen
pada server aplikasi SIPKD
Server aplikasi yang dibangun dengan teknologi komponen tidak
membatasi akses hanya dari aplikasi klien yang memiliki protokol
komunikasi sesuai dengan standar protokol yang digunakan
oleh kontainer komponen (dalam Gambar 4 di atas diasumsikan
menggunakan protokol IIOP dan kontainernya menggunakan
produk EJB); tetapi mungkin juga server aplikasi diakses dari
aplikasi �eb dengan menggunakan protokol HTTP. Bagi sistem
aplikasi lain juga disediakan akses le�at teknologi web services.
Adapun transaksi data ke dalam sistem basis data dilakukan oleh
server aplikasi secara transparan tanpa disadari oleh sisi aplikasi
pengguna.
Direktorat Jenderal Bina Administrasi Keuangan Daerah
Departemen Dalam Negeri Republik Indonesia
14
Arsitektur Referensi SIPKD
Dokumen 3
Model Komponen
Aplikasi klien yang ingin memanfaatkan layanan komponen pada sisi
server hanya perlu mengetahui spesifkasi antarmuka yang dimiliki
oleh komponen. Lalu aplikasi klien berusaha mendapatkan referensi
jarak jauh dari antarmuka komponen (remote interface). Setelah itu
aplikasi bisa menggunakan semua layanan yang dita�arkan oleh
komponen. Ketika suatu komponen akan mena�arkan layanan
baru maka komponen tersebut tinggal mempublikasikan antarmuka
dari layanan baru tersebut. Sedangkan jika pada sisi server akan
ditambahkan komponen baru maka komponen tersebut tinggal
diaktifkan dan dengan sendirinya antarmuka dari komponen baru
tersebut akan bisa diakses dari sisi aplikasi klien.
Hal utama dari beberapa kelebihan teknologi komponen pada sisi
server aplikasi adalah tingkat abstraksinya yang tinggi sehingga
pengembangan sistem aplikasi bisa dilakukan secara modular dan
bisa mengatasi kerumitan sistem jaringan komputer yang tersebar.
Sistem aplikasi terdistribusi seperti SAPKD akan sulit untuk
dibangun dengan arsitektur berabstraksi rendah seperti teknologi
pemrograman berorientasi prosedural. Selain itu, kontainer
komponen pada sisi server yang telah standar dan ada di pasaran
biasanya telah menyediakan berbagai macam layanan standar
seperti transaksional basis data, aktivasi, dan deaktivasi komponen
serta berbagai macam layanan standar lainnya. Berbagai macam
layanan standar tersebut akan sangat memakan �aktu jika harus
dikembangkan sendiri oleh pengembang sistem aplikasi.
Teknologi komponen sendiri berbasiskan pada teknologi objek
terdistribusi. Dalam hal ini, komponen pada tingkat pemrograman
memang biasanya dibangun dari beberapa objek. Gambar berikut
memperlihatkan prinsip dasar bagaimana aplikasi klien bisa
berkomunikasi dengan komponen.
Direktorat Jenderal Bina Administrasi Keuangan Daerah
Departemen Dalam Negeri Republik Indonesia
15
Arsitektur Referensi SIPKD
Dokumen 3
Model Komponen
Aplikasi
Klien
Stub
Jaringan
Komputer
Objek
Terdistribusi
(Server)
Skeleton
Gambar 5 - Sistem objek terdistribusi
Ketika aplikasi klien ingin memanggil salah satu layanan yang
dita�arkan suatu objek terdistribusi (objek ini yang membangun
komponen) maka aplikasi klien memanggil nama layanan yang
diinginkan le�at stub. Stub ini semacam proxy atau representasi
objek terdistribusi di sisi klien. Semua nama antarmuka yang
dimiliki objek terdistribusi bisa diakses oleh aplikasi klien melalui
stub dari objek terdistribusi yang bersangkutan. Stub tahu cara
membungkus semua argumen (nilai dari parameter antarmuka)
yang diberikan oleh aplikasi klien, membungkusnya dalam
bentuk paket yang sesuai dengan protokol jaringan komputer
lalu meneruskannya kepada skeleton dari objek terdistribusi.
Skeleton juga berperan sebagai proxy dari objek terdistribusi,
hanya ia berada di sisi server. Skeleton mengetahui bagaimana cara
menerima paket kiriman stub lalu membukanya dan meneruskan
kepada objek terdistribusi untuk diolah lebih lanjut sesuai dengan
antarmuka yang dipanggil oleh aplikasi klien. Jika terdapat nilai
Direktorat Jenderal Bina Administrasi Keuangan Daerah
Departemen Dalam Negeri Republik Indonesia
16
Arsitektur Referensi SIPKD
Dokumen 3
Model Komponen
yang harus dikembalikan dari objek terdistribusi kepada aplikasi
klien maka nilai tersebut dikirim le�at skeleton dengan cara yang
sama kepada stub di seberang jaringan komputer untuk diteruskan
kepada aplikasi klien.
Teknologi objek terdistribusi sangat baik untuk membangun
sistem aplikasi terdistribusi yang melintasi kompleksitas jaringan
komputer. Tetapi jika sistem aplikasi yang dikembangkan cukup
besar maka jumlah objek yang dibuat akan berkembang juga
jumlahnya dan akan menjadi cukup sulit untuk mengelolanya.
Maka perlu ada teknologi yang mengkombinasikan beberapa objek
membentuk suatu komponen yang lebih besar sehingga kumpulan
objek tersebut bisa dilihat dari tataran abstraksi yang lebih tinggi
membentuk komponen mandiri yang memberikan layanan utuh
tertentu. Komponen yang terbentuk ditempatkan dalam kontainer
sehingga komponen tersebut bisa memanfaatkan berbagai macam
layanan standar yang disediakan kontainer.
2.2 Enterprise Java Beans
Saat ini setidaknya ada dua teknologi komponen terkemuka, yaitu
EJB dari Sun Microsystem dan CORBA dari Object Management
Group (OMG). EJB dengan CORBA juga memiliki hubungan
erat karena saat ini EJB telah mengadopsi IIOP yang berasal dari
CORBA sebagai protokol komunikasi EJB. Dengan demikian,
komponen dari EJB akan bisa berkomunikasi dengan baik dengan
komponen dari CORBA.
Dalam bagian ini akan diuraikan konsep EJB secara ringkas
untuk menambah gambaran tentang teknologi komponen yang
Direktorat Jenderal Bina Administrasi Keuangan Daerah
Departemen Dalam Negeri Republik Indonesia
17
Arsitektur Referensi SIPKD
Dokumen 3
Model Komponen
sekarang ada di pasaran. EJB merupakan arsitektur komponen
yang mena�arkan fasilitas bagi para pengembang perangkat
lunak untuk membangun sistem server aplikasi dengan cara yang
modular, cepat, dan robus. EJB menyediakan middleware kelas
enterprise sehingga para pengembang sistem aplikasi bisa fokus
pada pengembangan komponen yang mengelola logik bisnis tanpa
harus memikirkan terlebih dahulu fasilitas yang harus tersedia
dalam lingkungan sistem aplikasi server terdistribusi.
Komponen perangkat lunak dalam EJB disebut bean. Untuk
mengelola komponen yang kita buat, EJB menyediakan kontainer
komponen. Kontainer menjadi perantara komunikasi antara
komponen dengan klien, mengelola persistensi komponen,
keamanan, dan hal lainnya. Semua komponen dalam EJB diturunkan
dari bean utama yang disebut Enterprise Beans. Sedangkan tipe
bean lainnya adalah: Session Beans, Entity Beans, dan Message-
driven Beans.
Session Beans memodelkan proses bisnis. Karena memodelkan
proses bisnis maka Session Beans menggambarkan aktivitas dan
pengelolaan logik bisnis. Dalam mendesain sistem server aplikasi
kita harus memodelkan proses, prosedur, fungsi, aktivitas sebagai
Session Beans.
Entity Beans memodelkan struktur data. Entity Beans dapat
berupa representasi dari kelompok data yang dikelola dalam suatu
proses bisnis. Dalam merancang sistem server aplikasi kita bisa
memetakan struktur data yang ada dalam tabel basis data ke dalam
Entity Beans.
Message-driven Beans memodelkan suatu aktivitas seperti pada
Direktorat Jenderal Bina Administrasi Keuangan Daerah
Departemen Dalam Negeri Republik Indonesia
18
Arsitektur Referensi SIPKD
Dokumen 3
Model Komponen
Session Beans, hanya Message-driven Beans fokus pada pengiriman
berita. Seperti pada pengiriman surat dalam kehidupan nyata,
aktivitas yang dilakukan Message-driven Beans tidak menuntut
pengembalian nilai atau ja�aban saat itu juga. Sedangkan Session
Beans bisa kita misalkan seperti komunikasi telepon, yaitu ketika
komunikasi dimulai harus terus tersambung hingga komunikasi
selesai.
Semua beans yang ada pada kontainer hanya bisa diakses oleh
klien le�at antarmuka yang dita�arkan oleh masing�masing beans.
Sebelum melakukan koneksi dengan suatu beans, klien harus
mendapatkan referensi jarak jauh (remote interface) dari beans
yang bersangkutan. Antarmuka jarak jauh ini bisa didapatkan secara
tidak langsung le�at kontainer dengan memanggil terlebih dahulu
Home Interface dari bean yang bersangkutan.
Aplikasi
Klien
Home
Object
Home
Interface
1
Buat koneksi
ke bean
EJB
Object
2
Buat EJB Object
3
Berikan referensi
EJB Object
4
Panggil suatu method
Session
Beans
5
Teruskan pemanggilan
method
Transactional Service,
Persistence Service, Security
Service dll.
Entity Beans
6
Manipulasi
data
Basisdata
EJB KONTAINER
Remote
Interface
Gambar 6 - Contoh komunikasi antara aplikasi klien dengan komponen EJB
Direktorat Jenderal Bina Administrasi Keuangan Daerah
Departemen Dalam Negeri Republik Indonesia
19
Arsitektur Referensi SIPKD
Dokumen 3
Model Komponen
Setelah pemanggilan atas Home Interface maka pada aplikasi
klien akan diberikan referensi (berupa remote interface) dari EJB
Object yang bersangkutan. EJB Object ini berupa proxy dari bean
(misalnya session beans) yang dipanggil le�at Home Interface.
Seluruh pemanggilan method (istilah lainnya prosedur/fungsi)
akan diteruskan oleh EJB Object kepada Session Beans yang
dimaksud. Session Beans dapat memanggil Entity Beans secara
lokal dalam kontainer jika memang diperlukan manipulasi data
dalam basis data.
Direktorat Jenderal Bina Administrasi Keuangan Daerah
Departemen Dalam Negeri Republik Indonesia
20
Arsitektur Referensi SIPKD
Dokumen 3
Model Komponen
3. TEKNOLOGI KOMPONEN DAN
PROSES BISNIS
EJB mena�arkan Session Beans dan Entity Beans. Hal ini telah
selaras dengan perancangan berorientasi proses. Session Beans bisa
dipandang sebagai representasi proses dan Entity Beans sebagai
representasi data yang dikelola dalam proses.
Teknik pemrograman yang baik dalam EJB menentukan bah�a
aplikasi klien tidak akan pernah memanggil Entity Beans secara
langsung. Entity Beans hanya dipanggil melalui Session Beans.
Desain pemrograman dalam EJB ini telah selaras dengan desain
proses bisnis yang selalu mengelola data di ba�ah proses.
Proses Data
Session Beans
Entity Beans
PEMODELAN PROSES BISNIS
PEMODELAN KOMPONEN
Gambar 7 - Pemetaan model proses bisnis ke model komponen
Seperti diperlihatkan le�at Gambar 7, penggunaan teknologi
komponen dalam perancangan sistem aplikasi memungkinan suatu
pemetaan yang mulus antara level perancangan (pemodelan proses
bisnis) dengan level implementasi perangkat lunak (pemodelan
komponen). Panah putus�putus menggambarkan pemetaan Proses
terhadap Session Beans dan pemetaan Data terhadap Entity Beans.
Direktorat Jenderal Bina Administrasi Keuangan Daerah
Departemen Dalam Negeri Republik Indonesia
21
Arsitektur Referensi SIPKD
Dokumen 3
Model Komponen
Sedangkan panah tanpa putus�putus menggambarkan pemanggilan
(eksekusi).
3.1 Session Façade
Session Façade merupakan pola perancangan sistem perangkat
lunak dengan arsitektur EJB. Dengan pola Session Façade bisa
dihemat pemakaian sumber daya jaringan, karena sekumpulan
Sessions Beans dipanggil secara lokal (tidak langsung le�at
jaringan oleh aplikasi klien).
Klien
J
a
r
i
n
g
a
n
Gambar 8 - Session Façade
Pola Session Façade seperti diperlihatkan oleh Gambar 8 juga
memberikan pembagian logik bisnis yang lebih baik. Misalnya jika
terjadi transaksi basis data maka konteks transaksi bisa dikelola
dengan lebih baik di sisi server.
Dalam perancangan sistem aplikasi seringkali ditemukan
agregasi proses (grup proses). Suatu proses pada tingkat abstraksi
paling atas bisa diurai kembali dalam banyak sub�proses hingga
menggambarkan aktivitas pada tingkat abstraksi paling rendah.
Hal ini dengan tepat sekali bisa di�akili oleh pola Session Façade
pada tingkat perancangan implementasi perangkat lunak dengan
teknologi komponen.
Direktorat Jenderal Bina Administrasi Keuangan Daerah
Departemen Dalam Negeri Republik Indonesia
22
Arsitektur Referensi SIPKD
Dokumen 3
Model Komponen
Ga mb a r 9 d i s a mp i n g i n i
memperlihatkan bagaimana pemetaan
agregasi proses Bisnis pada tingkat
perancangan model bi sni s ke
dalam tingkat implementasi dengan
pendekatan teknologi komponen.
Kita bisa melihat suatu pemetaan
yang bersih antara abstraksi di
level proses bisnis dan abstraksi
di tingkat implementasi secara
berkesinambungan. Dalam hal ini
tidak ada kehilangan semantik model
proses bisnis yang dipetakan pada
abstraksi model komponen.
Metodologi pemetaan model bisnis
ke dalam model komponen ini bisa
dilakukan untuk semua proses bisnis
pengelolaan keuangan daerah yang
telah dituangkan dalam Dokumen 1
Arsitektur Referensi SIPKD.
3.2 Multi Vendor/Developer
Pengembangan sistem aplikasi dengan teknologi komponen
memungkinkan beberapa komponen pembangun suatu aplikasi
dikembangkan oleh pihak yang berbeda tetapi dengan jaminan
integrasi komunikasi antarkomponen tersebut secara mulus. Hal
terpenting adalah dengan ditetapkannya antarmuka komunikasi
yang dita�arkan masing�masing komponen secara standar.
Grup Proses
Proses Proses Grup Proses
Proses
Data
Proses
Data
Session
Beans
Session
Beans
Session
Beans
Session
Beans
Session
Beans
Session
Beans
Entity Beans Entity Beans
MODEL PROSES BISNIS
MODEL KOMPONEN
Gambar 9 - Pemetaan agregasi
proses bisnis ke dalam komponen
dengan session façade
Direktorat Jenderal Bina Administrasi Keuangan Daerah
Departemen Dalam Negeri Republik Indonesia
23
Arsitektur Referensi SIPKD
Dokumen 3
Model Komponen
Komponen
Perencanaan &
Penganggaran
(Vendor A)
Komponen
Penatausahaan
(Vendor B)
Komponen
Akuntansi &
Pelaporan
(Vendor C)
KUA PPA
RKA-SKPD
SPP
SPM
SP2D
GL Neraca
Arus
Kas
EJB KONTAINER
Gambar 10 - Server Aplikasi SIPKD dengan komponen/modul dari vendor yang
berbeda
Pengembangan SAPKD dengan menggunakan teknologi komponen
akan memungkinkan daerah (Provinsi/Kabupaten/Kota) untuk
menggunakan dan mengintegrasikan modul�modul SAPKD dari
vendor yang berbeda. Sesuai dengan kenyataan, bah�a banyak
daerah mengimplementasikan SAPKD secara bertahap. Banyak
daerah yang pada tahap pertama hanya mengimplementasikan
modul penganggaran saja. Tapi tidak jarang kenyataannya vendor
yang dikontrak oleh daerah untuk mengimplementasikan modul
penganggaran tersebut tidak memiliki modul penatausahaan dan
akuntasi. Sehingga daerah yang bersangkutan tidak meneruskan
implementasi hingga modul penatausahaan dan akuntansi.
Jikalaupun pemda pada akhirnya mengimplementasikan modul
penatausahaan dan akuntansi dengan mengontrak vendor lain,
Direktorat Jenderal Bina Administrasi Keuangan Daerah
Departemen Dalam Negeri Republik Indonesia
24
Arsitektur Referensi SIPKD
Dokumen 3
Model Komponen
akhirnya modul penganggaran tidak bisa terintegrasi dengan modul
penatausahaan dan akuntansi.
Dokumen Model Komponen Versi 1.0 ini tidak menyertakan
spesifkasi antarmuka yang harus dimiliki oleh masing-masing
komponen pembangun SAPKD. Dokumen ini baru pada tahap
pengenalan dan penyertaan usulan penggunaan teknologi komponen
untuk pengembangan SAPKD. Tetapi pada versi selanjutnya dari
dokumen ini diharapkan telah disertakan spesifkasi antarmuka
standar yang harus dita�arkan oleh masing�masing komponen
pembangun SAPKD; juga tentunya telah ditentukan daftar dan
spesifkasi teknis dari masing-masing komponen tersebut.
Penyusunan spesifkasi teknis dan antarmuka dari tiap komponen
pembangun SAPKD harus dilakukan oleh gabungan vendor
SAPKD, mungkin dalam bentuk konsorsium. Dengan demikian
spesifikasi yang ditetapkan dapat diterima oleh pasar karena
merupakan kesepakatan bersama.
Pengembangan SAPKD secara modular ini juga tidak harus
menggunakan salah satu teknologi komponen saja semisal EJB.
Bisa juga modul�modul SAPKD dikembangkan oleh teknologi
komponen lainnya seperti CORBA. Tapi antarteknologi ini
memang dituntut kemampuan komunikasi dengan spesifkasi
protokol komunikasi yang telah distandarisasi. Dalam hal ini
tentunya EJB dengan CORBA akan bisa berkomunikasi dengan
baik karena kedua platform tersebut sama�sama menggunakan IIOP
sebagai protokol komunikasi.
Komunikasi antara platform komponen seperti EJB dan CORBA
dengan platform lain yang tidak berorientasi komponen masih
dimungkinkan dengan menggunakan jembatan komunikasi
Direktorat Jenderal Bina Administrasi Keuangan Daerah
Departemen Dalam Negeri Republik Indonesia
25
Arsitektur Referensi SIPKD
Dokumen 3
Model Komponen
(bridge) atau menggunakan semacam pembungkus pada platform
lain (�rapper). Teknologi objek terdistribusi seperti Java�RMI
dalam hal ini akan dengan mulus bisa berkomunikasi dengan
EJB, karena EJB juga menggunakan RMI sebagai protokol
komunikasi di samping IIOP. Tetapi teknologi lain semacam
DCOM dari Microsoft misalnya akan menuntut bridge untuk bisa
berkomunikasi dengan EJB atau CORBA.
3.3 Rancangan Komponen dan Objek
Seringkali pada realitas implementasi sistem terdistribusi, kita
perlu beralih dengan cepat dari sistem aplikasi terdistribusi dengan
teknologi objek ke sistem aplikasi terdistribusi berteknologi
komponen atau sebaliknya. Hal ini bisa terjadi misalnya ketika
sistem aplikasi telah dikembangkan dengan teknologi objek dan
suatu saat diputuskan untuk ditulis ulang dengan teknologi komponen
karena pertimbangan tertentu seperti modularitas, feksibilitas atau
karena memutuskan untuk menggunakan middleware komponen
semacam EJB. Tetapi bisa juga pertimbangannya karena kita
ingin memiliki sistem aplikasi dengan rancangan yang sama tetapi
bisa dipakai untuk skala besar maupun skala kecil. Masalahnya,
untuk penggunaan skala kecil, yaitu dengan jumlah klien yang
tidak begitu banyak, seringkali terasa prakstis lebih menggunakan
arsitektur yang lebih ringan semisal sistem client-server 2-tier.
Mengembangkan dua aplikasi dengan arsitektur berbeda padahal
untuk kepentingan pengelolaan proses bisnis yang sama tentunya
akan merepotkan. Selain memakan �aktu tentunya juga akan
memakan sumber daya yang berlipat. Jika kemungkinan seperti ini
bisa terjadi maka sebaiknya dibuat rancangan sistem aplikasi yang
Direktorat Jenderal Bina Administrasi Keuangan Daerah
Departemen Dalam Negeri Republik Indonesia
26
Arsitektur Referensi SIPKD
Dokumen 3
Model Komponen
bisa dengan mudah diadaptasi ke dalam teknologi objek maupun
ke dalam teknologi komponen.
Kita bisa merancang lapisan logik bisnis sistem aplikasi dengan
pola yang bisa diadaptasi ke dalam teknologi objek maupun ke
dalam teknologi komponen. Arsitektur n�tier untuk pengembangan
sistem dengan teknologi komponen maupun untuk teknologi objek
bisa dibuat sama. Perbedaannya hanya pada lapisan paling ba�ah
yang memiliki akses langsung atas sistem basis data. Lapisan paling
ba�ah pada sistem dengan teknologi komponen diperuntukan
bagi entity beans, sedangkan pada sistem dengan teknologi objek
diperuntukan bagi object library/package untuk akses ke dalam
basis data.
Session Beans A Session Beans B Session Beans C
Session Beans D
Session Beans F
Session Beans E
Entity Beans A Entity Beans C Entity Beans B Entity Beans D
Sistem Basisdata Relasional
Gambar 11 - Contoh n-lapisan logik bisnis dengan EJB
Direktorat Jenderal Bina Administrasi Keuangan Daerah
Departemen Dalam Negeri Republik Indonesia
27
Arsitektur Referensi SIPKD
Dokumen 3
Model Komponen
Gambar 11 memperlihatkan contoh lapisan logik bisnis dengan
arsitektur n�tier untuk diimplementasikan dengan EJB. Lapisan
paling atas ditempati oleh sekumpulan Session Beans utama.
Session Beans utama inilah yang mena�arkan antarmuka yang bisa
langsung diakses oleh aplikasi klien (remote interface). Sedangkan
lapisan kedua diisi oleh sekumpulan Session Beans yang melayani
Session Beans utama (session façade). Session Beans pada lapisan
kedua ini hanya memiliki local interface yang hanya bisa diakses
oleh beans lain dalam satu kontainer, tanpa menyediakan remote
interface untuk keperluan akses dari luar kontainer semisal akses
dari aplikasi klien. Lapisan ketiga menyediakan sekumpulan entity
beans yang memiliki akses langsung atas sistem basis data. Setiap
Session Beans pada lapisan dua yang ingin memanipulasi data
dalam basis data akan melakukannya le�at akses atas entity beans
yang ada pada lapisan ketiga.
Arsitektur n�tier yang diperuntukan bagi implementasi dengan
teknologi komponen semacam EJB bisa diadaptasi pula untuk
implementasi dengan teknologi objek semisal dengan objek
Java konvensional. Kita bisa menempatkan seluruh objek yang
mena�arkan antarmuka yang bisa diakses secara terbuka dari sisi
klien pada lapisan logik bisnis paling atas. Lalu untuk keperluan
objek pada lapisan pertama kita sediakan sekumpulan objek pada
lapisan dua untuk mengelola proses bisnis secara lebih rinci.
Ketika pengelolaan proses bisnis secara rinci yang dilakukan
oleh kumpulan objek pada lapisan kedua memerlukan akses pada
basis data maka objek pada lapisan dua akan mengakses objek
pada lapisan tiga yang disediakan untuk memanipulasi data secara
langsung ke dalam basis data. Hal ini diperlihatkan dalam Gambar
12 pada halaman berikut.
Direktorat Jenderal Bina Administrasi Keuangan Daerah
Departemen Dalam Negeri Republik Indonesia
28
Arsitektur Referensi SIPKD
Dokumen 3
Model Komponen
Sistem Basisdata Relasional
Objek A Objek B Objek C Objek D
Objek E Objek F Objek G Objek H
Objek I Objek J Objek K Objek M Objek L
Gambar 12 - Contoh n-lapisan logik bisnis dengan teknologi objek
Pengembangan sistem aplikasi dengan teknologi objek dan dengan
menggunakan arsitektur n�tier sesungguhnya tidak berbeda dari sisi
pengelompokan logik jika dibandingkan dengan arsitektur n�tier
dengan teknologi komponen. Perbedaan paling besar adalah bah�a
teknologi komponen seperti EJB telah menyediakan kontainer
komponen yang menyediakan berbagai macam layanan standar.
Sedangkan arsitektur n�tier yang kita bangun dengan teknologi
objek biasanya menuntut hampir seluruh layanan kita kembangkan
sendiri, yang tentunya hal ini sangat menuntut sumber daya yang
besar. Walaupun hal ini bisa diatasi secara parsial dengan cara
menggunakan paket objek yang telah mena�arkan layanan tertentu
dan dikembangkan oleh pihak ketiga.
Direktorat Jenderal Bina Administrasi Keuangan Daerah
Departemen Dalam Negeri Republik Indonesia
29
Arsitektur Referensi SIPKD
Dokumen 3
Model Komponen
Setelah mengamati Gambar 11 dan Gambar 12 di atas kita bisa
mulai mengamati kedua pola arsitektur logik bisnis yang sama
tetapi dengan dua teknologi implementasi yang berbeda, lalu
memikirkan bagaimana cara mengembangkan sistem aplikasi
yang bisa menghasilkan dua macam jenis implementasi, yaitu satu
dengan teknologi objek dan satu lagi dengan teknologi komponen.
Sehingga dengan satu kali pengembangan sistem aplikasi dengan
salah satu teknologi bisa secara singkat dan mudah dikembangkan
dengan teknologi lainnya. Untuk hal ini bisa kita cari pokok
permasalahannya, bah�a hal terberat dalam pengembangan sistem
aplikasi adalah penulisan logik bisnis yang baik. Maka jika logik
bisnis sistem aplikasi telah ditulis, diusahakan pola penulisan logik
bisnis ini bisa diadaptasi baik dalam teknologi objek maupun dalam
teknologi komponen. Sehingga yang diperlukan ketika dari satu
teknologi ditulis ulang ke dalam teknologi lainnya hanya perlu
penulisan kerangka objek/komponennya saja, tanpa harus menulis
ulang logik bisnisnya.
Setidaknya ada dua cara untuk mencapai hal yang diinginkan seperti
diuraikan di atas. Pertama adalah dengan menamai seluruh objek
beserta method di dalamnya persis sama dan direncanakan dengan
penamaan komponen yang se�aktu��aktu akan kita bangun.
Objek A
Komponen A
Gambar 13 - Penamaan dan logik objek sesuai dengan komponen
Direktorat Jenderal Bina Administrasi Keuangan Daerah
Departemen Dalam Negeri Republik Indonesia
30
Arsitektur Referensi SIPKD
Dokumen 3
Model Komponen
Objek A
Komponen A
Gambar 14 - Membungkus objek dalam komponen
Cara kedua adalah dengan membungkus bisnis logik yang telah
dibangun dengan teknologi objek dalam kerangka suatu komponen.
Setiap pemanggilan method atau antarmuka komponen maka akan
didelegasikan pada objek dengan cara memanggil method atau
antarmuka objek yang namanya persis dibuat sama.
Pada akhirnya, tujuan semua usaha di atas adalah untuk memudahkan
ketika mengimplementasikan sistem aplikasi terdistribusi seperti
SIPKD yang bisa diimplementasikan dalam skala kecil atau bisa juga
dalam skala besar. Jika diimplementasikan dalam skala kecil kita
bisa memilih sistem terdistribusi berteknologi objek dengan cukup
menggunakan arsitektur 2�tier. Tetapi jika mengimplementasikan
sistem terdistribusi dalam skala besar kita bisa memilih teknologi
komponen dengan segala fasilitas yang dita�arkannya sebagai
middle�are platform. Tatkala sistem yang telah diimplementasikan
dalam skala kecil lalu suatu saat skala sistem membesar dan perlu
ada middle�are untuk menangani sistem sehingga bisa semakin
stabil dan mudah ditangani maka dengan praktis implementasi
dengan teknologi objek bisa ditransformasikan ke dalam
implementasi dengan teknologi komponen tanpa harus banyak
menulis ulang bisnis logik yang telah ada.
Direktorat Jenderal Bina Administrasi Keuangan Daerah
Departemen Dalam Negeri Republik Indonesia
31
Arsitektur Referensi SIPKD
Dokumen 3
Model Komponen
4 SIPKD DAN TEKNOLOGI KOMPONEN
Dokumen ini tidak akan menguraikan implementasi SIPKD dengan
teknologi komponen secara rinci dan komplit. Tetapi dengan semua
uraian sebelumnya dalam dokumen ini diharapkan bisa didapatkan
gambaran bagaimana cara mengimplementasikan SIPKD dengan
teknologi komponen dan dengan cara yang baik dan praktis. Berikut
ini diperlihatkan gambar yang memberikan contoh pengembangan
modul�modul SIPKD dengan teknologi komponen.
Session Beans
Penganggaran
Session Beans
Penatausahaan
Session Beans
Akuntansi
Session Beans
KUA
Session Beans
RKA-SKPD
Session Beans
PPA
Entity Beans
RKA-SKPD 1
Entity Beans
RKA-SKPD 2.2.1
Entity Beans
RKA-SKPD 2.1
Sistem Basisdata Relasional
Entity Beans
Proyeksi KUA
Gambar 15 - Lapisan logik SAPKD dengan teknologi komponen
Gambar di atas memperlihatkan contoh bagaimana modul
penganggaran dibangun secara modular dengan pola session façade
sehingga masing�masing sub�modul penganggaran seperti KUA,
Direktorat Jenderal Bina Administrasi Keuangan Daerah
Departemen Dalam Negeri Republik Indonesia
32
Arsitektur Referensi SIPKD
Dokumen 3
Model Komponen
PPA, dan RKA�SKPD bisa di�akili oleh masing�masing session
bean. Lalu setiap session bean dari sub�modul yang bersangkutan
akan menggunakan entity beans yang berada di ba�ahnya untuk
memanipulasi data yang ada dalam sistem basis data.
Pengembang sistem aplikasi bisa menyediakan seluruh beans
yang diperlukan untuk membangun SAPKD secara utuh, sehingga
tersedia sistem aplikasi berteknologi komponen yang rapih dan
riliabel.
Direktorat Jenderal Bina Administrasi Keuangan Daerah
Departemen Dalam Negeri Republik Indonesia
33
Arsitektur Referensi SIPKD
Dokumen 3
Model Komponen
DAFTAR SINGKATAN
CORBA Common Object Request Broker Architecture
DCOM Distributed Component Object Model
EJB Enterprise Java Beans
IIOP Internet Inter ORB Protocol
ORB Object Request Broker
RMI Remote Method Invocation
SAPKD Sistem Aplikasi Pengelolaan Keuangan Daerah
SIMBADA Sistem Informasi Manajemen Barang Daerah
SIMPEG Sistem Informasi Manajemen Kepega�aian
SIPKD Sistem Informasi Pengelolaan Keuangan
Daerah

Direktorat Jenderal Bina Administrasi Keuangan Daerah
Departemen Dalam Negeri Republik Indonesia
34
Arsitektur Referensi SIPKD
Dokumen 3
Model Komponen

Sistem Informasi Pengelolaan Keuangan Daerah

ARSITEKTUR REFERENSI SIPKD
DOKUMEN 3

MODEL KOMPONEN
Versi 1.0
Direktorat Jenderal Bina Administrasi Keuangan Daerah Departemen Dalam Negeri Republik Indonesia

Dokumen ini disusun oleh Direktorat Jenderal Bina Administrasi Keuangan Daerah – Departemen Dalam Negeri Republik Indonesia. Isi dokumen ini bisa berubah se�aktu��aktu tanpa pemberitahuan resmi. Karena itu agar selalu melakukan pengecekan untuk mendapatkan informasi aktual tentang dokumen ini. Distribusi dokumen ini bisa dilakukan dengan bebas tanpa ke�ajiban apapun dan juga tanpa disertai dengan garansi dalam bentuk apapun.
Direktorat Jenderal Bina Administrasi Keuangan Daerah Departemen Dalam Negeri Republik Indonesia 

ARSITEKTUR REFERENSI SIPKD
MODEL KOMPONEN Abstrak
SIPKD merupakan sistem informasi terdistribusi. Salah satu cara mengimplementasikan SIPKD secara komplit dan terintegrasi adalah dengan menggunakan sistem basis data tersentralisasi. Antara server basis data dengan aplikasi pengguna bisa dipasang sistem server aplikasi yang mengurusi semua logik bisnis pengelolaan keuangan daerah. Karena dari naturnya sistem pengelolaan keuangan daerah terbagi dalam beberapa modul seperti perencanaan, penganggaran, penatausahaan, dan akuntansi; maka pemasangan sistem server aplikasi dengan berorientasi pada teknologi komponen akan sangat cocok. Dokumen Model Komponen ini akan memberikan gambaran, bagaimana jika sisi server aplikasi pengelolaan keuangan daerah diimplementasikan dengan teknologi komponen seperti Enterprise Java Beans (EJB). Walaupun contoh metodologi dalam dokumen ini berorientasi pada arsitektur EJB tetapi pada dasarnya realisasi dengan arsitektur lain seperti Common Object Request Broker Architecture (CORBA) adalah sangat mungkin. Kata Kunci: Model Komponen, Teknologi Komponen, Sistem Server Aplikasi, Enterprise Java Beans (EJB), Common Object Request Broker Architecture (CORBA), Logik Bisnis. Fasilitator: Direktorat Jenderal Bina Administrasi Keuangan Daerah Departemen Dalam Negeri Republik Indonesia Donasi: Asian Development Bank (ADB)
Direktorat Jenderal Bina Administrasi Keuangan Daerah Departemen Dalam Negeri Republik Indonesia 

1 3.Arsitektur Referensi SIPKD Dokumen 3 Model Komponen DAFTAR ISI 1 2 2.2 3.2 3.1 2.3 4 PENDAHULUAN ����������������������������������������������� TEKNOLOGI KOMPONEN �������������������������������� Komponen Server Aplikasi ������������������������������������� Enterprise Java Beans ������������������������������������������� TEKNOLOGI KOMPONEN DAN PROSES BISNIS Session Façade ���������������������������������������������������� Multi Vendor/Developer ���������������������������������������� Rancangan Komponen dan Objek ����������������������������� SIPKD DAN TEKNOLOGI KOMPONEN �������������� 5 9 12 16 20 21 22 25 31 33 DAFTAR SINGKATAN ���������������������������������������������� DAFTAR GAMBAR Gambar 1 � Integrasi SIPKD dengan SIMBADA dan SIMPEG Gambar 2 � Integrasi sistem aplikasi le�at akses langsung terhadap sistem basis data ������������������������������ Gambar 3 � Komponen dalam Kontainer ��������������������������� Gambar 4 � Contoh skenario penggunaan teknologi komponen pada server aplikasi SIPKD �������������� Gambar 5 � Sistem objek terdistribusi ������������������������������� Gambar 6 � Contoh komunikasi antara aplikasi klien dengan komponen EJB �������������������������������������������� 7 8 12 13 15 18 Gambar 7 � Pemetaan model proses bisnis ke model komponen 20 Direktorat Jenderal Bina Administrasi Keuangan Daerah Departemen Dalam Negeri Republik Indonesia  . 3.

Arsitektur Referensi SIPKD Dokumen 3 Model Komponen Gambar 8 � Session Façade �������������������������������������������� Gambar 9 � Pemetaan agregasi proses bisnis ke dalam komponen dengan session façade ��������������������� Gambar 10 � Server Aplikasi SIPKD dengan komponen/modul dari vendor yang berbeda ����������������������������� Gambar 11 � Contoh n�lapisan logik bisnis dengan EJB ���������� Gambar 12 � Contoh n�lapisan logik bisnis dengan teknologi objek ����������������������������������������������������� Gambar 13 � Penamaan objek sesuai dengan komponen ���������� Gambar 14 � Membungkus objek dalam komponen ��������������� 21 22 23 26 28 29 30 Gambar 15 � Lapisan logik SAPKD dengan teknologi komponen 31 Direktorat Jenderal Bina Administrasi Keuangan Daerah Departemen Dalam Negeri Republik Indonesia  .

Walaupun seluruh proses pengelolaan keuangan daerah pada tiap satuan kerja bisa dilakukan dengan bantuan sistem aplikasi standalone. Direktorat Jenderal Bina Administrasi Keuangan Daerah Departemen Dalam Negeri Republik Indonesia  . Orang bisa memandang aplikasi penunjang SIPKD sebagai sistem aplikasi standalone yang terdiri dari sistem basis data yang dilengkapi dengan aplikasi grafis sehingga pengguna bisa mengelola data untuk berbagai modul yang direalisasikan dalam bentuk menu seperti perencanaan. Sehingga dengan cara ini. setiap kali data diinput di masing�masing satuan kerja maka secara otomatis seluruh data terintegrasi di sisi server tanpa harus ada aksi ekspor/impor yang melelahkan dan mungkin memancing terjadinya kegagalan. artinya dengan menginstal sistem basis data pada tiap komputer satuan kerja secara terpisah. dan akuntansi keuangan. penganggaran. penatausahaan. Tapi juga tentunya cukup banyak orang lebih suka memandang SIPKD dengan kacamata pragmatis yang sederhana. Lalu data pengelolaan keuangan daerah seluruh satuan kerja diintegrasikan dengan cara mengekspor data di tiap satuan kerja ke dalam file dan mengimpornya di komputer tertentu seperti di biro keuangan. Orang sesungguhnya menginginkan arsitektur client-server secara terdistribusi tetapi tetap terintegrasi dengan sistem basis data tersentralisasi.Arsitektur Referensi SIPKD Dokumen 3 Model Komponen 1 PENDAHULUAN SIPKD merupakan sistem yang cukup kompleks. dan akuntansi keuangan daerah. Tapi tidak bisa dipungkiri bah�a SIPKD melibatkan puluhan satuan kerja pemerintah daerah yang masing�masing mengelola perencanaan. penganggaran. penatausahaan. Tapi sesungguhnya bisa dipastikan bah�a orang mendambakan implementasi SIPKD dengan cara yang lebih canggih dan terintegrasi dengan sempurna.

membangun SIPKD dengan arsitektur client-server secara terdistribusi juga menuntut arsitektur sistem aplikasi yang memadai. Selain seluruh komputer penunjang SIPKD pada masing�masing satuan kerja tersambung le�at Local Area Network (LAN). Persyaratan pertama yang akan langsung terpikirkan adalah tersedianya infrastruktur jaringan komputer lengkap yang menghubungkan seluruh satuan kerja di daerah. Orang bisa memulai dengan arstektur client-server 2-tier (dua lapis). Selain jaringan komputer lengkap. Pada setiap satuan kerja misalnya dipasang tiga atau lebih komputer khusus untuk menangani pengelolaan keuangan daerah. Tapi pilihan ini jangan dianggap enteng. membangun SIPKD dengan arsitektur 3�tier atau n�tier merupakan langkah berlebihan. Tapi bisa juga menggunakan arsitektur yang lebih menjamin skalabilitas dan realibilitas seperti menggunakan arsitektur client-server 3-tier atau n�tier. seluruh komputer tersebut juga telah tersambung ke komputer server SIPKD. Seringkali pemilihan arsitektur yang tidak tepat akan menyebabkan kerugian pada masa yang akan datang seperti terjadinya degradasi performansi sistem tatkala komputer di Direktorat Jenderal Bina Administrasi Keuangan Daerah Departemen Dalam Negeri Republik Indonesia  . Komputer server SIPKD ini merupakan komputer dengan spesifikasi yang mencukupi untuk melayani seluruh koneksi dan transaksi data dari seluruh satuan kerja. Bagi sebagian orang (atau mungkin banyak orang).Arsitektur Referensi SIPKD Dokumen 3 Model Komponen Ketika orang memutuskan untuk membangun SIPKD dengan arsitektur client-server secara terdistribusi maka dengan sendirinya menuntut beberapa persyaratan sehingga arsitektur client-server secara terdistribusi dapat terealisasi dengan baik. karena bahkan untuk membangun SIPKD dengan arsitektur 2�tier saja tidak terasa mudah.

Sebagian orang akan mengintegrasikan SIPKD dengan sistem lain seperti SIMBADA dan SIMPEG le�at cara dengan abstraksi yang lebih rendah seperti akses langsung terhadap sistem basis data Direktorat Jenderal Bina Administrasi Keuangan Daerah Departemen Dalam Negeri Republik Indonesia  . atau kemudian disadari bah�a integrasi SIPKD dengan sistem lainnya seperti Sistem Pengelolaan Barang Daerah dan Sistem Penggajian Pega�ai menjadi tidak mulus atau tidak mungkin kecuali dengan menggunakan cara semi manual seperti aksi ekspor/impor data lewat file. Komunikasi antaraplikasi ini akan dengan sangat baik jika direalisasikan dengan teknologi komponen. SIMBADA Pelaporan Akuntansi Penatausahaan Penganggaran SIPKD Remote Interface SIMPEG Gambar 1 .Integrasi SIPKD dengan SIMBADA dan SIMPEG Gambar 1 memperlihatkan contoh integrasi SIPKD dengan sistem lain seperti SIMBADA (Sistem Informasi Manajemen Barang Daerah) dan SIMPEG (Sistem Informasi Manajemen Kepega�aian). Integrasi yang diperlihatkan oleh Gambar 1 adalah integrasi pada tingkat sistem aplikasi dengan cara komunikasi le�at antarmuka komunikasi aplikasi yang disebut dengan remote interface.Arsitektur Referensi SIPKD Dokumen 3 Model Komponen sisi klien (pengguna) berkembang menjadi cukup banyak.

Realisasi SIPKD secara terdistribusi dengan menggunakan teknologi komponen pada sisi server memungkinkan terbentuknya SIPKD dengan abstraksi sistem yang lebih baik.Integrasi sistem aplikasi lewat akses langsung terhadap sistem basis data Integrasi sistem aplikasi dengan cara akses langsung terhadap sistem basis data seperti diperlihatkan pada Gambar 2 akan menimbulkan masalah otorisasi akses terhadap basis data dari sistem aplikasi lain. Selain itu cara seperti demikian juga telah melanggar prinsip transparansi komunikasi antarsistem aplikasi. seperti misalnya akses dari sistem aplikasi SIMBADA terhadap sistem data base SIPKD secara langsung. Direktorat Jenderal Bina Administrasi Keuangan Daerah Departemen Dalam Negeri Republik Indonesia  . Walaupun penggunaan teknologi komponen menuntut keahlian lebih dari pihak pengembang sistem aplikasi.Arsitektur Referensi SIPKD Dokumen 3 Model Komponen SIPKD SIMBADA Basisdata SIPKD Basisdata SIMBADA Gambar 2 . Pada bagian berikut dokumen ini akan diulas konsep teknologi komponen untuk sisi server aplikasi dan metodologi penerapannya pada suatu sistem aplikasi terdistribusi seperti Sistem Aplikasi Pengelolaan Keuangan Daerah (SAPKD). tetapi pada akhirnya akan melahirkan sistem aplikasi kelas enterprise dengan arsitektur yang matang.

Pengembangan perangkat lunak dengan orientasi objek telah cukup memasyarakat dan terkenal saat ini. Gaphic User Interface) seperti ActiveX atau Java Beans. Sebelum kita melanjutkan. Lalu apa perbedaan antara objek dengan komponen ketika kita memahami bah�a komponen juga bagian pembangun dari sistem aplikasi perangkat lunak? Model Objek akan dibahas dalam dokumen terpisah dari dokumen Direktorat Jenderal Bina Administrasi Keuangan Daerah Departemen Dalam Negeri Republik Indonesia  . kata komponen sudah tidak asing lagi dan banyak sekali digunakan baik secara konseptual maupun dalam realisasi suatu sistem perangkat lunak. Para pengembang perangkat lunak langsung akan ingat pada teknologi seperti ActiveX atau Java Beans ketika mendengar kata komponen perangkat lunak. Dalam hal ini para programmer memandang segala sesuatu dalam sistem sebagai objek. Dari banyak objek yang saling berelasi akhirnya ter�ujudlah sistem aplikasi yang diinginkan. Bahasa pemrograman berorientasi objek seperti Java dan C++ merupakan perangkat utama dalam mengembangkan perangkat lunak dengan orientasi objek. Teknologi komponen yang akan dibahas dalam dokumen ini adalah teknologi komponen untuk sisi server aplikasi yang di dalamnya pengelolaan logik bisnis dilakukan. Di dunia perangkat lunak. mungkin sebagian orang akan langsung teringat pada teknologi objek ketika mendengar istilah teknologi komponen. Tetapi teknologi komponen yang akan dibahas dalam dokumen ini bukan teknologi komponen pembangun antarmuka pengguna (GUI.Arsitektur Referensi SIPKD Dokumen 3 Model Komponen 2 TEKNOLOGI KOMPONEN Ketika kita mendengar kata komponen hampir bisa dipastikan bah�a rata�rata orang menginterpretasikan komponen sebagai bagian yang membangun sesuatu yang lebih besar atau lebih lengkap.

Objek dan komponen sama�sama memiliki persamaan seperti berikut:  Memiliki identitas yang unik  Menerapkan konsep enkapsulasi. Direktorat Jenderal Bina Administrasi Keuangan Daerah Departemen Dalam Negeri Republik Indonesia 0 . Dengan demikian penulisan ulang kode program untuk berbagai keperluan yang mirip akan terhindarkan. Sebelum kita membahas perbedaan�perbedaan antara objek dengan komponen di dunia perangkat lunak. Tetapi yang paling pokok dari konsep objek dan komponen adalah tingkat abstraksi yang tinggi dalam memandang sistem le�at pengelompokan dan relasi antarkelompok. Tetapi di sini kita akan menyinggung sedikit konsep teknologi objek untuk membedakannya dengan teknologi komponen. yaitu membungkus data (atribut) dan aktivitas secara transparan. sehingga pada pengembangan sistem perangkat lunak yang besar dan terdistribusi akan lebih mudah ditangani dan terkendali. kita akan menyinggung dulu persamaan di antara keduanya. pengembangan sistem perangkat lunak dengan teknologi objek bisa sangat modular dan bisa menggunakan objek atau komponen yang telah ada sebagai dasar untuk membangun objek atau komponen lainnya. penglokalisasian atribut dan aktivitas pada tiap kelompok (konsep enkapsulasi). Hanya aktivitas yang bersifat publik (biasanya disebut interface) yang bisa dikenal dari luar objek/komponen yang memilikinya  Memiliki kemampuan me�ariskan sifat�sifat yang dimilikinya kepada objek/komponen turunannya  Bisa memiliki nama aktivitas yang sama tetapi dengan efek atau hasil yang berlainan (polymorfik) Dengan ciri dan kemampuan yang dimiliki oleh objek dan komponen seperti di atas.Arsitektur Referensi SIPKD Dokumen 3 Model Komponen Model Komponen ini.

tetapi biasanya komponen memerlukan lingkungan untuk bisa hidup. Lingkungan ini biasanya berupa sistem perangkat lunak yang menyediakan fasilitas tertentu sehingga komponen bisa hidup di dalam sistem tersebut. Walaupun komponen itu mandiri dalam melaksanakan tugasnya. Objek biasanya me�akili satuan terkecil dari suatu sistem. Seringkali komponen yang ada dalam suatu kontainer tidak tampak dari luar kontainer tersebut. Tinggal ketika akan dikombinasikan dengan komponen lainnya perlu dilihat apakah masing�masing komponen memiliki antarmuka komunikasi yang cocok dan diperlukan. Karena itu. �alaupun beberapa komponen bisa dikombinasikan untuk membentuk menyelesaikan rangkaian kerja tertentu. Kadangkala objek bisa juga menjadi cukup besar dan terdiri dari objek lainnya (misalnya memiliki beberapa atribut yang berperan sebagai referensi terhadap objek lainnya).Arsitektur Referensi SIPKD Dokumen 3 Model Komponen Setelah membahas persamaan antara objek dengan komponen. Suatu komponen software tidak tergantung pada komponen software lainnya. lalu di mana letak perbedaan antara keduanya? Perbedaaan utama antara objek dengan komponen adalah pada kemandiriannya. Kontainer hanya bisa memperlihatkan referensi tidak langsung atas komponen� Direktorat Jenderal Bina Administrasi Keuangan Daerah Departemen Dalam Negeri Republik Indonesia  . biasanya suatu komponen telah merupakan kumpulan kode program yang diperuntukan bagi penyelesaian suatu pekerjaan utuh secara mandiri. Lain lagi dengan komponen. Tetapi suatu objek masih terlalu kecil untuk bisa melaksanakan suatu pekerjaan secara utuh dan mandiri tanpa bantuan objek lainnya. Lingkungan seperti tersebut biasanya disebut kontainer komponen. Artinya suatu komponen software telah memiliki tugas tertentu yang bisa ia selesaikan sendiri. komponen software bisa dikembangkan sendiri-sendiri dengan spesifikasi yang tidak tergantung pada spesifikasi komponen lainnya.

bagaimana pengolahan data dalam sistem basis data.Komponen dalam Kontainer Dari Gambar 3 di atas. diaktifkan atau dimatikan kembali secara tidak langsung dari luar kontainer atas permintaan pengguna. sehingga suatu komponen bisa dihidupkan.1 Komponen Server Aplikasi Dokumen Model Komponen ini tidak akan membahas komponen perangkat lunak untuk sisi klien berupa komponen antarmuka grafis Direktorat Jenderal Bina Administrasi Keuangan Daerah Departemen Dalam Negeri Republik Indonesia  . karena hal tersebut dilakukan oleh komponen untuk kita secara transparan. penatausahaan. kita sudah bisa langsung membayangkan dalam kepala kita.Arsitektur Referensi SIPKD Dokumen 3 Model Komponen komponen yang ada di dalamnya. Antarmuka Komponen Aplikasi Pengguna Komponen KONTAINER Antar Muka Luar Gambar 3 . bah�a berbagai modul dalam pengelolaan keuangan daerah seperti perencanaan. Jika kemudian dibangun sistem lain seperti SIMBADA atau SIMPEG maka tinggal membangun komponen yang diperlukan dalam SIMBADA/SIMPEG dan membiarkannya berkomunikasi le�at antarmuka masing�masing dengan komponen SAPKD yang telah ada lebih dulu! Bahkan kita tidak perlu mengetahui secara detail. penganggaran. 2. dan akuntansi keuangan masing�masing bisa di�akili oleh satu komponen.

Adapun transaksi data ke dalam sistem basis data dilakukan oleh server aplikasi secara transparan tanpa disadari oleh sisi aplikasi pengguna. Bagaimana membangun aplikasi server sistem pengelolaan keuangan daerah dengan teknologi komponen. Tema dalam dokumen ini adalah komponen perangkat lunak pada sisi server aplikasi. Gambar 4 . Bagi sistem aplikasi lain juga disediakan akses le�at teknologi web services.Arsitektur Referensi SIPKD Dokumen 3 Model Komponen seperti ActiveX Control atau Java Beans.Contoh skenario penggunaan teknologi komponen pada server aplikasi SIPKD Server aplikasi yang dibangun dengan teknologi komponen tidak membatasi akses hanya dari aplikasi klien yang memiliki protokol komunikasi sesuai dengan standar protokol yang digunakan oleh kontainer komponen (dalam Gambar 4 di atas diasumsikan menggunakan protokol IIOP dan kontainernya menggunakan produk EJB). Direktorat Jenderal Bina Administrasi Keuangan Daerah Departemen Dalam Negeri Republik Indonesia  . tetapi mungkin juga server aplikasi diakses dari aplikasi �eb dengan menggunakan protokol HTTP.

Gambar berikut memperlihatkan prinsip dasar bagaimana aplikasi klien bisa berkomunikasi dengan komponen. dan deaktivasi komponen serta berbagai macam layanan standar lainnya. kontainer komponen pada sisi server yang telah standar dan ada di pasaran biasanya telah menyediakan berbagai macam layanan standar seperti transaksional basis data. Sedangkan jika pada sisi server akan ditambahkan komponen baru maka komponen tersebut tinggal diaktifkan dan dengan sendirinya antarmuka dari komponen baru tersebut akan bisa diakses dari sisi aplikasi klien. komponen pada tingkat pemrograman memang biasanya dibangun dari beberapa objek. Setelah itu aplikasi bisa menggunakan semua layanan yang dita�arkan oleh komponen. Hal utama dari beberapa kelebihan teknologi komponen pada sisi server aplikasi adalah tingkat abstraksinya yang tinggi sehingga pengembangan sistem aplikasi bisa dilakukan secara modular dan bisa mengatasi kerumitan sistem jaringan komputer yang tersebar. Sistem aplikasi terdistribusi seperti SAPKD akan sulit untuk dibangun dengan arsitektur berabstraksi rendah seperti teknologi pemrograman berorientasi prosedural. Teknologi komponen sendiri berbasiskan pada teknologi objek terdistribusi. Dalam hal ini. Berbagai macam layanan standar tersebut akan sangat memakan �aktu jika harus dikembangkan sendiri oleh pengembang sistem aplikasi.Arsitektur Referensi SIPKD Dokumen 3 Model Komponen Aplikasi klien yang ingin memanfaatkan layanan komponen pada sisi server hanya perlu mengetahui spesifikasi antarmuka yang dimiliki oleh komponen. aktivasi. Direktorat Jenderal Bina Administrasi Keuangan Daerah Departemen Dalam Negeri Republik Indonesia  . Selain itu. Lalu aplikasi klien berusaha mendapatkan referensi jarak jauh dari antarmuka komponen (remote interface). Ketika suatu komponen akan mena�arkan layanan baru maka komponen tersebut tinggal mempublikasikan antarmuka dari layanan baru tersebut.

Arsitektur Referensi SIPKD Dokumen 3 Model Komponen Aplikasi Klien Objek Terdistribusi (Server) Stub Skeleton Jaringan Komputer Gambar 5 . Stub tahu cara membungkus semua argumen (nilai dari parameter antarmuka) yang diberikan oleh aplikasi klien.Sistem objek terdistribusi Ketika aplikasi klien ingin memanggil salah satu layanan yang dita�arkan suatu objek terdistribusi (objek ini yang membangun komponen) maka aplikasi klien memanggil nama layanan yang diinginkan le�at stub. Stub ini semacam proxy atau representasi objek terdistribusi di sisi klien. membungkusnya dalam bentuk paket yang sesuai dengan protokol jaringan komputer lalu meneruskannya kepada skeleton dari objek terdistribusi. Skeleton mengetahui bagaimana cara menerima paket kiriman stub lalu membukanya dan meneruskan kepada objek terdistribusi untuk diolah lebih lanjut sesuai dengan antarmuka yang dipanggil oleh aplikasi klien. Semua nama antarmuka yang dimiliki objek terdistribusi bisa diakses oleh aplikasi klien melalui stub dari objek terdistribusi yang bersangkutan. Skeleton juga berperan sebagai proxy dari objek terdistribusi. hanya ia berada di sisi server. Jika terdapat nilai Direktorat Jenderal Bina Administrasi Keuangan Daerah Departemen Dalam Negeri Republik Indonesia  .

EJB dengan CORBA juga memiliki hubungan erat karena saat ini EJB telah mengadopsi IIOP yang berasal dari CORBA sebagai protokol komunikasi EJB.2 Enterprise Java Beans Saat ini setidaknya ada dua teknologi komponen terkemuka.Arsitektur Referensi SIPKD Dokumen 3 Model Komponen yang harus dikembalikan dari objek terdistribusi kepada aplikasi klien maka nilai tersebut dikirim le�at skeleton dengan cara yang sama kepada stub di seberang jaringan komputer untuk diteruskan kepada aplikasi klien. komponen dari EJB akan bisa berkomunikasi dengan baik dengan komponen dari CORBA. Maka perlu ada teknologi yang mengkombinasikan beberapa objek membentuk suatu komponen yang lebih besar sehingga kumpulan objek tersebut bisa dilihat dari tataran abstraksi yang lebih tinggi membentuk komponen mandiri yang memberikan layanan utuh tertentu. yaitu EJB dari Sun Microsystem dan CORBA dari Object Management Group (OMG). Tetapi jika sistem aplikasi yang dikembangkan cukup besar maka jumlah objek yang dibuat akan berkembang juga jumlahnya dan akan menjadi cukup sulit untuk mengelolanya. Teknologi objek terdistribusi sangat baik untuk membangun sistem aplikasi terdistribusi yang melintasi kompleksitas jaringan komputer. 2. Komponen yang terbentuk ditempatkan dalam kontainer sehingga komponen tersebut bisa memanfaatkan berbagai macam layanan standar yang disediakan kontainer. Dalam bagian ini akan diuraikan konsep EJB secara ringkas untuk menambah gambaran tentang teknologi komponen yang Direktorat Jenderal Bina Administrasi Keuangan Daerah Departemen Dalam Negeri Republik Indonesia  . Dengan demikian.

Entity Beans memodelkan struktur data. dan Messagedriven Beans. Untuk mengelola komponen yang kita buat. Komponen perangkat lunak dalam EJB disebut bean.Arsitektur Referensi SIPKD Dokumen 3 Model Komponen sekarang ada di pasaran. Entity Beans. Dalam merancang sistem server aplikasi kita bisa memetakan struktur data yang ada dalam tabel basis data ke dalam Entity Beans. Sedangkan tipe bean lainnya adalah: Session Beans. Session Beans memodelkan proses bisnis. Semua komponen dalam EJB diturunkan dari bean utama yang disebut Enterprise Beans. mengelola persistensi komponen. fungsi. Kontainer menjadi perantara komunikasi antara komponen dengan klien. EJB merupakan arsitektur komponen yang mena�arkan fasilitas bagi para pengembang perangkat lunak untuk membangun sistem server aplikasi dengan cara yang modular. dan robus. EJB menyediakan middleware kelas enterprise sehingga para pengembang sistem aplikasi bisa fokus pada pengembangan komponen yang mengelola logik bisnis tanpa harus memikirkan terlebih dahulu fasilitas yang harus tersedia dalam lingkungan sistem aplikasi server terdistribusi. EJB menyediakan kontainer komponen. Message-driven Beans memodelkan suatu aktivitas seperti pada Direktorat Jenderal Bina Administrasi Keuangan Daerah Departemen Dalam Negeri Republik Indonesia  . prosedur. aktivitas sebagai Session Beans. dan hal lainnya. Dalam mendesain sistem server aplikasi kita harus memodelkan proses. keamanan. Entity Beans dapat berupa representasi dari kelompok data yang dikelola dalam suatu proses bisnis. cepat. Karena memodelkan proses bisnis maka Session Beans menggambarkan aktivitas dan pengelolaan logik bisnis.

Sebelum melakukan koneksi dengan suatu beans.Arsitektur Referensi SIPKD Dokumen 3 Model Komponen Session Beans. yaitu ketika komunikasi dimulai harus terus tersambung hingga komunikasi selesai. Persistence Service. hanya Message-driven Beans fokus pada pengiriman berita. Aplikasi Klien Berikan referensi EJB Object 3 Home Interface Home Object 1 Buat koneksi ke bean 4 Buat EJB Object Panggil suatu method Remote Interface EJB Object Teruskan pemanggilan method 5 Session Beans 6 Manipulasi data Gambar 6 . klien harus mendapatkan referensi jarak jauh (remote interface) dari beans yang bersangkutan. Semua beans yang ada pada kontainer hanya bisa diakses oleh klien le�at antarmuka yang dita�arkan oleh masing�masing beans. Seperti pada pengiriman surat dalam kehidupan nyata.Contoh komunikasi antara aplikasi klien dengan komponen EJB Direktorat Jenderal Bina Administrasi Keuangan Daerah Departemen Dalam Negeri Republik Indonesia 2 Entity Beans Basisdata  . Sedangkan Session Beans bisa kita misalkan seperti komunikasi telepon. Security Service dll. aktivitas yang dilakukan Message-driven Beans tidak menuntut pengembalian nilai atau ja�aban saat itu juga. Antarmuka jarak jauh ini bisa didapatkan secara tidak langsung le�at kontainer dengan memanggil terlebih dahulu Home Interface dari bean yang bersangkutan. EJB KONTAINER Transactional Service .

Session Beans dapat memanggil Entity Beans secara lokal dalam kontainer jika memang diperlukan manipulasi data dalam basis data.Arsitektur Referensi SIPKD Dokumen 3 Model Komponen Setelah pemanggilan atas Home Interface maka pada aplikasi klien akan diberikan referensi (berupa remote interface) dari EJB Object yang bersangkutan. EJB Object ini berupa proxy dari bean (misalnya session beans) yang dipanggil le�at Home Interface. Direktorat Jenderal Bina Administrasi Keuangan Daerah Departemen Dalam Negeri Republik Indonesia  . Seluruh pemanggilan method (istilah lainnya prosedur/fungsi) akan diteruskan oleh EJB Object kepada Session Beans yang dimaksud.

TEKNOLOGI KOMPONEN DAN PROSES BISNIS EJB mena�arkan Session Beans dan Entity Beans. penggunaan teknologi komponen dalam perancangan sistem aplikasi memungkinan suatu pemetaan yang mulus antara level perancangan (pemodelan proses bisnis) dengan level implementasi perangkat lunak (pemodelan komponen).Arsitektur Referensi SIPKD Dokumen 3 Model Komponen 3. Desain pemrograman dalam EJB ini telah selaras dengan desain proses bisnis yang selalu mengelola data di ba�ah proses.Pemetaan model proses bisnis ke model komponen Seperti diperlihatkan le�at Gambar 7. PEMODELAN PROSES BISNIS Proses Data Session Beans Entity Beans PEMODELAN KOMPONEN Gambar 7 . Teknik pemrograman yang baik dalam EJB menentukan bah�a aplikasi klien tidak akan pernah memanggil Entity Beans secara langsung. Hal ini telah selaras dengan perancangan berorientasi proses. Session Beans bisa dipandang sebagai representasi proses dan Entity Beans sebagai representasi data yang dikelola dalam proses. Direktorat Jenderal Bina Administrasi Keuangan Daerah Departemen Dalam Negeri Republik Indonesia 0 . Panah putus�putus menggambarkan pemetaan Proses terhadap Session Beans dan pemetaan Data terhadap Entity Beans. Entity Beans hanya dipanggil melalui Session Beans.

1 Session Façade Session Façade merupakan pola perancangan sistem perangkat lunak dengan arsitektur EJB. Jaringan Klien Gambar 8 . karena sekumpulan Sessions Beans dipanggil secara lokal (tidak langsung le�at jaringan oleh aplikasi klien). Hal ini dengan tepat sekali bisa di�akili oleh pola Session Façade pada tingkat perancangan implementasi perangkat lunak dengan teknologi komponen. Dengan pola Session Façade bisa dihemat pemakaian sumber daya jaringan. Misalnya jika terjadi transaksi basis data maka konteks transaksi bisa dikelola dengan lebih baik di sisi server. Direktorat Jenderal Bina Administrasi Keuangan Daerah Departemen Dalam Negeri Republik Indonesia  .Arsitektur Referensi SIPKD Dokumen 3 Model Komponen Sedangkan panah tanpa putus�putus menggambarkan pemanggilan (eksekusi). Dalam perancangan sistem aplikasi seringkali ditemukan agregasi proses (grup proses). Suatu proses pada tingkat abstraksi paling atas bisa diurai kembali dalam banyak sub�proses hingga menggambarkan aktivitas pada tingkat abstraksi paling rendah. 3.Session Façade Pola Session Façade seperti diperlihatkan oleh Gambar 8 juga memberikan pembagian logik bisnis yang lebih baik.

Arsitektur Referensi SIPKD Dokumen 3 Model Komponen MODEL PROSES BISNIS Grup Proses Proses Proses Grup Proses Proses Proses Data Data MODEL KOMPONEN Session Beans Session Beans Session Beans Session Beans Gambar 9 di samping ini memperlihatkan bagaimana pemetaan agregasi proses Bisnis pada tingkat perancangan model bisnis ke dalam tingkat implementasi dengan pendekatan teknologi komponen. Kita bisa melihat suatu pemetaan yang bersih antara abstraksi di level proses bisnis dan abstraksi di tingkat implementasi secara berkesinambungan. Direktorat Jenderal Bina Administrasi Keuangan Daerah Departemen Dalam Negeri Republik Indonesia  . Metodologi pemetaan model bisnis ke dalam model komponen ini bisa dilakukan untuk semua proses bisnis pengelolaan keuangan daerah yang telah dituangkan dalam Dokumen 1 Arsitektur Referensi SIPKD. Session Beans Session Beans Entity Beans Entity Beans Gambar 9 . Hal terpenting adalah dengan ditetapkannya antarmuka komunikasi yang dita�arkan masing�masing komponen secara standar.2 Multi Vendor/Developer Pengembangan sistem aplikasi dengan teknologi komponen memungkinkan beberapa komponen pembangun suatu aplikasi dikembangkan oleh pihak yang berbeda tetapi dengan jaminan integrasi komunikasi antarkomponen tersebut secara mulus. Dalam hal ini tidak ada kehilangan semantik model proses bisnis yang dipetakan pada abstraksi model komponen.Pemetaan agregasi proses bisnis ke dalam komponen dengan session façade 3.

Direktorat Jenderal Bina Administrasi Keuangan Daerah Departemen Dalam Negeri Republik Indonesia  . Tapi tidak jarang kenyataannya vendor yang dikontrak oleh daerah untuk mengimplementasikan modul penganggaran tersebut tidak memiliki modul penatausahaan dan akuntasi.Server Aplikasi SIPKD dengan komponen/modul dari vendor yang berbeda Pengembangan SAPKD dengan menggunakan teknologi komponen akan memungkinkan daerah (Provinsi/Kabupaten/Kota) untuk menggunakan dan mengintegrasikan modul�modul SAPKD dari vendor yang berbeda. Banyak daerah yang pada tahap pertama hanya mengimplementasikan modul penganggaran saja. bah�a banyak daerah mengimplementasikan SAPKD secara bertahap.Arsitektur Referensi SIPKD Dokumen 3 Model Komponen SPP SP2D RKA-SKPD Komponen Penatausahaan (Vendor B) SPM Komponen Perencanaan & Penganggaran (Vendor A) Komponen Akuntansi & Pelaporan (Vendor C) KUA PPA GL Neraca Arus Kas EJB KONTAINER Gambar 10 . Sehingga daerah yang bersangkutan tidak meneruskan implementasi hingga modul penatausahaan dan akuntansi. Sesuai dengan kenyataan. Jikalaupun pemda pada akhirnya mengimplementasikan modul penatausahaan dan akuntansi dengan mengontrak vendor lain.

Dalam hal ini tentunya EJB dengan CORBA akan bisa berkomunikasi dengan baik karena kedua platform tersebut sama�sama menggunakan IIOP sebagai protokol komunikasi. juga tentunya telah ditentukan daftar dan spesifikasi teknis dari masing-masing komponen tersebut. Penyusunan spesifikasi teknis dan antarmuka dari tiap komponen pembangun SAPKD harus dilakukan oleh gabungan vendor SAPKD.Arsitektur Referensi SIPKD Dokumen 3 Model Komponen akhirnya modul penganggaran tidak bisa terintegrasi dengan modul penatausahaan dan akuntansi. Dengan demikian spesifikasi yang ditetapkan dapat diterima oleh pasar karena merupakan kesepakatan bersama. Dokumen Model Komponen Versi 1. mungkin dalam bentuk konsorsium. Komunikasi antara platform komponen seperti EJB dan CORBA dengan platform lain yang tidak berorientasi komponen masih dimungkinkan dengan menggunakan jembatan komunikasi Direktorat Jenderal Bina Administrasi Keuangan Daerah Departemen Dalam Negeri Republik Indonesia  . Tetapi pada versi selanjutnya dari dokumen ini diharapkan telah disertakan spesifikasi antarmuka standar yang harus dita�arkan oleh masing�masing komponen pembangun SAPKD. Dokumen ini baru pada tahap pengenalan dan penyertaan usulan penggunaan teknologi komponen untuk pengembangan SAPKD. Pengembangan SAPKD secara modular ini juga tidak harus menggunakan salah satu teknologi komponen saja semisal EJB.0 ini tidak menyertakan spesifikasi antarmuka yang harus dimiliki oleh masing-masing komponen pembangun SAPKD. Bisa juga modul�modul SAPKD dikembangkan oleh teknologi komponen lainnya seperti CORBA. Tapi antarteknologi ini memang dituntut kemampuan komunikasi dengan spesifikasi protokol komunikasi yang telah distandarisasi.

Jika kemungkinan seperti ini bisa terjadi maka sebaiknya dibuat rancangan sistem aplikasi yang Direktorat Jenderal Bina Administrasi Keuangan Daerah Departemen Dalam Negeri Republik Indonesia  . Selain memakan �aktu tentunya juga akan memakan sumber daya yang berlipat. Tetapi teknologi lain semacam DCOM dari Microsoft misalnya akan menuntut bridge untuk bisa berkomunikasi dengan EJB atau CORBA. fleksibilitas atau karena memutuskan untuk menggunakan middleware komponen semacam EJB. kita perlu beralih dengan cepat dari sistem aplikasi terdistribusi dengan teknologi objek ke sistem aplikasi terdistribusi berteknologi komponen atau sebaliknya. Masalahnya. untuk penggunaan skala kecil. karena EJB juga menggunakan RMI sebagai protokol komunikasi di samping IIOP. Hal ini bisa terjadi misalnya ketika sistem aplikasi telah dikembangkan dengan teknologi objek dan suatu saat diputuskan untuk ditulis ulang dengan teknologi komponen karena pertimbangan tertentu seperti modularitas. Tetapi bisa juga pertimbangannya karena kita ingin memiliki sistem aplikasi dengan rancangan yang sama tetapi bisa dipakai untuk skala besar maupun skala kecil. seringkali terasa prakstis lebih menggunakan arsitektur yang lebih ringan semisal sistem client-server 2-tier. 3. yaitu dengan jumlah klien yang tidak begitu banyak. Teknologi objek terdistribusi seperti Java�RMI dalam hal ini akan dengan mulus bisa berkomunikasi dengan EJB.3 Rancangan Komponen dan Objek Seringkali pada realitas implementasi sistem terdistribusi. Mengembangkan dua aplikasi dengan arsitektur berbeda padahal untuk kepentingan pengelolaan proses bisnis yang sama tentunya akan merepotkan.Arsitektur Referensi SIPKD Dokumen 3 Model Komponen (bridge) atau menggunakan semacam pembungkus pada platform lain (�rapper).

Arsitektur Referensi SIPKD Dokumen 3 Model Komponen bisa dengan mudah diadaptasi ke dalam teknologi objek maupun ke dalam teknologi komponen. Session Beans A Session Beans B Session Beans C Session Beans D Session Beans E Session Beans F Entity Beans A Entity Beans B Entity Beans C Entity Beans D Sistem Basisdata Relasional Gambar 11 . Arsitektur n�tier untuk pengembangan sistem dengan teknologi komponen maupun untuk teknologi objek bisa dibuat sama.Contoh n-lapisan logik bisnis dengan EJB Direktorat Jenderal Bina Administrasi Keuangan Daerah Departemen Dalam Negeri Republik Indonesia  . Kita bisa merancang lapisan logik bisnis sistem aplikasi dengan pola yang bisa diadaptasi ke dalam teknologi objek maupun ke dalam teknologi komponen. sedangkan pada sistem dengan teknologi objek diperuntukan bagi object library/package untuk akses ke dalam basis data. Perbedaannya hanya pada lapisan paling ba�ah yang memiliki akses langsung atas sistem basis data. Lapisan paling ba�ah pada sistem dengan teknologi komponen diperuntukan bagi entity beans.

Ketika pengelolaan proses bisnis secara rinci yang dilakukan oleh kumpulan objek pada lapisan kedua memerlukan akses pada basis data maka objek pada lapisan dua akan mengakses objek pada lapisan tiga yang disediakan untuk memanipulasi data secara langsung ke dalam basis data. Session Beans pada lapisan kedua ini hanya memiliki local interface yang hanya bisa diakses oleh beans lain dalam satu kontainer. tanpa menyediakan remote interface untuk keperluan akses dari luar kontainer semisal akses dari aplikasi klien. Hal ini diperlihatkan dalam Gambar 12 pada halaman berikut. Lapisan paling atas ditempati oleh sekumpulan Session Beans utama. Setiap Session Beans pada lapisan dua yang ingin memanipulasi data dalam basis data akan melakukannya le�at akses atas entity beans yang ada pada lapisan ketiga. Session Beans utama inilah yang mena�arkan antarmuka yang bisa langsung diakses oleh aplikasi klien (remote interface). Lapisan ketiga menyediakan sekumpulan entity beans yang memiliki akses langsung atas sistem basis data. Lalu untuk keperluan objek pada lapisan pertama kita sediakan sekumpulan objek pada lapisan dua untuk mengelola proses bisnis secara lebih rinci. Sedangkan lapisan kedua diisi oleh sekumpulan Session Beans yang melayani Session Beans utama (session façade).Arsitektur Referensi SIPKD Dokumen 3 Model Komponen Gambar 11 memperlihatkan contoh lapisan logik bisnis dengan arsitektur n�tier untuk diimplementasikan dengan EJB. Direktorat Jenderal Bina Administrasi Keuangan Daerah Departemen Dalam Negeri Republik Indonesia  . Arsitektur n�tier yang diperuntukan bagi implementasi dengan teknologi komponen semacam EJB bisa diadaptasi pula untuk implementasi dengan teknologi objek semisal dengan objek Java konvensional. Kita bisa menempatkan seluruh objek yang mena�arkan antarmuka yang bisa diakses secara terbuka dari sisi klien pada lapisan logik bisnis paling atas.

Contoh n-lapisan logik bisnis dengan teknologi objek Pengembangan sistem aplikasi dengan teknologi objek dan dengan menggunakan arsitektur n�tier sesungguhnya tidak berbeda dari sisi pengelompokan logik jika dibandingkan dengan arsitektur n�tier dengan teknologi komponen. Walaupun hal ini bisa diatasi secara parsial dengan cara menggunakan paket objek yang telah mena�arkan layanan tertentu dan dikembangkan oleh pihak ketiga. Direktorat Jenderal Bina Administrasi Keuangan Daerah Departemen Dalam Negeri Republik Indonesia  . yang tentunya hal ini sangat menuntut sumber daya yang besar.Arsitektur Referensi SIPKD Dokumen 3 Model Komponen Objek A Objek B Objek C Objek D Objek E Objek F Objek G Objek H Objek I Objek J Objek K Objek L Objek M Sistem Basisdata Relasional Gambar 12 . Perbedaan paling besar adalah bah�a teknologi komponen seperti EJB telah menyediakan kontainer komponen yang menyediakan berbagai macam layanan standar. Sedangkan arsitektur n�tier yang kita bangun dengan teknologi objek biasanya menuntut hampir seluruh layanan kita kembangkan sendiri.

Sehingga yang diperlukan ketika dari satu teknologi ditulis ulang ke dalam teknologi lainnya hanya perlu penulisan kerangka objek/komponennya saja.Arsitektur Referensi SIPKD Dokumen 3 Model Komponen Setelah mengamati Gambar 11 dan Gambar 12 di atas kita bisa mulai mengamati kedua pola arsitektur logik bisnis yang sama tetapi dengan dua teknologi implementasi yang berbeda. Setidaknya ada dua cara untuk mencapai hal yang diinginkan seperti diuraikan di atas. diusahakan pola penulisan logik bisnis ini bisa diadaptasi baik dalam teknologi objek maupun dalam teknologi komponen. Sehingga dengan satu kali pengembangan sistem aplikasi dengan salah satu teknologi bisa secara singkat dan mudah dikembangkan dengan teknologi lainnya. Pertama adalah dengan menamai seluruh objek beserta method di dalamnya persis sama dan direncanakan dengan penamaan komponen yang se�aktu��aktu akan kita bangun. lalu memikirkan bagaimana cara mengembangkan sistem aplikasi yang bisa menghasilkan dua macam jenis implementasi. bah�a hal terberat dalam pengembangan sistem aplikasi adalah penulisan logik bisnis yang baik. tanpa harus menulis ulang logik bisnisnya. Untuk hal ini bisa kita cari pokok permasalahannya.Penamaan dan logik objek sesuai dengan komponen Direktorat Jenderal Bina Administrasi Keuangan Daerah Departemen Dalam Negeri Republik Indonesia  . Objek A Komponen A Gambar 13 . yaitu satu dengan teknologi objek dan satu lagi dengan teknologi komponen. Maka jika logik bisnis sistem aplikasi telah ditulis.

Jika diimplementasikan dalam skala kecil kita bisa memilih sistem terdistribusi berteknologi objek dengan cukup menggunakan arsitektur 2�tier. Setiap pemanggilan method atau antarmuka komponen maka akan didelegasikan pada objek dengan cara memanggil method atau antarmuka objek yang namanya persis dibuat sama. Tatkala sistem yang telah diimplementasikan dalam skala kecil lalu suatu saat skala sistem membesar dan perlu ada middle�are untuk menangani sistem sehingga bisa semakin stabil dan mudah ditangani maka dengan praktis implementasi dengan teknologi objek bisa ditransformasikan ke dalam implementasi dengan teknologi komponen tanpa harus banyak menulis ulang bisnis logik yang telah ada. Pada akhirnya.Membungkus objek dalam komponen Cara kedua adalah dengan membungkus bisnis logik yang telah dibangun dengan teknologi objek dalam kerangka suatu komponen. Tetapi jika mengimplementasikan sistem terdistribusi dalam skala besar kita bisa memilih teknologi komponen dengan segala fasilitas yang dita�arkannya sebagai middle�are platform.Arsitektur Referensi SIPKD Dokumen 3 Model Komponen Objek A Komponen A Gambar 14 . Direktorat Jenderal Bina Administrasi Keuangan Daerah Departemen Dalam Negeri Republik Indonesia 0 . tujuan semua usaha di atas adalah untuk memudahkan ketika mengimplementasikan sistem aplikasi terdistribusi seperti SIPKD yang bisa diimplementasikan dalam skala kecil atau bisa juga dalam skala besar.

Arsitektur Referensi SIPKD Dokumen 3 Model Komponen 4 SIPKD DAN TEKNOLOGI KOMPONEN Dokumen ini tidak akan menguraikan implementasi SIPKD dengan teknologi komponen secara rinci dan komplit. Tetapi dengan semua uraian sebelumnya dalam dokumen ini diharapkan bisa didapatkan gambaran bagaimana cara mengimplementasikan SIPKD dengan teknologi komponen dan dengan cara yang baik dan praktis.1 Sistem Basisdata Relasional Gambar 15 . Direktorat Jenderal Bina Administrasi Keuangan Daerah Departemen Dalam Negeri Republik Indonesia  .1 Entity Beans RKA-SKPD 2.Lapisan logik SAPKD dengan teknologi komponen Gambar di atas memperlihatkan contoh bagaimana modul penganggaran dibangun secara modular dengan pola session façade sehingga masing�masing sub�modul penganggaran seperti KUA. Session Beans Penganggaran Session Beans Penatausahaan Session Beans Akuntansi Session Beans KUA Session Beans PPA Session Beans RKA-SKPD Entity Beans Proyeksi KUA Entity Beans RKA-SKPD 1 Entity Beans RKA-SKPD 2.2. Berikut ini diperlihatkan gambar yang memberikan contoh pengembangan modul�modul SIPKD dengan teknologi komponen.

Direktorat Jenderal Bina Administrasi Keuangan Daerah Departemen Dalam Negeri Republik Indonesia  . sehingga tersedia sistem aplikasi berteknologi komponen yang rapih dan riliabel.Arsitektur Referensi SIPKD Dokumen 3 Model Komponen PPA. Lalu setiap session bean dari sub�modul yang bersangkutan akan menggunakan entity beans yang berada di ba�ahnya untuk memanipulasi data yang ada dalam sistem basis data. Pengembang sistem aplikasi bisa menyediakan seluruh beans yang diperlukan untuk membangun SAPKD secara utuh. dan RKA�SKPD bisa di�akili oleh masing�masing session bean.

Arsitektur Referensi SIPKD Dokumen 3 Model Komponen DAFTAR SINGKATAN CORBA DCOM EJB IIOP ORB RMI SAPKD SIMBADA SIMPEG SIPKD Common Object Request Broker Architecture Distributed Component Object Model Enterprise Java Beans Internet Inter ORB Protocol Object Request Broker Remote Method Invocation Sistem Aplikasi Pengelolaan Keuangan Daerah Sistem Informasi Manajemen Barang Daerah Sistem Informasi Manajemen Kepega�aian Sistem Informasi Pengelolaan Keuangan Daerah Direktorat Jenderal Bina Administrasi Keuangan Daerah Departemen Dalam Negeri Republik Indonesia  .

Arsitektur Referensi SIPKD Dokumen 3 Model Komponen Direktorat Jenderal Bina Administrasi Keuangan Daerah Departemen Dalam Negeri Republik Indonesia  .

You're Reading a Free Preview

Mengunduh
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->