9
LANDASAN TEORI
2.1 Service Oriented Architecture
Definisi Service Orientation Architecture (SOA) menurut Open Group adalah sebuah model arsitektur yang mendukung service orientation (John Erickson, Keng Siau, 2008). Definisi tersebut terfokus pada model arsitektur,
service orientation, service serta fitur – fitur yang menonjol pada SOA.
Organization for Advancement of Structured Information Standards (OASIS) mendefinisikan SOA sebagai paradigma yang digunakan untuk mengatur dan memanfaatkan kemampuan terdistribusi yang mungkin berada di bawah kendali kepemilikan suatu domain yang berbeda (John Erickson, Keng Siau, 2008). Definisi OASIS disebut sebagai “reference model” yang selanjutnya diperluas dan diformalkan.
SOA didefinisikan oleh World Wide Web Consortium (W3C) sebagai suatu bentuk arsitektur sistem terdistribusi yang pada umumnya ditandai dengan logical view, message orientation, description orientation, granularity
dan platform neutrality (John Erickson, Keng Siau, 2008). XML.com pada
tahun 2007 mendefinisikan SOA sebagai sebuah gaya arsitektur yang memiliki tujuan untuk mencapai loosely couple antara agen perangkat lunak yang berinteraksi (John Erickson, Keng Siau, 2008). Service adalah satuan kerja yang dilakukan oleh penyedia service untuk mencapai hasil akhir yang
diinginkan kepada consumer service. Empat karakteristik yang dimiliki oleh SOA berdasarkan Raghu Kodali antara lain :
a. Antarmuka yang disusun dengan XML yang menggunakan WSDL
b. Skema XML yang disebut dengan XSD yang harus digunakan untuk mengolah pesan
c. Registry UDDI berdasarkan pada penyimpanan daftar service yang
disediakan
d. setiap service harus mempertahankan tingkat kualitas yang ditetapkan untuk melalui persyaratan keamanan QoS.
IBM mengusulkan bahwa SOA menggambarkan gaya arsitektur yang memperlakukan komponen perangkat lunak sebagai service set (UNL – IBM system in Global Innovation Hub, 2007). Definisi tersebut ditegaskan sebagai kebutuhan bisnis yang harus mengendalikan definisi dari service dan nilai tujuan harus terfokus dengan reusability dan fleksibilitas service yang telah didefinisikan (John Erickson, Keng Siau, 2008).
2.2 Prinsip – Prinsip Service Orientation
Pendekatan Service Oriented Architecture (SOA) tidak memiliki prinsip – prinsip yang baku digunakan untuk pengembangan SOA tersebut. Beberapa prinsip yang seringkali digunakan terkait dengan pendekatan SOA terdapat pada pembahasan di bawah ini (Thomas Erl, 2008, p290-310):
Pengembangan sistem yang menggunakan pendekatan SOA, service dirancang secara khusus untuk mendukung penggunaan kembali sesuai dengan kebutuhannya.
ii. Prinsip 2 : Service merupakan formal specifation
Service tidak membutuhkan suatu pembagian apa pun di dalam pengembangan yang menggunakan pendekatan SOA untuk dapat berinteraksi dengan service. Service membutuhkan sebuah kontrak yang formal yang dapat mendeskripsikan setiap service yang telah ada dan menentukan persyaratan yang dibutuhkan pada pertukaran informasi yang terjadi.
iii. Prinsip 3 : Service merupakan loosely couple
Service secara khusus pada pendekatan SOA dirancang untuk dapat
berkomunikasi dengan antar service tanpa perlu saling ketergantungan.
iv. Prinsip 4 : Inti sari service berdasarkan logika
Satu – satunya bagian dari service yang terlihat di dunia luar pada penerapan pendekatan SOA merupakan hal – hal yang ditampilkan melalui kontrak service tersebut. Logika dasar yang melampui hal tersebut dinyatakan ke dalam deskripsi yang terdiri dari kontrak yang tidak nyata dan tidak relevan dengan permintaan dari service tersebut.
v. Prinsip 5 : Decomposition Service
Penggunaan SOA menyebabkan service dapat menyusun service yang lain. Hal ini memungkinkan logika yang dapat digambarkan pada tingkat granularity yang berbeda dan mempromosikan penggunaannya kembali serta penyusunan dari inti sari yang berada pada layer.
vi. Prinsip 6 : Service bersifat otonomi
Logika yang menggunakan pendekatan SOA dipengaruhi oleh sebuah
service yang diletakan pada sebuah batasan yang tidak dapat dilihat.
Service tersebut akan mengontrol batas tersebut dan untuk
mengeksekusinya tidak perlu bergantung dengan service lain.
vii. Prinsip 7 : Service bersifat stateless
Service yang berbasiskan SOA tidak harus membutuhkan pengaturan informasi state. Hal ini dikarenakan state tersebut dapat menghalangi kemampuan service untuk bergabung atau berintegrasi.
viii. Prinsip 8 : Service tidak terdeteksi
Service yang dirancang harus dapat memungkinkan deskripsi
mengenai diri service sendiri di dalam sistem yang telah menerapkan SOA untuk dapat menemukan servicenya tersebut dan dapat dimengerti oleh
manusia dan pemohon service tersebut yang dapat menggunakan logika dalam service tersebut.
2.3 Service Oriented Modeling and Architecture (SOMA)
Sebagai metode pengembangan perangkat lunak lifecycle untuk mengembangkan solusi berbasis SOA, atau solusi dengan menggunakan prinsip berorientasi layanan, SOMA mendefinisikan teknik kunci dan menjelaskan peran pada sebuah proyek SOA dan Work Breakdown Structure (WBS). SOMA sendiri dikemukakan oleh IBM (IBM Global Services, 2004, p2-3). WBS meliputi tugas, input dan hasil output, serta prescriptive guidance yang diperlukan untuk rincian analisis, desain, implementasi, dan deployment of services, komponen, dan flow yang dibutuhkan untuk membangun lingkungan SOA kuat dan dapat digunakan kembali. Metode SOA dalam SOMA meliputi tujuh fase utama ditunjukkan pada Gambar 2.1. Fractal phases menjelaskan kapabilitas yang dapat disesuaikan dengan kebutuhan dalam berbagai situasi. SOMA mengaplikasikan metode komponen dengan cara rekursif kepada dirinya sendiri dalam rilis kecil atau siklus iterasi, dan juga fokus pada pengelolaan resiko teknis dan menghasilkan perangkat lunak yang berguna secara bisnis.) Realisasinya, sebagai contoh pengembangan semua tahap. Tidak ada urutan yang baku. Dalam fractal model, fase akan terdiri dari kapabilitas yang mungkin dipergunakan oleh fase lainnya. SOMA memberikan dukungan dan hubungan terhadap dua aspek utama pengelolaan: desain-waktu dan tata olah runtime.
2.4 Fractal Model untuk Pengembangan Perangkat Lunak
SOMA terdiri dari beberapa pola yang mewakili kemampuan teknik untuk diterapkan ke dalam metode. Setiap isi pola dijalankan atau diterapkan ke dalam semua tahap dalam SOMA dengan tingkat elaborasi dan presisi yang berbeda. Sebagai salah satu contoh, dengan membuat paparan keputusan berdasarkan pada informasi yang kita tahu tentang services selama identifikasi dan kemudian kita gabungkan dan sempurnakan paparan keputusan di fase spesifikasi ketika kita tahu lebih banyak tentang persyaratan nonfunctional dari services. Contoh kedua adalah dengan menganalisa aset yang ada ke dalam fase identifikasi untuk mengidentifikasi sistem serta fungsi sistem yang dapat dimanfaatkan dalam pemberntukan services, serta diperluas lebih lanjut mengenai analisis dalam fase spesifikasi untuk mengidentifikasi komponen-komponen yang ada dan objek dan operasi yang dapat dipergunakan kembali untuk mewujudkan services. Dan sebagai contoh ketiga, model dibuat berdasarkan dependensi antar services yang didefinisikan ke dalam portofolio services dimana selanjutnya dependensi antar services dengan komponen dan fisik sistem diuraikan dan diidentifikasi untuk mewujudkan services.
Gambar 2.1 Fractral Model Development Software (A. Arsanjani, 2008, p382)
Prinsip dari pengembangan perangkat lunak fraktal adalah iterasi berturut-turut. Konsep siklus pengembangan iteratif dan incremental kehidupan telah ada untuk waktu yang lama. Fokus pada prioritas dan mitigation faktor risiko dalam rangka menjamin kualitas produk dari solusi. Ini berakar dalam model spiral pengembangan perangkat lunak oleh Boehm. Iterasi yang berurutan dihubungkan dengan gagasan evolusi services dan menyiratkan fokus tidak hanya pada risiko yang terkait dengan implementasi, tetapi juga dengan dependensi yang terkait dengan portofolio services sebagai evolusi services dalam lifecycle.
Siklus SOMA mengilustrasikan urutan proses dalam pelaksanaan metode SOMA dengan business proses yang ada.
Gambar 2.2 SOMA Lifecycle (A. Arsanjani, 2008, p383)
2.5.1 SOMA Step 1 : Business Modeling dan Transformasi
Tahapan pertama dari metodologi SOMA ini, kondisi proses bisnis sekarang dimodelkan, simulasi, dan dioptimalkan, dan area fokus transformasi diidentifikasi yang akan mendorong serangkaian proyek selanjutnya menggunakan serangkaian tahapan yang ditunjukkan pada Gambar 2.2 dimana hasilnya akan membentuk proses bisnis baru yang merupakan hasil dari Business Process Reengineering.
Menurut Michael R dan Boris L (Applied SOA) Business process modeling dapat dilakukan dengan penggunaan Value Chain, process diagram dan use case
terdapat pada sub bab ini. Untuk pemilihan prioritas dari business component, IBM (2005) merekomendasikan dapat menggunakan Component Business Model yang dijelaskan pada sub bab 2.5.1.1.
2.5.1.1Component Business Model
Komponen model bisnis menawarkan pendekatan yang terbukti mengarahkan secara fokus baik secara internal maupun eksternal. Secara internal, komponen membantu perusahaan-perusahaan memikirkan kembali pengaruh yang dapat terjadi dengan aset dan kapabilitasnya sendiri. Secara eksternal, komponen membantu perusahaan untuk mendokumentasikan kapabilitas secara spesifik dimana tidak dapat terbentuk dengan sendirinya. Ini adalah komponen industri tertentu dimana perusahaan tidak dapat menciptakan sendiri (Misalnya perusahaan dapat membuatnya dengan bantuan perusahaan eksternal atau organisasi publik). Menggabungkan jenis spesialisasi memungkinkan perusahaan untuk mendefinisikan kembali posisi kompetitif mereka dalam menghadapi perubahan besar dalam industrinya, sementara secara bersamaan mendapatkan keuntungan persaingan secara skala, fleksibilitas dan efisiensi. CBM memungkinkan perusahaan untuk mengevaluasi tujuan dan strategi perusahaan untuk mengambil keuntungan secara simultan dari internal dan eksternal spesialisasi. Tanpa meningkatnya kompleksitas, model ini memungkinkan organisasi untuk memperluas dan berkembang sekaligus mengurangi risiko, mendorong kinerja bisnis,
meningkatkan produktivitas, mengendalikan biaya dan meningkatkan efisiensi modal dan prediktabilitas keuangan.
Gambar 2.3 Component Business Diagram (George Pohle, 2005, p7)
2.5.1.2Use Case Diagram
Menurut Whitten et al. (2004, p271), use case diagram adalah diagram yang menggambarkan interaksi antara system, external system dan user. Dengan kata lain, digram ini menjelaskan siapa yang akan menggunakan sistem tersebut dan bagaimana cara user tersebut berinteraksi dengan sistem.
Gambar 2.4 Use Case Diagram (Joseph Schmuller, 1999, p385)
Menurut Michael, R. (2008, p125), value chain pertama kali dipopulerkan oleh Michael Porter dan diagram ini biasanya digunakan untuk menggambarkan proses bisnis utama dari suatu organisasi dan manajemen bisnis perusahaan yang terbagi menjadi dua bagian yaitu aktivitas utama dan aktivitas pendukung.
Gambar 2.5 Porter’s Diagram of Value Chain (Michael, R., 2008, p125)
2.5.1.4Process Diagram
Process Diagram digunakan untuk menggambarkan satu tingkat lebih detail dari proses bisnis utama dimana user dan proses dibuat detail untuk satu alur proses pekerjaan dan kemungkinan yang dapat terjadi. Skenario yang terjadi tersebut yang menggambarkan satuan proses bisnis dari suatu bagian kegiatan. Contoh process diagram yaitu sebagai berikut :
Gambar 2.6 Process Diagram (R. Mike, 2008, p510)
2.5.2 SOMA Step 2 : Manajemen Solusi
Tahapan kedua dari metodologi SOMA ini, solusi SOA biasanya mencakup beberapa jenis solusi di dalamnya. Hal ini karenakan services diidentifikasi dan ditetapkan selama fase awal SOMA yang dapat direalisasikan dalam fase berikutnya SOMA dalam skenario yang berbeda, seperti pengembangan secara kustomisasi, legacy integration dan transformasi, serta integrasi paket aplikasi.
SOMA dirancang untuk mendukung solusi SOA dalam mengatur kegiatan dan bimbingan yang khusus untuk implementasi setiap jenis solusi di atas. Dalam metode SOMA, berisi metode umum untuk semua jenis solusi SOA yang dipisahkan dari konten metode variabel dimana bergantung pada jenis solusi yang spesifik. Metode variabel konten yang spesifik untuk masing-masing jenis didefinisikan dan externalized sebagai template metode yang disebut solution template. Pada saat
realisasi keputusan untuk pembuatan services biasanya menemukan pilihan jenis solusi yang dibutuhkan untuk membangun solusi SOA bagi klien. Kegiatan dan tugas dari solution template yang terpilih dimasukkan ke dalam poin ekstensi standar pada metode SOMA untuk menyediakan suatu proses yang komprehensif untuk proses pengabungan dan realisasi. Secara keseluruhan tahapan kedua ini terdiri dari tiga bagian yaitu pembentukan project management activities, pemilihan solution template, dan diskusi pemilihan metode untuk dipergunakan.
2.5.3 SOMA Step 3 : Identifikasi
Tahapan ketiga dari metodologi SOMA ini, berkaitan dengan identifikasi dari tiga fundamental dasar SOA: services, components, dan flows. Praktek terbaiknya adalah dengan menggunakan seperangkat teknik identifikasi services yang saling melengkapi. Mengandalkan suatu teknik tertentu cenderung menghasilkan serangkaian services yang tidak lengkap. Informasi diawal sangat penting dalam pengembangan lifecycle, sering kali menjadi solusi atas pembiayaan yang lebih besar pada service lifecycle nanti dimana juga memerlukan upaya yang lebih besar pada
service refactoring. Selain itu, ini sering mengarah kepada kegagalan dalam
mengidentifikasi dependensi antar servis diawal, yang berdampak pada perencanaan realisasi dan penyelesaian proyek.
Rekomendasinya adalah dengan mulai dari penyelarasan services dengan tujuan bisnis, yang disebut dengan Goal Service Modeling (GSM). Hal ini sejalan antara eksekusi IT dengan business drivers, imperatif, dan tujuan yang sama halnya
dengan pemantauan dan pengelolaan ruang lingkup pemodelan proses bisnis lebih lanjut dan analisis aset.
Tahap identifikasi SOMA adalah proses identifikasi calon services dan menciptakan portofolio services bisnis-blok services TI yang secara kolektif mendukung proses bisnis dan tujuan organisasi. Hal ini dilakukan melalui proses penilaian fungsi yang ada untuk melihat apakah dapat ditempatkan dalam pemodelan services, dan dengan menentukan kapabilitas IT yang hilang dimana akan diperlukan untuk mendukung penyelarasan strategi bisnis, tujuan, dan proses.
Gambar 2.7 Goal Service Modelling (A. Arsanjani, 2008, p386)
2.5.4 SOMA Step 4 : Spesifikasi
Tahapan keempat dari metodologi SOMA ini, SOA dirancang. Rancangan tingkat tinggi sama halnya dengan bagian-bagian penting dari rincian desain komponen service diselesaikan dalam fase ini. Selama fase spesifikasi, pemanfaatkan aset yang ada dan penggabungan services, flows, dan komponen dari tahap identifikasi secara iteratif dan inkremental untuk membantu pencapaian realisasi
keputusan. Model services akan dibahas lebih lanjut dalam hal dependensi antara services, flows dan komposisi, event, peraturan dan kebijakan, operations, dan pesan.
Dalam melakukan spesifikasi, diperlukan fokus pada desain pesan services yang meliputi input, output, dan pesan kesalahan. Untuk menghilangkan beberapa transformasi data pada lapisan services, praktik terbaiknya adalah dengan menggunakan model pesan umum yang disetujui semua pihak. Model ini mendefinisikan aliran pesan dalam lapisan services. Dalam canonical message model, pemilihan format pesan (misalnya, Extensible Markup Language atau record fixed-length) dan pendefinisian set tipe, elemen, dan atribut yang mewakili entitas bisnis dan atribut bisnis masing – masing pesan. Jenis pesan yang digunakan sebagai pembatas untuk input, output, dan pesan kesalahan untuk services. Spesifikasi model services dan analisa subsystem secara sederhana dibentuk ke dalam Domain Model.
Refactoring dari aset dan kode yang ada sebagai persiapan untuk membuat keputusan tentang bagaimana realisasi services yang diberikan harus dengan pemikiran yang cermat dan matang. Analisis antarmuka sistem dan parameter masukan dan keluaran dari sistem yang ada serta pemetaan yang baik dan terarah pada services untuk transaksi aplikasi tertentu atau proses batch. Pemetaan menyimpulkan suatu rangkaian potensi realisasi keputusan untuk SOA tersebut. Pemanfaatan aset yang ada melalui refactoring dan pemetaan ke services adalah aspek kunci dari orientasi services. Sebagai contoh, diperlukan identifikasi duplikasi kode, kode yang tidak terstruktur, dan kode yang tidak terpakai sebelum
dirasionalisasi dan enkapsulasi fungsionalitas yang terpapar sebagai services bersama antar channels.
Gambar 2.8 Domain Model (Craig Larman, 2002, p129)
2.5.5 SOMA Step 5 : Realisasi
Tahapan kelima dari metodologi SOMA ini memerlukan validasi keputusan realisasi dengan mengeksplorasi kelayakan teknis yang bertujuan untuk melaksanakan keputusan arsitektur dan faktor risiko tertinggi proyek melalui prototipe extensible yang dirancang dan dikembangkan sebelumnya. Selection awal dikembangkan dan instantiation pola merupakan dasar untuk realisasi SOA yang berhasil dan berulang. Pemilihan kategori pola yang sesuai untuk menangani beberapa masalah domain termasuk pola pelayanan informasi untuk realisasi
informasi, Enterprise Service Bus (ESB) pola untuk skenario integrasi, dan pola aturan untuk realisasi aturan. Tahapan pengambilan keputusan dan proses percobaan dapat disederhanakan ke dalam tahapan prototyping, di samping itu detail layer SOA tergambarkan lewat SOA Reference Architecture.
2.5.6 SOMA Step 6 : Implementasi
Tahapan keenam dari metodologi SOMA ini, mulai dilakukan pembentukan servis – servis yang sudah didefine sebelumnya dan semua servis dinaikkan ke tahap testing dimana unit test yang bertugas seperti Quality Control / Quality Assurance
dan Developer melakukan testing terhadap servis yang ada. Tidak dilupakan untuk
testing sistem integrasi dengan pihak luar jika ada dan sistem secara keseluruhan dapat dipastikan berjalan lancar dimana dapat digabungkan dalam tahapan Unit Testing.
2.5.7 SOMA Step 7 : Deployment, Monitoring dan Management
Tahapan ketujuh dari metodologi SOMA ini, mulai dilakukan deployment terhadap semua services ke tingkat production setelah dilakukan application acceptance test dimana user melakukan testing secara keseluruhan dan memberikan tanda bahwa proses sistem berjalan benar. Setelah deployment services, perlu dilakukan monitoring akan proses dan perfoma stabilitas sistem.
Web Service merupakan sebuah sistem perangkat lunak yang didesain untuk mendukung interaksi operasi mesin-ke-mesin melalui jaringan. Memiliki antarmuka yang dijelaskan dalam format mesin yang dapat diproses (Web Services Description Language / WSDL). Sistem lain berinteraksi dengan web service dengan cara yang ditentukan oleh deskripsi menggunakan pesan SOAP, biasanya disampaikan menggunakan HTTP dengan serialisasi XML dalam hubungannya dengan standar Web-terkait lainnya. Web Service biasanya menggunakan Extensible Markup Language (XML) pesan yang mengikuti standar SOAP dan telah populer dengan perusahaan tradisional. Dalam sistem seperti itu, sering kali ada deskripsi dapat dibaca oleh mesin operasi yang ditawarkan oleh layanan ditulis dalam Web Services Description Language (WSDL)
2.7 Penggunaan Service Berulang
Penggunaan Berulang merupakan salah satu keuntungan SOA dimana perusahaan dapat menekan biaya yang tidak diperlukan. Penggunaan kembali pola teknik bisa digunakan untuk model driven architecture (MDA), model-driven design (MDD) dan penggunaan dalam dekomposisi model industri.Arsitek akan membentuk business services baru dan melakukan peningkatan pada business services yang ada dengan penggunaan kembali model dan pola yang sudah ada. Pendekatan lainnya disebut "aset analisis yang sudah ada" Analisis aset merupakan suatu pendekatan yang digunakan untuk memeriksa aset seperti aplikasi warisan yang ada dan menentukan leverage untuk mewujudkan fungsi layanan. Ketika transisi ke SOA,
khususnya, ada empat area sistem warisan untuk mempertimbangkan menggunakan kembali dan mengubah yang logika fungsional itu sendiri, aturan bisnis legacy dalam logika fungsional, alur kerja fungsi, dan data antarmuka. Dengan bermigrasi aset warisan ke layanan reuseable, itu akan mengendalikan jumlah besar waktu, tenaga dan biaya yang telah diinvestasikan oleh perusahaan menjadi sesuatu yang reuseable sekarang dan ke masa depan
2.8 Customer Service
Customer Service adalah suatu rangakain kegiatan yang dirancang untuk meningkatkan nilai kepuasan pelanggan yang meliputi tingkat kepercayaan dan informatif. Dari sudut pandang bisnis, Customer Service memberikan pengaruh yang cukup penting dalam meningkatkan pendapatan dari suatu perusahaan atas barang atau jasa yang dijual kepada konsumen.
2.9 Insurance
Asuransi adalah suatu istilah yang digunakan untuk menggambarkan suatu bisnis perlindungan keuangan yang meliputi Jiwa, Property, Kesehatan, dan lain sebagainya. Bentuk perlindungan yang ditawarkan meliputi jaminan ganti rugi atas segala jenis kejadian seperti kematian, kehilangan, kerusakan, sakit dan lain sebagainya dengan syarat adanya jaminan pembayaran premi secara berkala yang dilakukan oleh tertanggung kepada pihak penanggung.
2.10 Life Insurance
Asuransi jiwa atau yang biasa disebut juga dengan polis asuransi jiwa, adalah sebuah bentuk bisnis dimana perusahaan asuransi / penanggung wajib untuk membayar manfaat atas kematian orang yang diasuransikan / tertanggung. Asuransi Jiwa diberikan untuk perorangan maupun kumpulan dan diberikan daman bentuk polis. Asuransi Jiwa terbagi ke dalam 3 jenis :
a. Asuransi Jiwa Berjangka
Asuransi Jiwa Berjangka memberikan manfaat kematian jika tertanggung meninggal dalam suatu jangka waktu tertentu.
b. Asuransi Jiwa Tetap (Seumur Hidup)
Asuransi Jiwa Tetap memberikan pertanggungan asuransi jiwa seumur hidup bagi tertanggung dan juga memiliki unsur tabungan. Sejalan dengan premi yang dibayarkan untuk polis ini, maka jumlah tabungan terakumulasi – disebut nilai tunai polis yang terkumpul secara bertahap.
c. Asuransi Jiwa Dwiguna
Asuransi jiwa Dwiguna memberikan mafaat polis yang dibayar pada saat tertanggung meninggal atau pada tanggal yang ditentukan jika tertanggung masih hidup sampai dengan tanggal tersebut.
