Revisi Tugas UAS SOA.docx

8/10/2019 Revisi Tugas UAS SOA.docx

1/43

Tugas UAS

INTEGRASI DAN MIGRASI SISTEM

SOA (Service Oriented Architecture)

Oleh :

Nuria Agustin (1204505027)

Ni Kadek Rahayu Widya Utami (1204505043)

Ni Wayan Sri Lestari (1204505046)

JURUSAN TEKNOLOGI INFORMASI

FAKULTAS TEKNIK UNIVERSITAS UDAYANA

2014


2/43

A. Pengantar

Service Oriented Architecture (SOA) merupakan paradigma arsitektur yang

sangat populer untuk merancang dan mengembangkan sistem terdistribusi. Solusi SOA

telah diciptakan untuk memenuhi tujuan bisnis yang mencakup integrasi yang mudah

dan fleksibel dengan sistem warisan, proses bisnis yang efisien, mengurangi biaya,

layanan inovatif untuk pelanggan, dan adaptasi lincah dan reaksi terhadap peluang dan

ancaman yang kompetitif

Salah satu prinsip-prinsip rekayasa perangkat lunak yang paling berharga

adalah untuk memperkenalkan poin pemeriksaan ke dalam siklus hidup perangkat

lunak. Evaluasi arsitektur perangkat lunak adalah titik pemeriksaan sangat penting,

karena arsitektur adalah jembatan antara tujuan bisnis dan sistem perangkat lunak.

Memilih dan merancang arsitektur yang memenuhi persyaratan atribut kualitas

fungsional serta (misalnya, ketersediaan, keamanan, dan kinerja) sangat penting untuk

keberhasilan sistem. Keputusan arsitektur memiliki efek mendalam dan luas pada

tahap pengembangan hilir. Evaluasi awal persyaratan dan arsitektur menghemat waktu

dan uang, karena memperbaiki cacat setelah kode ini menerjunkan setidaknya tiga kali

lebih mahal [McConnell 2001]

Service Oriented Architecture (SOA) adalah pendekatan arsitektur untuk

membangun aplikasi bisnis yang diatur untuk memberikan tingkat yang didefinisikan

dengan pelayanan dan menghubungkan proses bisnis secara bersama-sama. Definisi

diatas menjabarkan bahwa SOA adalah sebuah konsep arsitektur yang penerapannya

dilakukan selama fase desain awal dari suatu siklus pengembangan sistem.

Bila menggunakan pendekatan SOA, aplikasi bisnis dipandang sebagai

seperangkat komponen yang dapat meningkatkan tingkat abstraksi.. Interaksi antara

komponen ini sederhana, sehingga salah satu komponen mengirimkan permintaan ke

satu sama lain, dan yang terakhir menjawab kembali dengan data yang diminta atau

berupa tindakan lain.

Komponen sebelumnya digabungkan menjadi subsistem yang berinteraksi satu

sama lain atau dengan pengguna akhir agar dapat memberikan layanan dengan nilai


3/43

bisnis tertentu, seperti cek duplikat produk atau menghitung efek perubahan yang

fungsi bisnis tingkat yang lebih tinggi bagi organisasi.

Sumber :

http://www.secc.org.eg/recocape/Documents/SECC_Tutorials_A%20Quick%20Introd

uction%20to%20SOA.pdf

www.sei.cmu.edu/reports/07tr015.pdf

B. Apa itu SOA?

Ada banyak definisi SOA tapi tidak ada yang diterima secara universal. Apa

pengertian SOA yang bisa diterima secara umum, jawabannya adalah sebuah gagasan

dari pelayanan . SOA adalah sebuah layanan yang:

1. mandiri. Layanan ini sangat mempunyai modular tinggi dan dapat secara

mandiri dikerahkan.

2. Komponen terdistribusi. Layanan ini tersedia melalui jaringan dan dapat

diakses melalui nama atau locator selain alamat jaringan mutlak.

3. Memiliki antarmuka yang sudah di-publish. Pengguna layanan hanya perlu

melihat antarmuka dan dapat mengtehaui rincian implementasi.

4. Menekankan interoperabilitas. Pengguna jasa dan penyedia dapat

menggunakan bahasa implementasi yang berbeda dan platform.

5. Mempunyai sifat discoverable. Sebuah layanan direktori khusus

memungkinkan layanan untuk didaftarkan, sehingga pengguna dapat

mencarinya.

6. Batasnya dinamis. Seorang pengguna jasa tidak perlu memiliki implementasi

layanan yang tersedia pada waktu pembangunan; layanan berada dan dibatasi

runtime.

Karakteristik ini menjelaskan layanan yang ideal. Pada kenyataannya, layanan

diimplementasikan dalam layanan sistem berorientasi kekurangan atau bersantai

beberapa karakteristik ini, seperti menjadi mudah ditemukan dan batasnya dinamis
http://www.secc.org.eg/recocape/Documents/SECC_Tutorials_A%20Quick%20Introduction%20to%20SOA.pdfhttp://www.secc.org.eg/recocape/Documents/SECC_Tutorials_A%20Quick%20Introduction%20to%20SOA.pdfhttp://www.secc.org.eg/recocape/Documents/SECC_Tutorials_A%20Quick%20Introduction%20to%20SOA.pdfhttp://www.secc.org.eg/recocape/Documents/SECC_Tutorials_A%20Quick%20Introduction%20to%20SOA.pdfhttp://www.secc.org.eg/recocape/Documents/SECC_Tutorials_A%20Quick%20Introduction%20to%20SOA.pdf


4/43

Definsi SOA sebagai gaya arsitektur di mana sistem terdiri dari pengguna jasa

dan penyedia jasa. Sebuah gaya arsitektur mendefinisikan komponen kosakata dan

jenis konektor, dan kendala pada bagaimana mereka dapat dikombinasikan [Shaw

1996]. Untuk SOA, jenis komponen dasar pengguna jasa dan penyedia jasa. Jenis

komponen tambahan, seperti layanan bus perusahaan (ESB) dan dapat digunakan

layanan direktori,. Jenis konektor SOA termasuk panggilan sinkron dan asynchronous

menggunakan SOAP, http, dan infrastruktur messaging. Banyak properti dapat

ditugaskan untuk komponen jenis ini dan konektor, tetapi mereka biasanya spesifik

untuk setiap teknologi implementasi. Beberapa kendala yang berlaku untuk gaya

arsitektur SOA

a.

Pengguna Layanan mengirim permintaan ke penyedia layanan.

b. Sebuah penyedia layanan juga dapat menjadi pengguna layanan.

c. Seorang pengguna layanan secara dinamis dapat menemukan penyedia layanan

dalam direktori layanan.

d. Sebuah ESB dapat memediasi interaksi antara pengguna jasa dan penyedia

layanan.

Sumber : www.sei.cmu.edu/reports/07tr015.pdf

C. Deskripsi SOA

SOA bisa digambarkan dalam tiga lapisan seperti yang terlihat pada gambar di

bawah 1 dibawah ini:

Gambar 1. Deskripsi SOA dengan 3 layer


5/43

Di satu sisi kita memiliki provider dan di sisi lain kita memiliki konsumen,

dipisahkan oleh sebuah jembatan di mana kedua belah pihak berkomunikasi.

Konsumen menggunakan sejumlah aplikasi yang diperlukan untuk itu bisnis dan

penyedia menggunakan Komponen yang menyediakan aplikasi ini dengan informasi.

Mereka berkomunikasi melalui serangkaian Layanan menggunakan arsitektur yang

umum.

Sumber :http://stackoverflow.com/questions/2026523/what-is-soa-in-plain-english

D. Analogi SOA

Bayangkan sebuah rumah pada suatu negara, yang dalam banyak hal

merupakan bagian dari komunitas yang lebih luas, seperti kota besar atau kota kecil.

Kota ini memiliki sistem yang kompleks untuk menyediakan air dan listrik,

penanganan sanitasi, menyediakan transportasi dan utilitas lainnya. Rumah adalah

konsumen dalam model ini, kota (atau masyarakat) adalah penyedia dan pipa saluran

pembuangan, kabel listrik, serat optik dan lain-lain adalah infrastruktur di mana

mereka berkomunikasi.

Model ini bisa dibandingkan dengan SOA. Orang-orang di rumah

menggunakan sejumlah "aplikasi" berbeda seperti radiator, komputer, toilet, lampu,

bathtub dan lain-lain, namun aplikasi ini tidak peduli bagaimana kota menghasilkan

air, menciptakan listrik atau menangani limbah selama aplikasi ini bekerja. Komponen

kota berupa generator, pompa air dan sanitasi daerah. Kota menyediakan semua

kebutuhan rumah ini tapi itu terserah ke rumah untuk menggunakannya dengan cara

apa yang cocok untuk mereka sendiri.

Sumber :http://stackoverflow.com/questions/2026523/what-is-soa-in-plain-english

E.

Mengapa menggunakan SOA?

Ruang masalah dapat dikategorikan dengan investasi TI masa lalu di daerah

eProcurement, eSourcing, Supply Chain Management, Customer Relationship

Management (CRM) dan komputasi internet pada umumnya. Semua investasi ini

dibuat dalam silo. Seiring dengan pertumbuhan inkremental dalam sistem ini untuk
http://stackoverflow.com/questions/2026523/what-is-soa-in-plain-englishhttp://stackoverflow.com/questions/2026523/what-is-soa-in-plain-englishhttp://stackoverflow.com/questions/2026523/what-is-soa-in-plain-englishhttp://stackoverflow.com/questions/2026523/what-is-soa-in-plain-english


6/43

memenuhi jangka pendek (taktis) persyaratan, keputusan yang dibuat dalam ruang ini

melukai jangka panjang kelangsungan hidup aplikasi dan infrastruktur. Tiga

pendorong utama untuk menerapkan pendekatan SOA adalah:

1. Pengurangan biaya:

Dicapai dengan cara layanan berbicara satu sama lain. Pengaruh biaya langsung

disampaikan melalui peningkatan produktivitas operasi, pilihan sourcing yang

efektif, dan kemampuan ditingkatkan secara signifikan untuk menggeser biaya

berkelanjutan untuk model variabel.

2. Memberikan solusi TI yang lebih cepat dan lebih cerdas

Sebuah pendekatan berbasis standar akan memungkinkan organisasi untuk

terhubung dan berbagi informasi dan proses bisnis lebih cepat dan lebih mudah

dari sebelumnya. Produktivitas pengiriman TI nyata ditingkatkan melalui

penyederhanaan peran pengembang dengan menyediakan kerangka kerja standar

dan interface. Rentang waktu pengiriman telah secara drastis dikurangi dengan

mengurangi beban integrasi fungsi individual, dan menerapkan teknik pengiriman

dipercepat dalam lingkungan.

3. Memaksimalkan laba atas investasi

Web Services membuka jalan bagi bisnis baru peluang dengan memungkinkan

model bisnis baru. Web Services menyajikan kemampuan untuk mengukur nilai

dan diskrit kembali jauh berbeda dari metode fungsional-manfaat tradisional. Khas

Total Cost of Ownership (TCO) model tidak memperhitungkan nilai seumur hidup

yang dihasilkan oleh investasi sejarah. Centric melihat biaya ini menghancurkan

banyak kesempatan untuk mengeksploitasi ini investasi masa lalu dan sebagian

besar perusahaan akhirnya redundansi bangunan dalam arsitektur mereka, bukan

karena kebutuhan, tetapi kebutuhan yang dirasakan. Organisasi-organisasi yang

sama fokus proposisi nilai investasi TI mereka pada portofolio aplikasi, seimbang

dengan overhead infrastruktur. Pendekatan berdasarkan Web Services

memperhitungkan kontribusi seumur hidup warisan investasi TI dan

mempromosikan evolusi dari investasi ini bukan pengganti yang direncanakan.


7/43

Layanan SOA / Web fundamental mengubah cara perusahaan perangkat lunak

yang dikembangkan dan digunakan. SOA telah berkembang di mana aplikasi

baru tidak akan dikembangkan dengan menggunakan pendekatan monolitik,

melainkan menjadi model virtual on-demand eksekusi yang melanggar

hambatan ekonomi dan teknologi saat ini disebabkan oleh pendekatan

tradisional.

Software sebagai sebuah layanan telah menjadi merasuk sebagai model untuk

perusahaan ke depan untuk merampingkan operasi, biaya kepemilikan yang

lebih rendah dan memberikan diferensiasi kompetitif di pasar. Web Services

menawarkan kesempatan yang layak bagi perusahaan untuk mendorong biaya

yang signifikan dari akuisisi perangkat lunak, bereaksi terhadap kondisi pasar

dan melakukan transaksi cepat berubah dengan mitra bisnis di akan. Longgar

digabungkan, arsitektur berbasis standar adalah salah satu pendekatan untuk

komputasi terdistribusi yang akan memungkinkan sumber daya perangkat

lunak yang tersedia pada jaringan untuk dimanfaatkan. Aplikasi yang

memisahkan proses bisnis, aturan presentasi, aturan bisnis dan akses data

menjadi terpisah lapisan longgar ditambah tidak hanya akan membantu dalam

pembangunan perangkat lunak yang lebih baik tetapi juga membuatnya lebih

mudah beradaptasi terhadap perubahan di masa depan.

SOA akan memungkinkan untuk menggabungkan fungsi-fungsi yang ada

dengan upaya pengembangan baru, yang memungkinkan pembuatan aplikasi

komposit. Memanfaatkan apa yang berhasil menurunkan risiko dalam proyek

pengembangan perangkat lunak. Dengan menggunakan kembali fungsi yang

ada, itu mengarah ke kiriman cepat dan kualitas pengiriman yang lebih baik.

Loose coupling membantu melestarikan masa depan dengan memungkinkan

bagian untuk mengubah dengan kecepatan mereka sendiri tanpa risiko terkait

dengan migrasi mahal menggunakan pendekatan monolitik. SOA

memungkinkan pengguna bisnis untuk fokus pada masalah bisnis di tangan

tanpa khawatir tentang kendala teknis. Bagi individu yang mengembangkan

solusi, SOA membantu dengan cara sebagai berikut:


8/43

a. Analis bisnis fokus pada tanggung jawab yang lebih tinggi dalam siklus

pengembangan sementara meningkatkan pengetahuan mereka sendiri dari

domain bisnis.

b. Memisahkan fungsi menjadi layanan berbasis komponen yang dapat

ditangani oleh beberapa tim yang memungkinkan pembangunan paralel.

c. Jaminan kualitas dan unit testing menjadi lebih efisien; kesalahan dapat

dideteksi lebih awal dalam siklus pengembangan

d. Pengembangan tim dapat menyimpang dari persyaratan awal tanpa

menimbulkan risiko tambahan.

e. Komponen dalam arsitektur dapat membantu dalam menjadi aset yang

dapat digunakan kembali untuk menghindari menciptakan kembali roda

f. Dekomposisi fungsional dari layanan dan komponen yang mendasari

mereka sehubungan dengan proses bisnis membantu melestarikan

fleksibilitas, pemeliharaan masa depan dan memudahkan upaya integrasi.

g. Aturan keamanan diimplementasikan pada tingkat layanan dan dapat

memecahkan banyak pertimbangan keamanan dalam perusahaan

Sumber :http://docs.jboss.org/jbossesb/whitepapers/WhyESB.pdf

F. SOA dan Web Service

Meskipun banyak yang telah ditulis tentang SOA dan layanan Web, masih ada

beberapa kebingungan antara dua istilah di kalangan pengembang perangkat lunak.

SOA adalah sebuah gaya arsitektur, sedangkan layanan Web adalah teknologi yang

dapat digunakan untuk mengimplementasikan SOA. Teknologi layanan Web terdiri

dari beberapa standar yang dipublikasikan, yang paling penting adalah SOAP dan

WSDL. Teknologi lainnya juga dapat dipertimbangkan teknologi untuk menerapkan

SOA, seperti CORBA. Meskipun tidak ada teknologi saat ini sepenuhnya memenuhi

visi dan tujuan SOA seperti yang didefinisikan oleh sebagian besar penulis, mereka

masih disebut sebagai teknologi SOA. Hubungan antara SOA dan teknologi SOA

diwakili dalam Gambar 2. Sebagian besar informasi teknis dalam laporan ini terkait
http://docs.jboss.org/jbossesb/whitepapers/WhyESB.pdfhttp://docs.jboss.org/jbossesb/whitepapers/WhyESB.pdfhttp://docs.jboss.org/jbossesb/whitepapers/WhyESB.pdfhttp://docs.jboss.org/jbossesb/whitepapers/WhyESB.pdf


9/43

dengan teknologi layanan Web, karena umumnya digunakan dalam implementasi SOA

hari ini.

Gambar 2. SOA dan Teknologi SOA


G. SOA Driver

Dalam organisasi besar, tipe berikut dari organisasi, bisnis, dan teknologi

mendorong keinginan untuk menuai keuntungan dari SOA:

1. integrasi dengan sistem warisan

2. penggabungan perusahaan

3. penataan kembali tanggung jawab melalui reorganisasi bisnis

4. mengubah kemitraan bisnis (misalnya, hubungan dengan pemasok dan

pelanggan)

5. modernisasi sistem usang karena alasan keuangan, fungsional, atau teknis

6. perolehan atau dekomisioning produk perangkat lunak

7. kekuatan sosial politik terkait dengan atau independen dari driver yang dikutip

di atas

Kekuatan ini menyebabkan SOA memimpin karena mereka melibatkan upaya

integrasi aplikasi yang signifikan. Ketika sebuah aplikasi terintegrasi berubah,

modifikasi menjadi beresiko dan mahal untuk aplikasi lain yang sering dibutuhkan.


10/43

Sebagai interkoneksi sistem menjadi lebih luas dan laju bisnis dan proses perubahan

meningkat, ketidakmampuan untuk mengintegrasikan secara efisien dapat

menyebabkan kegagalan usaha bisnis. SOA nampaknya ideal untuk situasi ini.

Sistem teknologi Distributed masa lalu, seperti CORBA, tidak mencapai adopsi

luas karena sebagian standar yang tidak banyak didukung oleh vendor CORBA.

Terlebih teknologi SOA baru-baru ini, seperti layanan Web, tampaknya baik dari awal

ketika mereka mulai diadopsi secara luas. Satu penjelasan yang mungkin untuk

perubahan sikap adalah bahwa kebutuhan untuk beroperasi dengan aplikasi di luar

lingkup organisasi yang diberikan menjadi lebih penting. Gagasan pengiriman

Software as a Service(SaaS) ini dimaksudkan untuk memungkinkan organisasi untuk

selektif membeli, mencampur, cocok, dan mengubah sumber layanan untuk

keuntungan bisnis mereka. Tujuan dari pendekatan berorientasi-layanan untuk

memungkinkan komposisi layanan baru atau yang sudah ada dan aplikasi dalam

lingkungan teknologi heterogen. Namun, banyak dari masalah dan kekhawatiran yang

dihadapi dan ditangani dalam sistem terdistribusi desain selama 20 sampai 30 tahun

terakhir juga langsung mendaftar ke SOA. Kekurangan yang signifikan dari

pendekatan integrasi terkait dengan entropi independen (atau gerakan gangguan) dari

aplikasi yang terhubung tapi dikelola secara terpisah. Karena banyak masalah teknis

tetap, evaluasi yang cermat dari keputusan desain sistem adalah penting untuk

memastikan bahwa solusi SOA dapat mencapai manfaat yang diiklankan oleh para

pendukung pendekatan SOA.


H. Komponen SOA

Gambar 1 dibawah ini menggambarkan komponen utama dari solusi berbasis

SOA.


11/43

Gambar 3.Komponen Utama Pada Sistem SOA

Berikut ini, secara singkat akan didefinisikan masing-masing komponen yang

ditunjukkan pada Gambar 1 :

1) Enterprise Service BUS (ESB) : Hal ini didefinisikan sebagai satu set

komponen software yang mengelola pesan routing dan transmisi dari

komponen satu software ke software yang lain. Hal ini juga bertanggung

jawab untuk menerjemahkan protokol transfer dalam kasus menggunakan

protokol transfer yang berbeda dalam komponen software berkomunikasi.

2) SOA Registry : Menyimpan informasi tentang masing-masing fungsi

layanan dan lokasi.

3) Layanan Broker : Hal ini bertanggung jawab untuk menghubungkan

pemohon layanan ke penyedia layanan dengan bantuan Registry SOA dan

SOA Service Manager. Pemohon akan berkomunikasi dengan broker, dan

kemudian broker akan membuat hubungan antara pemohon dan penyedia

menurut aturan yang dibuat.

4) SOA Service Manager: Ini menjamin kualitas layanan dalam arsitektur

SOA.

5) Proses Bisnis Orkestrasi Manager: Set alat untuk membantu sistem untuk

menghubungkan:


12/43

orang untuk orang

orang untuk proses

proses untuk proses

sumber :



I. Mengapa perlu ada SOA?

Jadi mengapa kita perlu SOA? Jawabannya adalah dalam satu kata kelincahan.

Persyaratan bisnis sering berubah. Departemen TI harus merespon lebih cepat dan

biaya-efektif untuk perubahan tersebut. Dengan arsitektur tradisional, semua

komponen yang dibundel bersama-sama dengan satu sama lain. Jadi, bahkan

perubahan kecil untuk satu komponen akan membutuhkan sejumlah besar komponen

lain dikompilasi ulang dan didistribusikan. Jaminan kualitas (QA) upaya ini juga besar

untuk setiap perubahan kode. Proses pengumpulan persyaratan, desain,

pengembangan, QA, dan penyebaran terlalu panjang bagi perusahaan untuk

menunggu, dan menjadi hambatan yang sebenarnya.

Untuk memperumit masalah lebih lanjut, beberapa proses bisnis tidak lagi statis.Persyaratan berubah secara ad-hoc, dan bisnis harus mampu untuk secara dinamis

menentukan proses sendiri. Sebuah bisnis membutuhkan sistem yang cukup gesit

untuk perusahaan sehari-hari kerja. Ini sangat sulit, jika bukan tidak mungkin, dengan

infrastruktur tradisional dan sistem yang ada.

Unit dasar SOA adalah layanan. Layanan ini sedang membangun blok yang

pengguna bisnis dapat digunakan untuk menentukan proses mereka sendiri. Layanan

dirancang dan dilaksanakan sehingga mereka dapat melayani tujuan yang berbeda atau

proses, dan bukan hanya orang-orang tertentu. Tidak peduli apa proses baru

membutuhkan usaha untuk membangun atau apa proses yang ada dengan kebutuhan

bisnis perlu memodifikasi, pengguna bisnis harus selalu dapat menggunakan blok

layanan yang ada, agar dapat bersaing dengan orang lain sesuai dengan kondisi

pemasaran saat ini. Juga, jika perlu, beberapa blok layanan baru dapat digunakan.
http://www.secc.org.eg/recocape/Documents/SECC_Tutorials_A%20Quick%20Introduction%20to%20SOA.pdfhttp://www.secc.org.eg/recocape/Documents/SECC_Tutorials_A%20Quick%20Introduction%20to%20SOA.pdfhttp://www.secc.org.eg/recocape/Documents/SECC_Tutorials_A%20Quick%20Introduction%20to%20SOA.pdfhttp://www.secc.org.eg/recocape/Documents/SECC_Tutorials_A%20Quick%20Introduction%20to%20SOA.pdf


13/43

Layanan ini juga dirancang dan dilaksanakan sehingga mereka bebas

digabungkan, dan independen satu sama lain. Perubahan untuk satu layanan tidak

mempengaruhi layanan lainnya. Selain itu, penyebaran layanan baru tidak

mempengaruhi layanan yang ada. Hal ini sangat memudahkan manajemen rilis dan

membuat kelincahan mungkin.

Sebagai contoh, layanan GetBalance dapat dirancang untuk mengambil saldo

pinjaman. Ketika peminjam panggilan dalam untuk query status pinjaman tertentu,

layanan GetBalance ini dapat disebut oleh aplikasi yang digunakan oleh perwakilan

layanan pelanggan. Ketika peminjam melakukan pembayaran online, layanan ini juga

dapat dipanggil untuk mendapatkan keseimbangan pinjaman, sehingga peminjam akan

tahu saldo pinjaman nya setelah pembayaran. Namun dalam proses pembayaran

posting, layanan ini masih dapat digunakan untuk menghitung bunga akrual untuk

pinjaman, dengan mengalikan keseimbangan dengan tingkat suku bunga. Bahkan lebih

jauh, proses baru dapat dibuat oleh pengguna bisnis untuk memanfaatkan layanan ini

jika saldo pinjaman harus diambil.

Layanan GetBalance dikembangkan dan digunakan secara independen dari semua

proses di atas. Sebenarnya, layanan ini ada bahkan tanpa mengetahui siapa klien akan

atau bahkan berapa banyak klien akan ada. Semua aplikasi client berkomunikasi

dengan layanan ini melalui antarmuka, dan antarmuka akan tetap stabil setelah berada

di produksi. Jika kita harus mengubah pelaksanaan layanan ini, misalnya dengan

memperbaiki bug, atau mengubah suatu algoritma dalam metode layanan, semua

aplikasi client masih bisa bekerja tanpa perubahan apapun.

Ketika dikombinasikan dengan teknologi lebih matang Business Procces

Management (BPM), SOA memainkan peran yang lebih penting dalam upaya

organisasi untuk mencapai kelincahan. Bisnis pengguna dapat membuat dan mengelola

proses dalam BPM, dan melalui SOA mereka bisa pasang layanan ke salah satu proses.

The front-end aplikasi BPM longgar digabungkan ke back-end sistem SOA.

Kombinasi BPM dan SOA akan memberikan organisasi fleksibilitas yang lebih besar

untuk mencapai kelincahan.

Sumber:http://www.packtpub.com/article/soa-service-oriented-architecture
http://www.packtpub.com/article/soa-service-oriented-architecturehttp://www.packtpub.com/article/soa-service-oriented-architecturehttp://www.packtpub.com/article/soa-service-oriented-architecturehttp://www.packtpub.com/article/soa-service-oriented-architecture


14/43

J. Migrasi ke SOA

Gambar 3 dibawah ini menunjukkan contoh skenario sistem informasi yang dapat

mengambil manfaat dari migrasi ke SOA. Dalam satu organisasi, tiga proses bisnis

yang terpisah menggunakan fungsi yang sama, masing-masing encapsulating itu dalam

sebuah aplikasi. Dalam skenario ini, fungsi login, kemampuan untuk mengubah nama

pengguna, dan kemampuan untuk bertahan itu adalah tugas umum dilaksanakan secara

berlebihan dalam semua tiga proses. Ini adalah situasi yang suboptimal karena

perusahaan telah membayar untuk mengimplementasikan fungsi dasar yang sama tiga

kali

Gambar 4. tigas bisnis proses yang ada pada perusahaan yang mempunyai fungsi

yang sama


15/43

Selain itu, skenario tersebut sangat tidak efisien dan memperkenalkan kompleksitas

pemeliharaan dalam infrastruktur TI. Sebagai contoh, perhatikan sebuah

implementasi di mana keadaan pengguna tidak disinkronisasi di seluruh tiga

proses. Dalam lingkungan ini pengguna mungkin harus ingat multiple login token

username / password dan mengelola perubahan profil mereka di tiga wilayah yang

terpisah. Selain itu, jika seorang manajer ingin untuk menolak akses pengguna ke

semua tiga proses, ada kemungkinan bahwa tiga prosedur yang berbeda akan

diperlukan (satu untuk masing-masing aplikasi). Pekerja TI perusahaan mengelola

sistem seperti itu akan efektif tiga kali lipat mereka kerja dan menghabiskan lebih

banyak untuk perangkat lunak dan perangkat keras sistem.

Dalam skenario yang lebih efisien, tugas umum akan dibagi di semua tiga proses.

Hal ini dapat diimplementasikan dengan decoupling fungsi dari setiap proses atau

aplikasi dan membangun otentikasi pengguna dan aplikasi manajemen mandiri

yang dapat diakses sebagai layanan. Dalam skenario seperti itu, layanan itu sendiri

dapat ditujukan kembali di beberapa proses dan aplikasi dan perusahaan

memilikinya hanya untuk mempertahankan fungsi tersebut dalam satu tempat pada

pusatnya. Ini akan menjadi contoh sederhana dalam praktik Service Oriented

Architecture. Infrastruktur TI yang dihasilkan akan menyerupai Gambar 4.

Gambar 5.tiga proses bisnis repurposingsatu layanan untuk tugas umum.


16/43

Pada gambar 5 tugas account pengguna bersama telah dipisahkan dari setiap proses

dan dilaksanakan dengan cara yang memungkinkan proses-proses lain untuk

memanggil mereka sebagai layanan. Hal ini memungkinkan fungsi bersama untuk

ditujukan kembali di seluruh tiga proses. Layanan Bus memang benar-benar

lingkungan virtual dimana layanan yang dibuat tersedia untuk semua konsumen

potensial. Hal ini biasanya disebut sebagai Enterprise Service Bus (ESB) dan

memiliki koleksi subkomponen khusus termasuk penamaan dan direktori lookup,

registry-repositori, dan antarmuka penyedia layanan (untuk menghubungkan

kemampuan dan mengintegrasikan sistem) serta koleksi standar standar dan

protokol untuk membuat komunikasi mulus di semua perangkat yang terhubung.

Vendor Lanjutan ESB memiliki alat yang dapat agregat layanan ke dalam proses

yang kompleks dan alur kerja.

Dalam contoh sebelumnya dari SOA, komplikasi yang relatif kecil sebagai seluruh

infrastruktur yang ada dalam satu domain. Pada kenyataannya , perusahaan SOA

jauh lebih sulit karena layanan dapat digunakan di beberapa domain kepemilikan.

Untuk membuat kemungkinan berinteraksi mekanisme harus ditampilkan dalam

penyampain yang semantik, dinyatakan dan ditegakkan suatu kebijakan dan

kontrak, kemampuan untuk menggunakan kendala untuk data lewat masuk dan

keluar dari layanan serta ekspresi untuk model perilaku layanan. Kemampuan

untuk memahami baik struktur dan semantik data yang lewat di antara endpoint

layanan penting untuk semua pihak yang terlibat.

Sementara sebagian contoh SOA biasanya ditampilkan sebagai pola interaksi

permintaan-respon, pertukaran yang lebih kuat diperlukan. Selain itu, platform jasa

modern juga membutuhkan fleksibilitas untuk mendukung pola-pola pertukaran

pesan lanjutan

Sumber:

http://www.adobe.com/enterprise/pdfs/Services_Oriented_Architecture_from_Ado

be.pdf


17/43

K. Contoh SOA

Gambar 6. Desain Sistem Menggunakan Pendekatan Desain Konvensional

Untuk menunjukkan ide menggunakan SOA, berikut ini merupakan contoh

sederhana menggunakan SOA. Perusahaan X bekerja di bidang asuransi, memiliki

sistem warisan (lihat gambar 6) yang memungkinkan karyawan perusahaan untuk

melihat dan mengedit data pelanggan dan menghitung berbagai tingkat sesuai

dengan permintaan pelanggan. Karena ekspansi perusahaan dan kebutuhan bisnis

untuk menawarkan layanan baru kepada pelanggan, departemen TI harus

menambahkan fungsi baru untuk sistem. Dengan demikian, tim pengembangan TI

telah ditingkatkan dan menemukan bahwa harus dilakukan tes ulang terhadap

seluruh sistem untuk memastikan fungsi aslinya masih berfungsi normal. Dalam

hal ini, tim pengembangan perlu untuk menguji ulang sistem yang lama dan

menambahkan fungsionalitas baru.


18/43

Jika perusahaan telah menggunakan pendekatan SOA, tim pengembang akan

melihat sistem sebagai set layanan termasuk fungsi lama dan fungsionalitas baru

yang diajukan, seperti yang ditunjukkan pada gambar 6.

Gambar 7. Desain Sistem Menggunakan Pendekatan SOA

Seperti terlihat pada gambar 7, sistem ini menggunakan ESB, layanan registry, dan

sistem warisan dengan antarmuka komunikasi untuk menghubungkan ke ESB.

Sekarang, layanan baru dapat dikembangkan dan dikaitkan dengan ESB tanpa

perlu mengetahui internal dari sistem warisan. Juga, satu set layanan data dapat

digunakan kembali dan dikembangkan dalam rangka untuk mengakses server data

dan membuat fungsi CRUD. Layanan ini akan digunakan oleh sistem lama serta

setiap layanan yang baru dikembangkan. Dalam desain baru ini, pengujian dapat

dilakukan pada layanan baru dan bagian antarmuka hanya dari komponen yang

lama

Sumber :

http://www.secc.org.eg/recocape/Documents/SECC_Tutorials_A%20Quick%20Int

roduction%20to%20SOA.pdf


19/43

L. Pendekatan Arsitektur SOA

Dalam evaluasi arsitektur, kita sering tidak punya waktu untuk melihat semua

elemen arsitektur sistem. Evaluator Arsitektur memahami betapa berbedanya

pendekatan dan pola arsitektur yang mempengaruhi atribut kualitas. Oleh karena itu,

untuk mengevaluasi apakah suatu arsitektur perangkat lunak dapat memenuhi

persyaratan atribut kualitas, kita bisa fokus pada pendekatan arsitektur yang digunakan

dalam sistem. Untuk evaluasi sistem SOA, kita fokus terutama pada integrasi dan

layanan komunikasi pola, daripada yang mendasari arsitektur aplikasi terintegrasi.

Selain desain tradisional sistem terdistribusi kekhawatiran-seperti jaringan komunikasi,

keamanan, manajemen transaksi, penamaan, dan lokasi-pendekatan arsitektur apa yang

berbeda dengan SOA? Bagian ini menjelaskan SOA pendekatan arsitektur umum dan

yang akan muncul menjadi faktor dalam mengevaluasi sebuah SOA.

1. Pendekatan Komunikasi SOA

Setiap interaksi antara pengguna jasa dan penyedia layanan dalam SOA dapat

diimplementasikan secara berbeda. Alternatif implementasi mempengaruhi kualitas

atribut yang penting dari sistem, seperti interoperabilitas dan modifiabilitas. Dalam

solusi layanan Web murni, digunakan protokol SOAP. Namun, arsitek juga dapat

menghindari SOAP dan menggunakan pendekatan yang lebih sederhana, seperti

Reprsentational State Transfer (REST). Pilihan lain adalah dengan menggunakan

sistem pesan, seperti Microsoft MSMQ dan IBM WebSphere MQ (sebelumnya disebut

MQSeries). alternatif dan kekhawatiran ini terkait atribut kualitas dibahas di bawah ini.

Lingkungan SOA mungkin melibatkan campuran alternatif ini bersama dengan

warisan dan milik, protokol komunikasi seperti IIOP, DCOM, DCE, dan SNA/LU6.2.

1.1 SOAP Layanan Berbasis Web

Layanan Web adalah teknologi yang umum digunakan untuk mengimplementasikan

SOA. Antarmuka layanan didefinisikan dalam bahasa WSDL, dan pengguna jasa dan

penyedia layanan berkomunikasi menggunakan protokol SOAP. Dua atribut dalam

antarmuka WSDL, "gaya" dan "digunakan," mendefinisikan komunikasi SOAP antara

pengguna jasa dan penyedia. Atribut style memiliki dua nilai yang mungkin: "RPC"

dan ". Dokumen" Penggunaan atribut mengacu pada data encoding dan memiliki dua


20/43

nilai yang mungkin: ". Literal" "encoded" atau Akibatnya ada empat kemungkinan

kombinasi dari kedua sifat ini. Dua opsi gabungan yang umum dalam praktik adalah

RPC-encodeddan dokumen-literal.

- RPC-EncodedSOAP

Dalam gaya RPC, pesan SOAP setara dengan metode panggilan jarak jauh

berbasis XML. Nama dan jenis setiap argumen adalah bagian dari definisi antarmuka

WSDL. Kumpulan dari permintaan SOAP tentu mengandung unsur yang menunjukkan

nama operasi dan sub-elemen yang sesuai dengan argumen operasi. Encoded atribut

menunjukkan bahwa data serial menggunakan format encoding standar. Format ini

didefinisikan oleh spesifikasi SOAP dan berisi aturan untuk mengkodekan tipe primitif

data, string, dan array. Gambar 8 merupakan interaksi RPC-encoded. Gaya RPC-

encoded. yang populer di tahun-tahun pertama teknologi layanan Web karena model

pemrograman sederhana dan kesamaan antara operasi layanan dan metode objek.

Namun, itu bukan pilihan yang baik, karena masalah interoperabilitas dapat timbul dari

kekurangan dalam spesifikasi SOAP-encoding[Ewald 2002].


21/43

Gambar 8.Interaksi RPC-Encoded

- Dokumen-Literal SOAP

Isi pesan SOAP dalam permintaan gaya dokumen-literal dapat berisi XML

yang berubah-ubah (dokumen bisnis). Definisi WSDL tidak harus menentukan

parameter bernama, dan isi XML dari tubuh pesan tidak mengikuti struktur standar

seperti dalam gaya RPC. Atribut literal menunjukkan bahwa tidak ada format

pengkodean standar yang digunakan-data dalam tubuh SOAP diformat dan

diinterpretasikan dengan menggunakan aturan yang ditetapkan dalam skema XML

yang dibuat oleh pengembang layanan. Skema XML yang mendefinisikan struktur

data permintaan dan respon adalah unsur kunci dalam definisi antarmuka. Gambar 3menunjukkan interaksi dokumen-literal.


22/43

Gambar 9: InteraksiDocument-Literal

Tabel 1 membandingkan pendekatan RPC-encoded dan dokumen-literal terhadap

atribut kualitas yang berbeda, menjelaskan mengapa dokumen-literal saat ini adalah

pendekatan yang paling umum untuk pesan SOAP. Dokumen-literal pendekatan yang

dianjurkan oleh organisasi WS-I. Dalam evaluasi arsitektur, arsitek harus menyadari

perbedaan antara gaya ini. Beberapa toolkit layanan Web masih menggunakan RPC-

encoded sebagai gaya default; Oleh karena itu, penting bahwa pengembang tahu

bagaimana menentukan gaya yang diinginkan saat membuat layanan.

Tabel 1.Perbandingan Pendekatan RPC-encoded dengan Dokumen Literal

Kualitas Atribut RPC-encoded Dokumen literal

Interopabilitas Kurang interoperable karena

ketidakcocokan dalam

SOAP encoding seluruh

platform

lebih interoperable dan

direkomendasikan oleh WS-I

Performance

Dapat menghasilkan kinerja

buruk karena pengolahan

overhead yang diperlukan

untuk mengkodekan muatan

Tidak membutuhkan encoding

biaya overhead

Membutuhkan parsing

DOM

Memungkinkan teknologi

parsing lain (misalnya, SAX)

Modifiability

Dalam teori menghasilkan

modifiability lebih baik

karena antarmuka layanan

yang

lebih dekat dengan

antarmuka bahasa

pemrograman dengan

Biasanya sulit untuk

melaksanakan karena definisi

skema XML dan kode untuk

memproses dan mengubah

dokumen XML biasanya tidak

dibuat secara otomatis


23/43

operasi dan parameter.

Kesamaan ini juga

memungkinkan penggunaan

terjemahan objectto-WSDL

otomatis

Dalam prakteknya, setiap

perubahan pada sintaks dari

operasi membutuhkan

perubahan dalam pengguna

jasa, sehingga

meningkatkan coupling.ion

Menghasilkan coupling

kurang. Ada lebih banyak

fleksibilitas untuk mengubah

dokumen bisnis tanpa

mempengaruhi semua

pengguna layanan.

1.2 REST

REST diusulkan oleh Roy Fielding [Fielding 2000]. Ini menghindari kompleksitas dan

pengolahan overhead protokol layanan Web dengan menggunakan http yang paling

sederhana. Sebagai contoh, mempertimbangkan layanan cuaca yang tersedia untuk

umum dan disediakan oleh http://www.weather.com. Salah satu konsep REST penting

adalah sumber daya, yang merupakan bagian dari informasi yang memiliki pengenal

yang unik (misalnya, uniform resource identifier (URI)). Untuk layanan cuaca, contoh

sumber daya termasuk

cuaca saat ini untuk kode pos 15213

ramalan cuaca untuk besok untuk kota Pittsburgh

ramalan cuaca 10-hari untuk kode pos 15213

rata-rata suhu untuk kota Pittsburgh pada bulan Oktober

Dalam contoh ini, ada tiga jenis sumber: cuaca saat ini, prakiraan cuaca, dan rata-rata

suhu. Kita dapat struktur URL dari sumber daya didasarkan pada tiga jenis. Parameter

dapat diwakili oleh unsur-unsur di jalur hirarkis URL atau [key] = [nilai] pasang. The

URL yang sesuai dengan sumber daya yang kami tercantum di atas termasuk

http://www.weather.com/current/zip/15213


24/43

http://www.weather.com/forecast/tomorrow/city/Pittsburgh

http://www.weather.com/forecast/tenday/zip/15213

http://www.weather.com/avg/city/Pittsburgh?month=10

Bukan suatu kebetulan bahwa URL ini terlihat seperti apa yang kita ketik di browser

Web. REST bergantung pada protokol http untuk interaksi antara pengguna jasa dan

penyedia. Protokol http memiliki empat operasi dasar: POST, GET, PUT, dan

DELETE. Dalam desain REST, penerapan operasi ini untuk sumber daya URL sesuai

untuk membuat, mengambil, memperbarui, dan menghapus (CRUD) operasi yang

umum digunakan dalam sistem informasi. Jadi, jika pengguna jasa mengirimkan

permintaan POST pada http://www.weather.com/current/zip/15213, ia meminta

penyedia layanan untuk membuat data untuk cuaca saat ini di kode pos 15213 dengan

menggunakan data yang diberikan bersama dengan permintaan. Permintaan GET pada

URL yang sama memberitahu penyedia layanan untuk mengambil data untuk cuaca

saat ini di kode pos 15213 dan mengembalikannya dalam respon. Permintaan PUT

menunjukkan bahwa penyedia layanan harus mengganti data itu dengan data yang

dikirim dalam permintaan. Permintaan DELETE menunjukkan bahwa pengguna jasa

menginginkan penyedia layanan untuk menghapus data. Protokol http juga

mendefinisikan kode status yang dapat dikembalikan: 200 untuk OK, 201 untuk

dibuat, 401 untuk yang tidak sah, dan sebagainya

Karakteristik unik REST adalah bahwa ia mengatur antarmuka-layanan seragam

sebagai sumber informasi yang di atasnya seperangkat tetap operasi dapat diterapkan,

bukan satu set metode dengan parameter yang berbeda. Dalam solusi REST, untuk

setiap sumber daya kita harus mendefinisikan representasi. Dalam kebanyakan kasus,

dasar XML adalah format yang digunakan. Juga, REST layanan yang selalu stateless-

mereka tidak menyimpan keadaan percakapan di beberapa permintaan dari pengguna

jasa yang sama.

Pendukung REST mengklaim beberapa keuntungan lebih berbasis SOAP layanan

Web:


25/43

Hasil REST dalam meningkatkan modifiability. Untuk pengguna layanan untuk

berinteraksi dengan Web Service non-REST, pengguna jasa harus memahami

secara spesifik dari kontrak data (yaitu, bagaimana data terstruktur) dan

kontrak antarmuka (yaitu, operasi apa yang dapat dilakukan). Karena

antarmuka yang seragam, untuk memanggil layanan REST, pengguna jasa

hanya harus memahami kontrak data, karena kontrak antarmuka seragam untuk

semua layanan [Vinoski 2007].

REST mudah untuk menerapkan dan menghasilkan interoperabilitas yang

tinggi, karena hanya memerlukan dukungan http standar dari kedua pengguna

jasa dan penyedia. Ini tidak memerlukan toolkit SOAP untuk menerapkan kode

atau server aplikasi yang mendukung layanan Web.

REST memiliki kinerja yang lebih baik karena kemampuannya untuk cache

tanggapan (bila ada) dan tidak adanya perantara, pembungkus pesan, dan

serialisasi yang diperlukan oleh layanan Web.

Layanan Web dan REST merupakan paradigma yang berbeda untuk menerapkan SOA.

Salah satunya adalah berpusat pada operasi yang akan dijalankan oleh penyedia

layanan. Yang lain difokuskan pada akses ke sumber daya. Dalam evaluasi arsitektur

sistem SOA, tim evaluasi dapat mempertanyakan pendekatan yang akan lebih tepat

untuk masing-masing layanan. REST adalah pilihan yang baik untuk mengakses

sumber daya statis atau hampir statis. Hal ini juga berguna untuk perangkat portabel

dengan bandwidth yang terbatas, karena pesan REST kurang verbose dari pesan

SOAP. Teknologi layanan Web menawarkan dukungan yang lebih baik untuk

keamanan, pesan handal, dan manajemen transaksi [MacVittie 2006]. Sebagai hasil

dari adopsi, banyak pengetahuan tentang layanan Web disediakan di Web dan di

komunitas profesional. Ada juga dukungan alat yang lebih baik untukmengembangkan layanan Web, meskipun API untuk memudahkan pengembangan

solusi REST sedang dibuat, seperti API Java untuk layanan Web [Sun 2007b]. Jika

aplikasi yang akan memberikan layanan kepada beberapa pengguna dan mitra bisnis,

alternatif adalah untuk membangun kedua SOAP dan REST interface untuk layanan

yang dilakukan.seperti Amazon.com dan eBay.


26/43

1.3 Pesan Solusi

Interaksi antara pengguna jasa dan penyedia layanan juga dapat didasarkan pada sistem

messaging, seperti IBM WebSphere MQ, Microsoft MSMQ, Oracle AQ, dan

SonicMQ. Produk ini menawarkan pertukaran pesan terutama asynchronous antara

aplikasi terdistribusi dalam point to-point (pengirim-penerima) atau mempublikasikan-

berlangganan fashion. Pada dasarnya, sistem pesan memungkinkan administrator

untuk mengkonfigurasi antrian pesan. Aplikasi kemudian dapat terhubung ke antrian

ini untuk mengirim atau menerima pesan, sedangkan sistem pesan mengkoordinasikan

pengiriman dan penerimaan pesan. Solusi ini juga dapat ditunjuk sebagai event-driven

architecture (EDA), dalam hal ini adalah peristiwa pesan dan antrian sering disebut

saluran.

Manfaat utama dari solusi messaging yang

Mereka menawarkan keandalan yang besar dengan jaminan pengiriman pesan.

Mereka mempromosikan loose coupling antara produsen dan konsumen pesan,

dan penggunaan kembali konsumen pesan.

Mereka sangat berguna saat menghubungkan sistem yang berbeda dan aplikasi

warisan.

implementasi komersial menyediakan skalabilitas tinggi untuk mendukungpeningkatan jumlah klien dengan menambahkan lebih banyak contoh

konsumen pesan.

Mereka mungkin dirancang untuk bekerja secara offline (yaitu, terputus dari

jaringan). Pesan antri dan disimpan pada pengirim, dan ketika konektivitas

resume, mereka akan dikirim ke penerima dengan cara yang sama bahwa PDA

sinkronisasi dengan server.

Ada tiga tantangan utama dalam sistem messaging. Tantangan pertama adalah bahwa

model pemrograman asynchronous lebih kompleks, terutama ketika interaksi sinkron

dan mekanisme callback harus digunakanTantangan kedua adalah biaya kinerja untuk

membungkus data dalam paket pesan dan untuk menyimpan (kadang-kadang pada

disk) pesan pada pengirim dan / atau komputer penerima. Tantangan ketiga adalah

interoperabilitas. Sistem pesan Proprietary biasanya tidak tersedia pada semua


27/43

platform. Sebagai contoh, Microsoft MSMQ adalah Windows-satunya produk. Selain

itu, sistem pesan biasanya bergantung pada protokol proprietary dan membutuhkan

jembatan thirdparty untuk berinteraksi dengan sistem messaging lainnya.

Ada solusi terisolasi yang menggunakan SOAP melalui sistem messaging [Shah 2006,

Kiss 2004], tetapi upaya berkelanjutan yang paling penting saat ini untuk

memungkinkan sistem pesan untuk mendapatkan keuntungan dari interoperabilitas

SOAP adalah WS-Reliability [OASIS 2004a] dan WS-ReliableMessaging [OASIS

2006b ] standar. Mereka memiliki lebih banyak kesamaan daripada nama. Vendor

layanan Web platform, seperti Microsoft, IBM, Sun Microsystems, dan BEA, telah

mengumumkan dukungan untuk salah satu atau kedua standar. Implementasi standar

sering membangun sebuah sistem pesan yang ada. Kedua standar memungkinkan

produsen dan konsumen pesan diimplementasikan dalam bahasa yang berbeda dan

pada platform yang berbeda untuk beroperasi mulus dengan menggunakan protokol

SOAP. Meskipun demikian, fakta bahwa ada spesifikasi yang bersaing mungkin

sendiri menjadi hambatan bagi interoperabilitas, meskipun industri tampaknya akan

bergerak menuju WS-ReliableMessaging. Salah satu indikator ini adalah resep dalam

baru ini diterbitkan WS-I Handal aman Profil Versi 1.0. Dalam evaluasi arsitektur, jika

kedua keandalan dan interoperabilitas persyaratan kuat, penggunaan produk yang

kompatibel dengan WS-Reliable Messaging merupakan langkah ke arah yang benar.

2.

Pendekatan Integrasi - Direct Point-To-Point Versus ESB

Pembentukan pola integrasi sistem dan strategi untuk sistem SOA memiliki dampak

yang signifikan dan tahan lama. Dua opsi yang signifikan bagi pola integrasi utama

adalah (1) langsung point-to-point dan (2) hub-and-spoke. Dalam pendekatan langsung

point-to-point, setiap koneksi antara aplikasi (yaitu, setiap layanan interaksi pengguna-

provider) dirancang secara individual dan dilaksanakan kooperatif, dikerahkan, dandikelola. Tanggung jawab untuk masalah konektivitas seperti lokasi, penamaan,

keamanan, auditing, dan versi layanan didistribusikan di antara aplikasi.

Dalam pendekatan hub-dan- spoke, interaksi antara pengguna jasa dan penyedia

dimediasi oleh perantara perangkat lunak. Dalam ruang SOA, software perantara ini


28/43

biasanya disebut ESB. Istilah yang lebih klasik adalah software enterprise application

integration (EAI). Setiap aplikasi dirancang untuk berinteraksi dengan ESB,

memungkinkan untuk mengelola routing dan transformasi pesan antara aplikasi.

Gambar 2 memberikan perbandingan topologi integrasi sederhana dari ESB dan point-

to-point. Hal ini umum dalam organisasi besar untuk memiliki campuran pendekatan

yang bergantung pada berbagai faktor, seperti usia aplikasi dan tujuan integrasi

konektivitas

Gambar 10. Simplified Comparison of ESBandPoint-to-Point Integration

Approaches


29/43

Istilah ESB digunakan secara bergantian untuk mengacu pada pola arsitektur dan

produk. Meskipun tidak ada standar industri yang dibuat yang mendefinisikan apa

yang merupakan ESB, vendor dan pelaksana telah mencoba untuk mengidentifikasi

beberapa kemampuan umum yang diuraikan di bawah ini:

1. ESB memberikan dukungan mendasar untuk layanan Web.

2. ESB dapat pesan rute ke satu atau lebih aplikasi. Pesan routing kontrol ESB

memungkinkan

Tetap pada application-to-application

Dinamis membaca berdasarkan isi pesan yang ditunjuk

Dinamis berdasarkan ketersediaan sistem

Dinamis berdasarkan load balancing

Distribusi dari satu sumber ke banyak penerima (yaitu, mempublikasikan-

berlangganan)

Konsolidasi pesan dari berbagai sumber untuk satu penerima (pesan

agregasi)

3. The ESB dapat mengubah data, termasuk konversi

- Format data (misalnya, dari warisan-aplikasi tertentu, fixed-field format

record file ke skema XML yang telah ditetapkan)

Konten bisnis (misalnya, sejumlah bagian dalam perencanaan sumber daya

perusahaan (ERP) aplikasi untuk nomor yang berbeda dalam sistem order-

entry berbasis Web)

Multiplisitas (yaitu, pemisahan atau menggabungkan pesan terpisah)

4.

The ESB fungsi dapat didistribusikan di beberapa server, yang dikelola secara

terpusat. Solusi hub-dan-spokelain sering mandat server tunggal.

5. The ESB menyediakan dukungan untuk penggunaan proprietary atau kustom

adapter untuk menghubungkan ke warisan dan komersial off-the-shelf (COTS)

aplikasi.


30/43

6. produk ESB dapat mendukung otentikasi, otorisasi, dan enkripsi menggunakan

beberapa standar keamanan seperti WS-Security, Kerberos, dan secure socket

layer (SSL).

7. produk ESB biasanya menyediakan perkakas canggih (seperti dokumen grafis

pemetaan lapangan dan routing definisi), keamanan terpadu, fungsi

administrasi, dan layanan pemantauan runtime.

Atribut kualitas arsitektur utama yang ditangani oleh ESB termasuk

a. interoperabilitas. Sebuah ESB memungkinkan aplikasi yang terhubung dengan

teknologi dan format data yang berbeda persyaratan untuk beroperasi sebagai

pengguna jasa dan penyedia tanpa perubahan invasif untuk masing-masing.

b. modifiability. Sebuah ESB memungkinkan banyak (tidak semua) jenis

perubahan atau penggantian dari penyedia layanan tanpa mempengaruhi

pengguna jasa. Sebagai contoh, sebuah ESB dapat digunakan untuk

crossreference ID untuk produk antara aplikasi atau format standar

pertandingan tanggal-dan-waktu tanpa mengubah aplikasi sumber.

c. Extensibility. Dibandingkan dengan strategi integrasi point-to-point, ESB

menyediakan kemampuan untuk lebih mudah menambahkan layanan yang

diperlukan untuk memenuhi perubahan kebutuhan bisnis.

Menambahkan ESB ke SOA versus penggunaan langsung koneksi point-to-point

menyajikan beberapa arsitektur pertimbangan kualitas tradeoff:

Kinerja dapat mengalami dampak negatif akibat hop pesan tambahan dan

transformasi pesan dilakukan oleh ESB.

Kompleksitas sistem secara keseluruhan dan biaya implementasi awal

meningkat dengan menambahkan ESB untuk arsitektur. Dengan demikian,

mengadopsi ESB mungkin tidak layak dalam lingkungan dengan sejumlah

kecil aplikasi dan layanan, atau dalam proyek-proyek dengan jadwal yang

ketat. Sebuah organisasi yang mengadopsi ESB perlu

- Menetapkan strategi jangka panjang yang terdiri dari kebijakan dan standar

untuk menggunakan ESB, seperti sebagai format pesan standar,


31/43

konektivitas dan keamanan standar, standar penamaan untuk endpoint

layanan, antrian, koneksi database, skema pesan, dan penyebaran file.

Kebijakan dan standar ini juga penting dalam direct solusi point-to-point,

tapi menjadi penting ketika ada tulang punggung umum dimiliki oleh

semua aplikasi.

- Menetapkan proses untuk memastikan bahwa aplikasi tidak dibenarkan

melewati ESB.

- Mengevaluasi infrastruktur ESB dan platform pendukung untuk

memastikan bahwa mereka memberikan mekanisme untuk manajemen

transaksi, ketersediaan, logging dan monitoring, kesalahan penanganan,

skalabilitas, dan mekanisme lainnya yang diperlukan untuk memenuhi

persyaratan atribut kualitas dari aplikasi.

Mekanisme Keamanan administrasi di lingkungan ESB dapat membantu untuk

mengkonfigurasi dan mengelola kontrol akses dari setiap koneksi ke dan dari

ESB. Di sisi lain, konten diproses oleh ESB mungkin perlu selektif dilindungi

dan terkena tergantung dari pilihan antara pendekatan point-to-point, hub-and-

spoke, atau integrasi hybridlangsung didorong oleh faktor-faktor seperti:

- Nomor saat ini dan direncanakan aplikasi dan teknologi yang

terintegrasi

- throughput dan waktu respon persyaratan aplikasi yang terintegrasi saat

ini dan masa depan

- pola komunikasi (misalnya, sinkron, antrian pesan, mempublikasikan-

berlangganan) dan meningkatnya jumlah layanan terpadu oleh aplikasi

saat ini dan masa depan

- persyaratan dukungan untuk aplikasi baru, transaksi bisnis, dan

persyaratan data

- tingkat adopsi dan kematangan teknologi baru dan standar dalam

industri


32/43

- bisnis, organisasi, dan peraturan dinamika (misalnya, kecepatan yang

diperoleh perusahaan harus terintegrasi) ntung pada routing dan

persyaratan pemetaan.

3. Business Process Execution Language(BPEL)

BPEL merupakan standar yang digunakan untuk menggambarkan alur kerja

yang berorientasi proses bisnis [OASIS 2006a]. Aliran BPEL orkestrasi

mendefinisikan proses bisnis melalui aturan untuk mengkoordinasikan aliran data,

interface untuk layanan (biasanya layanan Web) bahwa proses mengekspos dan

penggunaan, dan ketentuan untuk penanganan kondisi pengecualian. Sekitar standarBPEL, vendor telah menciptakan alat yang memungkinkan programmer BPEL bisnis

non-teknis untuk menyusun alur kerja visual. Setelah deskripsi antarmuka untuk

layanan yang berpartisipasi berada di tempat, alat BPEL dapat membuat kode BPEL

yang menggambarkan alur kerja. Bahasa BPEL adalah berbasis XML dan memiliki

primitif seperti "menerima," "membalas," "memberi," dan "menunggu." Kode BPEL

kemudian diposting ke mesin BPEL (juga disebut Server BPEL) yang berjalan pada

aplikasi Server. Ketika peristiwa yang memicu alur kerja terjadi, mesin BPEL

mengkoordinasikan doa layanan menggunakan kode BPEL sebagai script.

Kemampuan biasanya disediakan dalam implementasi orkestrasi BPEL meliputi jenis

pengolahan berikut:

1. Pola aliran proses bisnis dokumen dan interaksi layanan. Operasi yang

merupakan bagian dari aliran proses BPEL dapat mencakup

- Arus berurutan layananinvocation: layanan panggilan dalam urutan seri.

- invocationlayanan paralel: memanggil layanan yang terpisah secara paralel,

menunggu respon sebelum melanjutkan dalam aliran

- Request-reply korelasi: mengeluarkan panggilan layanan asynchronous

dan menghubungkan callbacklayanan terpisah

- Waktunya menunggu: menunggu jangka waktu untuk respon layanan

panggilan


33/43

2. Alur kerja manusia yang spesifik dan pola interaksi proses bisnis yang spesifik.

Contohnya termasuk:

- Pekerjaan manajemen antrian (misalnya, prioritas pekerjaan, load

balancing, pergantian otomatis).

- Dual control (juga dikenal sebagai double-cek atau empat-mata) proses

alur kerja persetujuan. Dalam sistem pengadaan misalnya, dua tingkat

manajemen dapat diminta untuk menyetujui pembayaran faktur atas nilai

tertentu.

3. Penanganan kesalahan proses bisnis. Contoh skenario termasuk

- Pesan pengiriman kedaluwarsa

-

Coba lagi sinkron atau membatalkan pada kegagalan

- Retry asynchronous kompensasi transaksi pada kegagalan

- Pemberitahuan dan heuristik proses penyelesaian pada kegagalan

Saat ini banyak sistem SOA yang menerapkan alur kerja bisnis aplikasi kustom atau

didasarkan pada produk proprietary. Dalam jangka panjang, hal itu akan menjadi hal

yang biasa bagi media untuk desain SOA besar mengandalkan mesin BPEL untuk

sinkronisasi internal maupun eksternal yang dihadapi proses bisnis dan koneksi

layanan.

4. Statis Dinamis Versus Jasa Web

Untuk memanggil penyedia layanan, pengguna layanan harus menentukan antarmuka

layanan (operasi yang tersedia, diharapkan input dan output) dan menemukan layanan

yang sebenarnya. Untuk mengikat statis, seperti yang ditunjukkan pada Gambar 5,

antarmuka layanan dan lokasi harus diketahui ketika pengguna layanan

diimplementasikan atau digunakan. Pengguna jasa biasanya memiliki stub ke

antarmuka layanan dan mengambil lokasi layanan dari file konfigurasi lokal. Pengguna

jasa dapat meminta penyedia layanan secara langsung, dan tidak ada registry swasta

atau publik yang terlibat


34/43

Gambar 11.Contoh Static Binding

Untuk layanan Web dinamis, seperti yang ditunjukkan pada Gambar 6,

penyedia harus mendaftar layanan ke registri layanan. Registri ini dipertanyakan oleh

pengguna layanan di runtime untuk alamat penyedia dan kontrak layanan. Setelah

mendapatkan informasi yang diperlukan, pengguna jasa dapat meminta operasi

penyedia layanan.


35/43


36/43

Paradiga service-orientationmendukung sembilan prinsip-prinsip desain yang

berbeda berikut, yang masing-masing mendukung karakteristik desain dasar yang

membentuk target solusi logika sepertiservice-orientation.

Berikut ini adalah penjelasan singkat dari masing-masing prinsip disertai

dengan penggambarannya :

a. Prinsip 1 : Standardized service contract

Semua deskripsi layanan, tujuan, protokol komunikasi, dan format pesan harus

didokumentasikan dalamservice contract. Dalam rangka untuk membuat semua klien

memahami kontrak ini, maka harus ditulis dalam format deskripsi layanan berbasis

standar seperti yang ditunjukkan pada Gambar 13.

Gambar 13. Prinsip Standardized service contract

b. Prinsip 2 :Loose coupling

Loose coupling menekankan bahwa layanan harus dirancang untuk memiliki

dependensi minimal satu sama lain. Layanan tidak boleh tightly-coupledseperti yang

ditunjukkan pada Gambar 14. Lapisan yang berbeda dari loose couplingharus dibuat

saat merancang layanan, mulai dari service contract, hingga implementasi layanan.

Misalnya, ketika penyedia layanan diubah atau dihapus, ini akan memerlukan

perubahan layanan konsumen. Jadi, lebih baik untuk menjaga dependensi ini untuk

mengurangi perubahan yang diperlukan ketika upgrade dalam sistem yang dibutuhkan.


37/43

Gambar 14. PrinsipLoose coupling

c. Prinsip 3 : Service abstraction

Layanan merangkum logika yang diberikan dari dunia luar untuk menghindari

proliferasi layanan informasi yang tidak perlu untuk implementasi internal, teknologi,

logika, dan fungsi dari pengguna layanan seperti yang ditunjukkan pada Gambar 15.

Ini sangat membantu dalam mengembangkan aplikasi tanpa perlu meninjau, dan

menganalisis rincian penting tentang sistem.

Gambar 15. Prinsip Service Abstration

d. Prinsip 4 : Layanan usabilitas

Usabilitas menyatakan bahwa logika solusi dibagi kedalam layanan denganmaksud memaksimalkan penggunaan kembali. Layanan harus mengandung dan

mengekspresikan logika agnostik dan dapat diposisikan sebagai sumber daya yang

dapat digunakan kembali oleh perusahaan. Layanan usabilitas merupakan prinsip

desain yang harus dipertimbangkan selama desain layanan dan merupakan tujuan

penting dari SOA. Gambar 16 mengilustrasikan ide menggunakan layanan kembali


38/43

dengan membandingkan dua desain aplikasi yang dibutuhkan untuk menyediakan

fungsi yang sama. Tapi, usabilitas memerlukan pertimbangan khusus untuk

menyeimbangkan pengembangan usaha dan waktu yang dibutuhkan dengan manfaat

yang akan dicapai di masa depan.

Gambar 16. Prinsip Layanan Usabilitas

e. Prinsip 5 : Otonomi layanan

Prinsip ini menjamin bahwa manfaat layanan diperoleh hanya dengan

pelaksanaan pelayanan, dengan demikian, tidak ada layanan yang dikendalikan oleh

layanan lain seperti yang ditunjukkan pada Gambar 17. Dua manfaat utama yang

dicapai ketika menerapkan otonomi layanan adalah keandalan sistem dan perilaku

prediktabilitas.


39/43

Gambar 17. Prinsip Otonomi Layanan

f. Prinsip 6 : Service statelessness

Dalam arsitektur terdistribusi, penting untuk melacak interaksi sejarah antara

server dan client dari sistem. Namun, untuk membuat scalable arsitektur (yaitu

dipercaya bisa mendukung sejumlah besar permintaan), itu adalah praktik yang baik

untuk mengikuti prinsip Service Statelessness.

Service Statelessnessmenunjukkan perbedaan informasi state sebanyak mungkin

untuk meminimalkan konsumsi sumber daya. Seperti ditunjukkan dalam Gambar 18,

Service Statelessness mendorong pendekatan manajemen untuk menjaga layanan

dalam kondisi stateless dimanapun berada. Sebagai contoh, ini dapat dilakukan dengan

menggunakan komponen terpisah yang melacak negara dari layanan (misalnya

menyimpan data session dalam database)


40/43

Gambar 18. Prinsip Service Statelessness

g.

Prinsip 7 : Layanan discoverability

Aplikasi harus belajar tentang layanan sistem dengan cara yang sistematis.

Prinsip layanan discoverability ini menyiratkan dua persyaratan: (1) kontrak layanan

dilengkapi dengan metadata yang tepat, dan (2) registri layanan yang ada dalam rangka

untuk menyimpan catatan deskripsi layanan seperti yang ditunjukkan pada Gambar 19.

Gambar 19. Prinsip LayananDiscoverability


41/43

h. Prinsip 8 : Layanan composability

Layanan composability dirancang sebagai unit reusable yang dapat dengan

mudah dikonfigurasi ulang untuk mencerminkan persyaratan baru dan proses bisnis,

dengan demikian dapat digunakan dalam aplikasi yang berbeda. Prinsip ini

mempengaruhi secara langsung kelincahan bisnis. Jadi aplikasi apapun akan terdiri

dari sejumlah layanan seperti yang ditunjukkan pada Gambar 20.

Gambar 20. Prinsip Layanan Composability

i. Prinsip 9 : Layanan interoperabilitas

Dalam banyak aplikasi nyata, banyak kemungkinan layanan konsumen berjalan

pada platform yang berbeda selain dari penyedia layanan. Dalam hal ini, akan sulit

untuk berinteraksi kecuali mereka sepakat pada standar yang sama untuk interaksi.

Layanan interoperabilitas memerlukan penggunaan standar yang memungkinkan

pelanggan yang beragam untuk menggunakan layanan ini. Dengan demikian,

perawatan khusus harus diberikan untuk protokol transport yang digunakan dan format

pesan, contoh penggunaan layanan ini seperti yang ditunjukkan pada Gambar 21


42/43

Gambar 21. Prinsip Layanan Interoperabilitas

N. Manfaat SOA

Meningkatnya kompleksitas proses bisnis dan sistem, ditambah dengan

perubahan yang cepat dalam kebutuhan pasar dan kebutuhan bisnis; dan kelincahan,

fleksibilitas, dan otomatisasi bisnis telah menjadi penting bagi perusahaan untuk

bertahan. SOA adalah sebuah paradigma kuat untuk realisasi kelincahan, fleksibilitas,

dan otomatisasi proses bisnis yang mencakup sistem terdistribusi besar. Ini adalah

pendekatan yang dapat mendukung sistem untuk tetap terukur dan fleksibel saat

tumbuh. Perusahaan membutuhkan solusi yang disesuaikan atau menggunakan IT

untuk nilai kompetitif, perusahaan yang ingin memanfaatkan kemampuan untuk

keuntungan bisnis IT, merupakan perusahaan yang harus peduli tentang SOA. SOA

mendukung realisasi tujuan strategis ini, yang memungkinkan bisnis dan IT untuk

berkolaborasi dalam rangka mencapai :

Fleksibilitas yang lebih besar dalam aplikasi strategis

Waktu yang lebih cepat untuk nilai dari IT

Aplikasi strategis yang dimodernisasi

Menurunkan biaya perawatan aplikasi atau infrastruktur

Reuse sebagai tujuan untuk membawa produk atau kemampuan ke pasar lebih

cepat


43/43

SOA menyediakan potensi untuk meningkatkan respon dan efektivitas biaya TI

melalui paradigma desain yang menekankan realisasi strategi tujuan dan manfaatnya.

Gambar 13 menggambarkan manfaat SOA pada dimensi teknis dan bisnis.

Gambar 22.Manfaat SOA Pada Dimensi Teknik Dan Bisnis

Sumber:



Revisi Tugas UAS SOA.docx

Documents

Transcript of Revisi Tugas UAS SOA.docx