Aplikasi Enterprise Integrasi (EAI) didefinisikan sebagai penggunaan sistem perangkat lunak dan

komputer prinsip arsitektur untuk mengintegrasikan satu set aplikasi komputer perusahaan.

Ikhtisar

Aplikasi Enterprise Integrasi (EAI) adalah kerangka integrasi terdiri dari kumpulan teknologi dan jasa
yang membentuk middleware untuk memungkinkan integrasi sistem dan aplikasi di seluruh perusahaan.

Aplikasi manajemen rantai pasokan (untuk mengelola persediaan dan pengiriman), pelanggan aplikasi
manajemen hubungan (untuk mengelola pelanggan sekarang dan potensial), kecerdasan aplikasi bisnis
(untuk mencari pola dari data yang ada dari operasi), dan jenis lain dari aplikasi (untuk mengelola data
seperti data sumber daya manusia, kesehatan, komunikasi internal, dll) biasanya tidak dapat
berkomunikasi dengan satu sama lain untuk berbagi data atau aturan bisnis. Untuk alasan ini, aplikasi
tersebut kadang-kadang disebut sebagai pulau silo otomatisasi atau informasi. Kurangnya komunikasi
menyebabkan inefisiensi, data dimana identik disimpan di beberapa lokasi, atau proses langsung tidak
akan otomatis.

Integrasi aplikasi enterprise (EAI) adalah proses menghubungkan aplikasi tersebut dalam satu
organisasi bersama dalam rangka untuk menyederhanakan dan mengotomatisasi proses bisnis sejauh
mungkin, sementara pada saat yang sama menghindari harus membuat perubahan besar terhadap
aplikasi yang ada atau struktur data . Dalam kata-kata dari Grup Gartner, EAI adalah "terbatas berbagi
data dan proses bisnis antara setiap aplikasi yang terhubung atau sumber data dalam perusahaan." [1]

Salah satu tantangan besar EAI adalah bahwa berbagai sistem yang perlu dihubungkan bersama sering
berada pada sistem operasi yang berbeda, menggunakan solusi database yang berbeda dan bahasa
komputer yang berbeda, dan dalam beberapa kasus adalah warisan sistem yang tidak lagi didukung oleh
vendor yang awalnya diciptakan mereka. Dalam beberapa kasus, sistem tersebut dijuluki "sistem
cerobong asap" karena mereka terdiri dari komponen yang telah macet bersama-sama dengan cara yang
membuatnya sangat sulit untuk memodifikasi mereka dengan cara apapun.
[Sunting] konektivitas Meningkatkan
Unbalanced scales.svg
Netralitas dari artikel ini adalah sengketa. Silakan lihat diskusi di halaman pembicaraan. Harap jangan
hapus pesan ini sampai sengketa diselesaikan. (Maret 2011)

Jika integrasi diterapkan tanpa mengikuti pendekatan EAI terstruktur, koneksi point-to-point tumbuh di
seluruh organisasi. Dependensi ditambahkan secara spontan, sehingga dalam kekacauan kusut yang
sulit untuk mempertahankan. Hal ini sering disebut sebagai spaghetti, kiasan kepada setara
pemrograman kode spageti. Sebagai contoh:

Jumlah koneksi yang diperlukan untuk memiliki sepenuhnya dihubungkan koneksi point-to-point,
dengan poin n, diberikan oleh \ frac {n (n-1)} {2}. Jadi, untuk aplikasi sepuluh sepenuhnya terintegrasi
point-to-point, \ frac {10 \ times9} {2}, atau 45 sambungan point-to-point diperlukan.

Namun, EAI bukan hanya tentang berbagi data di antara aplikasi, tetapi berfokus pada berbagi data
usaha baik dan proses bisnis. Analis Middleware menghadiri EAI melibatkan mengamati sistem sistem,
yang melibatkan masalah besar antar-disiplin dengan beberapa skala, heterogen, sistem terdistribusi
yang tertanam dalam jaringan di berbagai tingkat.
[Sunting] Tujuan

EAI dapat digunakan untuk tujuan yang berbeda:

Data integrasi: Memastikan bahwa informasi dalam beberapa sistem disimpan konsisten. Hal ini juga
dikenal sebagai Enterprise Information Integration (EII).
kemerdekaan Vendor: kebijakan bisnis Ekstrak atau aturan dari aplikasi dan
mengimplementasikannya dalam sistem EAI, sehingga bahkan jika salah satu aplikasi bisnis diganti
dengan aplikasi vendor yang berbeda itu, aturan bisnis tidak harus kembali diterapkan.
fasad Umum: Sebuah sistem EAI dapat front-end sekelompok aplikasi, menyediakan antarmuka
akses tunggal yang konsisten ke aplikasi ini dan melindungi pengguna dari harus belajar untuk
menggunakan paket perangkat lunak yang berbeda.

[Sunting] Pola
[Sunting] pola Integrasi

Ada dua pola yang menerapkan sistem EAI:

Mediasi (intra-komunikasi)
Di sini, sistem EAI bertindak sebagai perantara atau broker antara (interface atau berkomunikasi)
beberapa aplikasi. Setiap kali sebuah peristiwa menarik terjadi dalam aplikasi (misalnya, informasi baru
dibuat, transaksi baru selesai, dll) modul integrasi dalam sistem EAI diberitahu. Modul ini kemudian
menjalar perubahan terhadap aplikasi lain yang relevan.
Federasi (inter-komunikasi)
Dalam hal ini, sistem EAI bertindak sebagai fasad menyeluruh di beberapa aplikasi. Acara Semua
panggilan dari 'dunia luar' ke salah satu aplikasi yang depan berakhir oleh sistem EAI. Sistem EAI
dikonfigurasi untuk mengekspos hanya informasi yang relevan dan interface dari aplikasi yang
mendasari ke dunia luar, dan melakukan semua interaksi dengan aplikasi yang mendasari atas nama
pemohon.

Kedua pola sering digunakan secara bersamaan. Sistem EAI sama bisa menjaga berbagai aplikasi di
sync (mediasi), sedangkan melayani permintaan dari pengguna eksternal terhadap aplikasi ini (federasi).
[Sunting] Akses pola

EAI mendukung kedua pola akses asinkron dan sinkron, mantan yang khas dalam hal mediasi dan yang
terakhir dalam kasus federasi.
[Sunting] pola Lifetime

Operasi integrasi bisa berumur pendek (misalnya data tetap sinkron di dua aplikasi yang dapat
diselesaikan dalam waktu satu detik) atau panjang-hidup (misalnya salah satu langkah yang bisa
melibatkan sistem EAI berinteraksi dengan aplikasi alur kerja manusia untuk persetujuan dari pinjaman
yang mengambil jam atau hari untuk menyelesaikan).
[Sunting] Topologi

Ada dua topologi utama: hub-dan-berbicara, dan bus. Masing-masing memiliki kelebihan dan
kekurangan. Dalam model hub-dan-berbicara, sistem EAI berada di pusat (hub), dan berinteraksi
dengan aplikasi melalui jari-jari. Dalam model bus, sistem EAI adalah bus (atau diimplementasikan
sebagai modul penduduk dalam bus pesan yang sudah ada atau middleware pesan-oriented).
[Sunting] Teknologi

Beberapa teknologi yang digunakan dalam pelaksanaan masing-masing komponen dari sistem EAI:

Bus / hub
Hal ini biasanya dilakukan dengan meningkatkan produk middleware standar (aplikasi server, bus
pesan) atau diimplementasikan sebagai program yang berdiri sendiri (yakni, tidak menggunakan
middleware ada), bertindak sebagai middleware sendiri.
Aplikasi konektivitas
 Bus / hub terhubung ke aplikasi melalui serangkaian adapter (juga disebut sebagai konektor). Ini
adalah program yang tahu bagaimana berinteraksi dengan aplikasi bisnis yang mendasari. Adaptor
melakukan komunikasi dua arah, melakukan permintaan dari pusat terhadap aplikasi, dan
memberitahukan hub ketika sebuah peristiwa yang menarik terjadi dalam aplikasi (rekor baru
dimasukkan, transaksi selesai, dll). Adapter dapat spesifik ke salah satu aplikasi (misalnya, dibangun
dengan pustaka klien vendor aplikasi) atau khusus untuk suatu kelas aplikasi (misalnya, dapat
berinteraksi dengan aplikasi apapun melalui protokol komunikasi standar, seperti SOAP, SMTP atau
Action pesan Format (AMF )). Adaptor ini dapat berada di ruang proses yang sama seperti bus / hub
atau mengeksekusi di lokasi terpencil dan berinteraksi dengan hub / bus melalui protokol standar
industri seperti antrian pesan, layanan web, atau bahkan menggunakan protokol proprietary. Dalam
dunia Jawa, standar seperti JCA adapter memungkinkan untuk dibuat dengan cara vendor-netral.
Format data dan transformasi
Untuk menghindari setiap adaptor harus mengkonversi data ke / dari setiap format aplikasi lain ', EAI
sistem biasanya menetapkan format (atau umum) aplikasi independen data. Sistem EAI biasanya
menyediakan layanan transformasi data juga untuk membantu mengkonversi antara format aplikasi
spesifik dan umum. Hal ini dilakukan dalam dua langkah: adaptor mengubah informasi dari format
aplikasi ke format umum bus itu. Kemudian, transformasi semantik yang diterapkan pada ini
(mengubah kode pos ke nama kota, pemecahan / penggabungan objek dari satu aplikasi ke objek di
aplikasi lain, dan seterusnya).
Integrasi modul
Sebuah sistem EAI bisa berpartisipasi dalam beberapa operasi integrasi bersamaan pada waktu
tertentu, tiap jenis integrasi yang diproses oleh modul integrasi yang berbeda. Integrasi modul
berlangganan peristiwa jenis tertentu dan pemberitahuan proses yang mereka terima saat peristiwa ini
terjadi. Modul-modul ini dapat diterapkan dalam cara yang berbeda: pada sistem EAI berbasis Java, ini
bisa web aplikasi atau EJBs atau bahkan POJOs yang sesuai dengan spesifikasi sistem EAI itu.
Dukungan untuk transaksi
Ketika digunakan untuk proses integrasi, sistem EAI juga menyediakan konsistensi transaksional
berbagai aplikasi dengan menjalankan operasi integrasi semua di semua aplikasi dalam suatu transaksi
tunggal terdistribusi menyeluruh (menggunakan dua-tahap melakukan protokol atau transaksi
kompensasi).

[Sunting] Komunikasi arsitektur

Saat ini, ada banyak variasi pemikiran tentang apa yang merupakan infrastruktur terbaik, model
komponen, dan struktur standar untuk EAI. Tampaknya ada konsensus bahwa empat komponen yang
penting bagi integrasi aplikasi enterprise arsitektur modern:

Seorang broker terpusat yang menangani keamanan, akses, dan komunikasi. Hal ini dapat dicapai
melalui server integrasi (seperti Sekolah Interoperabilitas Framework (SIF) Zona Integrasi Server) atau
melalui software yang serupa seperti bus pelayanan perusahaan (ESB) model yang bertindak sebagai
manajer layanan SOAP-oriented.
Model data independen berdasarkan struktur data standar, juga dikenal sebagai model data kanonik.
Tampaknya XML dan penggunaan style sheets XML telah menjadi de facto dan dalam beberapa kasus
standar de jure untuk bahasa bisnis seragam.
Sebuah konektor, atau model agen di mana setiap vendor, aplikasi, atau interface dapat membangun
sebuah komponen tunggal yang dapat berbicara native untuk aplikasi itu dan berkomunikasi dengan
broker terpusat.
Sebuah model sistem yang mendefinisikan aliran API, data dan aturan keterlibatan pada sistem
sehingga komponen dapat dibangun untuk berinteraksi dengannya dalam cara yang standar.

Meskipun pendekatan lain seperti menghubungkan pada database atau level user-interface telah
dieksplorasi, mereka belum ditemukan skala atau dapat menyesuaikan. Masing-masing aplikasi dapat
mempublikasikan pesan ke broker terpusat dan berlangganan untuk menerima pesan tertentu dari broker
itu. Setiap aplikasi hanya memerlukan satu sambungan kepada broker. Pendekatan kontrol pusat bisa
sangat scalable dan sangat evolvable.

Integrasi Aplikasi Enterprise berkaitan dengan middleware teknologi seperti pesan middleware
berorientasi (MOM), dan teknologi representasi data seperti XML. Lain EAI teknologi melibatkan
menggunakan layanan web sebagai bagian dari arsitektur berorientasi layanan sebagai alat integrasi.
Otomasi cenderung menjadi data centric. Dalam waktu dekat, itu akan datang untuk memasukkan
konten dan integrasi proses bisnis.
[Sunting] jebakan Pelaksanaan

Pada tahun 2003 dilaporkan bahwa 70% dari semua proyek EAI gagal. Kebanyakan dari kegagalan ini
bukan karena perangkat lunak itu sendiri atau kesulitan teknis, tetapi karena masalah manajemen.
Integrasi Ketua Konsorsium Eropa Steve Craggs telah digariskan tujuh perangkap utama yang telah
dilaksanakan oleh perusahaan menggunakan sistem EAI dan menjelaskan solusi dari permasalahan
tersebut. [2]

Perubahan Konstan: Sifat sangat EAI bersifat dinamis dan membutuhkan manajer proyek yang
dinamis untuk mengelola pelaksanaannya.
Kekurangan tenaga ahli EAI: EAI membutuhkan pengetahuan tentang banyak masalah dan aspek
teknis.
Bersaing standar: Dalam bidang EAI, paradoks adalah bahwa EAI standar sendiri tidak universal.
EAI merupakan paradigma alat: EAI bukanlah alat, melainkan sistem dan harus dilaksanakan seperti
itu.
Membangun interface adalah sebuah seni: Engineering solusi tidak cukup. Solusi perlu
dinegosiasikan dengan departemen pengguna untuk mencapai konsensus umum pada hasil akhir.
Kurangnya konsensus mengenai desain antarmuka mengarah pada upaya berlebihan untuk memetakan
antara berbagai sistem data persyaratan.
Kehilangan detail: Informasi yang sepertinya tidak penting pada tahap awal mungkin menjadi
penting kemudian.
Akuntabilitas: Karena begitu banyak departemen memiliki kebutuhan yang saling bertentangan
banyak, harus ada pertanggungjawaban yang jelas untuk struktur akhir sistem.

potensi masalah lain bisa muncul di daerah-daerah:

Emerging Persyaratan: implementasi EAI harus extensible dan modular untuk memungkinkan
perubahan masa depan.
Proteksionisme: Aplikasi yang terintegrasi data sedang sering berasal dari departemen berbeda yang
memiliki teknis, budaya, dan alasan politik untuk tidak ingin berbagi data dengan departemen lain

[Sunting] Keuntungan dan kerugian

Keuntungan

Real time akses informasi antara sistem

bisnis-arus proses dan membantu meningkatkan efisiensi organisasi
Menjaga integritas informasi di beberapa sistem
Kemudahan pembangunan dan pemeliharaan

Kekurangan

Tinggi biaya pengembangan awal, terutama untuk usaha kecil dan menengah (UKM)
 Memerlukan jumlah wajar desain bisnis di depan, yang banyak manajer tidak dapat membayangkan
atau tidak mau berinvestasi

Sebagian besar proyek-proyek EAI biasanya mulai sebagai upaya point-to-point, cepat menjadi diatur
sebagai jumlah peningkatan aplikasi.
[Sunting] Masa Depan

teknologi EAI masih sedang dikembangkan dan masih ada konsensus pada pendekatan ideal atau
kelompok yang benar dari teknologi perusahaan yang harus digunakan. Ada banyak proyek yang sudah
berjalan yang memberikan dukungan untuk merancang solusi EAI. Mereka mungkin berkisar dari
proyek proprietary atau terbuka seperti Microsoft BizTalk Server atau Apache Camel untuk proyek-
proyek akademis seperti Guarana DSL. Masa depan adalah untuk memberikan teknologi yang
memungkinkan desain solusi EAI pada tingkat abstraksi tinggi dan menggunakan MDA untuk secara
otomatis mengubah desain menjadi solusi executable. Sebuah perangkap umum adalah dengan
menggunakan teknologi eksklusif lainnya yang mengaku terbuka dan diperluas tetapi menciptakan
vendor lock-in.

Sumber: http://en.wikipedia.org/wiki/Enterprise_application_integration
Arsitektur berorientasi layanan (SOA) adalah seperangkat prinsip desain fleksibel digunakan selama
fase pengembangan sistem dan integrasi dalam komputasi. Sebuah sistem yang didasarkan pada SOA
akan paket fungsionalitas sebagai rangkaian layanan interoperable yang dapat digunakan dalam
beberapa sistem yang terpisah dari domain beberapa bisnis.

SOA juga umumnya menyediakan cara bagi konsumen jasa, seperti aplikasi berbasis web, untuk
menyadari layanan berbasis SOA yang tersedia. Sebagai contoh, beberapa departemen yang berbeda
dalam perusahaan dapat mengembangkan dan memperluas layanan SOA dalam bahasa implementasi
yang berbeda; klien mereka masing-masing akan mendapatkan keuntungan dari antarmuka, dipahami
dengan baik didefinisikan dengan baik untuk mengaksesnya. XML umumnya digunakan untuk
antarmuka dengan layanan SOA, meskipun hal ini tidak diperlukan.

SOA mendefinisikan bagaimana untuk mengintegrasikan aplikasi luas yang berbeda untuk lingkungan
berbasis web dan menggunakan berbagai platform implementasi. Daripada mendefinisikan sebuah API,
SOA mendefinisikan antarmuka dalam hal protokol dan fungsionalitas. Suatu titik akhir adalah titik
masuk untuk seperti implementasi SOA.

Service-orientasi membutuhkan loose coupling jasa dengan sistem operasi, dan teknologi lainnya yang
mendasari aplikasi. SOA memisahkan fungsi menjadi unit-unit yang berbeda, atau jasa, [1] yang
membuat pengembang dapat diakses melalui jaringan untuk memungkinkan pengguna untuk
menggabungkan dan menggunakan kembali mereka dalam produksi aplikasi. Layanan ini dan
konsumen yang berhubungan berkomunikasi satu sama lain dengan melewatkan data dalam format,
yang jelas bersama, atau dengan mengkoordinasikan aktivitas antara dua atau lebih layanan. [2]

SOA bisa dilihat dalam sebuah kontinum, dari konsep yang lebih tua dari komputasi terdistribusi [1] [3]
dan pemrograman modular, melalui SOA, dan pada saat praktek mashup, SaaS, dan Cloud Computing
(yang beberapa lihat sebagai keturunan SOA [4]).

Ikhtisar

Implementasi SOA mengandalkan mesh layanan perangkat lunak. Layanan terdiri unassociated, longgar
ditambah unit fungsi yang tidak memiliki panggilan satu sama lain tertanam di dalamnya. Setiap
layanan melaksanakan satu tindakan, seperti mengisi aplikasi online untuk account, atau melihat
pernyataan bank online, atau menempatkan pemesanan online atau memesan tiket pesawat. Daripada
layanan embedding panggilan satu sama lain dalam kode sumber mereka, mereka menggunakan
protokol didefinisikan yang menjelaskan bagaimana layanan lancar dan mengurai pesan menggunakan
metadata deskripsi.
SOA asosiasi pengembang objek SOA individu dengan menggunakan orkestrasi. Dalam proses
orkestrasi asosiasi pengembang perangkat lunak fungsionalitas (layanan) dalam pengaturan non-hirarkis
menggunakan perangkat lunak yang berisi daftar lengkap dari semua layanan yang tersedia,
karakteristik mereka, dan sarana untuk membangun aplikasi memanfaatkan sumber-sumber ini.

Yang mendasari dan memungkinkan semua ini membutuhkan metadata secara rinci cukup untuk
menggambarkan tidak hanya karakteristik layanan ini, tetapi juga data yang mendorong mereka.
Programmer telah membuat ekstensif menggunakan XML dalam SOA untuk struktur data yang mereka
bungkus dalam wadah-deskripsi hampir lengkap. Analog, Web Services Description Language (WSDL)
biasanya menggambarkan layanan sendiri, sedangkan protokol SOAP menggambarkan protokol
komunikasi. Apakah bahasa-bahasa deskripsi adalah yang terbaik mungkin untuk pekerjaan itu, dan
apakah mereka akan menjadi / tetap menjadi favorit di masa depan, tetap pertanyaan terbuka. Pada
tahun 2008 SOA tergantung pada data dan jasa yang dijelaskan oleh metadata yang harus memenuhi
dua kriteria sebagai berikut:

metadata harus datang dalam bentuk yang sistem perangkat lunak dapat digunakan untuk
mengkonfigurasi secara dinamis dengan penemuan dan penggabungan layanan pasti, dan juga untuk
menjaga koherensi dan integritas. Sebagai contoh, metadata dapat digunakan oleh aplikasi lain, seperti
katalog, untuk melakukan autodiscovery layanan tanpa memodifikasi kontrak fungsional layanan.
metadata harus datang dalam bentuk yang desainer sistem dapat memahami dan mengelola dengan
pengeluaran biaya yang wajar dan usaha.

SOA bertujuan untuk memungkinkan pengguna untuk string bersama potongan cukup besar fungsi
untuk membentuk ad hoc aplikasi yang dibangun hampir seluruhnya dari layanan perangkat lunak yang
ada. Semakin besar potongan, semakin sedikit antarmuka poin yang diperlukan untuk melaksanakan
setiap set fungsionalitas tertentu, namun potongan yang sangat besar fungsi mungkin tidak
membuktikan cukup rinci untuk digunakan kembali mudah. Setiap antarmuka membawa serta beberapa
jumlah overhead pengolahan, sehingga ada pertimbangan kinerja dalam memilih granularity pelayanan.
Janji besar SOA menunjukkan bahwa biaya marjinal menciptakan aplikasi-n rendah, karena semua
perangkat lunak yang diperlukan sudah ada untuk memenuhi persyaratan dari aplikasi lain. Idealnya,
satu hanya memerlukan orkestrasi untuk menghasilkan aplikasi baru.

Untuk ini beroperasi, tidak ada interaksi harus ada antara potongan yang ditentukan atau dalam
potongan sendiri. Sebaliknya, manusia menentukan interaksi layanan (semuanya unassociated peer)
dengan cara yang relatif ad hoc dengan maksud didorong oleh kebutuhan yang baru muncul. Dengan
demikian kebutuhan pelayanan sebagai unit jauh lebih besar dari fungsionalitas dari fungsi tradisional
atau kelas, agar kompleksitas semata-mata ribuan benda butiran seperti membanjiri desainer aplikasi.
Programmer mengembangkan layanan sendiri menggunakan bahasa tradisional seperti Java, C, C + +,
C #, Visual Basic, COBOL, atau PHP.

layanan SOA fitur kopling longgar, berbeda dengan fungsi yang linker yang mengikat bersama untuk
membentuk dieksekusi, ke perpustakaan terkait secara dinamis atau untuk perakitan. SOA layanan juga
dijalankan dalam "aman" pembungkus (seperti Java atau NET.) Dan dalam bahasa pemrograman lain
yang mengelola alokasi memori dan reklamasi, memungkinkan ad hoc dan akhir mengikat, dan
menyediakan beberapa derajat data tak tentu mengetik.

Pada tahun 2008, peningkatan jumlah perusahaan perangkat lunak pihak ketiga menawarkan layanan
perangkat lunak untuk biaya. Di masa depan, sistem SOA mungkin [riset asli?] Terdiri dari layanan
pihak ketiga seperti dikombinasikan dengan orang lain dibuat di-rumah. Ini memiliki potensi untuk
menyebar biaya lebih banyak pelanggan dan menggunakan pelanggan, dan mempromosikan
standardisasi baik di dalam maupun di industri. Secara khusus, industri perjalanan kini memiliki [5]
yang jelas dan didokumentasikan set kedua layanan dan data, yang memadai untuk mengizinkan semua
software engineer cukup kompeten untuk membuat perangkat lunak-agen perjalanan menggunakan
layanan sepenuhnya off-the-rak perangkat lunak. Industri lainnya , seperti industri keuangan, juga sudah
mulai membuat kemajuan yang signifikan dalam arah ini.

SOA sebagai arsitektur yang mengandalkan pelayanan-orientasi sebagai prinsip desain yang
fundamental [6] Jika sebuah pelayanan hadiah. Antarmuka sederhana yang abstrak jauh kompleksitas
yang mendasari nya, pengguna dapat mengakses layanan mandiri tanpa pengetahuan tentang
implementasi platform layanan. [7]
[Sunting] Persyaratan

Dalam rangka untuk efisien menggunakan SOA, arsitektur harus memenuhi persyaratan sebagai
berikut:

Interoperabilitas di antara sistem yang berbeda dan bahasa pemrograman yang menyediakan dasar
bagi integrasi antara aplikasi pada platform yang berbeda melalui sebuah protokol komunikasi. Salah
satu contoh komunikasi tersebut tergantung pada konsep pesan. Menggunakan pesan di saluran pesan
pasti menurunkan kompleksitas aplikasi akhir, sehingga memungkinkan pengembang aplikasi untuk
fokus pada fungsionalitas aplikasi yang benar, bukan kebutuhan yang rumit dari sebuah protokol
komunikasi.
Keinginan untuk membuat sebuah federasi sumber daya. Menetapkan dan memelihara aliran data ke
sistem database Federated. Hal ini memungkinkan fungsionalitas baru dikembangkan untuk referensi
format bisnis umum untuk setiap elemen data.

[Sunting] Prinsip

Prinsip-prinsip panduan berikut mendefinisikan aturan-aturan dasar untuk pengembangan,

pemeliharaan, dan penggunaan SOA [8]:

kembali, granularity, modularitas, composability, komponenisasi dan interoperabilitas.

standar kepatuhan (baik umum dan industri-spesifik).
layanan identifikasi dan kategorisasi, provisioning dan pengiriman, serta pemantauan dan pelacakan.

Penelitian publik diterbitkan pertama layanan-orientasi dari perspektif industri yang diberikan oleh
Thomas Erl SOA Systems Inc yang didefinisikan delapan prinsip khusus layanan-orientasi umum untuk
semua platform SOA primer. Prinsip-prinsip ini telah dipublikasikan dalam "Service-Oriented
Architecture: Konsep, Teknologi, dan Desain", pada www.soaprinciples.com lokasi penelitian, dan
dalam edisi September 2005 dari Web Services Journal (lihat Layanan-orientasi).

Standar Kontrak Jasa - Layanan mematuhi perjanjian komunikasi, seperti yang didefinisikan secara
kolektif oleh satu atau lebih dokumen layanan-deskripsi.

Layanan Loose Coupling - Layanan menjaga hubungan yang meminimalkan dependensi dan hanya
mensyaratkan bahwa mereka mempertahankan kesadaran satu sama lain.

Layanan Abstraksi - Beyond deskripsi dalam kontrak layanan, layanan menyembunyikan logika dari
dunia luar.

Service Reusability - Logika dibagi menjadi layanan dengan tujuan mempromosikan penggunaan
kembali.

Otonomi Layanan - Layanan memiliki kendali atas logika mereka merangkum.

 Granularity Layanan - Pertimbangan desain untuk memberikan lingkup yang optimal dan tingkat
granular kanan fungsi bisnis dalam operasi pelayanan.

Layanan Tanpa Kewarganegaraan - Layanan mengurangi konsumsi sumber daya dengan menunda
pengelolaan informasi negara bila diperlukan

Layanan Discoverability - Layanan yang dilengkapi dengan meta data komunikatif dengan mana
mereka dapat secara efektif ditemukan dan ditafsirkan.

Layanan Composability - Layanan komposisi peserta efektif, terlepas dari ukuran dan kompleksitas
komposisi.

Beberapa penulis juga memasukkan prinsip-prinsip berikut:

Layanan Optimization - Semua, lain sama layanan berkualitas tinggi umumnya lebih baik untuk yang
berkualitas rendah.
Relevansi Layanan - Fungsi disajikan pada granularity diakui oleh pengguna sebagai layanan
bermakna.
Enkapsulasi layanan - layanan Banyak konsolidasi untuk penggunaan di bawah SOA tersebut.
Seringkali layanan tersebut tidak direncanakan berada di bawah SOA.
Lokasi Layanan Transparansi - ini mengacu pada kemampuan seorang konsumen layanan untuk
memanggil layanan terlepas dari lokasi sebenarnya di jaringan. Ini juga mengakui properti
discoverability (salah satu prinsip inti dari SOA) dan hak konsumen untuk mengakses layanan tersebut.
Sering kali, gagasan virtualisasi pelayanan juga berhubungan dengan transparansi lokasi. Di sinilah
konsumen hanya panggilan layanan logis sementara SOA runtime memungkinkan komponen
infrastruktur yang sesuai, umumnya layanan bis, peta ini logis layanan panggilan ke layanan fisik.

Referensi berikut ini memberikan pertimbangan tambahan untuk mendefinisikan implementasi SOA:

SOA Reference Architecture menyediakan desain kerja penerapan SOA enterprise-wide dengan
arsitektur diagram rinci, deskripsi komponen, persyaratan rinci, pola desain, pendapat tentang standar,
pola pada kepatuhan peraturan, standar template dll [9]
Manajemen siklus hidup SOA Praktisi Panduan Bagian 3: Pendahuluan kepada Layanan Lifecycle
memperkenalkan siklus layanan dan menyediakan proses rinci untuk manajemen jasa melalui siklus
hidup layanan, dari awal hingga pensiun atau repurposing jasa. Hal ini juga berisi lampiran yang
meliputi organisasi dan tata-praktik terbaik, template, komentar pada standar SOA kunci, dan
direkomendasikan link untuk informasi lebih lanjut.
Prinsip Desain SOA memberikan informasi lebih lanjut tentang realisasi SOA dengan menggunakan
prinsip desain Layanan

Selain itu, orang mungkin mengambil faktor-faktor berikut ke account user ketika menentukan sebuah
implementasi SOA:

Efisien penggunaan sumber daya sistem

Layanan jatuh tempo dan kinerja
EAI (Enterprise Integrasi Aplikasi)

[Sunting] Pendekatan Web layanan

Web services dapat mengimplementasikan service-oriented architecture. Layanan web membuat

bangunan-blok fungsional diakses melalui protokol Internet standar independen dari platform dan
bahasa pemrograman. Layanan ini dapat mewakili salah satu aplikasi baru atau hanya pembungkus
sekitar sistem warisan yang ada untuk membuat mereka jaringan-diaktifkan.

Setiap blok bangunan SOA dapat memainkan salah satu atau kedua dari dua peran:

Service Provider - Penyedia layanan menciptakan layanan web dan mungkin menerbitkan antarmuka
dan informasi akses ke registri layanan. Setiap penyedia layanan yang harus memutuskan untuk
mengekspos, bagaimana membuat trade-off antara keamanan dan ketersediaan mudah, bagaimana harga
layanan, atau (jika tidak dikenakan biaya) bagaimana / apakah untuk mengeksploitasi mereka untuk
nilai yang lain. Penyedia layanan juga harus memutuskan apa kategori layanan yang harus tercantum
dalam untuk layanan broker diberikan dan macam apa perjanjian mitra dagang yang diperlukan untuk
menggunakan layanan ini. Ini register layanan apa yang tersedia di dalamnya, dan daftar semua
penerima layanan potensial. Pelaksana broker kemudian memutuskan lingkup broker. Umum broker
tersedia melalui Internet, sementara broker swasta hanya diakses oleh khalayak yang terbatas, misalnya,
pengguna intranet perusahaan. Selain itu, jumlah informasi yang ditawarkan harus memutuskan.
Beberapa broker mengkhususkan diri pada banyak listing. Lain menawarkan tingkat kepercayaan yang
tinggi dalam layanan terdaftar. Beberapa mencakup pemandangan luas layanan dan fokus lain dalam
industri. Beberapa katalog broker broker lain. Tergantung pada model bisnis, broker dapat mencoba
untuk memaksimalkan Cari permintaan, jumlah daftar atau keakuratan dari daftar. The Universal
Deskripsi Discovery dan Integrasi (UDDI) mendefinisikan spesifikasi cara untuk mempublikasikan dan
menemukan informasi tentang layanan Web. teknologi selular lainnya broker termasuk (misalnya)
ebXML (Elektronik Bisnis menggunakan eXtensible Markup Language) dan mereka yang didasarkan
pada standar ISO / IEC 11179 artikel Registry (MDR).
konsumen Layanan - Para konsumen jasa atau klien layanan web menempatkan entri dalam registri
menggunakan berbagai broker menemukan operasi dan kemudian mengikat ke penyedia layanan untuk
memanggil salah satu layanan web. Apapun layanan-layanan kebutuhan konsumen, mereka harus bawa
ke broker, lalu mengikatnya dengan layanan masing-masing dan kemudian menggunakannya. Mereka
dapat mengakses berbagai layanan, jika layanan tersebut menyediakan berbagai layanan.

[Sunting] SOA dan protokol Web service

Pelaksana umumnya membangun SOA menggunakan layanan web standar (misalnya, SOAP) yang
telah mendapatkan penerimaan industri yang luas setelah rekomendasi dari Versi 1.2 dari W3C [10]
(World Wide Web Consortium) pada tahun 2003. Standar-standar ini (juga disebut sebagai spesifikasi
Web Service) juga menyediakan interoperabilitas yang lebih besar dan perlindungan dari lock-in vendor
perangkat lunak berpemilik. Satu bisa, bagaimanapun, menerapkan SOA menggunakan layanan
berbasis teknologi, seperti Jini, CORBA atau REST.
[sunting] konsep Lain SOA

Arsitektur dapat beroperasi secara independen dari teknologi tertentu [3] Desainer dapat
mengimplementasikan SOA menggunakan berbagai teknologi, termasuk.:

SOAP, RPC
REST
DCOM
CORBA
Layanan Web

DDS
WCF (implementasi Microsoft Layanan Web sekarang merupakan bagian dari WCF)

Implementasi dapat menggunakan salah satu atau lebih dari protokol dan, misalnya, mungkin
menggunakan mekanisme file sistem untuk berkomunikasi data sesuai dengan spesifikasi-interface
didefinisikan antara proses sesuai dengan konsep SOA. Kuncinya adalah layanan independen dengan
antarmuka yang didefinisikan yang dapat dipanggil untuk melakukan tugas mereka dengan cara standar,
tanpa servis yang mempunyai pengetahuan lebih dulu dari aplikasi yang memanggil, dan tanpa aplikasi
memiliki atau membutuhkan pengetahuan tentang bagaimana layanan ini benar-benar melakukan tugas-
tugasnya.

Banyak pelaksana SOA telah mulai [kapan?] untuk mengadopsi suatu evolusi dari konsep SOA menjadi
lebih maju [rujukan?] arsitektur disebut SOA 2.0.

SOA memungkinkan pengembangan aplikasi yang dibangun dengan menggabungkan layanan longgar
digabungkan dan interoperable. [12]

Layanan-layanan antar-beroperasi berdasarkan definisi formal (atau kontrak, misalnya, WSDL) yang
independen dari platform yang mendasari dan bahasa pemrograman. Definisi menyembunyikan
antarmuka pelaksanaan layanan bahasa tertentu. SOA berbasis sistem sehingga dapat berfungsi secara
independen dari perkembangan teknologi dan platform (seperti Java, NET,. dll). Layanan yang ditulis
dalam C # berjalan pada. Platform NET dan jasa ditulis di Jawa berjalan pada platform Java EE,
misalnya, bisa baik dikonsumsi oleh aplikasi komposit umum (atau klien). Aplikasi berjalan pada
platform baik juga dapat mengkonsumsi layanan yang berjalan di sisi lain sebagai layanan web yang
memfasilitasi reuse. Dikelola lingkungan juga dapat membungkus sistem warisan COBOL dan sekarang
mereka sebagai layanan perangkat lunak. Hal ini telah memperpanjang masa manfaat dari sistem
warisan banyak inti tanpa batas, tidak peduli apapun bahasa mereka awalnya digunakan.

SOA dapat mendukung aktivitas integrasi dan konsolidasi dalam sistem perusahaan yang kompleks, tapi
SOA tidak menentukan atau menyediakan metodologi atau kerangka kerja untuk mendokumentasikan
kemampuan atau jasa.

Bahasa tingkat tinggi seperti BPEL dan spesifikasi seperti WS-CDL dan WS-Koordinasi
memperpanjang konsep pelayanan dengan menyediakan sebuah metode mendefinisikan dan
mendukung orkestrasi layanan fine-grained ke lebih layanan bisnis kasar, yang arsitek pada gilirannya
dapat menggabungkan ke dalam alur kerja dan proses bisnis diimplementasikan dalam aplikasi
komposit atau portal [rujukan?].

Pada tahun 2008 peneliti telah mulai menyelidiki penggunaan Layanan Komponen Arsitektur (SCA)
untuk menerapkan SOA.

pemodelan berorientasi layanan [1] adalah sebuah kerangka kerja SOA yang mengidentifikasi berbagai
disiplin yang membimbing praktisi SOA untuk konsep, analisis, desain, dan arsitek aset mereka service-
oriented. Kerangka pemodelan berorientasi layanan (SOMF) menawarkan sebuah bahasa pemodelan
dan struktur bekerja atau "peta" yang menggambarkan berbagai komponen yang berkontribusi terhadap
pendekatan model layanan yang berorientasi sukses. Ini menggambarkan unsur-unsur utama yang
mengidentifikasi "apa yang harus dilakukan" aspek skema pengembangan pelayanan. Model ini
memungkinkan praktisi untuk kerajinan rencana proyek dan untuk mengidentifikasi tonggak dari
inisiatif layanan-oriented. SOMF juga menyediakan notasi pemodelan umum untuk alamat keselarasan
antara organisasi bisnis dan TI.

SOMF membahas prinsip-prinsip berikut:

bisnis ketertelusuran
arsitektur-praktik terbaik traceability
teknologi ketertelusuran
 SOA nilai proposisi
aset software reuse
Integrasi strategi SOA
teknologi abstraksi dan generalisasi
arsitektur komponen abstraksi

[Sunting] definisi SOA

Komentator telah memberikan beberapa definisi SOA. Kelompok OASIS [13] dan Open Group [14]
memiliki keduanya menciptakan definisi formal.

OASIS mendefinisikan SOA sebagai berikut:

Sebuah paradigma untuk mengatur dan memanfaatkan kemampuan terdistribusi yang mungkin berada
di bawah kendali kepemilikan domain yang berbeda. Menyediakan seragam sarana untuk menawarkan,
menemukan, berinteraksi dengan dan menggunakan kemampuan untuk menghasilkan efek yang
diinginkan sesuai dengan prasyarat terukur dan harapan.
[Sunting] kontrak layanan Programatik

Sebuah kontrak jasa kebutuhan [rujukan?] Untuk memiliki komponen-komponen berikut:

Header
Nama - Nama layanan. Ini harus mengindikasikan secara umum pelayanan apa tidak, bukan hanya
definisinya
Versi - Versi kontrak layanan ini
Pemilik - Orang / tim yang bertanggung jawab atas layanan
Tanggung jawab tugas (Raci)
Bertanggung jawab - Peran / orang / tim yang bertanggung jawab atas kontrak ini kiriman / jasa.
Semua versi dari kontrak
Akuntabel - Ultimate Pembuat Keputusan dalam hal kontrak ini / jasa
Dikonsultasikan - Siapa orang harus berkonsultasi sebelum tindakan diambil untuk kontrak ini /
jasa. Ini adalah komunikasi dua arah. Orang-orang ini berdampak pada keputusan atau pelaksanaan
keputusan itu.
Informasi - Siapa yang harus diberitahu bahwa keputusan atau tindakan yang sedang diambil.
Ini adalah komunikasi satu arah. Orang-orang ini dipengaruhi oleh keputusan atau eksekusi keputusan
itu, tetapi tidak memiliki kendali atas tindakan.
Tipe - Ini adalah jenis layanan: untuk membantu membedakan lapisan di mana ia berada.
implementasi yang berbeda akan memiliki jenis layanan yang berbeda. Contoh jenis pelayanan
meliputi:

Presentasi
Proses
Bisnis
Data
Integrasi
Fungsional
Kebutuhan Fungsional (dari Persyaratan Dokumen) - Menunjukkan fungsi dalam item bulet
spesifik - apa sebenarnya layanan ini menyelesaikan. Bahasa harus mendorong uji kasus untuk
membuktikan fungsionalitas dicapai.
Layanan Operasi - Metode, tindakan dll Harus ditentukan dalam hal apa bagian dari fungsi yang
disediakan.
Doa - Menunjukkan bagaimana untuk memanggil layanan tersebut. Ini termasuk URL, interface,
dll Mungkin ada beberapa jalur doa untuk layanan yang sama. Seseorang mungkin memiliki fungsi
yang sama untuk beberapa klien internal dan eksternal, masing-masing dengan cara doa yang berbeda
dan interface. Contoh:
SOAP
REST
Acara Pemicu
Non-Fungsional
Kendala Keamanan - Tetapkan yang dapat melaksanakan pelayanan ini dalam hal peran atau
individu dll mitra dan yang mekanisme pemanggilan mereka bisa memanggil.
Kualitas Layanan - Menentukan tingkat kegagalan diizinkan
Transaksional - Apakah ini yang mampu bertindak sebagai bagian dari transaksi yang lebih besar
dan jika demikian, bagaimana kita kontrol yang?
Service Level Agreement - Menentukan jumlah latency layanan diperbolehkan harus melakukan
tindakan yang
Semantik - menentukan atau mendefinisikan arti istilah yang digunakan dalam deskripsi dan
interface layanan
Proses - Menjelaskan proses, jika ada, dari layanan yang dikontrak

[Sunting] SOA dan arsitektur pengelolaan jaringan

Pada tahun 2008 prinsip-prinsip SOA sedang diterapkan [oleh siapa?] Untuk bidang manajemen
jaringan. Contoh arsitektur berorientasi layanan jaringan manajemen termasuk TS 188 001 NGN
Manajemen OSS Arsitektur dari ETSI, dan M.3060 Prinsip-Prinsip Manajemen Jaringan Next
Generation rekomendasi dari ITU-T.

Alat untuk mengelola infrastruktur SOA meliputi:

HP Software & Solusi

HyPerformix IPS Pengoptimal Kinerja
IBM Tivoli Framework
Red Hat JBoss Operasi Jaringan

[Sunting] Diskusi
[Sunting] Manfaat

Beberapa arsitek perusahaan percaya bahwa SOA dapat membantu perusahaan merespon lebih cepat
dan biaya-efektif untuk perubahan pasar-kondisi [15] Ini gaya arsitektur mempromosikan kembali pada
tingkat (layanan) makro dan bukan mikro (kelas) tingkat.. Hal ini juga dapat menyederhanakan
interkoneksi kepada - dan penggunaan - TI yang ada (warisan) aset.

Dalam beberapa hal, seseorang dapat menganggap SOA sebagai evolusi arsitektur daripada sebagai
revolusi. Ia menangkap banyak dari praktek-praktek terbaik dari arsitektur perangkat lunak sebelumnya.
Dalam sistem komunikasi, misalnya, pengembangan kecil telah tempat solusi yang menggunakan
binding benar-benar statis untuk berbicara dengan peralatan lain dalam jaringan. Dengan resmi
merangkul pendekatan SOA, sistem tersebut dapat memposisikan diri mereka untuk menekankan
pentingnya didefinisikan dengan baik, interface sangat antar-dioperasikan. [16]

Beberapa [siapa?] Telah mempertanyakan apakah SOA hanya menghidupkan konsep seperti
pemrograman modular (1970), desain acara berorientasi (1980) atau antarmuka / desain berbasis
komponen (1990) [rujukan?]. SOA mempromosikan tujuan memisahkan user (konsumen) dari
implementasi layanan. Layanan itu dapat dijalankan di berbagai platform didistribusikan dan diakses di
jaringan. Ini juga dapat memaksimalkan penggunaan kembali layanan [rujukan?].
SOA menyadari bisnis dan TI manfaat dengan menggunakan metodologi analisis dan desain saat
membuat jasa. Metodologi ini memastikan bahwa layanan tetap konsisten dengan visi arsitektur dan
peta jalan, dan bahwa mereka mematuhi prinsip-prinsip pelayanan-orientasi. Argumen yang mendukung
aspek bisnis dan manajemen dari SOA diuraikan dalam berbagai publikasi. [17]

Layanan terdiri dari unit yang berdiri sendiri dari fungsi yang tersedia hanya melalui antarmuka yang
ditetapkan secara formal. Layanan dapat menjadi semacam "-perusahaan nano" yang mudah untuk
menghasilkan dan meningkatkan. Juga layanan dapat "mega-korporasi" dibangun sebagai karya
dikoordinasikan layanan sub-ordinat.

Layanan umum mematuhi prinsip-prinsip berikut layanan-orientasi: [18]

abstraksi
otonomi
composability
discoverability
formal kontrak
lepas kopling
reusabilitas
Tanpa Kewarganegaraan

Sebuah peluncuran dewasa SOA efektif mendefinisikan API organisasi.

Alasan untuk mengobati pelaksanaan pelayanan sebagai proyek terpisah dari proyek-proyek besar
meliputi:

Pemisahan mempromosikan konsep dengan bisnis bahwa layanan dapat disampaikan dengan cepat
dan independen dari proyek yang lebih besar yang bergerak lambat dan umum dalam organisasi. bisnis
dimulai sistem pemahaman dan antarmuka pengguna disederhanakan menyerukan layanan. Ini
kelincahan pendukung. Artinya, itu mendorong inovasi bisnis dan mempercepat waktu-pasar-. [19]
Pemisahan mempromosikan decoupling jasa dari proyek mengkonsumsi. Hal ini mendorong desain
yang baik sepanjang layanan dirancang tanpa tahu siapa konsumen perusahaan.
Dokumentasi dan uji artefak pelayanan tersebut tidak tertanam dalam detail dari proyek yang lebih
besar. Hal ini penting pada saat jasa harus digunakan kembali nanti.

Keuntungan tidak langsung dari SOA melibatkan secara dramatis disederhanakan pengujian. Layanan
otonom, tanpa negara, dengan antarmuka sepenuhnya didokumentasikan, dan terpisah dari masalah
lintas sektor pelaksanaan. Industri [mana?] Belum pernah terkena keadaan ini sebelum. [Rujukan?]

Jika organisasi memiliki ditetapkan secara sesuai data tes, maka rintisan yang sesuai dibangun yang
bereaksi terhadap data uji ketika layanan sedang dibangun. Sebuah set lengkap uji regresi, script, data,
dan tanggapan juga ditangkap untuk layanan ini. Layanan ini dapat diuji sebagai Rintisan menggunakan
'kotak hitam' yang ada sesuai dengan jasa yang panggilan. Test lingkungan bisa dibangun di mana
primitif dan keluar-layanan-lingkup yang bertopik, sedangkan sisanya mesh adalah uji penyebaran
layanan penuh. Seperti setiap antarmuka sepenuhnya didokumentasikan dengan mengatur sendiri penuh
dokumentasi uji regresi, menjadi sederhana untuk mengidentifikasi masalah pada layanan uji. Pengujian
berevolusi untuk hanya memvalidasi bahwa layanan uji beroperasi sesuai dengan dokumentasi, dan
menemukan kesenjangan dalam kasus dokumentasi dan tes semua jasa di dalam lingkungan. Mengelola
negara layanan data idempoten adalah kompleksitas saja.

Contoh mungkin berguna untuk membantu dalam mendokumentasikan layanan ke tingkat di mana ia
menjadi berguna. Dokumentasi dari beberapa API dalam Java Community Process memberikan contoh
yang baik. Seperti ini lengkap, staf biasanya akan menggunakan hanya subset penting. File 'ossjsa.pdf'
dalam JSR-89 contoh file seperti itu. [20]
[Sunting] Tantangan dalam mengadopsi SOA

Salah satu tantangan yang jelas dan umum yang dihadapi meliputi pengelolaan layanan metadata
[rujukan?]. lingkungan berbasis SOA dapat mencakup banyak layanan yang bertukar pesan untuk
melakukan tugas. Tergantung pada desain, sebuah aplikasi tunggal dapat menghasilkan jutaan pesan.
Mengelola dan memberikan informasi tentang bagaimana layanan berinteraksi bisa menjadi kompleks.
Hal ini menjadi lebih rumit ketika layanan ini disampaikan oleh organisasi yang berbeda dalam
perusahaan atau bahkan perusahaan yang berbeda (rekanan, pemasok, dll). Hal ini menciptakan masalah
kepercayaan besar di seluruh tim, dan karenanya SOA Kelola datang ke dalam gambar.

Tantangan lain melibatkan kurangnya pengujian dalam ruang SOA. Tidak ada alat canggih yang
menyediakan testability dari semua layanan tanpa kepala (termasuk pesan dan layanan database
bersama dengan layanan web) dalam arsitektur khas. Kurangnya kepercayaan horisontal membutuhkan
baik produsen dan konsumen layanan uji secara terus menerus. Tujuan utama SOA adalah untuk
memberikan Agility untuk Bisnis [rujukan?]. Oleh karena itu penting untuk berinvestasi dalam
kerangka pengujian (membangun atau membeli) yang akan memberikan visibilitas yang diperlukan
untuk menemukan pelakunya dalam arsitektur. kelincahan Bisnis memerlukan SOA jasa yang
dikendalikan oleh tujuan bisnis dan arahan sebagaimana didefinisikan dalam Model Motivasi Bisnis
(BMM). [21]

Tantangan lainnya berkaitan dengan tingkat yang tepat menyediakan keamanan. model Keamanan
dibangun ke aplikasi mungkin tidak lagi cukup bila aplikasi memperlihatkan kemampuan sebagai
layanan yang dapat digunakan oleh aplikasi lain. Artinya, keamanan aplikasi yang dikelola bukan model
yang tepat untuk mengamankan layanan. Sejumlah teknologi baru dan standar sudah mulai [kapan?]
Untuk muncul dan menyediakan model yang lebih tepat untuk keamanan di SOA.

Sebagai SOA dan spesifikasi WS-* praktisi mengembangkan, memperbaharui dan menyempurnakan
output mereka, mereka menghadapi kekurangan orang terampil untuk bekerja pada sistem berbasis
SOA, termasuk integrasi layanan dan pembangunan infrastruktur layanan.

Interoperabilitas menjadi aspek penting dari implementasi SOA. The WS-I organisasi telah
mengembangkan Basic Profile (BP) dan Keamanan Dasar Profile (BSP) untuk menegakkan
kompatibilitas. [22] WS-I telah merancang pengujian alat untuk membantu menilai apakah layanan web
sesuai dengan pedoman WS-I profil. Selain itu, piagam lain telah dibentuk untuk bekerja pada Reliable
Secure Profile.

Signifikan vendor hype mengelilingi SOA, yang dapat membuat harapan berlebihan. tumpukan Produk
terus berkembang sebagai pengadopsi awal pengujian produk pengembangan dan runtime dengan
masalah di dunia nyata. SOA tidak menjamin mengurangi biaya TI, meningkatkan kelincahan sistem
atau lebih cepat waktu-ke-pasar. Sukses implementasi SOA mungkin menyadari beberapa atau semua
manfaat tersebut tergantung pada kualitas dan relevansi dari arsitektur sistem dan desain. [23] [24]

Internal organisasi TI pengiriman secara rutin melakukan upaya SOA, dan beberapa di antaranya tidak
benar memperkenalkan konsep untuk bisnis [rujukan?] Sehingga tetap disalahpahami [oleh siapa?].
adopsi mulai memenuhi kebutuhan TI pengiriman bukan orang-orang dari bisnis, sehingga dalam suatu
organisasi dengan, misalnya, layanan provisioning laptop superlatif, bukan hanya satu yang bisa dengan
cepat merespon peluang pasar. kepemimpinan bisnis juga menjadi yakin bahwa organisasi ini
melaksanakan baik di SOA.
Salah satu manfaat paling penting dari SOA adalah kemudahan reuse. Oleh karena itu akuntabilitas dan
pendanaan model akhirnya harus berkembang dalam organisasi. [Rujukan?] Sebuah unit usaha perlu
didorong untuk menciptakan layanan yang unit lain akan digunakan. Sebaliknya, unit harus didorong
untuk menggunakan kembali layanan. Hal ini memerlukan beberapa komponen pemerintahan baru:

Setiap unit usaha menciptakan layanan harus memiliki struktur dukungan yang sesuai di tempat
untuk memenuhi kewajibannya tingkat layanan, dan untuk mendukung peningkatan layanan yang telah
ada hanya untuk kepentingan orang lain. Hal ini biasanya cukup asing bagi pemimpin bisnis.
Setiap unit usaha jasa mengkonsumsi menerima resiko tampak dari menggunakan kembali layanan di
luar kendali mereka sendiri, dengan dependensi petugas proyek eksternal, dll
Model pendanaan yang inovatif diperlukan sebagai insentif untuk mendorong perilaku tersebut di
atas. [Rujukan?] Bisnis unit biasanya membayar Organisasi TI untuk membantu selama proyek, dan
kemudian untuk mengoperasikan lingkungan. insentif Perusahaan harus diskon biaya-biaya tersebut ke
penyedia layanan, dan menciptakan internal pendapatan-aliran dari unit bisnis mengkonsumsi ke
penyedia layanan. [rujukan?] Ini sungai harus kurang daripada biaya seorang konsumen hanya
bangunan dengan cara kuno. Ini adalah tempat penyebaran SOA bisa mendapatkan keuntungan dari
arsitektur monetisasi SaaS. [25]

[Sunting] Kritik terhadap SOA

Beberapa kritik [26] dari SOA tergantung pada conflating SOA dengan layanan Web. Sebagai contoh,
beberapa kritikus [siapa?] Hasil SOA klaim pada penambahan lapisan XML, memperkenalkan parsing
XML dan komposisi. Dengan tidak adanya bentuk asli atau biner dari Remote Procedure Call (RPC),
aplikasi dapat berjalan lebih lambat dan memerlukan daya proses yang lebih, meningkatkan biaya.
Kebanyakan implementasi dikenakan biaya overhead ini, tapi SOA dapat diimplementasikan
menggunakan teknologi (misalnya, Java Business Integration (JBI) dan Distribusi Data Service (DDS))
yang tidak bergantung pada prosedur panggilan jarak jauh atau terjemahan melalui XML. Pada saat
yang sama, muncul open-source XML parsing teknologi (seperti VTD-XML) dan berbagai format XML
yang kompatibel biner berjanji untuk secara signifikan meningkatkan kinerja SOA. [27] [28] [29]

Stateful memerlukan layanan konsumen maupun penyedia untuk berbagi konteks konsumen tertentu
yang sama, yang baik termasuk dalam atau dirujuk oleh pesan dipertukarkan antara penyedia dan
konsumen. kendala ini memiliki kelemahan yang bisa mengurangi skalabilitas keseluruhan penyedia
layanan jika layanan penyedia perlu untuk mempertahankan konteks bersama untuk setiap konsumen.
Hal ini juga meningkatkan coupling antara penyedia layanan dan konsumen dan membuat penyedia
layanan switching lebih sulit. [30] Pada akhirnya, beberapa kritikus merasa bahwa layanan SOA masih
terlalu dibatasi oleh aplikasi yang mereka wakili. [31]

Masalah lain berkaitan dengan evolusi yang sedang berlangsung standar WS-* dan produk-produk
(misalnya, transaksi, keamanan), dan SOA sehingga dapat memperkenalkan risiko baru kecuali dikelola
dengan baik dan diperkirakan dengan anggaran tambahan dan darurat untuk tambahan bukti-kerja-
konsep.

Beberapa kritik [siapa?] SOA menganggap sebatas sebagai evolusi arsitektur jelas saat ini baik
digunakan (antarmuka terbuka, dll).

desain sistem TI kadang-kadang mengabaikan keinginan untuk memodifikasi sistem siap. Banyak
sistem, termasuk sistem berbasis SOA, hard-kode operasi, barang dan jasa organisasi, sehingga
membatasi layanan online mereka dan kelincahan bisnis di pasar global. [rujukan?]

Berikutnya [yang?] Langkah dalam proses desain mencakup definisi Pelayanan Platform (SDP) dan
pelaksanaannya. Pada tahap desain SDP salah mendefinisikan model informasi bisnis, manajemen
identitas, produk, konten, perangkat, dan karakteristik layanan pengguna akhir, serta bagaimana sistem
tangkas sehingga dapat menangani dengan evolusi bisnis dan perusahaan pelanggan.
[Sunting] Manifesto SOA

Pada bulan Oktober 2009, di SOA Simposium Internasional ke-2, kelompok campuran dari 17 praktisi
SOA independen dan vendor, yang "Manifesto SOA Kelompok Kerja", mengumumkan penerbitan
Manifesto SOA. [32] Manifesto SOA adalah seperangkat tujuan dan prinsip panduan yang bertujuan
untuk memberikan pemahaman yang jelas dan visi SOA dan layanan-orientasi. Tujuannya adalah
menyelamatkan konsep SOA dari penggunaan berlebihan istilah oleh komunitas vendor dan "proliferasi
tampaknya tak berujung misinformasi dan kebingungan". [2]

Manifesto ini menyediakan definisi yang luas dari SOA, nilai-nilai yang diwakilinya untuk
penandatangan dan beberapa prinsip. Manifesto memprioritaskan:

Bisnis nilai lebih dari strategi teknis.

Sasaran-sasaran strategis di atas manfaat proyek-spesifik.
Intrinsik interoperabilitas atas integrasi kustom.
Shared layanan melalui implementasi spesifik-tujuan.
Fleksibilitas atas optimasi.
Evolusi penyempurnaan atas pengejaran kesempurnaan awal.

Sumber: http://en.wikipedia.org/wiki/Service-oriented_architecture