apa.....?: Oktober 2016

1.1 SOAP

SOAP (Simple Object Access Protocol) adalah standar untuk bertukar pesan-pesan berbasis XML melalui jaringan komputer atau sebuah jalan untuk program yang berjalan pada suatu sistem operasi (OS) untuk berkomunikasi dengan program pada OS yang sama maupun berbeda dengan menggunakan HTTP dan XML sebagai mekanisme untuk pertukaran data.

SOAP menspesifikan secara jelas bagaimana cara untuk meng-encode header HTTP dan file XML sehingga program pada suatu komputer dapat memanggil program pada pada komputer lain dan mengirimkan informasi, dan bagaimana program yang dipanggil memberikan tanggapan.

SOAP adalah protokol ringan yang ditujukan untuk pertukaran informasi struktur pada lingkup desentralisasi, dan terdistribusi. SOAP menggunakan teknologi XML utuk mendefinisikan rangka kerja pemesanan terekstrensi di mana menyediakan konstruksi pesan yang dapat dipertukarkan pada protokol berbeda. Rangka kerja dirancang bebas dari model pemrograman dan spesifikasi implementasi semantik.

SOAP dirancang sebagai protokol objek-akses pada tahun 1998 oleh Dave Winer, Don Box, Bob Atkinson, dan Mohsen Al-Ghosein untuk Microsoft, di mana Atkinson dan Al-Ghosein bekerja. Karena politik dalam Microsoft, spesifikasi tidak dibuat tersedia sampai itu diserahkan ke IETF 13 September 1999. Karena ragu-ragu Microsoft, Dave Winer dikirim XML-RPC pada tahun 1998.

Draft Internet disampaikan tidak mencapai statusnya RFC dan karena itu tidak dianggap sebagai "standar" seperti itu. Versi 1.1 dari spesifikasi diterbitkan sebagai W3C Catatan pada 8 Mei 2000. Sejak versi 1.1 tidak mencapai status Rekomendasi W3C, tidak dapat dianggap sebagai "standar" baik. Versi 1.2 dari spesifikasi, bagaimanapun, menjadi rekomendasi W3C pada tanggal 24 Juni 2003.

SOAP spesifikasi dipertahankan oleh Protokol Group dari World Wide Web Consortium Kerja XML sampai kelompok itu ditutup 10 Juli 2009. SOAP awalnya berdiri untuk "Simple Object Access Protocol" tapi versi 1.2 dari standar ini menjatuhkan akronim.

Setelah SOAP pertama kali diperkenalkan, itu menjadi lapisan yang mendasari satu set yang lebih kompleks dari layanan Web, berdasarkan Web Services Description Language (WSDL), skema XML dan Universal Description Discovery dan Integrasi (UDDI). Layanan ini berbeda, terutama UDDI, telah terbukti dari jauh lebih menarik, tetapi apresiasi dari mereka memberikan pemahaman yang lengkap tentang peran yang diharapkan dari SOAP dibandingkan dengan bagaimana layanan web telah benar-benar berkembang.

Arsitektur SOAP

Pesan SOAP berbentuk seperti sebuah envelope yang berisi header (optional) dan body (required). Header berisi blok informasi yang berhubungan dengan bagaimana pesan tersebut diproses. Hal ini meliputi pe-routingan dan delivery setting, authentication atau authorization assertions, and transaction contexts. Body berisi pesan sebenarnya yang dikirim dan diproses. Semua yang dapat ditampilkan dengan sintaks XML dapat dimasukkan dalam pesan body.

Setiap elemen Envelope harus berisi tepat satu elemen Body. Elemen Body dapat berisi sebanyak mungkin child nodes yang diperlukan. Isi dari elemen Body adalah pesan. Elemen Body ditentukan dalam suatu cara dimana dapat berisi valid dan wellformed XML yang telah dibatasi oleh suatu namespace (qualified).

Jika sebuah Envelope berisi elemen Header, harus berisi tidak lebih dari satu, dan harus tampak pada first child dari Envelope, sebelum elemen Body. Header dapat berisi valid, well-formed, dan dibatasi dengan namespace XML dimana hendak dimasukkan oleh pencipta pesan SOAP.

Setiap elemen yang berada dalam Header disebut blok header. Tujuan dari blok header adalah untuk memberitahukan infomasi yang berhubungan dengan pemrosesan pesan SOAP.

Contoh

POST /InStock HTTP/1.1

Host: www.example.org

Content-Type: application/soap+xml; charset=utf-8

Content-Length: 299

SOAPAction: "http://www.w3.org/2003/05/soap-envelope"

<?xml version="1.0"?>

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">

<soap:Header>

</soap:Header>

<soap:Body>

<m:GetStockPrice xmlns:m="http://www.example.org/stock/Surya">

<m:StockName>IBM</m:StockName>

</m:GetStockPrice>

</soap:Body>

</soap:Envelope>

1.2 Remote Procedure Call (RPC)

               Dalam komputasi terdistribusi panggilan prosedur jauh (RPC) adalah ketika sebuah program komputer menyebabkan prosedur (subroutine) untuk mengeksekusi di ruang alamat lain (umumnya pada komputer lain pada jaringan bersama), yang dikodekan sebagai olah itu adalah normal (lokal) panggilan prosedur, tanpa programmer secara eksplisit coding rincian untuk interaksi jarak jauh. Artinya, programmer menulis dasarnya kode yang sama apakah subrutin lokal untuk program mengeksekusi, atau remote. Ini adalah bentuk interaksi client-server (pemanggil adalah klien, executer adalah server), biasanya dilaksanakan melalui sistem pesan-passing permintaan-respon. Analog pemrograman berorientasi obyek adalah doa metode remote (RMI). Model RPC menunjukkan tingkat transparansi lokasi, yaitu bahwa memanggil prosedur sebagian besar sama apakah itu lokal atau remote, tapi biasanya mereka tidak identik, sehingga panggilan lokal dapat dibedakan dari panggilan jarak jauh. panggilan jarak jauh biasanya lipat lebih lambat dan kurang dapat diandalkan dibandingkan panggilan lokal, sehingga membedakan mereka adalah penting.

               RPC adalah bentuk antar-proses komunikasi (IPC), dalam proses yang berbeda memiliki ruang alamat yang berbeda: jika pada mesin host yang sama, mereka memiliki ruang alamat virtual yang berbeda, meskipun ruang alamat fisik adalah sama; sedangkan jika mereka berada di host yang berbeda, ruang alamat fisik yang berbeda. Banyak yang berbeda (sering tidak sesuai) teknologi telah digunakan untuk mengimplementasikan konsep tersebut

Respon-request tanggal protokol untuk didistribusikan awal komputasi pada akhir tahun 1960, proposal teoritis prosedur remote panggilan sebagai model operasi jaringan tanggal ke 1970, dan implementasi praktis tanggal untuk awal 1980-an. Pada 1990-an, dengan popularitas pemrograman berorientasi objek, model alternatif doa metode remote (RMI) secara luas diterapkan, seperti di Umum Object Request Broker Architecture (CORBA, 1991) dan Jawa doa metode remote. SIMLR pada gilirannya jatuh popularitas dengan munculnya internet, khususnya di tahun 2000-an.

panggilan prosedur remote yang digunakan dalam sistem operasi modern melacak akar mereka kembali ke sistem multiprogramming RC 4000, yang menggunakan protokol komunikasi permintaan-respon untuk sinkronisasi proses. Ide mengobati operasi jaringan sebagai prosedur panggilan jarak jauh kembali setidaknya untuk tahun 1970 dalam dokumen ARPANET awal. Pada tahun 1978, Per Brinch Hansen diusulkan Proses Terdistribusi, bahasa untuk komputasi terdistribusi berdasarkan "permintaan eksternal" yang terdiri dari prosedur panggilan antara proses.

Bruce Jay Nelson biasanya dikreditkan dengan coining "panggilan prosedur jauh" (1981) istilah, dan implementasi praktis pertama oleh Andrew Birrel dan Bruce Nelson, disebut Lupine, di lingkungan Cedar di Xerox PARC. Lupin secara otomatis bertopik, menyediakan jenis-aman binding, dan digunakan protokol yang efisien untuk komunikasi. Salah satu bisnis pertama menggunakan RPC adalah dengan Xerox dengan nama "Courier" pada tahun 1981. Pelaksanaan populer pertama RPC pada Unix RPC Sun (sekarang disebut ONC RPC), yang digunakan sebagai dasar untuk Network File System.

Arsitektur RPC

Tabel berikut mencantumkan dan menjelaskan komponen dan fungsi dari arsitektur RPC.

komponen	Keterangan
Client or server process	Program atau layanan yang memulai atau menanggapi permintaan RPC.
RPC stubs	subsistem program yang digunakan oleh klien atau server untuk memulai permintaan RPC.
Marshalling engine (NDR20 or NDR64)	Menyediakan antarmuka RPC umum antara klien RPC dan server. NDR20 digunakan dalam arsitektur 32-bit dan NDR64 dioptimalkan untuk arsitektur 64-bit. Klien dan server menegosiasikan yang mesin marshalling digunakan untuk komunikasi.
Runtime application programming interface (API)	Menyediakan antarmuka langsung untuk RPC untuk klien atau server. RPC klien dan server biasanya memanggil runtime API untuk menginisialisasi RPC dan mempersiapkan struktur data yang digunakan untuk melakukan panggilan RPC. Lapisan API runtime ini juga menentukan apakah permintaan RPC yang berasal dari mesin marshalling atau langsung dari klien atau server akan server lokal atau server jauh. Lapisan runtime API kemudian rute RPC ke RPC Connection, Datagram RPC, atau lapisan RPC lokal.
Connection RPC protocol engine	Digunakan ketika RPC membutuhkan protokol berorientasi koneksi. Lapisan ini menunjuk protokol berorientasi koneksi untuk digunakan jika RPC adalah keluar atau menerima RPC berorientasi koneksi yang masuk.
Datagram RPC protocol engine	Digunakan ketika RPC membutuhkan protokol connectionless. Lapisan ini menunjuk protokol connectionless untuk digunakan jika RPC adalah keluar atau menerima connectionless RPC masuk.
Local RPC protocol engine	Digunakan ketika server dan klien berada pada host yang sama.
Registry	Diakses ketika layanan RPC beban pertama. Kunci registri dapat menentukan IP rentang pelabuhan dan nama-nama perangkat kartu jaringan yang RPC harus mengikat. Kecuali API memaksa penggunaannya, registri tidak digunakan dalam operasi RPC normal.
Win32 APIs (kernel32.dll, advapi32.dll, ntdll.dll)	Kernel32.dll adalah basis klien API library (DLL) file yang Windows NT dynamic-link yang menyediakan layanan sistem untuk mengelola benang, memori, dan sumber daya. Advapi32.dll adalah Windows 32 basis berkas API DLL canggih; itu adalah perpustakaan layanan API yang mendukung panggilan keamanan dan registry. Ntdll.dll adalah file lapisan DLL NT yang mengontrol fungsi sistem Windows NT.
SSPI (secur32.dll)	Menyediakan antarmuka keamanan untuk RPC. Melakukan negosiasi penggunaan Kerberos, NTLM, atau Secure Sockets Layer (SSL) untuk otentikasi dan enkripsi.
Endpoint Mapper (EPM) (rpcss.dll)	Rpcss.dll terutama menyediakan infrastruktur untuk COM, tetapi sebagian dari Rpcss.dll digunakan untuk EPM. Sebuah kontak RPC server yang EPM untuk menerima endpoint dinamis dan daftar orang-orang endpoint dalam database EPM. klien RPC menghubungi EPM dari tingkat protokol-mesin untuk menyelesaikan titik akhir ketika membangun koneksi dengan endpoint RPC server yang tidak diketahui.
Active Directory	Digunakan dalam proses RPC klien hanya ketika antarmuka keamanan menentukan Kerberos atau Negosiasikan sebagai penyedia keamanan atau ketika server menggunakan NTLM sebagai penyedia keamanan.
Network stack	Digunakan untuk melewati permintaan RPC dan balasan antara klien dan server jauh.
Kernel	Digunakan untuk melewati permintaan RPC dan balasan antara klien dan server lokal.

Contoh

Contoh Source Code Sederhana Program RPC Menggunakan Array asosiatif Dalam Parameter Request. Jika Anda ingin menggunakan array asosiatif dalam parameter metode Anda, Anda akan perlu menggunakan struct datatype:

1.3 Extensible Markup Language (XML)

               Dalam komputasi, Extensible Markup Language (XML) adalah bahasa markup yang mendefinisikan seperangkat aturan untuk dokumen encoding dalam format yang baik manusia-dibaca dan dapat dibaca oleh mesin. W3C XML 1.0 Spesifikasi dan beberapa spesifikasi terkait lainnya, -semua dari mereka terbuka bebas standar-mendefinisikan XML.

               Tujuan desain XML menekankan kesederhanaan, umum, dan kegunaan di Internet.  Ini adalah format data tekstual dengan dukungan kuat melalui Unicode untuk bahasa manusia yang berbeda. Meskipun desain XML berfokus pada dokumen, bahasa ini banyak digunakan untuk representasi dari struktur data sewenang-wenang  seperti yang digunakan dalam layanan web.

               Beberapa sistem skema ada untuk membantu dalam definisi bahasa berbasis XML, sementara programmer telah mengembangkan banyak antarmuka pemrograman aplikasi (API) untuk membantu pengolahan data XML.

               XML adalah profil aplikasi SGML (ISO 8879).  Fleksibilitas dari SGML untuk menampilkan informasi dinamis dipahami oleh penerbit media digital di awal 1980-an sebelum munculnya internet. Pada pertengahan 1990-an beberapa praktisi dari SGML telah memperoleh pengalaman dengan World Wide Web maka-baru, dan percaya bahwa SGML menawarkan solusi untuk beberapa masalah Web itu kemungkinan menghadapi seperti itu tumbuh. Dan Connolly menambahkan SGML ke daftar kegiatan W3C ketika ia bergabung dengan staf pada tahun 1995; pekerjaan dimulai pada pertengahan 1996 ketika Sun Microsystems insinyur Jon Bosak mengembangkan piagam dan direkrut kolaborator. Bosak baik terhubung dalam komunitas kecil orang yang memiliki pengalaman baik dalam SGML dan Web.

               XML disusun oleh kelompok kerja dari sebelas anggota,  didukung oleh (kira-kira) 150-anggota Interest Group. Perdebatan teknis berlangsung di milis Interest Group dan masalah diselesaikan dengan konsensus, atau jika yang gagal, suara mayoritas dari Kelompok Kerja. Sebuah catatan keputusan desain dan alasan-alasan mereka dikompilasi oleh Michael Sperberg-McQueen pada tanggal 4 Desember 1997. James Clark menjabat sebagai Lead Technical Working Group, terutama kontribusi kosong-elemen "<kosong />" sintaks dan nama "XML". Nama lain yang telah diajukan untuk dipertimbangkan termasuk "magma" (Minimal Arsitektur untuk Aplikasi Generalized Markup), "SLIM" (Structured Bahasa internet Markup) dan "MGML" (Minimal Generalized Markup Language). Co-editor dari spesifikasi awalnya Tim Bray dan Michael Sperberg-McQueen. Setengah jalan melalui proyek Bray menerima keterlibatan konsultasi dengan Netscape, memprovokasi protes gencar dari Microsoft. Bray untuk sementara diminta untuk mengundurkan diri redaktur tersebut. Hal ini menyebabkan sengketa intens dalam Kelompok Kerja, akhirnya diselesaikan dengan penunjukan Microsoft Jean Paoli sebagai co-editor ketiga.

XML Kelompok Kerja pernah bertemu tatap muka; desain dilakukan dengan menggunakan kombinasi email dan teleconference mingguan. Keputusan desain utama yang dicapai dalam ledakan singkat kerja yang intensif antara Agustus dan November 1996, ketika Draft Kerja pertama dari spesifikasi XML diterbitkan. karya desain lebih lanjut sampai 1997, dan XML 1.0 menjadi Rekomendasi W3C pada tanggal 10 Februari 1998.

Arsitektur XML

Contoh

<?xml version="1.0" encoding="UTF-8"?>

 <Resep nama="roti" waktu_persiapan="5 menit" waktu_masak="3 jam">

   <judul>Roti tawar</judul>

   <bahan jumlah="3" satuan="cangkir">tepung</bahan>

   <bahan jumlah="0,25" satuan="ons">ragi</bahan>

   <bahan jumlah="1,5" satuan="cangkir">air hangat</bahan>

   <bahan jumlah="1" satuan="sendok teh">garam</bahan>

   <Cara_membuat>

    <langkah>Campur semua bahan dan uleni adonan sampai merata.</langkah>

    <langkah>Tutup dengan kain lembap dan biarkan selama satu jam di ruangan yang hangat.</langkah>

    <langkah>Ulangi lagi, letakkan di loyang dan panggang di oven.</langkah>

    <langkah>Keluarkan, hidangkan</langkah>

   </Cara_membuat>

</Resep>

1.4 JavaScript Object Notation (JSON)

               JSON (kanonis diucapkan / dʒeɪsən / jay-sən; kadang-kadang JavaScript Object Notation) adalah format standar terbuka yang menggunakan teks terbaca-manusia untuk mengirimkan data objek yang terdiri dari pasangan atribut-nilai. Ini adalah format data yang paling umum digunakan untuk komunikasi browser / server yang asynchronous, sebagian besar menggantikan XML yang digunakan oleh AJAX.

               JSON adalah format data bahasa-independen. Ini berasal dari JavaScript, tetapi sebagai 2016, kode untuk menghasilkan dan mengurai JSON-format data tersedia dalam banyak bahasa pemrograman. Jenis media Internet resmi untuk JSON adalah application / json. JSON ekstensi nama file yang .json.

               Douglas Crockford semula ditentukan format JSON; dua standar yang bersaing, RFC 7159 dan ECMA-404, mendefinisikannya. ECMA standar hanya menjelaskan sintaks diperbolehkan, sedangkan RFC juga menyediakan beberapa pertimbangan semantik dan keamanan.

               JSON tumbuh dari kebutuhan untuk stateful, real-time komunikasi server-ke-browser tanpa menggunakan plugin browser seperti Flash atau Java applet, yang metode yang dominan di awal 2000-an.

Douglas Crockford adalah yang pertama untuk menentukan dan mempopulerkan format JSON. akronim diciptakan di Negara Software, sebuah perusahaan yang didirikan oleh Crockford, Chip Morningstar dan Robert F. Napiltonia pada bulan April 2001 dan didanai oleh Tesla Ventures. Co-pendiri sepakat untuk membangun sebuah sistem yang digunakan kemampuan browser standar dan memberikan lapisan abstraksi untuk pengembang Web untuk membuat aplikasi Web stateful yang memiliki koneksi duplex gigih untuk server Web dengan memegang dua koneksi HTTP terbuka dan daur ulang mereka sebelum waktu browser standar -outs jika tidak ada data lebih lanjut ditukar. Ide untuk Framework Aplikasi Negara dikembangkan oleh Morningstar di Software Negara. JSON digunakan dalam proyek di Communities.com untuk Cartoon Network, yang menggunakan plug-in dengan format pesan eksklusif untuk memanipulasi elemen DHTML (sistem ini juga dimiliki oleh 3DO). Setelah penemuan awal kemampuan Ajax, digiGroups, Noosh, dan lain-lain digunakan frame untuk menyampaikan informasi ke lapangan visual browser pengguna tanpa menyegarkan konteks visual aplikasi Web, menyadari real-time aplikasi Web yang kaya hanya menggunakan standar HTTP, HTML dan kemampuan JavaScript Netscape 4.0.5+ dan IE 5+. Crockford kemudian menemukan bahwa JavaScript dapat digunakan sebagai format pesan berbasis obyek untuk sistem tersebut. Sistem ini dijual ke Sun Microsystems, Amazon.com dan EDS. Situs Web JSON.org diluncurkan pada tahun 2002. Pada bulan Desember 2005, Yahoo! mulai menawarkan beberapa layanan Web dalam JSON. Google mulai menawarkan JSON feed untuk protokol web GData pada bulan Desember 2006.

               JSON pada awalnya ditujukan untuk menjadi bagian dari bahasa scripting JavaScript (khusus, Standard ECMA-262 3rd Edition-Desember 1999) dan umumnya digunakan dengan Javascript, tapi itu adalah format data bahasa-independen. Kode untuk parsing dan menghasilkan data JSON sudah tersedia dalam banyak bahasa pemrograman. Situs Web JSON ini berisi JSON perpustakaan oleh bahasa.

               Meskipun JSON awalnya diiklankan dan diyakini menjadi bagian ketat JavaScript dan ECMAScript, itu secara tidak sengaja memungkinkan beberapa karakter lolos dalam string yang ilegal di JavaScript dan ECMAScript string. Lihat masalah portabilitas data di bawah ini.

               JSON itu sendiri menjadi sebuah standar internasional ECMA pada tahun 2013 sebagai standar ECMA-404.  Pada tahun yang sama RFC 7158 digunakan ECMA-404 sebagai acuan. Di 2014 RFC 7159 menjadi acuan utama untuk penggunaan internet JSON ini (ex. Aplikasi MIME / json), dan obsoletes RFC 4627 dan RFC 7158 (tapi melestarikan ECMA-262 dan ECMA-404 sebagai referensi utama).

Arsitektur JSON

Contoh

{

"firstName": "John",

"lastName": "Smith",

"isAlive": true,

"age": 25,

"address": {

"streetAddress": "21 2nd Street",

"city": "New York",

"state": "NY",

"postalCode": "10021-3100"

"phoneNumbers": [

{

"type": "home",

"number": "212 555-1234"

{

"type": "office",

"number": "646 555-4567"

{

"type": "mobile",

"number": "123 456-7890"

}

"children": [],

"spouse": null

}

1.5 Enterprise Service Bus (ESB)

Enterprise Service Bus (ESB) adalah model arsitektur perangkat lunak yang digunakan untuk merancang dan menerapkan komunikasi antara aplikasi perangkat lunak yang saling berinteraksi dalam arsitektur berorientasi layanan (SOA). Sebagai model arsitektur perangkat lunak untuk komputasi terdistribusi, itu adalah varian khusus dari model client-server yang lebih umum dan mempromosikan kelincahan dan fleksibilitas berkaitan dengan komunikasi antara aplikasi. Terutama digunakan dalam integrasi aplikasi enterprise (EAI) dari lanskap yang heterogen dan kompleks.

Penggunaan diterbitkan pertama istilah "pelayanan perusahaan bus" dikaitkan dengan Roy W. Schulte dari Gartner Group 2002 dan buku The Enterprise Service Bus oleh David Chappell. Layanan - menunjukkan program non-berulang dan mandiri melaksanakan yang berkomunikasi dengan layanan lain melalui pertukaran pesan Bus - digunakan dalam analogi bus perangkat keras komputer Perusahaan - konsep telah awalnya diciptakan untuk mengurangi kompleksitas integrasi aplikasi enterprise dalam suatu perusahaan; pembatasan telah menjadi usang karena komunikasi internet modern tidak lagi terbatas pada entitas perusahaan Bahkan, istilah "bus" diciptakan pada tahun 1980 oleh Teknekron Software Systems . Frustrasi oleh bagaimana perangkat lunak tampaknya selalu di bawah-memberikan, sementara hardware selalu tepat waktu dan sesuai anggaran, Vivek Ranadive berangkat untuk membangun perangkat lunak berbasis pada premis dari "Software Bus" (yang kemudian dikenal sebagai "The Information Bus" atau TIB), dimana "bus" adalah jalan raya data yang standar yang berbagai elemen-seperti sistem komputer seperti CPU, memori, perangkat I / O, dll-berkomunikasi. Konsep ini akan memungkinkan untuk coupling "ketat" aplikasi. Pada tahun 1986 Teknekron Perusahaan memulai sebuah proyek konsultasi dengan Goldman Sachs untuk mendefinisikan kembali "lantai perdagangan masa depan" menerapkan pendekatan ini. Pada tahun 1987 TIB-untuk pertama integrasi dan pengiriman data pasar seperti harga saham, berita, dan keuangan lainnya informasi-pergi tinggal di Fidelity, Diikuti oleh First Interstate Bank, Kemudian Salomon, akhirnya digitalisasi semua Wall Street. Teknekron kemudian diakuisisi oleh Reuters pada tahun 1994 Untuk memperluas penggunaan dari Bus Informasi di pasar jasa keuangan. Pada Januari 1997, Ranadive didirikan Tibco Software Inc untuk membuat dan software pasar untuk digunakan dalam integrasi aplikasi bisnis di luar sektor jasa keuangan. Pada tahun 1998 Tibco Software merilis TIB / ActiveEnterprise suite. Pada bulan Juli 1999 Tibco go public di NASDAQ Stock Market Di bawah TIBX simbol ticker. Tibco singkatan Informasi Bus Perusahaan

Arsitektur Enterprise Service Bus (ESB)

Relasinya dengan SOA, ESB dianggap sebagai platform yang merealisasikan SOA dalam hal interoperability. Dalam arsitektur yang komplek, ESB merupakan sebuah software yang terletak di antara aplikasi atau yang lebih dikenal dengan adaptor/broker. Broker ini memungkinkan komunikasi antara aplikasi tersebut. ESB secara ideal harus mampu mengganti semua kontak langsung antara software dengan aplikasi pada bus sehingga komunikasi berlangsung melalui ESB. Untuk mencapai tujuannya, ESB harus merangkum fungsi yang ditawarkan oleh service dalam cara yang dimengerti oleh service lain.

Contoh

Proses pembayaran menggunakan e-banking difasilitasi oleh softwareuntuk e-banking serta internet, agar pembayaran berjalan lancar. Softwareyang digunakan dalam proses e-banking harus memiliki fasilitas pengintegrasian dengan software yang digunakan untuk pengolahan data pembayaran air, telepon, listrik, pajak, dan lain-lain, sehingga informasi mengalir dengan tepat dan jelas. Apabila kode program masing-masingsoftware tidak bersifat terbuka, maka pembuatan fasilitas untuk melakukan integrasi akan terhambat.

Level terakhir dari integrasi adalah middleware. Middleware sering disebut dengan istilah protokol(aturan atau standar yang mengatur hubungan antar perangkat). Secara hirarki, middleware berada diantara hardware dansoftware. Middleware dapat diterapkan pada hardware, software, maupun keduanya.

Penerapan Enterprise Service Bus(ESB) adalah salah satu pengintegrasian di level middleware. ESB merupakan platform integrasi berbasis standar untuk menghubungkan dan mengkoordinasi interaksi beberapa aplikasi di sebuah perusahaan. Artinya, ESB adalah infrastruktur untuk menngintegrasikan aplikasi dan layanan. Gambar berikut memberikan illustrasi mengenai ESB.

Gambar 3. Ilustrasi ESB

ESB memiliki beberapa tugas utama. Sesuai fungsinya sebagaimiddleware, ESB akan memantau dan mengontrol routing pertukaran pesan antar layanan. Selain itu, ESB juga mengatasi konflik antar komponen layanan komunikasi. Mengontrol penyebaran dan versioning dari layanan, serta melayani penanganan event, transformasi data dan pemetaan, konversi protokol, dan menguatkan kualitas layanan komunikasi yang tepat, juga bagian dari tugas utama ESB.

1.6 Web Services

               Sebuah layanan Web adalah layanan yang ditawarkan oleh perangkat elektronik ke perangkat elektronik lain, berkomunikasi satu sama lain melalui World Wide Web. Dalam layanan Web, teknologi Web seperti HTTP, awalnya dirancang untuk komunikasi manusia-ke-mesin, digunakan untuk komunikasi mesin-ke-mesin, lebih khusus untuk mentransfer mesin yang dapat dibaca format file seperti XML dan JSON. Dalam prakteknya, layanan Web biasanya menyediakan sebuah antarmuka berbasis Web berorientasi objek ke server database, digunakan misalnya dengan server Web lain, atau dengan aplikasi mobile, yang menyediakan antarmuka pengguna ke pengguna akhir. Aplikasi lain yang umum ditawarkan kepada pengguna akhir mungkin mashup, di mana server Web mengkonsumsi beberapa layanan Web di mesin yang berbeda, dan mengkompilasi konten ke dalam satu antarmuka pengguna.

W3C mendefinisikan layanan Web secara umum sebagai:

Sebuah layanan Web adalah sistem software yang dirancang untuk mendukung interaksi interoperable mesin-ke-mesin melalui jaringan.

- W3C, Web Services Glosarium

               layanan web dapat menggunakan SOAP melalui protokol HTTP, memungkinkan interaksi lebih murah melalui internet daripada melalui solusi proprietary seperti EDI / B2B. Selain SOAP melalui HTTP, layanan Web juga dapat diimplementasikan pada mekanisme transportasi terpercaya lainnya seperti FTP. Dalam sebuah dokumen tahun 2002, Web Services Arsitektur Kelompok Kerja W3C mendefinisikan Web Services Arsitektur, membutuhkan implementasi standar dari "layanan Web." Di dalam:

               Layanan Web Ini memiliki antarmuka yang dijelaskan dalam format mesin-processable (khusus WSDL). Sistem lain berinteraksi dengan layanan Web dalam cara yang ditentukan oleh deskripsi menggunakan SOAP-pesan, biasanya disampaikan menggunakan HTTP dengan serialisasi XML dalam hubungannya dengan standar yang berhubungan dengan Web lainnya.

- W3C, Web Services Glosarium

               Dalam sebuah dokumen tahun 2004, W3C diperpanjang definisi:

Kita dapat mengidentifikasi dua kelas utama dari layanan Web:

·         layanan Web SISA-compliant, di mana tujuan utama dari layanan ini untuk memanipulasi representasi XML sumber daya Web menggunakan satu set seragam operasi "stateless"; dan

·         layanan Web sewenang-wenang, di mana layanan ini dapat mengekspos set sewenang-wenang operasi.

- W3C, Web Services Architecture

Arsitektur Web Services

Bagaimana Web Service Beroperasi?

Sisi Server:

· Membuat fungsi utama/core function

· Membuat service wrapper berupa XML-RPC atau SOAP

· Membuat deskripsi service berupa WSDL atau instruksi integrasi XML-RPC (memuat semua method public, argumen dan return valuenya); plus dokumentasi yang human readable

· Deploy (rilis) service

· Daftarkan service tersebut melalui UDDI agar discoverable

Sisi Client:

· Mencari service melalui UDDI

· Mengambil service description file berupa WSDL atau instruksi XML-RPC

· Membuat klien XML-RPC atau SOAP (dapat berupa fungsi lokal atau pesan XML untuk dikirim → berdasarkan WSDLnya)

· Memanggil remote service tersebut

Contoh

Pada contoh kasus membuat aplikasi Web Service untuk mengakses Data mahasiswa. yang perlu kita siapkan untuk membuat aplikasi Web service “Data Mahasiswa” antara lain :

1. Library Web Service : NuSOAP

2. Rancangan Database Mahasiswa (mhs_webserv.sql)

3. Rancangan Script untuk Server (server.php)

4. Rancangan Script untuk Client. (client.php)

1. Library Web Service NuSOAP

NuSOAP yang sudah kita download kita extrak dan kita letakkan satu folder dengan aplikasi web service yang akan kita buat. Jangan lupa untuk menon-aktifkan fitur SOAP bawaan PHP yang bisa disetting di file php.ini. (extension=php_soap.dll) dan mengaktifkan fitur CURL (extension=php_curl.dll).

2. Rancangan Database Mahasiswa :

Database Engine yang kita pakai adalah MySQL. Struktur Database/Table : Database Name = mhs_webserv, Table Name = mahasiswa;

a. Buat Database “mhs_webserv”

create database mhs_webserv;

b. Buat Tabel “mahasiswa” :

CREATE TABLE IF NOT EXISTS `mahasiswa` (

`nim` varchar(10) NOT NULL,

`nama` varchar(50) NOT NULL,

`alamat` text NOT NULL,

PRIMARY KEY (`nim`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

c. Isi data mahasiswa.

INSERT INTO `mahasiswa` (`nim`, `nama`, `alamat`) VALUES

('001', 'Kabul', 'Pekalongan'),

('002', 'Ridwan', 'Semarang');

3. Rancangan Script untuk Server (server.php)

<?php

//panggil file soap

require_once '../../nusoap/nusoap.php';

$ws_srv = new soap_server();

$ws_srv->register(ambilData);

function tes($param){

$nama= $param['nama'];

$alamat = $param['alamat'];

$return_value[] =array('nama'=>$nama,'alamat'=>$alamat);

return ($return_value);}

function ambilData(){

mysql_connect('127.0.0.1','root','');

mysql_select_db('coba_wservice');

$sql = mysql_query('SELECT * FROM mahasiswa WHERE 1');

$return_data_count=mysql_num_rows($sql);

//$return_data[]=array();

while ($row=mysql_fetch_array($sql)){

$return_data[]=array('nim'=>$row['nim'],'nama'=>$row['nama'],

'alamat'=>$row['alamat']);

}

$return['count']=$return_data_count;

$return['data']=$return_data;

return $return;

}

$HTTP_RAW_POST_DATA = isset ($HTTP_RAW_POST_DATA) ?

$HTTP_RAW_POST_DATA:"";

$ws_srv->service($HTTP_RAW_POST_DATA);

4. Rancangan Script untuk Client. (client.php)

<?php

require_once('../../nusoap/nusoap.php');

$client = new soapclient('http://127.0.0.1/mhs_webserv/server/');

//$param = array('nama'=>'Kabul Kurniawan','alamat'=>'Pekalongan');

$result = $client->call('ambilData');

$n=$result['count'];

$data=$result['data'];

echo '<table border=1>';

echo "<tr><th>Nim</th><th>Nama</th><th>Alamat</th></tr>";

for($i=0;$i<$n;$i++){

echo "<tr><td>".$data[$i]['nim']."</td><td>".$data[$i]['nama'].

"</td><td>".$data[$i]['alamat']."</td></tr>";

}

echo "</table>";

print_r ($result['count']);

echo'<br>';

print_r ($result['data']);

Setelah rancangan-rancangan tersebut dibuat, kita dapat langsung mengakses data mahasiswa melalui client.php, berikut hasilnya..

1.7 Resource Description Framework (RDF)

Resource Description Framework (RDF) adalah keluarga dari World Wide Web Consortium (W3C) spesifikasi awalnya dirancang sebagai model metadata data. Ia telah datang untuk digunakan sebagai metode umum untuk deskripsi konseptual atau model informasi yang diimplementasikan dalam sumber daya web, menggunakan berbagai notasi sintaks dan format data serialisasi. Hal ini juga digunakan dalam aplikasi manajemen pengetahuan.

RDF diadopsi sebagai rekomendasi W3C pada tahun 1999. RDF 1.0 spesifikasi diterbitkan pada tahun 2004, RDF 1.1 spesifikasi pada tahun 2014.

Desain RDF awal, dimaksudkan untuk "membangun sistem sistem-independen vendor-netral dan operasi metadata," berasal dari Platform W3C untuk Seleksi Konten Internet (PICS), web sistem konten pelabelan awal, tetapi proyek ini juga dibentuk oleh ide-ide dari Dublin core, dan dari Meta Content Framework (MCF), yang telah dikembangkan selama 1995-1997 oleh Ramanathan V. Guha di Apple dan Tim Bray di Netscape.

Rancangan publik pertama dari RDF muncul pada bulan Oktober 1997, yang dikeluarkan oleh sebuah kelompok kerja W3C yang termasuk perwakilan dari IBM, Microsoft, Netscape, Nokia, Reuters, SoftQuad, dan University of Michigan.

W3C menerbitkan spesifikasi model data RDF dan serialisasi XML sebagai rekomendasi pada bulan Februari 1999. Dua kesalah pahaman yang terus-menerus dikembangkan sekitar RDF saat ini: pertama, dari pengaruh MCF dan RDF "Resource Description" singkatan, gagasan bahwa RDF adalah khusus untuk digunakan dalam mewakili metadata. Kedua bahwa RDF adalah format XML, bukan RDF menjadi model data dan hanya RDF / XML serialisasi menjadi berbasis XML. RDF melihat sedikit take-up pada periode ini, tapi ada pekerjaan yang signifikan dilakukan di Bristol, sekitar ILRT di Universitas Bristol dan HP Labs, dan juga di Boston di MIT. RSS 1.0 dan FOAF menjadi aplikasi contoh bagi RDF dalam periode ini.

Rekomendasi tahun 1999 diganti pada tahun 2004 oleh satu set enam spesifikasi: "The RDF Primer", "RDF Konsep dan Abstrak", "RDF / XML Sintaks Keterangan (revisi)", "RDF semantik ", " RDF Kosakata Description Language 1.0 ", dan" The RDF Uji Kasus ".

Seri ini digantikan pada 2014 oleh enam "RDF 1.1" dokumen-dokumen berikut: "RDF 1.1 Primer", "RDF 1.1 Konsep dan Abstrak Sintaks", "RDF 1.1 XML Sintaks", "RDF 1.1 semantik ", " RDF Schema 1.1 ", dan" RDF Kasus 1.1 Test ".

Arsitektur Resource Description Framework (RDF)

Contoh

Sebagai contoh, kita ingin mepresentasikan ide “Dokumen ini berjudul Jadwal Ujian dan dipublikasi oleh Jurusan TI UIN”

<rdf:RDF

xmlns:rdf=”http://www.w3.org/1999/02/22-rdf-syntax-ns#”

xmlns:dc=”http://purl.org/dc/elements/1.1/”>

<rdf:Description

rdf:about=”http://www.uin-malang.ac.id/jadwal”>

<dc:title>Jadwal Ujian</dc:title>

<dc:publisher>Jurusan TI UIN</dc:publisher>

</rdf:Description>

</rdf:RDF>

1.8 Internet Protocol (IP)

Internet Protocol (IP) adalah protokol komunikasi utama di Internet protokol untuk menyampaikan datagram melintasi batas-batas jaringan. Fungsi routing memungkinkan internetworking, dan pada dasarnya menetapkan internet.

IP memiliki tugas memberikan paket-paket dari host sumber ke host tujuan semata-mata berdasarkan alamat IP dalam header paket. Untuk tujuan ini, IP mendefinisikan struktur paket yang merangkum data yang akan dikirimkan. Hal ini juga mendefinisikan pengalamatan metode yang digunakan untuk label datagram dengan sumber dan informasi tujuan.

Secara historis, IP adalah layanan datagram connectionless dalam Program Transmission Control asli diperkenalkan oleh Vint Cerf dan Bob Kahn pada tahun 1974; yang lainnya adalah berorientasi koneksi Transmission Control Protocol (TCP). Protokol internet Oleh karena itu sering disebut sebagai TCP / IP.

Versi besar pertama dari IP, Internet Protocol Version 4 (IPv4), adalah protokol yang dominan dari Internet. penggantinya adalah Internet Protocol Version 6 (IPv6).

Versi saat ini yang relevan adalah IPv4 dan IPv6.

Pada bulan Mei 1974, Institute of Electrical dan Electronic Engineers (IEEE) menerbitkan sebuah makalah berjudul "A Protokol untuk Jaringan Packet pergaulan". [2] koran penulis, Vint Cerf dan Bob Kahn, menggambarkan sebuah protokol internetworking untuk berbagi sumber daya menggunakan packet switching antara node jaringan. Sebuah komponen kontrol pusat dari model ini adalah "Transmission Control Program" yang menggabungkan kedua link connection-oriented dan layanan datagram antara host. The Transmission Control Program monolitik kemudian dibagi menjadi arsitektur modular terdiri dari Transmission Control Protocol pada layer transport dan Internet Protocol pada lapisan jaringan. Model ini dikenal sebagai Departemen Pertahanan (DoD) Model Internet dan Internet Protocol Suite, dan informal sebagai TCP / IP.

Versi IP 0 sampai 3 adalah versi percobaan, digunakan antara tahun 1977 dan 1979. Berikut Internet Percobaan Catatan (IEN) dokumen menggambarkan versi Internet Protocol sebelum versi modern dari IPv4:

IEN 2 (Komentar Internet Protocol dan TCP), tanggal Agustus 1977 menggambarkan kebutuhan untuk memisahkan fungsi TCP dan Internet Protocol (yang sebelumnya dikombinasikan.) Ini mengusulkan versi pertama dari header IP, menggunakan 0 untuk bidang versi.

IEN 26 (A Usulan Baru Internet Format Header), tertanggal Februari 1978 menggambarkan versi dari header IP yang menggunakan medan versi 1-bit.

IEN 28 (Draft Internetwork Protocol Keterangan Versi 2), tanggal Februari 1978 menjelaskan IPv2.

IEN 41 (Internetwork Protocol Keterangan Versi 4), tanggal Juni 1978 menjelaskan protokol pertama yang disebut IPv4. IP header yang berbeda dari header IPv4 modern.

IEN 44 (Terbaru header Format), tanggal Juni 1978 menjelaskan versi lain dari IPv4, juga dengan sundulan yang berbeda dari header IPv4 modern.

IEN 54 (Internetwork Protocol Keterangan Versi 4), tanggal September 1978 adalah deskripsi pertama dari IPv4 menggunakan header yang akan dibakukan dalam RFC 760.

Protokol internetworking dominan di Layer Internet yang digunakan saat ini adalah IPv4; nomor 4 adalah nomor versi protokol dilakukan dalam setiap datagram IP. IPv4 dijelaskan dalam RFC 791 (1981).

Versi 5 digunakan oleh Internet Stream Protocol, protokol streaming yang eksperimental.

Penerus IPv4 adalah IPv6. Its Perbedaan yang paling menonjol dari versi 4 adalah ukuran alamat. Sementara IPv4 menggunakan 32 bit untuk menangani, menghasilkan c. 4,3 miliar (4,3 × 109) alamat, IPv6 menggunakan alamat 128-bit menyediakan ca. 340 undecillion, atau 3,4 × 1038 alamat. Meskipun adopsi IPv6 telah lambat, pada Juni 2008, semua sistem pemerintah Amerika Serikat telah menunjukkan dukungan infrastruktur dasar untuk IPv6. IPv6 adalah hasil dari beberapa tahun percobaan dan dialog di mana berbagai model protokol yang diusulkan, seperti TP / IX (RFC 1475), PIP (RFC 1621) dan TUBA (TCP dan UDP dengan Alamat Bigger, RFC 1347).

Penugasan protokol baru sebagai IPv6 tidak pasti sampai due diligence mengungkapkan bahwa IPv6 belum digunakan sebelumnya. proposal protokol lainnya bernama IPv9 dan IPv8 sebentar muncul, tetapi tidak memiliki afiliasi dengan badan standar internasional, dan tidak memiliki dukungan.

Pada tanggal 1 April 1994, IETF dipublikasikan lelucon Hari April Mop tentang IPv9.

Fungsi

Internet Protocol bertanggung jawab untuk menangani host dan untuk routing datagram (paket) dari sumber host ke host tujuan di satu atau lebih jaringan IP. Untuk tujuan ini, Internet Protocol mendefinisikan format paket dan menyediakan sistem pengalamatan yang memiliki dua fungsi:. Mengidentifikasi host dan menyediakan layanan lokasi logis

konstruksi datagram

enkapsulasi sampel data aplikasi dari UDP ke bingkai protokol link

Setiap datagram memiliki dua komponen: header dan payload. Header IP ditandai dengan alamat IP sumber, alamat IP tujuan, dan meta-data lain yang diperlukan untuk rute dan menyampaikan datagram. payload adalah data yang diangkut. Metode ini bersarang payload data dalam paket dengan header disebut enkapsulasi.

IP dan routing [sunting]

IP memerlukan penugasan alamat IP dan parameter yang terkait untuk menjadi tuan rumah interface. Ruang alamat dibagi menjadi jaringan dan subnetwork, yang melibatkan penunjukan jaringan atau prefiks routing. IP routing dilakukan oleh semua host, serta router, yang fungsi utamanya adalah untuk mengangkut paket melintasi batas-batas jaringan. Router berkomunikasi dengan satu sama lain melalui protokol routing yang dirancang khusus, baik protokol gateway interior atau protokol eksterior gateway, seperti yang diperlukan untuk topologi jaringan.

IP routing juga umum dalam jaringan lokal. Misalnya, banyak switch Ethernet mendukung operasi IP multicast. switch ini menggunakan alamat IP dan Internet Group Management Protocol untuk mengontrol multicast routing tapi menggunakan alamat MAC untuk routing yang sebenarnya.

Arsitektur Internet Protocol (IP)

Contoh

References

· https://s81067.wordpress.com/2014/01/05/makalah-soap-simple-object-access-protocol/ SOAP (Simple Object Access Protocol)