Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Aplikasi yang berbagi program
Diagram berikut menggambarkan aplikasi mainframe A dan B yang menjalankan program bersama yang disebut program AB.1. Kasus ini juga berlaku ketika aplikasi A dan B menyertakan program yang memanggil subprogram bersama.
![\[Mainframe applications that share programs\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared.png)
**Langkah-langkah untuk analisis**
1. Lakukan analisis dampak dari program bersama AB.1, sehingga Anda dapat memigrasikan aplikasi A dan B, dan memprogram AB.1 bersama-sama. Sebaiknya gunakan alat penemuan yang tercantum di bagian [Sumber daya tambahan](resources.md) untuk mengotomatiskan analisis.
1. Berdasarkan analisis dampak, identifikasi jumlah aplikasi dependen yang menggunakan program bersama seperti program AB.1.
1. (Disarankan) Selesaikan analisis domain bisnis untuk menentukan apakah program bersama dapat digabungkan ke dalam domain dengan aplikasi dan diekspos sebagai API sebagai salah satu layanan domain.
Anda dapat menggunakan salah satu pendekatan berikut untuk memisahkan aplikasi dalam persiapan migrasi:
+ [Menggunakan API mandiri](api.md)
+ [Menggunakan pustaka bersama](library.md)
+ [Menggunakan antrian pesan](queue.md)
# Pendekatan 1: Pisahkan dengan menggunakan API mandiri
Saat Anda menggunakan pendekatan ini, Anda membuat instance API mandiri dengan mengonversi program COBOL bersama AB.1 menjadi program Java. Untuk meminimalkan upaya refactoring, Anda dapat menggunakan alat refactoring otomatis yang disediakan oleh AWS Mitra (lihat bagian [Sumber daya tambahan](resources.md)) untuk menghasilkan jaringan untuk program. APIs Beberapa alat dapat secara otomatis menghasilkan lapisan fasad dari program yang dipilih dengan menggunakan lingkungan pengembangan terintegrasi (IDE) seperti Eclipse.
Kami merekomendasikan pendekatan ini ketika program bersama dapat dipakai sebagai layanan mandiri. Komponen aplikasi A dan B yang tersisa difaktorkan ulang ke Java secara keseluruhan dan dimigrasikan ke cloud. Anda dapat memigrasikan aplikasi dalam gelombang yang sama atau dalam gelombang yang berbeda.
## Migrasi aplikasi dalam gelombang yang sama
Dalam diagram berikut, aplikasi A dan B dikelompokkan untuk dimigrasikan dalam gelombang yang sama.
![\[Migrating mainframe applications that share programs: using an standalone API and a single migration wave\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-1-same.png)
Jika Anda memisahkan kode dengan menggunakan API mandiri dan memigrasikan aplikasi dalam gelombang yang sama, ikuti langkah-langkah berikut:
1. Refactor kedua aplikasi dengan program masing-masing dan memigrasikannya ke cloud.
1. Gunakan laporan analisis dampak dari fase analisis untuk membantu pengembang dan tim mengidentifikasi aplikasi refactored yang memanggil program bersama AB.1. Ganti panggilan program dalam ke program bersama AB.1 dengan panggilan API jaringan.
1. Setelah migrasi, hentikan aplikasi mainframe lokal dan komponennya.
## Migrasi aplikasi dalam gelombang yang berbeda
Ketika aplikasi terlalu besar untuk dikelompokkan ke dalam gelombang migrasi yang sama, Anda dapat memigrasikannya dalam beberapa gelombang, seperti yang ditunjukkan pada diagram berikut, dan mempertahankan kontinuitas layanan selama migrasi. Dengan pendekatan ini, Anda dapat memodernisasi aplikasi Anda secara bertahap tanpa menggabungkannya. Migrasi aplikasi Anda dalam gelombang terpisah memisahkan mereka tanpa memerlukan perubahan kode yang signifikan pada mainframe.
![\[Migrating mainframe applications that share programs: using an standalone API and multiple migration waves\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-1-diff.png)
Jika Anda memisahkan kode dengan menggunakan API mandiri dan memigrasikan aplikasi dalam gelombang yang berbeda, ikuti langkah-langkah berikut:
1. Migrasikan (refactor) aplikasi A dengan program terkait ke cloud sementara aplikasi B terus berada di tempat.
1. Dalam aplikasi A, ganti panggilan program dalam ke program bersama AB.1 dengan panggilan API.
1. Simpan salinan program AB.1 pada mainframe sehingga aplikasi B dapat terus beroperasi.
1. Bekukan pengembangan fitur program AB.1 pada mainframe. Setelah titik ini, semua pengembangan fitur akan berlangsung di program refactored AB.1 di cloud.
1. Setelah aplikasi A berhasil dimigrasi, hentikan aplikasi lokal dan komponennya (tidak termasuk program bersama). Aplikasi B dan komponennya (termasuk program bersama) terus berada di tempat.
1. Pada rangkaian gelombang migrasi berikutnya, migrasi aplikasi B dan komponennya. Anda dapat memanggil program yang dimigrasi dan difaktorkan ulang AB.1 untuk mengurangi upaya refactoring untuk aplikasi B.
# Pendekatan 2: Pisahkan dengan menggunakan pustaka bersama
Dalam pendekatan ini, program bersama AB.1 diubah menjadi perpustakaan umum Java dan dikemas dengan aplikasi untuk migrasi. Kami merekomendasikan pendekatan ini ketika program bersama adalah pustaka pendukung, bukan layanan mandiri.
Komponen aplikasi A dan B yang tersisa difaktorkan ulang ke program Java dan dimigrasikan ke cloud. Anda dapat memigrasikan aplikasi dalam gelombang yang sama atau dalam gelombang yang berbeda.
## Migrasi aplikasi dalam gelombang yang sama
Dalam diagram berikut, aplikasi A dan B dikelompokkan untuk dimigrasikan dalam gelombang yang sama.
![\[Migrating mainframe applications that share programs: using a common library and a single migration wave\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-2-same.png)
Jika Anda memisahkan kode dengan menggunakan pustaka bersama dan memigrasikan aplikasi dalam gelombang yang sama, ikuti langkah-langkah berikut:
1. Refactor aplikasi A dan B dengan program terkait mereka ke Java dan memigrasikannya ke cloud.
1. Pertahankan kode sumber aplikasi dalam layanan kontrol sumber yang dikelola sepenuhnya. Tim yang menggunakan program bersama dapat berkolaborasi pada perubahan kode dengan menggunakan permintaan tarik, percabangan, dan penggabungan, dan dapat mengontrol perubahan yang dibuat pada kode program bersama.
1. Setelah migrasi, hentikan aplikasi mainframe lokal dan komponennya.
## Migrasi aplikasi dalam gelombang yang berbeda
Ketika aplikasi terlalu besar untuk dikelompokkan ke dalam gelombang migrasi yang sama, Anda dapat memigrasikannya dalam beberapa gelombang, seperti yang ditunjukkan pada diagram berikut, dan mempertahankan kontinuitas layanan selama migrasi. Dengan pendekatan ini, Anda dapat memodernisasi aplikasi Anda secara bertahap tanpa menggabungkannya. Migrasi aplikasi Anda dalam gelombang terpisah memisahkan mereka tanpa memerlukan perubahan kode yang signifikan pada mainframe.
![\[Migrating mainframe applications that share programs: using a common library and multiple migration waves\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-2-diff.png)
Jika Anda memisahkan kode dengan menggunakan pustaka bersama dan memigrasikan aplikasi dalam gelombang yang berbeda, ikuti langkah-langkah berikut:
1. Migrasikan (refactor) aplikasi A dengan program terkait ke cloud sementara aplikasi B terus berada di tempat.
1. Simpan salinan program AB.1 pada mainframe sehingga aplikasi B dapat terus beroperasi.
1. Bekukan pengembangan fitur program AB.1 pada mainframe. Pada titik ini, semua pengembangan fitur akan berlangsung di program refactored AB.1 di cloud.
1. Saat mengembangkan fitur baru untuk program AB.1, pertahankan kompatibilitas mundur untuk mendukung migrasi aplikasi B di gelombang masa depan.
1. Setelah aplikasi A berhasil dimigrasi, hentikan aplikasi lokal dan komponennya (tidak termasuk program bersama). Aplikasi B dan komponennya (termasuk program bersama) terus berada di tempat.
1. Pada rangkaian gelombang migrasi berikutnya, migrasi aplikasi B dan komponennya. Anda dapat menggunakan perpustakaan bersama terbaru dari program AB.1 di cloud untuk mengurangi upaya refactoring untuk aplikasi B.
# Pendekatan 3: Pisahkan dengan menggunakan antrian pesan
Dalam pendekatan ini, program bersama AB.1 diubah menjadi program Java dan bermigrasi ke cloud sebagai bagian dari aplikasi A. Antrian pesan digunakan sebagai antarmuka antara aplikasi refactored di cloud dan aplikasi lama di tempat. Dengan menggunakan pendekatan ini, Anda dapat memecah aplikasi mainframe yang digabungkan erat menjadi produsen dan konsumen, dan membuatnya lebih modular sehingga dapat berfungsi secara mandiri. Keuntungan tambahannya adalah Anda dapat memigrasikan aplikasi dalam gelombang yang berbeda.
Kami menyarankan Anda menggunakan pendekatan ini ketika:
+ Aplikasi yang berada di mainframe dapat berkomunikasi dengan aplikasi yang dimigrasi di cloud melalui antrian pesan.
+ Beberapa salinan program AB.1 (misalnya, salinan lokal dan salinan cloud, seperti pada dua pendekatan sebelumnya) tidak dapat dipertahankan.
+ Pola arsitektur antrian memenuhi persyaratan bisnis untuk aplikasi yang berada di mainframe, karena melibatkan arsitektur ulang aplikasi yang ada.
+ Aplikasi yang bukan bagian dari gelombang pertama membutuhkan waktu yang lebih lama (enam bulan atau lebih) untuk dimigrasikan ke cloud.
## Migrasi aplikasi dalam gelombang yang berbeda
Ketika aplikasi terlalu besar untuk dikelompokkan ke dalam gelombang migrasi yang sama, Anda dapat memigrasikannya dalam beberapa gelombang, seperti yang ditunjukkan pada diagram berikut, dan mempertahankan kontinuitas layanan selama migrasi. Dengan pendekatan ini, Anda dapat memodernisasi aplikasi Anda secara bertahap tanpa menggabungkannya.
![\[Migrating mainframe applications that share programs: using a message queue and multiple migration waves\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-3-diff.png)
Jika Anda menggunakan pendekatan ini, ikuti langkah-langkah berikut:
1. Migrasikan (refactor) aplikasi A dengan program terkait ke cloud sementara aplikasi B terus berada di tempat.
1. Aplikasi refactor A (di cloud) untuk berkomunikasi dengan aplikasi B (di tempat) melalui antrian pesan.
1. Refactor aplikasi B di tempat untuk mengganti program bersama AB.1 dengan program proxy yang mengirim pesan ke, dan menerima pesan dari, aplikasi A melalui antrian pesan.
1. Setelah aplikasi A berhasil dimigrasi, hentikan aplikasi lokal A dan komponennya (termasuk program bersama). Aplikasi B dan komponennya terus berada di tempat.
1. Pada rangkaian gelombang migrasi berikutnya, migrasi aplikasi B dan komponennya. Arsitektur antrian yang digabungkan secara longgar terus bertindak sebagai antarmuka antara aplikasi A dan B di cloud. Ini mengurangi upaya refactoring untuk aplikasi B tanpa memengaruhi aplikasi A.