BAB 2 DASAR TEORI

BAB 2
DASAR TEORI
2.1 Service Oriented Architecture (SOA)
Saat berbicara mengenai SOA, maka terlebih dahulu harus dilakukan pembahasan
mengenai services. Services adalah sebuah fungsi yang terdefinisi dengan baik,
terenkapsulasi, dan tidak tergantung state yang dimiliki oleh fungsi yang lain. [BAR09].
Service sendiri dapat melingkupi [MER07] :
1. Menangani sebuah proses bisnis seperti menghitung jumlah pajak atau melakukan
sebuah kegiatan teknis melakukan akses terhadap sebuah basis data.
2. Dapat melakukan akses terhadap services lain dan dengan teknologi pendukung yang
memadai dapat mengakses aplikasi lain dan dapat memberikan respon terhadap
permintaan yang bermacam-macam.
3. Independen terhadap aplikasi lain sehingga pengubahan terhadap aplikasi yang
menggunakan services tersebut tidak akan mengubah services tersebut. Sementara
pengubahan terhadap services tidak akan mengubah aplikasi yang menggunakan
services yang bersangkutan.
SOA adalah sebuah arsitektur yang bersifat service oriented (berorientasi service), dimana
sebuah permasalahan akan dibagi-bagi menjadi berbagai macam service kecil yang saling
berkerja sama. [ERL05]. Pembahasan mengenai konsep service oriented ini akan dibahas
pada subbab berikut.
2.1.1 Konsep Service Oriented
Dengan service oriented, sebuah permasalahan akan dibagi-bagi menjadi service yang
lebih kecil dimana masing-masing service mempunyai tugasnya sendiri-sendiri. Service
melakukan hal ini dengan cara melakukan enkapsulasi dari lojik yang terkandung dalam suatu
proses/cara kerja. Proses/cara kerja ini dapat meliputi suatu kegiatan dalam bisnis, sebuah
entitas, atau suatu bentuk kumpulan lojik yang lain. [ERL05]
Seperti dapat dilihat dalam Gambar 2-1, sebuah service dapat mengenkapsulasi sebuah
proses, baik proses itu melupakan proses besar atau hanya sebuah proses kecil. Service ini
dapat mengengkapsulasi langkah lojik yang ada dalam suatu proses, dan menyediakan
langkah tersebut sebagai sebuah service yang dapat dengan mudah digunakan atau
2-1
2-2
dipasangkan dengan service lainnya. Sebuah service juga dapat terdiri dari service-service
lainnya yang lebih kecil. [ERL05]
Gambar 2-1. Enkapsulasi lojik dalam bentuk service [ERL05]
Contoh dari dekomposisi lojik menjadi service dapat dilihat dalam sebuah proses bisnis.
Misalkan kita ambil contoh sebuah proses bisnis dalam sebuah restoran. Saat seorang
pelanggan masuk, dia akan diberikan menu oleh pelayan. Pelayan lalu akan mencatat pesanan
yang dibuat oleh pelanggan, lalu membawa pesanan tersebut ke dapur. Di dapur, masakan
akan dibuat oleh seorang juru masak. Setelah masakan tersebut jadi, pelayan akan membawa
masakan tersebut ke pada pelanggan.
Dari contoh ini dapat dilihat empat proses yang berbeda, yaitu proses pemesanan,
proses pencatatan pesanan dan pemberitahuan pesanan ke dapur, proses pembuatan pesanan,
dan proses pengantaran pesanan yang sudah terbuat ke pelanggan. Masing-masing proses ini,
dapat dianggap sebuah service tersendiri, sehingga kita akan mempunyai service memesan
makanan, service pencatatan pesanan, dan service lainnya yang sesuai. Selain itu, serviceservice tersebut dapat didekomposisi menjadi service yang lebih kecil, sebagai contoh service
memesan makanan dapat didekomposisi menjadi service melihat daftar menu dan service
memilih menu yang dipesan.
2-3
Dalam konsep service oriented, ada beberapa prinsip yang mendasari sebuah service
yaitu [ERL05] :
1. Service bersifat reusable, baik itu secara langsung maupun tidak langsung
2. Service saling mempunyai sebuah kontrak formal bagaimana service itu saling
berinteraksi
3. Service bersifat loosely coupled yaitu independen satu sama lain
4. Service menyembunyikan lojik yang ada di dalam service tersebut dari dunia luar
5. Service mampu untuk membentuk service lain
6. Service bersifat mandiri dan mampu untuk mengatur dirinya sendiri
7. Service bersifat stateless, yaitu service tidak menyimpan kondisi dirinya sendiri
8. Service bersifat discoverable, yaitu service dapat ditemukan oleh service lain
2.1.2 Komponen SOA
Gambar 2-2. Komponen-Komponen SOA [ERL05]
Ada 4 komponen utama yang ada di dalam SOA seperti dalam Gambar 2-2, yaitu
[ERL05] :
1. Operation, yaitu lojik yang diperlukan oleh process untuk menyelesaikan sebuah
pekerjaan
2. Message, yaitu data yang diperlukan untuk menyelesaikan sebagian atau seluruh
bagian dari pekerjaan
3. Service, yaitu kumpulan operation yang mampu mengerjakan pekerjaan yang saling
berkaitan.
4. Process, yaitu kumpulan aturan bisnis yang menentukan service mana yang akan
digunakan untuk menyelesaikan suatu pekerjaan.
2-4
Komponen-komponen yang ada di dalam SOA akan saling berhubungan dengan cara
sebagai berikut [ERL05] :
1. Sebuah operation mengirim dan menerima message untuk melakukan suatu pekerjaan
tertentu.
2. Sebuah operation biasanya didefinisikan oleh message apa saja yang operation
tersebut terima dan kirimkan.
3. Sebuah service adalah kumpulan dari operation yang saling berhubungan
4. Sebuah service didefinisikan oleh operation-operation yang dipunyai oleh service
tersebut.
5. Sebuah instan dari process dapat membentuk service
6. Sebuah instan dari process tidak didefinisikan oleh service yang dimilikinya, karena
process tersebut dapat hanya menggunakan sebagian saja dari seluruh fungsionalitas
dari service
7. Sebuah instan dari process menggunakan kumpulan operasi yang unik untuk
menyelesaikan pekerjaannya
8. Setiap instan dari process didefinisikan oleh service operation yang process tersebut
pergunakan.
Gambar 2-3 menggambarkan ilustrasi mengenai keterhubungan antar komponenkomponen SOA.
Gambar 2-3. Keterhubungan antar komponen SOA [ERL05]
2.1.3 Layering pada SOA
Aplikasi yang digunakan oleh perusahaan pada umumnya menggunakan sebuah
enterprise architecture, yaitu sebuah arsitektur aplikasi untuk skala enterprise. Fokus
2-5
utamanya dari enterprise architecture adalah pada pengaturan lojik bisnis yang dimiliki oleh
perusahaan untuk selanjutnya diimplementasi dalam sebuah aplikasi.
Gambar 2-4. Posisi SOA pada sebuah enterprise architecture [ERL05]
Gambar 2-4 menunjukkan sebuah aplikasi yang menggunakan enterprise architecture
yang terbagi menjadi 3 bagian utama, yaitu business process layer, service enterprise layer,
dan application layer. Business process layer adalah layer yang berkaitan dengan kebutuhan
dan pengetahuan bisnis yang dipunyai oleh suatu enterprise. Application layer berkaitan
dengan dengan implementasi dari lojik bisnis yang terkandung di dalam business process
layer dalam suatu solusi teknologi informasi. SOA masuk menjadi bagian dari enterprise
architecture ini dengan menjadi penjembatan antara lojik dan pengetahuan bisnis dengan
implementasi dari lojik tersebut. SOA membuat sebuah layer baru bernama service interface
layer yang terletak di antara business process layer dan application layer. [ERL05]
Service interface layer sendiri akan dibagi menjadi 3 bagian utama seperti yang
ditunjukkan dalam Gambar 2-5, yaitu orchestration service layer, business service layer, dan
application service layer.
2-6
Gambar 2-5. Layering pada SOA [ERL05]
2.1.3.1
Application Service Layer
Application service layer, seperti yang ditunjukkan dalam Gambar 2-6 adalah layer yang
terletak berbatasan dengan aplication layer. Layer ini menjadi fondasi dasar untuk membuat
fungsionalitas-fungsionalitas aplikasi secara teknis. Service yang ada di dalam layer ini biasa
disebut sebagai application services, dimana tugasnya adalah menyediakan fungsi-fungsi
untuk pemrosesan data pada suatu lingkungan aplikasi baik aplikasi modern maupun aplikasi
legacy (aplikasi yang sudah dipakai sejak lama). Fungsi yang disediakan bersifat reusable
sehingga selalu dapat digunakan kembali. [ERL05]
Karakteristik yang dimiliki oleh application services adalah sebagai berikut [ERL05] :
1. Menyediakan fungsionalitas yang spesifik terhadap tugas pemrosesan tertentu
2. Menggunakan sumber daya yang disediakan oleh platform terknologi tertentu
3. Berorientasi solusi
4. Bersifat generik dan reusable
5. Dapat digunakan untuk membuat integrasi point-to-point dengan service yang
disediakan oleh aplikasi lain
6. Inkonsisten dalam tingkatan transparansi interface yang disediakan oleh service yang
bersangkutan
2-7
7. Dapat terdiri dari service yang dikembangkan sendiri maupun dikembangkan oleh
orang lain
Gambar 2-6. Application Service Layer [ERL05]
2.1.3.2
Business Service Layer
Berbeda
dengan
application
service
layer
yang
bertanggung
jawab
untuk
merepresentasikan teknologi yang digunakan dan lojik dari aplikasi, business service layer
yang ditunjukkan dalam Gambar 2-7 bertanggung jawab untuk menyediakan service yang
berkaitan dengan representasi lojik dari bisnis. Lojik bisnis ini akan diatur dalam sebuah
service bernama business service. Tanggung jawab dari business service adalah
mengimplementasikan lojik dan model bisnis perusahaan dalam sebuah service. [ERL05]
Business service sendiri terbagi menjadi 2 katagori, yaitu [ERL05] :
1. Task-centric business service, yaitu service yang mengenkapsulasi lojik bisnis yang
spesifik terhadap sebuah kegiatan atau proses bisnis yang dimiliki perusahaan.
Service ini paling mudah untuk dianalisis, namun potensi reuse yang ada terbatas.
2-8
2. Entity- centric business service, yaitu service yang mengenkapsulasi sebuah entitas
bisnis (seperti invoice atau jadwal kegiatan). Service ini memiliki potensi reuse yang
tinggi, namun memerlukan proses analisis yang lebih sulit.
Gambar 2-7. Business Service Layer [ERL05]
2.1.3.3
Service Orchestration Layer
Orchestration service layer, yang diilustrasikan dalam Gambar 2-8, adalah layer yang
memberikan abstraksi paling tinggi dari lojik dan aturan bisnis perusahaan serta bagaimana
service harus berjalan. Layer ini digunakan untuk memenuhi kebutuhan perlunya sebuah
service lain yang bertanggung jawab untuk mengatur bagaimana service-service yang ada
dapat dieksekusi dengan urutan yang sesuai. Orchestration service layer mempunyai process
services, yaitu service yang dapat mengatur business service dan application service untuk
berjalan dengan aturan dan urutan yang sesuai dengan lojik dan aturan bisnis perusahaan yang
telah terdefinisi di dalam process service tersebut. [ERL05]
2-9
Gambar 2-8. Orchestration Service Layer [ERL05]
2.2 Service Oriented Analysis and Design
Aplikasi berbasis SOA berdasarkan pada konsep service-oriented, sehingga untuk
membangun sebuah aplikasi berbasis SOA tidak bisa menggunakan teknik pengembangan
aplikasi yang pada umumnya digunakan seperti analisis terstruktur atau object-oriented. Salah
satu metode dengan konsep service-oriented yang dapat digunakan adalah Service Oriented
Analysis and Design (SOAD) yang diperkenalkan oleh Thomas Erl [ERL05].
Gambar 2-9. Fase dalam SOAD [ERL05]
2-10
Skema fase pengembangan aplikasi dengan menggunakan SOAD dapat dilihat dalam
Gambar 2-9. Fase pengembangan dalam SOAD terbagi menjadi 6 fase yaitu service-oriented
analysis, service oriented design, service development, service testing, service deployment,
dan service administration. Walaupun terbagi menjadi 6 fase, inti dari SOAD dapat dilihat
dari 2 fase pertama, yaitu service-oriented analysis dan service-oriented design karena dari 2
fase pertama inilah konsep dan prinsip mengenai service-oriented mulai dimasukkan dalam
analisis dan desain solusi yang akan dibuat.
2.2.1 Service-Oriented Analysis
Service-oriented analysis adalah fase awal dalam pengembangan sebuah aplikasi SOA,
dimana akan ditentukan lingkup dari aplikasi SOA yang akan dibuat. Setelah lingkup aplikasi
ditentukan, selanjutnya dilakukan identifikasi dan analisis service yang akan ada di dalam
aplikasi.
Tujuan yang ingin dicapai dalam tahapan service-oriented analysis adalah sebagai berikut
[ERL05] :
1. Mendefinisikan kandidat-kandidat service yang akan ada
2. Mengelompokkan kandidat service yang telah didefinisikan dalam sesuai dengan
konteks lojik masing-masing
3. Mendefinisikan batasan antara service sehingga tidak terjadi overlap antar service.
4. Mengidentifikasi lojik yang terkandung di dalam service yang berpotensi untuk
digunakan kembali
5. Memastikan bahwa lojik dalam tiap service sudah sesuai dengan tujuan dan
fungsionalitas dari service yang bersangkutan
6. Mendefinisikan model awal komposisi service
Service-oriented analysis terbagi menjadi 3 langkah, yaitu [ERL05] :
1. Mendefinisikan kebutuhan bisnis, dimana kebutuhan bisnis akan ditangkap dan
dimodelkan menggunakan teknik seperti Business Process Management (BPM).
2. Mengidentifikasi sistem yang telah ada, yaitu melihat dan melakukan pendataan
sistem lain pada lingkungan operasional aplikasi yang mempunyai kemungkinan
untuk berinteraksi atau memberikan pengaruh kepada aplikasi nantinya.
3. Memodelkan kandidat-kandidat service yang disediakan oleh aplikasi. Contoh dari
kandidat service dan service operation yang dihasilkan dapat dilihat dalam Gambar 210. Kandidat service yang dimaksud di sini adalah kandidat service dalam bentuk
2-11
business service dan application service, serta lojik orkestrasi dalam bentuk process
services.
Gambar 2-10. Contoh Kandidat Service dan Operasi pada Service [ERL05]
2.2.2 Service Oriented Design
Setelah membuat kandidat dari service pada tahap analisis, maka tahap berikutnya adalah
membuat desain konkrit dari kandidat service yang telah ada dan mengimplementasikannya
dalam sebuah komposisi yang membentuk suatu proses bisnis. Dalam SOAD, desain dan
implementasi dari service menggunakan teknologi web service yang berbasis XML
(eXtensible Markup Language), XSD (XML Schema Definition), SOAP (Simple Object Access
Protocol), dan WSDL (Web Service Definition Language), dan WS-* extension. [ERL05]
Tujuan yang ingin dicapai dalam kegiatan service oriented design ini adalah sebagai
berikut [ERL05] :
1. Bagaimana mendefinisikan secara fisik interface service dari kandidat service yang
telah didapatkan dalam service oriented analysis
2. Karakteristik SOA apa saja yang akan diimplementasikan
3. Standar apa saja yang diperlukan oleh aplikasi SOA yang dibuat
Tujuan yang telah disebutkan di atas akan didetilkan lagi dalam poin-poin sebagai berikut
[ERL05]:
1. Menentukan bagian utama dari sistem
2. Menentukan standar apa saja yang akan dipakai dalam sistem yang akan dibuat
3. Membuat batasan yang jelas dari sistem yang akan dibuat
4. Mendefinisikan interface service
5. Mengidentifikasi kemungkinan komposisi service yang mungkin muncul
2-12
6. Menerapkan prinsip service orientation
7. Mengeksplorasi dukungan untuk sistem SOA lainnya
Gambar 2-11. Proses Service Oriented Design [ERL05]
Gambar 2-11 menunjukkan langkah-langkah yang ada pada service oriented design. Ada
3 langkah utama, yaitu [ERL05] :
1. Mengkomposisi SOA, yaitu mendefinisikan teknologi yang akan digunakan dalam
SOA. Dalam SOAD, teknologi SOA yang dipergunakan adalah web service.
2. Service design, yang mencakup penentuan hasil akhir services berupa entity-centric
business service, task-centric business service, dan application services berdasarkan
kandidat service yang telah didapatkan dalam tahap analisis.
3. Business process design. Proses bisnis yang akan didesain pada langkah ini adalah
proses bisnis untuk orchestration layer yang akan menentukan lojik workflow dari
SOA.
Dalam mendesain service baik entity-centric, task-centric, dan application services,
langkah yang dilakukan adalah sebagai berikut [ERL05] :
1. Menentukan service mana dari tahap analisis yang akan didesain
2. Menentukan schema pesan yang digunakan. Service bertukar informasi dengan
mengirimkan pesan, sehingga schema atau struktur pesan yang digunakan harus
didefinisikan dari awal sehingga services dapat saling mengerti pesan yang
2-13
dikirimkan. Schema akan didefinisikan dalam format XML dengan menggunakan
XSD yang diterapkan dalam bentuk web services menggunakan WSDL dan SOAP.
3. Mendefinisikan interface dari service. Interface disini berupa port dimana melalui
port tersebut service dapat mengirimkan dan menerima pesan. Port akan
didefinisikan dengan menggunakan WSDL, lalu untuk tiap port akan didefinisikan
pesan yang akan diterimanya dengan menggunakan schema yang telah disepakati.
4. Mengaplikasikan prinsip service-orientation, yang berupa reusablity, autonomy,
statelessness, dan discoverability
5. Me-refine ulang interface service yang telah didefinisikan
6. Mengembangkan lebih lanjut operasi yang ada dalam suatu service sehingga
mencakup semua hal yang mungkin.
7. Mengidentifikasi batasan teknis yang ada, baik dari segi keamanan, performansi, dan
realibilitas
8. Mengidentifikasi service lain yang diperlukan, apabila service yang didesain bersifat
kompleks dan merupakan hasil komposisi dari banyak service.
Gambar 2-12. Contoh Service dan Service Operation yang telah didesain [ERL05]
Gambar 2-12 menunjukkan contoh service yang bersifat entity-centric, yaitu service
employee. Service dan service operation yang telah didefinisikan di atas selanjutnya akan
didefinisikan dalam bentuk WSDL seperti dalam Gambar 2-13.
2-14
Gambar 2-13. Contoh WSDL dari Service dan Service Operation [ERL05]
2.3 Service Component Architecture
SCA (Service Component Architecture) adalah sebuah metode pengembangan aplikasi
SOA yang memandang sebuah aplikasi SOA sebagai sebuah komposisi dari komponenkomponen. SCA ini akan memberikan cara untuk mendefinisikan bagian-bagian dari SOA
sebagai sebuah komponen-komponen, bagaimana cara untuk merangkai komponenkomponen
tersebut
untuk
bekerja
bersama,
dan
memberikan
spesifikasi
untuk
mengimplementasikan komponen-komponen tersebut dalam suatu bahasa pemograman
tertentu.
2.3.1 Konsep SCA
Gambar 2-14 memperlihatkan struktur aplikasi yang dibangun dengan menggunakan
SCA. SCA membagi aplikasi dalam berbagai SCA component, SCA component sendiri dapat
berupa banyak hal, seperti sebuah kelas dalam Java, sebuah kelas dalam C++, atau sebuah
implementasi dari BPEL maupun sebuah framework seperti Spring. SCA components ini lalu
akan dikelompokkan dalam sebuah satuan lojik yang dinamanakan SCA composite. SCA
composite ini dapat terdiri dari berbagai macam SCA component dengan implementasi yang
berbeda-beda. Sebuah aplikasi dapat terdiri dari satu atau lebih SCA composite. [CHA07]
2-15
Gambar 2-14. Aplikasi SOA dengan SCA [CHA07]
Aplikasi yang dibangun dengan SCA dapat berinteraksi dengan aplikasi lain yang tidak
dikembangkan dengan SCA seperti web services, sebuah halaman web, dan jenis aplikasi
lainnya. Sebuah SCA component juga dapata melakukan akses terhadap basis data, baik
dengan menggunakan teknologi SCA yaitu SDO (Service Data Object), maupun dengan
memanfaatkan teknologi yang dibawa oleh implementasi dari SCA component tersebut.
Misalkan apabila SCA component adalah sebuah kelas dalam Java, maka untuk melakukan
pengaksesan terhadap basis data dapat menggunakan JDBC (Java Data Base Connectivity)
atau JPA (Java Persistence API). [CHA07]
Sebuah SCA composite akan dideskripsikan dalam sebuah file konfigurasi dengan
ekstensi .composite. File ini menggunakan sebuah format XML bernama SCDL (Service
Component Definition Language) untuk mendeskripsikan SCA component yang ada di dalam
SCA composite tersebut dan bagaimana SCA component tersebut saling berelasi satu sama
lain. [CHA07]
SCA lebih lanjut lagi membagi lingkungan operasional sebuah aplikasi SCA dalam bentuk
domain-domain, dimana setiap aplikasi SCA yang berjalan di dalam domain tersebut sebagai
sebuah runtime. Konsep domain ini sangat penting di dalam SCA karena walaupun SCA
mendukung untuk membuat aplikasi terdistribusi, SCA tidak memberikan definisi khusus
bagaimana tiap bagian dari aplikasi terdistribusi tersebut untuk saling berinteraksi. Dengan
membagi menjadi domain-domain, SCA dapat membedakan antara komunikasi di dalam
domain dengan aplikasi di luar domain SCA, seperti ditunjukkan dalam Gambar 2-15.
[CHA07]
2-16
Gambar 2-15. Domain dalam SCA [CHA07]
2.3.2 Elemen SCA
SCA terdiri 4 elemen utama, yaitu [KAR06] :
1. Assembly model, yaitu bagaimana mendefinisikan struktur aplikasi yang dibangun
dari SCA
2. Client and Implementation model, yaitu bagaimana mengimplementasikan service
yang dibuat dalam assembly model ke dalam bahasa pemograman tertentu
3. Bindings, yaitu bagaimana interaksi antar komponen dan services yang dimiliki SCA
4. Policy Framework, yaitu bagaimana menambah pengaturan interaksi tiap komponen
dalam aplikasi
2.3.2.1
Assembly Model
Gambar 2-16. Contoh SCA Assembly Model [OPE207]
2-17
Assembly model, yang mendefinisikan struktur dari sebuah aplikasi SCA, merupakan
sebuah model yang memuat artifak-artifak yang mendefinisikan konfigurasi dari sebuah
domain SCA dalam bentuk SCA composite dan SCA component serta hubungan dan artifakartifak lain yang mendefinisikan bagaimana artifak tersebut saling berinteraksi. [OPE207]
Artifak-artifak dari Assembly Model akan didefinisikan dalam sebuah file XML yang
menyimpan semua keterangan mengenai artifak-artifak tersebut. Beberapa contoh artifak
dapat dilihat dalam Gambar 2-16.
SCA Component
Dalam SCA, SCA component adalah satuan pembangun aplikasi SCA yang terkecil. SCA
component merupakan sebuah instans pengimplementasian yang telah dikonfigurasi.
Implementasi yang dimaksud di sini dapat berupa kode program yang membuat SCA
component tersebut mampu untuk melakukan suatu fungsi tertentu. Konfigurasi di sini
maksudnya adalah bagaimana komponen tersebut mampu melakukan interaksi dengan dunia
luar, baik komunikasi data maupun pemanggilan fungsi dari SCA component yang
bersangkutan. [CHA07]
Gambar 2-17. SCA Component [CHA07]
Gambar 2-17 memperlihatkan bagian-bagian dari suatu SCA component. Setiap SCA
component mengimplementasikan suatu lojik bisnis tertentu, yang kemudian akan dikelola
dalam bentuk satu atau lebih services. Sebuah service memiliki sejumlah operations yang
dapat digunakan oleh client yang mengakses SCA component tersebut. Bagaimana service
dideskripsikan tergantung dari bagaimana SCA component yang mengandung service tersebut
diimplementasi. Apabila SCA component diimplementasi dengan menggunakan Java, maka
2-18
service dapat berupa interface Java, atau misal SCA component diimplementasi dengan
menggunakan BPEL, maka service akan dapat berupa WSDL. [CHA07]
Selain menyediakan services kepada client penggunanya, sebuah SCA component dapat
menggunakan service yang disediakan oleh SCA component lain di dalam domain yang sama
atau yang disediakan oleh aplikasi lain di luar domain. Sebuah SCA component dapat
mendeskripsikan service-service yang dibutuhkannya itu dengan menggunakan references.
References akan mengandung interface dari service-service lain yang akan digunakan oleh
SCA component tersebut. [CHA07]
Di luar service dan references, sebuah SCA component juga dapat mengandung nilai
tertentu yang dibaca dari file konfigurasi SCDL untuk SCA component yang bersangkutan,
yang diberi nama property. Dengan property ini, SCA component mampu mendapatkan data
seperti lokasi, waktu, atau pengaturan konfigurasi lainnya. [CHA07]
SCA component didefinisikan sebagai sub-elemen dari sebuah SCA composite. Contoh
dari pendefinisian ini dapat dilihat dalam Gambar 2-18.
Gambar 2-18. Pendefinisian SCA Component di dalam SCA Composite [KAR06]
2-19
SCA Composites
Gambar 2-19. SCA Composite [CHA07]
Gambar 2-19 mendeskripsikan sebuah SCA composite. SCA composite adalah sebuah
satuan lojik untuk pengelompokkan beberapa SCA component. Di dalam SCA composite,
sebuah reference yang menunjuk kepada service yang disediakan oleh sebuah SCA
component di dalam domain yang sama akan dihubungkan dengan wire. Selain itu, service
dan reference yang ada dimiliki SCA component yang ada di dalam SCA composite dapat dipublish ke luar dari SCA composite sehingga dapat digunakan oleh SCA composite lain, hal
ini dinamakan promotion. [CHA07]
SCA composite didefinisikan dalam sebuah file XML dengan ekstensi .composite. Contoh
pendefinisian SCA composite dapat dilihat dalam Gambar 2-18.
2.3.2.2
Client and Implementation Model
Artifak SCA yang telah dibuat dalam assembly model selanjutnya diimplementasikan
menjadi kode dalam bahasa pemograman tertentu. SCA menyediakan pedoman untuk
mengimplementasikan model yang telah dibuat dalam bentuk client and implementation
model. Client and implementation model menyediakan penjelasan spesifik bagaimana untuk
membangun artifak-artifak yang telah dibuat sebelumnya dalam suatu bahasa pemograman
tertentu. Client and implementation model ini bersifat extensible, artinya dapat terus
dikembangkan sehingga SCA dapat diimplementasikan dalam berbagai macam bahasa. Saat
2-20
ini, SCA menyediakan 8 jenis client and implementation model, yaitu dalam BPEL, Java,
Spring Framework, EJB, JAX-WS, C++, COBOL, dan PHP. [CHA07]
Contoh dari client and implementation model ini dalam Java misalnya SCA component
dideklarasikan dalam kelas Java, services adalah fungsi di dalam kelas tersebut, dan untuk
mengakses service kita menggunakan interface dalam Java. [OPE407]
2.3.2.3
Bindings
Gambar 2-20. Bindings pada SCA [CHA07]
Bindings, seperti tampak pada Gambar 2-20 adalah cara suatu SCA component untuk
berkomunikasi dengan hal lain di luar dirinya. Bindings dapat dideklarasikan secara implisit
dan eksplisit, implisit apabila komunikasi yang berlangsung antara SCA component dalam
satu domain yang sama, dan eksplisit apabila komunikasi berlangsung antara SCA component
dengan SCA component lain di luar domain atau dengan aplikasi lain yang tidak dibangun
dengan SCA. Setiap bindings akan mendefinisikan sebuah protokol tertentu yang dapat
dipergunakan
untuk
berkomunikasi
dengan
service/reference
tertentu.
Setiap
service/reference dapat memiliki banyak bindings, sehingga memungkinkan service/reference
tersebut untuk dapat diakses dengan berbagai macam cara. [CHA07]
2-21
Untuk saat ini, bindings yang didukung dengan SCA ada 4 jenis, yaitu web service, JMS
(Java Message Service), JCA (JavaEE Connector Architecture), dan EJB (Enterprise Java
Beans). [KAR06]
2.3.2.4
Policy Framework
Mengatur bagaimana interaksi antara bagian-bagian dalam sebuah aplikasi cukup rumit,
sehingga untuk membantu para developer dalam melakukan pengaturan tersebut SCA
menyediakan bagian yang bernama policy. Policy berguna untuk mendefinisikan bagaimana
suatu bagian aplikasi harus bekerja dalam berbagai kondisi yang ada. Policy dikategorikan
menjadi 2 bagian, yaitu [OPE207] :
1. Interaction policies, yaitu untuk modifikasi bagaimana suatu SCA component
berinteraksi dengan SCA component lain. Contohnya adalah policy yang berkaitan
dengan keamanan pesan. Interaction policies biasa diaplikasikan pada bindings
2. Implementation policies, yaitu untuk modifikasi bagaimana sebuah SCA component
bertingkah laku dalam suatu domain. Contohnya adalah bagaimana sebuah SCA
component harus berperilaku dalam sebuah transaksi data.
Policy yang telah dibuat selanjutnya akan didefinisikan dalam bentuk tag XML
dengan menggunakan WS-Policy dan WS-PolicyAssessment. [OPE207]
2.3.3 SCA Runtime
Lingkungan operasional sebuah aplikasi SCA haruslah dalam lingkungan yang
mendukung bagian-bagian SCA seperti SCA component, SCA composite, dan kemampuan
untuk membaca file konfigurasi SCA dalam bentuk SDLC dan implementasi dari policy SCA.
Karena itulah lingkungan operasional dari aplikasi SCA ini bersifat khusus dan diberi nama
SCA runtime. Untuk saat ini, beberapa lingkungan SCA runtime yang ada adalah IBM
Websphere, Rougewave, TIBCO, dan Oracle Fabric.
Selain runtime dari vendor yang
bersifat propeitary seperti disebutkan sebelumnya, ada yang bersifat open source, yaitu
apache tuscany. [KAR06]