December 13, 2017

Memahami Bagaimana SOAP Bekerja

by , in

Memahami bagaimana SOAP bekerja
Inti layanan Web adalah SOAP (Simple Object Access Protocol), protokol komunikasi utama yang memungkinkan semua bagian arsitektur bekerja sama satu sama lain. Di kolom ini, bagian kedua dari rangkaian yang membahas protokol yang mendasari layanan Web, saya akan memeriksa peran SOAP dalam layanan Web, menjelaskan bagaimana SOAP bekerja, dan melihat beberapa potensi perangkap dengan protokol.

Bagaimana SOAP cocok dengan layanan Web
Pertama, mari kita lihat bagaimana SOAP sesuai dengan skema layanan Web. Kami akan memulai dengan penyegaran singkat tentang bagaimana layanan Web bekerja. Layanan Web adalah modul perangkat lunak yang diselenggarakan oleh penyedia layanan, yang dapat dijalankan melalui Internet.

Agar tersedia untuk orang lain, deskriptor berbasis XML tentang layanan Web diterbitkan ke registri layanan. Informasi tentang layanan Web dan cara menjalankannya ditemukan di deskriptor. Ketika peminta layanan (yang bisa menjadi perangkat lunak) ingin menjalankan layanan Web, ia menghubungi layanan registri. Berdasarkan apa yang ditemukannya dalam deskriptor, pemohon mengikat penyedia layanan dan menjalankan layanan Web.

SOAP adalah protokol komunikasi yang memungkinkan semua ini terjadi. Ini digunakan untuk mempublikasikan deskriptor ke dalam registry layanan; untuk mengirim permintaan layanan dari peminta ke registri; untuk mengirim informasi dari registri ke pemohon; dan kemudian mengizinkan pemohon untuk mengikat ke penyedia layanan dan menjalankan layanan Web. Ini aman untuk mengatakan bahwa tanpa SOAP, tidak mungkin ada layanan Web.

SOAP adalah protokol berbasis XML - keseluruhan tujuannya adalah mengirim dan menerima informasi XML. Ini diciptakan dan diperjuangkan oleh Microsoft, dan pada awalnya disambut dengan skeptis oleh orang-orang yang percaya bahwa ini adalah usaha raksasa perangkat lunak untuk membajak sebuah internet. Tapi pandangan itu telah berubah, dan sekarang diakui sebagai standar umum, dan perkembangannya dipandu oleh World Wide Web Consortium (W3C), organisasi yang memandu standar Web yang paling penting.



Anatomi pesan SOAP
Pesan yang dikirim melalui SOAP ada dalam format XML, dan terdiri dari tiga bagian - sebuah Envelope, Header dan Body, seperti yang dapat Anda lihat di gambar diatas. Envelope tersebut mengenkapsulasi header dan body pesan, dan berisi berbagai informasi yang diperlukan untuk memproses pesan, termasuk deskripsi jenis data yang dapat ditemukan di dalam envelope, dan informasi tentang bagaimana data tersebut harus diproses. Ini juga berisi informasi tentang pengirim dan penerima pesan.

SOAP tidak mengharuskan pesan berisi header, meskipun sebagai masalah praktis, pesan akan menyertakannya saat SOAP digunakan di layanan Web. Informasi yang ditemukan di header bisa melakukan berbagai fungsi, seperti memberikan otentikasi. Data yang ditemukan di header disusun menjadi blok header. Ada satu atau lebih blok di header.

Body pesan adalah apa yang sebenarnya berisi data. Data mungkin merupakan permintaan informasi - misalnya, saat peminta layanan mencari registri layanan untuk layanan Web. Atau mungkin akan menanggapi permintaan informasi, seperti saat registri mengirim kembali deskriptor layanan. Data yang ditemukan di dalam body diatur ke dalam sub-elemen. Bisa ada satu atau lebih sub elemen dalam body.

Ini semua mungkin terdengar agak abstrak, jadi saya menyertakan contoh pesan SOAP yang disatukan oleh W3C. Pesan sampel adalah permintaan reservasi perjalanan dikirim melalui SOAP. Seperti yang dapat Anda lihat, seluruh pesan itu sendiri ada dalam format XML, seperti juga semua pesan SOAP. Meskipun Anda mungkin tidak dapat memahami semua hal yang Anda lihat, jika Anda meluangkan beberapa menit untuk memeriksanya, Anda akan bisa merasakan apa yang dilakukan oleh setiap elemen pesan SOAP.

<?xml version='1.0' ?> <env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope"> <env:Header> <m:reservation xmlns:m="http://travelcompany.example.org/reservation" env:actor="http://www.w3.org/2001/12/soap-envelope/actor/next" env:mustUnderstand="true"> <m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</reference> <m:dateAndTime>2001-11-29T13:20:00.000-05:00</m:dateAndTime> </m:reservation> <n:passenger xmlns:n="http://mycompany.example.com/employees" env:actor="http://www.w3.org/2001/12/soap-envelope/actor/next" env:mustUnderstand="true"> <n:name>John Q. Public</n:name> </n:passenger> </env:Header> <env:Body> <p:itinerary xmlns:p="http://travelcompany.example.org/reservation/travel"> <p:departure> <p:departing>New York</p:departing> <p:arriving>Los Angeles</p:arriving> <p:departureDate>2001-12-14</p:departureDate> <p:departureTime>late afternoon</p:departureTime> <p:seatPreference>aisle</p:seatPreference> </p:departure> <p:return> <p:departing>Los Angeles</p:departing> <p:arriving>New York</p:arriving> <p:departureDate>2001-12-20</p:departureDate> <p:departureTime>mid morning</p:departureTime> <p:seatPreference/> </p:return> </p:itinerary> <q:lodging xmlns:q="http://travelcompany.example.org/reservation/hotels"> <q:preference>none</q:preference> </q:lodging> </env:Body> </env:Envelope>

Potensi masalah dengan SOAP
Perangkap potensial terbesar dengan protokolnya adalah bahwa implementasi SOAP yang berbeda mungkin tidak bekerja satu sama lain. Anda jarang akan bekerja secara langsung dengan SOAP sendiri - sebagai gantinya, Anda akan bekerja dengan toolkit SOAP yang menciptakan pesan SOAP, atau dengan toolkit layanan Web yang akan membuatnya. Seringkali, toolkit ini diterjemahkan dari bahasa ke SOAP - misalnya, Anda dapat menggunakan toolkit untuk menerjemahkan fungsi COM ke SOAP, dan toolkit yang berbeda untuk menerjemahkan fungsi JAVA ke SOAP. Masalahnya adalah bahwa setiap toolkit dapat menerapkan SOAP secara berbeda, dan mungkin tidak akan bekerja dengan baik satu sama lain.

Ini akan menjadi masalah khusus bagi siapa saja yang ingin mengembangkan keduanya .NET dan untuk layanan Web berbasis Java. Mungkin ada ketidaksesuaian saat berhadapan dengan SOAP di dua dunia yang berperang itu. Sebagai contoh kecil, ketika menyangkut angka, implementasi NET dan Java bervariasi: Dengan .NET Anda dapat memasukkan angka ke 29 angka desimal, sementara dengan Java, Anda hanya bisa pergi ke 18 tempat desimal.

Jika Anda mengembangkan layanan Web, Anda harus bekerja dengan SOAP, tidak kompatibel atau tidak. Jadi, Anda akan bisa segera memulai berbagai implementasi sekarang, sehingga Anda siap menghadapi masalah yang mungkin harus Anda hadapi.



December 10, 2017

SOAP (Simple Object Access Protocol)

by , in

SOAP (Simple Object Access Protocol) adalah protokol perpesanan yang memungkinkan program berjalan pada sistem operasi yang berbeda (seperti Windows dan Linux) untuk berkomunikasi menggunakan Hypertext Transfer Protocol (HTTP) dan Extensible Markup Language (XML).

Karena protokol Web telah terinstal dan tersedia untuk digunakan oleh semua platform sistem operasi utama, HTTP dan XML menyediakan solusi langsung yang memungkinkan program berjalan di bawah sistem operasi yang berbeda dalam jaringan untuk berkomunikasi satu sama lain. SOAP menentukan secara tepat bagaimana menyandikan header HTTP dan file XML sehingga sebuah program di satu komputer dapat memanggil sebuah program di komputer lain dan menyampaikan informasi. SOAP juga menentukan bagaimana program yang dipanggil dapat mengembalikan respons. Meskipun sering dipasangkan dengan HTTP, SOAP juga mendukung protokol transportasi lainnya.

SOAP mendefinisikan format pesan berbasis XML yang digunakan aplikasi layanan Web untuk berkomunikasi dan saling berkomunikasi satu sama lain melalui Web. Lingkungan heterogen dari Web menuntut agar aplikasi mendukung protokol pengkodean dan format pesan umum yang umum. SOAP adalah standar untuk pengkodean pesan dalam XML yang memanggil fungsi pada aplikasi lain.

SOAP analog dengan Remote Procedure Calls (RPC), digunakan di banyak teknologi seperti DCOM dan CORBA, namun menghilangkan beberapa kerumitan penggunaan antarmuka ini. SOAP memungkinkan aplikasi memanggil fungsi dari aplikasi lain, berjalan pada sembarang

Beberapa keuntungan memanfaatkan SOAP meliputi:

• Ini adalah platform dan bahasa yang independen.
• SOAP menyediakan komunikasi yang disederhanakan melalui proxy dan firewall, seperti yang disebutkan di atas.
• Memiliki kemampuan untuk memanfaatkan protokol transportasi yang berbeda, termasuk HTTP dan SMTP, dan juga yang lainnya.

Beberapa kelemahan dari penggunaan SOAP meliputi:
• SOAP biasanya jauh lebih lambat daripada jenis standar middleware lainnya, termasuk CORBA. Ini karena SOAP menggunakan format XML verbose. Anda perlu memahami keterbatasan kinerja sebelum membuat aplikasi di sekitar SOAP.
• SOAP biasanya terbatas pada penyatuan, dan bukan notifikasi acara, saat memanfaatkan HTTP untuk transportasi. Terlebih lagi, hanya satu klien yang bisa menggunakan layanan satu server dalam situasi biasa.
• Sekali lagi, ketika memanfaatkan HTTP sebagai protokol transport, cenderung ada latency firewall karena firewall menganalisa transport HTTP. Hal ini disebabkan fakta bahwa HTTP juga dimanfaatkan untuk penjelajahan Web, dan banyak firewall tidak memahami perbedaan antara penggunaan HTTP dalam browser Web, dan penggunaan HTTP dalam SOAP.
• SOAP memiliki tingkat dukungan yang berbeda, tergantung pada bahasa pemrograman yang didukung. Sebagai contoh, dukungan SOAP dalam Python dan PHP tidak sekuat itu di dalam Java dan .NET.
December 05, 2017

Prinsip Desain RESTful

by , in

Di sini, saya akan menjelaskan sekumpulan prinsip desain RESTful yang harus dipatuhi saat membuat RESTful service.

Mari kita mulai dengan dasar-dasarnya. Apa itu REST?
REST = REpresentational State Transfer. REST adalah gaya arsitektur untuk perangkat lunak berbasis jaringan yang memerlukan komunikasi client-server stateless, dapat di-cache melalui antarmuka yang seragam antar komponen.

Fokus utama kita adalah mengenalkan REST bersama dengan terminologi REST, konsep REST, dan beberapa contoh sederhana yang menggambarkan seperti apa REST dalam praktiknya.

Prinsip Dasar

Komunikasi Client Server
Arsitektur client-server memiliki pemisahan keprihatinan yang sangat berbeda. Semua aplikasi yang dibangun dengan gaya RESTful juga harus menjadi client-server pada prnsipnya.

Stateless
Setiap permintaan dari setiap klien ke server mengharuskan state sepenuhnya terwakili. Server harus dapat sepenuhnya memahami permintaan klien tanpa menggunakan konteks server atau status sesi server. Ini berarti bahwa semua state harus disimpan pada klien.

Cacheable
Kendala cache dapat digunakan, sehingga memungkinkan data respons ditandai sebagai cacheable atau tidak-cachable. Setiap data yang ditandai sebagai cacheable dapat digunakan kembali sebagai respons terhadap permintaan berikutnya yang sama.

Uniform Interface
Semua komponen harus berinteraksi melalui satu antarmuka seragam. Karena semua komponen interaksi terjadi melalui interface ini, interaksi dengan berbagai layanan sangat sederhana. Antarmuka itu sama! Ini juga berarti bahwa perubahan implementasi dapat dilakukan secara terpisah. Perubahan seperti itu, tidak akan mempengaruhi interaksi komponen mendasar karena antarmuka seragam selalu tidak berubah. Salah satu kelemahannya adalah Anda terjebak dengan antarmuka. Jika pengoptimalan dapat diberikan ke layanan tertentu dengan mengubah antarmuka, Anda kurang beruntung karena REST melarang hal ini. Sisi baiknya, bagaimanapun, REST dioptimalkan untuk web, maka popularitas REST yang luar biasa melalui HTTP!
 

Konsep di atas mewakili karakteristik pendefinisian REST dan membedakan arsitektur REST dari arsitektur lain seperti layanan web. Hal ini berguna untuk dicatat bahwa layanan REST adalah layanan web, namun layanan web belum tentu layanan REST.

Mari selami sedikit detail dan diskusikan berbagai elemen yang digunakan untuk menyusun sistem RESTful.


Sumber Daya dan Sumber Daya Identifier:
Abstraksi kunci REST adalah sumbernya. Sumber daya bisa berupa apa saja. Ini bisa berupa dokumen atau gambar, objek, koleksi sumber daya lainnya, dan lainnya. Sumber daya diidentifikasi oleh pengenal sumber dayanya. Pengenal sumber daya sering digunakan saat banyak komponen berkomunikasi satu sama lain. Mereka dapat referensi sumber daya spesifik menggunakan sumber daya identifier.

Dalam prakteknya, sumber daya adalah kata benda. Sumber daya dan diidentifikasi oleh URI,
misalnya Sumber daya Mobil ini diidentifikasi oleh pengenal sumber daya, http://www.automart.com/cars/12345

Representation:

Komponen melakukan tindakan sumber daya dengan menerapkan operasi yang disediakan oleh komponen uniform interface. Sumber daya diwakili oleh keadaan saat ini atau keadaan yang dimaksudkannya (dengan asumsi tindakan akan mengubah sumber daya dengan cara tertentu). Representasi ini mencakup urutan byte dan beberapa deskripsi byte tersebut. Format representasi didefinisikan sebagai jenis media.

Dalam prakteknya, sumber daya sering digambarkan sebagai XML, JSON, RDF, dan banyak lagi

Prinsip Dasar dalam Praktek

Mari kembali ke bagian Prinsip Dasar dan jelaskan bagaimana prinsip-prinsip tersebut dapat diterapkan dalam praktik.

Client-Server

HTTP adalah protokol client-server. Mengapa tidak menggunakannya dengan REST.

Uniform Interface
REST dioptimalkan untuk web, sehingga HTTP biasanya digunakan. HTTP mendefinisikan GET, POST, PUT, DELETE. Itu memenuhi persyaratan REST untuk menyediakan antarmuka seragam untuk komponen.

Cacheable
HTTP menyediakan mekanisme kontrol cache. Lihat disini. HTTP hanya mengisi persyaratan REST yang lain.

Stateless
Tidak begitu mudah. Mari menerapkan beberapa aturan ke antarmuka seragam yang disediakan oleh HTTP
GET - Aman, Cacheable, Idempotent
PUT - Idempotent
DELETE - Idempotent
HEAD - Aman, Idempotent
POST - n / a

Apa artinya?
- Aman - operasi tidak boleh memiliki efek samping
- Cacheable - hasilnya mungkin di-cache misalnya oleh server proxy
- Idempotent - Operasi harus selalu mengembalikan hasil yang sama


REST Penggunaan Praktis

Mari sekarang berikan beberapa contoh penggunaan dalam praktik:

Resource and Resource Identifier

Contoh sumber daya adalah Mobil, Mesin, Bagian. Setiap sumber daya diidentifikasi oleh pengenal sumber dayanya. Sebagai contoh:
Mobil: http://www.automart.com/cars/12345
Bagian: http://www.automart.com/part/12345
Mesin: http://www.automart.com/engine/12345

Representation

Mobil kami dengan pengenal sumber daya, http://www.automart.com/cars/12343 dapat dimanipulasi oleh komponen melalui antarmuka seragam GET, POST, PUT, DELETE. Berikut adalah beberapa contohnya:
 

GET mengembalikan representasi negara sumber daya, Misalnya, http://www.automart.com/cars/12343.
 

Representasi XML tentang keadaan itu mungkin:
  <Mobil>
  <Make> Audi </ Make>
  <Model> A5 </ Model>
  <Tahun> 2013 </ Tahun>
  </Mobil>
atau di JSON
{
"Membuat": "Audi",
"Model": "A5",
"Tahun 2013
}

Representasi dengan Linked Resources

Representasi sumber daya mungkin berisi tautan ke sumber lain
misalnya
<Mobil>
  ...
  <Engine uri = "http://www.automart.com/engine/1242" />
  ...
</ Mobil>
atau di JSON
{
...
"mesin": "http://www.automart.com/engine/1242"
...
}














 


December 04, 2017

REST (REpresentational State Transfer)

by , in

REST (representasional state transfer)

REST (REpresentational State Transfer) adalah gaya arsitektural, dan pendekatan terhadap komunikasi yang sering digunakan dalam pengembangan layanan Web. Penggunaan REST sering disukai daripada gaya SOAP (Simple Object Access Protocol) yang lebih berat karena REST tidak memanfaatkan bandwidth sebanyak itu, yang membuatnya lebih sesuai untuk digunakan melalui Internet. Pendekatan SOAP memerlukan penulisan atau penggunaan program server yang disediakan (untuk melayani data) dan program klien (untuk meminta data).

Arsitektur REST'S decoupled, dan komunikasi bobot yang lebih ringan antara produsen dan konsumen, menjadikan REST sebagai bangunan populer untuk cloud-based API, seperti yang disediakan oleh Amazon, Microsoft, dan Google. Ketika layanan Web menggunakan arsitektur REST, disebut RESTful APIs (Application Programming Interfaces) atau REST APIs.

Arsitektur REST melibatkan membaca halaman Web yang ditunjuk yang berisi file XML. File XML menjelaskan dan menyertakan konten yang diinginkan. Setelah didefinisikan secara dinamis, konsumen dapat mengakses antarmuka.


REST, yang biasanya berjalan di atas HTTP (Hypertext Transfer Protocol), memiliki beberapa kendala arsitektural:
  1. Uniform interface
  2. Stateless
  3. Client-server
  4. Cacheable
  5. Leyered system
  6. Code on demand
Untuk Penjelasan Diatas Baca Prinsip RESTful berikut:
http://bisacodingphp.blogspot.com/2017/12/prinsip-desain-restful.html

REST sering digunakan pada aplikasi mobile, situs jejaring sosial, mashup tools, dan proses bisnis otomatis. Gaya REST menekankan bahwa interaksi antara klien dan layanan ditingkatkan dengan memiliki sejumlah operasi (kata kerja) terbatas. Fleksibilitas diberikan dengan menetapkan sumber daya (kata benda) Pengenal Sumber Daya Universal unik mereka sendiri (URI). Karena setiap kata kerja memiliki arti tertentu (GET, POST, PUT dan DELETE), REST menghindari ambiguitas.

Ada beberapa kerugian. Dalam dunia REST, tidak ada dukungan langsung untuk menghasilkan klien dari metadata yang dihasilkan oleh server. SOAP dapat mendukungnya dengan Web Service Description Language (WSDL).

REST memberikan keuntungan sebagai berikut, khususnya keuntungan dari penggunaan SOAP:

  • Layanan Web yang tenang mudah digunakan oleh kebanyakan alat, termasuk yang gratis dan tidak mahal. REST menjadi nada sambung untuk interaksi sistem, termasuk penggunaan RESTful Layanan web, yang sebagian besar, cara penyedia cloud mengeksternalisasikan layanan cloud mereka.
  • Layanan SOAP jauh lebih sulit untuk diukur daripada layanan RESTful. Dengan demikian, REST sering dipilih sebagai arsitektur untuk layanan yang terpapar melalui Internet (seperti Facebook, MySpace, Twitter, dan penyedia cloud paling umum).
  • Kurva belajar cenderung berkurang. Pengembang dapat memanfaatkan REST dari dalam aplikasi lebih cepat daripada yang dapat mereka lakukan dengan SOAP. Ini menghemat waktu, yang menghemat uang.
  • REST menggunakan format pesan yang lebih kecil dari SOAP. SOAP menggunakan XML untuk semua pesan, yang membuat ukuran pesan jauh lebih besar, dan karenanya kurang efisien. Ini berarti REST memberikan kinerja yang lebih baik, serta menurunkan biaya dari waktu ke waktu. Selain itu, tidak diperlukan pengolahan intensif, sehingga jauh lebih cepat daripada SOAP tradisional.
  • REST dirancang untuk penggunaan melalui Open Internet / Web. Ini adalah pilihan yang lebih baik untuk aplikasi skala Web, dan tentunya untuk platform berbasis cloud. 

Ke depan, REST kemungkinan akan melanjutkan pertumbuhannya karena perusahaan berusaha menyediakan antarmuka terbuka dan terdefinisi dengan baik untuk layanan aplikasi dan infrastruktur. Pertumbuhan komputasi cloud publik dan swasta mendorong sebagian besar permintaan ini, dan akan terus mendorong pertumbuhan ke masa depan.