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]
