You are on page 1of 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

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

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

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:
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
dengan teknologi layanan Web, karena umumnya digunakan dalam implementasi SOA
hari ini.









Gambar 2. SOA dan Teknologi SOA
Sumber : www.sei.cmu.edu/reports/07tr015.pdf

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.
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.
Sumber : www.sei.cmu.edu/reports/07tr015.pdf

H. Komponen SOA
Gambar 1 dibawah ini menggambarkan komponen utama dari solusi berbasis
SOA.

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:
 orang untuk orang
 orang untuk proses
proses untuk proses
sumber :
http://www.secc.org.eg/recocape/Documents/SECC_Tutorials_A%20Quick%20Introd
uction%20to%20SOA.pdf

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

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

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 repurposing satu layanan untuk tugas umum.

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

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

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
nilai yang mungkin: ". Literal" "encoded" atau Akibatnya ada empat kemungkinan
kombinasi dari kedua sifat ini. Dua opsi gabungan yang umum dalam praktik adalah
RPC-encoded dan dokumen-literal.
- RPC-Encoded SOAP
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].













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 3
menunjukkan interaksi dokumen-literal.


















Gambar 9: Interaksi Document-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
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
• 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:
• 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 untuk
mengembangkan 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.
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 mendukung
peningkatan 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
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, dan
dikelola. 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
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 ESB and Point-to-Point Integration
Approaches

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-spoke lain 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.
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,
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 hybrid langsung 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
- 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 standar
BPEL, 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 layanan invocation: layanan panggilan dalam urutan seri.
- invocation layanan paralel: memanggil layanan yang terpisah secara paralel,
menunggu respon sebelum melanjutkan dalam aliran
- Request-reply korelasi: mengeluarkan panggilan layanan asynchronous
dan menghubungkan callback layanan terpisah
- Waktunya menunggu: menunggu jangka waktu untuk respon layanan
panggilan
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






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.














Gambar 12. Dinamis Binding Contoh

Hasil ikatan statis dalam tighter coupling antara pengguna jasa dan penyedia.
Perubahan ke lokasi layanan atau kontrak dapat menyebabkan pengguna jasa untuk
istirahat saat runtime saat jasa dipanggil atau selama marshalling dan unmarshalling
objek. Keuntungan utama dari mengikat statis adalah kinerja yang lebih baik, karena
komunikasi ke registri dihindari. Namun, dalam beberapa konfigurasi di mana registri
digunakan untuk permintaan keseimbangan beban di kolam penyedia layanan,
throughput keseluruhan bisa lebih baik daripada alternatif mengikat statis. Mengikat
statis sering digunakan, karena itu sudah cukup untuk kebanyakan skenario bisnis dan
solusi desain [Zimmermann 2003].
Untuk mengikat dinamis informasi yang diperlukan untuk pemanggilan diperoleh pada
saat runtime, sehingga mengurangi penghubung antara pengguna jasa dan penyedia.
Lokasi penyedia layanan dapat berubah tanpa mempengaruhi pengguna jasa. Beberapa
versi interface juga dapat dikelola oleh registri layanan dan hidup berdampingan dalam
produksi. Namun, fleksibilitas yang diberikan oleh dinamis mengikat mengharuskan
pengguna jasa dan penyedia layanan untuk memiliki perjanjian yang sudah ditentukan
pada sintaks dan semantik interface. Kinerja terkena dampak negatif karena interaksi
dengan registri layanan. Kinerja overhead ini dapat dikompensasikan dengan
menggunakan registri untuk load balancing. Bahkan registri dapat memiliki banyak
tujuan selain penemuan dinamis layanan.
Sumber : www.sei.cmu.edu/reports/07tr015.pdf

M. Prinsip Desain SOA
Inti dari pendekatan SOA adalah memiliki berbagai unit dari solusi logika dan
diekspos sebagai layanan. Hal ini memerlukan pengembangan praktik dan standar
untuk membantu pengembang perangkat lunak untuk mengidentifikasi desain dan
layanan desain.
Paradiga service-orientation mendukung sembilan prinsip-prinsip desain yang
berbeda berikut, yang masing-masing mendukung karakteristik desain dasar yang
membentuk target solusi logika seperti service-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 dalam service 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-coupled seperti yang
ditunjukkan pada Gambar 14. Lapisan yang berbeda dari loose coupling harus 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.

Gambar 14. Prinsip Loose 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 dengan
maksud 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
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.


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 Statelessness menunjukkan 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)


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 Layanan Discoverability



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


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
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:
http://www.secc.org.eg/recocape/Documents/SECC_Tutorials_A%20Quick%20Introd
uction%20to%20SOA.pdf