PERSONAL ASSIGNMENT 3 Session 7 (7083T-TP3-S2-R1) Due Date : 02 Agustus 2015, 23:59:00 MATA KULIAH SERVICED ORIENTED ARCHITECTURE DOSEN Ford Lumban Gaol, S.Si., M.Kom., Dr Dr. Suryadiputra Liawatimena, S.Kom., Pgdip.App.Sci. OLEH: TINA TRI WULANSARI 1412409315 Program Pascasarjana Ilmu Komputer PROGRAM STUDI TEKNIK INFORMATIKA JENJANG S2 UNIVERSITAS BINA NUSANTARA JAKARTA 2015
Personal Assignment 3 Session 7 1. Jelaksan apa yang dimasud dengan SOA maturity dibawah ini. As indicated in the previous section, integration maturity is a progressive realization in a serviceoriented world, going from tight-integration and tight-coupling to loose-coupling and availability of Information and Business Capabilities as an IT Service. There are multiple dimensions along which service integration maturity can be measured or captured, and it also provides a roadmap for where future efforts should be focused on in order to fully realize the power and benefits of a SOA. The multiple dimensions across which maturity should be considered are also indicative of the various areas that service oriented architecture typically touches and thus influences during an SOA project. The SOA Maturity Model uses the concept of domains to classify and organize the related capabilities. As depicted in Figure above, there are eight domains in the maturity model:
Business & Strategy: Contains capabilities that provide the high-level constructs that allow the SOA initiative to proceed. This includes such things as business motivation, expected benefits, guiding principles, expected costs, funding model, etc. Organization: Contains capabilities concerning the development of corporate competency around SOA including the organizational structure and skills development. Method (Operations, Administration & Managemen): Contains capabilities concerning the post deployment aspects of solutions based on a service-oriented architecture i.e. the operations, administration, and management aspects of SOA. Application (Projects, Portfolios & Services): Contains capabilities concerning the planning and building of services and the service usage guidelines of service consumers. Architecture: Contains capabilities concerning the definitions of the overall architecture and guidelines for various practitioners to ensure adherence to the architecture. Information: Contains capabilities concerning the information aspects of SOA, e.g., providing Information as a Service (IaaS). This includes shared data models, message formats and schemas, master data management, content management, etc. Infrastructure: Contains capabilities concerning the service infrastructure and tools that provide the technical foundation for the SOA initiative. Governance: Contains capabilities concerning the governance structures and processes that support and guide the SOA efforts. Maturity and adoption of an adequate amount of governance is a leading indicator of the overall SOA success. These eight domains, although interrelated, are sufficiently distinct. To succeed at SOA adoption, an organization must adequate progress in all of these domains. Inevitably an organization will be more advanced in some domains (and further in some of the capabilities within a domain) than others. Therefore, it is important to be able to measure the relative maturity within each domain (and capabilities therein) and across domains to identify areas that are lagging. Once the lagging areas have been identified it is possible to formulate remedies and there by improve the success of the overall SOA initiative.
2. Apa yang dimaksud dengan SOA Requirement? Requirement adalah pernyataan yang menidentifikasikan kebutuhan yang penting dalam SOA dan didalamnya mencakup aspek Kebenaran, Realistis, Dibutuhkan, Tidak ambigu, dan Terukur. Langkah yang paling penting dalam proses requirement adalah komunikasi yang akurat antara user yang memerlukan sistem dengan pembuat sistem. 3. Jelaskan secara rinci definisi dan peranan dari istilah berikut ini: Services Services menyediakan fungsionalitas bisnis, seperti aplikasi untuk perjalanan bisnis, permohonan untuk pinjaman, dll. Hal ini berbeda jauh dari fungsionalitas yang ada di technology-oriented functionalities, seperti mengambil atau meng-update data 1 satu tabel dalam database. Services dalam SOA harus menyediakan nilai bisnis, menyembunyikan rincian implementasi,, and be autonomous. Service consumers adalah entitas perangkat lunak, yang memanggil service dan menggunakan fungsi fungsinyanya. Interfaces Layanan konsumen mengakses layanan melalui Interfaces. Interface adalah kontrak antara penyedia layanan dan layanan konsumen. Interface terpisah dari implementasi. Deskripsi interface adalah menyediakan dasar bagi pelaksanaan layanan oleh penyedia layanan dan dasar untuk pelaksanaan layanan konsumen. Messages Operasi-operasi didefinisikan sebagai seperangkat pesan. Pesan menentukan data yang akan dipertukarkan dan menggambarkannya dalam sebuah platform dan bahasa yang bebas sebagai cara menggunakan skema. Services hanya mempertukarkan data yang berbeda jauh dari pendekatan object-oriented dan komponen,dimana behavior (implementation code) dapat juga dipertukarakan. WSDL adalah bahasa service description yang memenuhi kriteria SOA.
Synchronicity Service consumers mengakses layanan melalui service bus. Hal ini dapat berupa sebuah transport protocol, seperti SOAP, atau ESB. Service consumers dapat menggunakan komunikasi yang sinkron atau asinkron mode komunikasi untuk meminta/menjalankan operasi services. Dalam mode sinkron, sebuah operasi service mengembalikan respon ke service consumer setelah proses selesai service consumer harus menunggu proses selesai. Biasanya kita menggunakan mode sinkron dengan operasi pengolahan lengkap dalam waktu singkat. Dalam modus asynchronous, service operation tidak mengembalikan response kepada consumer, tetapi dapat mengembalikan acknowledgement(pengakuan/informasi) sehingga konsumen mengetahui bahwa operasi telah berhasil dijalankan. Jika respons diperlukan, biasanya digunakan pemanggilan balik dari service kepada consumer yang digunakan. Dalam skenario, korelasi antara pesan diperlukan. Loose Coupling Melalui self-describing interface, secara kasar, pertukaran dari struktur data mendukung synchronous and asynchronous mode komunikasi, loose coupling dari services (service yang saling tidak tergantung) tercapai. Loosely coupled services adalah service yang terbuka hanya pada ketergantungan yang diperlukan dan mengurangi semua jenis ketergantungan buatan. Hal ini sangat penting ketika service akan pakai sering berubah. Ketergantungan yang Minimal ini menjamin bahwa akan ada jumlah perubahan yang minimal juga untuk service lainnya ketika satu service dimodifikasi. Pendekatan seperti meningkatkan Robustness, membuat sistem lebih tahan terhadap perubahan, dan mempromosikan untuk menggunakan kembali service yang ada. Registries Untuk menyederhanakan dan mengotomatisasi mencari layanan yang sesuai, jasa layanan dijaga/dipelihara/didaftarkan pada service registries yang bertindak sebagai daftar direktori. Service providers mempublikasikan services di registries. Service consumers mencari layanan di registries. Pencarian dapat dilakukan berdasarkan nama, fungsi layanan, atau proses bisnis properti. UDDI adalah contoh layanan registri.
Quality of Service Services biasanya memiliki keterkaitan dengan atribut kualitas service. Termasuk atribut seperti keamanan, pesan yang dapat diandalkan, transaksi, korelasi, manajemen, policy, dan persyaratan lainnya. Infrastruktur harus menyediakan dukungan untuk atribut ini. Attribut dr kualitas service cukup penting dalam sistem informasi yang besar. Dalam web services, attribute dr kualitas service dibungkus oleh spesifikasi WS-*,seperti WS-Security, WS-Addressing, WS-Koordinasi, dll Kualitas dr service juga disediakan oleh ESB. Services Communicate Setelah service berkomunikasi dengan mengirimkan message, maka service tersebut kehilangan kontrol akan message tsb (what happens to the message thereafter). Karena hal inilah, message perlu seperti service dapat bebas berdiri sendiri / (autonomous). Karena hal itu, sebuah message dapat dilengkapi dengan kecerdasan untuk bisa mengurus bagian processing logic nya sendiri. Service yang menyediakan service description dan ber komunikasi via messages membentuk sebuah arsitektur dasar/sederhana. Sejauh ini, arsitekture tesebut, tampak sama dengan arsitektur lama yang disalurkan, yang mensuport messaging dan pembagian interface dr processing logic Perbedaannya adalah 3 komponen inti yang di design yaitu : Service yang bersifat bebas(loosely Coupled), service yang memelihara sebuah relasi dimana ketergantungan diminimalisasikan Service Contract, service yang melekat pada sebuah persetujuan komunikasi, yang umumnya didefinisikan oleh satu atau lebih service description dan oleh document-document berkaitan Service autonomy yang memiliki control penuh akan logika yang dikapsulkan. Service abstraction diluar dr apa yg dideskripsikan di service contract, service menyembunyikan logika dari manapun. Service reusability, service ini dibagi kedalam beberapa service dengan maksud untuk dapat digunakan ulang Service composability, koleksi dari service-service dapat dikordinasikan dan dirakit menjadi gabungan service. Statelessness Service, Service meminimalkan ketahanan akan informasi spesifik untuk sebuah aktivitas. Kemampuan menemukan Service (Service discoverability), service yang
didesign untuk mengeluarkan deskripsi sehingga service yang dicari dapat ditemukan dan ditafsirkan via discovery mechanisms yang tersedia. Built Services Service oriented dan macam-macam abstrak model SOA sudah ada sebelum WEb Service diluncurkan. Bagaimanapun juga tidak ada 1 pun kemajuan teknologi yang sangat lengkap dan sukses,dalam mendaftarkan SOA tanpa web service. Tapi sekarang ini semua perusahaan platforms sekarang mendukung pembuatan dari solusi service oriented dan kebanyakan melakukannya dengan memahami bahwa SOA menyediakan dukungan didasari dengan menggunakan web service. Oleh karena itu, sementara ini kita benar benar mengakui bahwa untuk dapat mencapai SOA tidak memerlukan web service.
Referensi: Ford Lumban Gaol. The Artifice of Requirements. LECTURE NOTES Services Oriented Architecture. fgaol@binus.edu An Oracle White Paper September 2013 SOA Maturity Model - Guiding and Accelerating SOA Success. http://www.oracle.com/technetwork/topics/entarch/oracle-wp-soa-maturity-model-76717.pdf http://www.imsglobal.org/soa/imssoawhitepaper_v1p0pd.html http://ilmukomputer.org/2009/05/26/membuat-software-requirement/