EAI didefinisikan sebagai penggunaan perangkat lunak sistem
dan prinsip-prinsip arsitektur komputer untuk mengintegrasikan seperangkat
aplikasi komputer perusahaan.
Pengembangan Aplikasi (EAI) adalah sebuah
kerangka integrasi terdiri dari kumpulan teknologi dan layanan yang membentuk middleware untuk
memungkinkan integrasi sistem dan aplikasi di seluruh perusahaan.
Supply chain management aplikasi (untuk
mengelola persediaan dan pengiriman), customer relationship management aplikasi (untuk mengelola pelanggan saat ini
dan potensi), intelijen bisnis aplikasi
(untuk menemukan pola dari data yang ada dari operasi), dan jenis-jenis
aplikasi (untuk mengelola data seperti sumber daya
manusia data, perawatan kesehatan, komunikasi internal, dll)
biasanya tidak dapat berkomunikasi dengan satu sama lain untuk berbagi data
atau aturan bisnis. Untuk alasan ini, aplikasi seperti kadang-kadang
disebut sebagai pulau
otomatisasi atau silo informasi .Kurangnya
komunikasi menyebabkan inefisiensi, data identik dimana disimpan di beberapa
lokasi, atau proses langsung tidak dapat otomatis.
Perusahaan integrasi aplikasi (EAI) adalah
proses menghubungkan aplikasi tersebut dalam satu organisasi bersama dalam
rangka untuk mempermudah dan mengotomatisasi proses bisnis untuk sejauh
mungkin, sementara pada saat yang sama menghindari harus membuat perubahan
besar untuk aplikasi yang ada atau struktur data . Dalam kata-kata dari Gartner Group ,
EAI adalah "berbagi tak terbatas dari data dan proses bisnis antara setiap
sumber aplikasi atau data yang terhubung dalam perusahaan." [1]
Salah satu tantangan besar EAI adalah bahwa
berbagai sistem yang perlu dihubungkan bersama sering berada pada berbagai sistem operasi ,
gunakan berbeda basis data solusi
dan berbeda bahasa komputer ,
dan dalam beberapa kasus adalah warisan sistem yang
tidak lagi didukung oleh vendor yang awalnya dibuat 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 mengubah mereka
dengan cara apapun.
Tujuan
EAI dapat digunakan untuk berbagai tujuan:
§ Integrasi data : Memastikan bahwa
informasi dalam beberapa sistem disimpan konsisten. Hal ini juga dikenal
sebagai Integrasi
Informasi Enterprise (EII).
§ Kemerdekaan Vendor: Ekstrak
bisnis kebijakan 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
dilaksanakan.
§ Fasad Umum: Sebuah sistem
EAI dapat front-end sekelompok aplikasi, menyediakan antarmuka akses tunggal
yang konsisten untuk aplikasi ini dan melindungi pengguna dari keharusan untuk
belajar menggunakan paket software yang berbeda.
Pola
Integrasi pola
Ada dua pola yang sistem EAI melaksanakan:
Mediasi (intra-komunikasi)
Di sini, sistem EAI bertindak sebagai perantara atau broker
antara beberapa aplikasi. Setiap kali sebuah peristiwa menarik terjadi
pada aplikasi (misalnya, informasi baru dibuat atau transaksi baru selesai)
modul integrasi dalam sistem EAI diberitahu. Modul ini kemudian
menyebarkan perubahan ke aplikasi lain yang relevan.
Federasi (antar-komunikasi)
Dalam hal ini, sistem EAI bertindak sebagai fasad menyeluruh
di beberapa aplikasi. Acara Semua panggilan dari 'dunia luar' ke salah
satu aplikasi front-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 yang sering digunakan secara bersamaan. Sistem
EAI sama dapat menjaga beberapa aplikasi di sync (mediasi), sementara melayani
permintaan dari pengguna eksternal terhadap aplikasi ini (federasi).
pola Akses
EAI mendukung pola akses baik asinkron dan sinkron, yang
pertama menjadi khas dalam hal mediasi dan yang terakhir dalam kasus federasi.
Pola Lifetime
Sebuah operasi integrasi bisa berumur pendek (data menjaga
misalnya di sync di dua aplikasi dapat diselesaikan dalam satu detik) atau
berumur panjang (misalnya salah satu langkah bisa melibatkan sistem EAI
berinteraksi dengan manusia alur kerja permohonan persetujuan dari pinjaman
yang mengambil jam atau hari untuk menyelesaikan).
Topologies
Ada dua utama topologi: hub-dan-berbicara , dan bus . Masing-masing memiliki
kelebihan dan kekurangan. Dalam model hub-dan-berbicara, sistem EAI adalah
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 pesan yang berorientasi middleware ).
Teknologi
Beberapa teknologi yang digunakan dalam melaksanakan
masing-masing komponen dari sistem EAI:
Bus / hub
Hal ini biasanya diimplementasikan dengan meningkatkan
standar middleware produk ( aplikasi server , bus pesan) atau
diimplementasikan sebagai program yang berdiri sendiri (yaitu, 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
untuk berinteraksi dengan aplikasi bisnis yang mendasarinya. Adaptor
melakukan komunikasi dua arah, melakukan permintaan dari pusat terhadap
aplikasi, dan memberitahu hub ketika suatu peristiwa yang menarik terjadi dalam
aplikasi (rekor baru dimasukkan, transaksi selesai, dll). Adapter dapat
spesifik untuk sebuah aplikasi (misalnya, dibangun terhadap librari klien
vendor aplikasi) atau khusus untuk kelas aplikasi (misalnya, dapat berinteraksi
dengan aplikasi apapun melalui protokol komunikasi standar, seperti SOAP , SMTP atau Action Message Format (AMF )). Adaptor
ini dapat menetap dalam ruang proses yang sama dengan bis / hub atau
mengeksekusi di lokasi terpencil dan berinteraksi dengan hub / bus melalui
protokol standar industri seperti antrian pesan, layanan web, atau bahkan
menggunakan protokol khusus. 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 format setiap aplikasi lain, sistem EAI biasanya menetapkan
aplikasi-independen (atau umum) format data. Sistem EAI biasanya
menyediakan layanan transformasi data juga untuk membantu mengkonversi antara
format aplikasi khusus dan umum. Hal ini dilakukan dalam dua langkah:
adaptor mengkonversi informasi dari format aplikasi ke format umum bus itu. Kemudian,
transformasi semantik yang diterapkan pada ini (mengkonversi kode pos untuk
nama kota, membelah / penggabungan objek dari satu aplikasi ke objek dalam
aplikasi lain, dan sebagainya).
Integrasi modul
Sebuah sistem EAI dapat berpartisipasi dalam beberapa
operasi integrasi bersamaan pada waktu tertentu, setiap jenis integrasi sedang
diproses oleh modul integrasi yang berbeda. Integrasi modul berlangganan
peristiwa tipe tertentu dan pemberitahuan proses yang mereka terima saat
peristiwa ini terjadi. Modul-modul ini dapat diterapkan dengan cara yang
berbeda: di Jawa berbasis sistem EAI, ini bisa
menjadi aplikasi web atau EJBs atau bahkan POJOs yang sesuai dengan spesifikasi sistem EAI itu.
Dukungan untuk transaksi
Ketika digunakan untuk integrasi proses, sistem EAI juga
menyediakan konsistensi transaksional di seluruh aplikasi dengan menjalankan
semua operasi integrasi di semua aplikasi dalam transaksi didistribusikan
tunggal menyeluruh (menggunakan dua fase komit protokol atau transaksi kompensasi ).
Komunikasi arsitektur
Saat ini, ada banyak variasi pemikiran tentang apa yang
merupakan infrastruktur terbaik, model komponen, dan struktur standar untuk
Integrasi Aplikasi Enterprise. Sepertinya ada konsensus bahwa empat
komponen penting untuk arsitektur aplikasi integrasi perusahaan modern:
Seorang broker terpusat yang menangani keamanan, akses, dan
komunikasi. Hal ini dapat dicapai melalui server integrasi (seperti Sekolah Interoperabilitas Framework
(SIF) Zona Server Integrasi) atau melalui software yang serupa seperti layanan bis perusahaan (ESB) model yang
bertindak sebagai manajer layanan SOAP yang berorientasi.
Sebuah model data independen didasarkan pada struktur data
standar, yang juga dikenal sebagai model data kanonik . Tampaknya XML dan penggunaan
style sheet XML telah menjadi de factodan dalam beberapa kasus de jure standar untuk bahasa bisnis seragam.
Sebuah konektor, atau model agen di mana masing-masing
vendor, aplikasi, atau interface dapat membangun komponen tunggal yang dapat
berbicara secara native untuk aplikasi itu dan berkomunikasi dengan broker
terpusat.
Sebuah model sistem yang mendefinisikan API, aliran data dan
aturan keterlibatan dengan sistem sehingga komponen dapat dibangun untuk
antarmuka dengan itu dengan cara standar.
Meskipun pendekatan-pendekatan lain seperti menghubungkan
pada tingkat database atau user interface telah dieksplorasi, mereka belum
ditemukan untuk skala atau dapat menyesuaikan diri.Aplikasi individu dapat
mempublikasikan pesan ke broker terpusat dan berlangganan untuk menerima pesan
tertentu dari broker itu. Setiap aplikasi hanya membutuhkan satu koneksi
kepada broker.Pendekatan kontrol pusat dapat sangat scalable dan sangat evolvable .
Pengembangan Aplikasi ini terkait dengan middleware teknologi seperti
pesan-berorientasi
middleware ( MOM ), dan teknologi
representasi data seperti XML . Lain EAI teknologi melibatkan
menggunakan layanan web sebagai bagian dari arsitektur berorientasi
layanan sebagai
alat integrasi. Pengembangan Aplikasi cenderung data sentris. Dalam
waktu dekat, akan datang untuk memasukkan integrasi konten dan proses
bisnis .
Implementasi perangkap
Pada tahun 2003 dilaporkan bahwa 70% dari semua proyek EAI
gagal. Sebagian besar kegagalan tidak karena perangkat lunak itu sendiri
atau kesulitan teknis, tetapi karena masalah manajemen.Integrasi Konsorsium
Eropa Ketua Steve Craggs telah menggariskan tujuh perangkap utama yang
dilakukan oleh perusahaan yang menggunakan sistem EAI dan menjelaskan solusi
untuk masalah ini.
Perubahan konstan: Sifat EAI adalah dinamis dan membutuhkan
manajer proyek yang dinamis untuk mengelola pelaksanaannya.
Kekurangan ahli EAI : EAI membutuhkan pengetahuan
tentang banyak hal dan aspek teknis.
Bersaing standar: Dalam bidang EAI, paradoks adalah bahwa
EAI standar sendiri tidak universal.
EAI adalah paradigma alat: EAI bukanlah alat, melainkan
sistem dan harus dilaksanakan seperti itu.
Membangun interface adalah seni: Teknik solusinya 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.
Hilangnya detail: Informasi yang tidak penting pada tahap
awal dapat menjadi penting kemudian.
Akuntabilitas: Karena begitu banyak departemen memiliki
kebutuhan yang banyak bertentangan, harus ada pertanggungjawaban yang jelas
untuk struktur akhir sistem.
Potensi masalah lain mungkin muncul dalam daerah-daerah:
Emerging Persyaratan: EAI implementasi harus extensible dan
modular untuk memungkinkan perubahan masa depan.
Proteksionisme: Aplikasi yang data sedang diintegrasikan
sering milik berbagai departemen yang memiliki alasan teknis, budaya, dan
politik karena tidak ingin berbagi data dengan departemen lain.
