2-1

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-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, service-

service 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 komponen-

komponen 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 2-

10. 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 komponen-

komponen. SCA ini akan memberikan cara untuk mendefinisikan bagian-bagian dari SOA

sebagai sebuah komponen-komponen, bagaimana cara untuk merangkai komponen-

komponen 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 artifak-

artifak 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 di-

publish 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]