Bab-bab sebelumnya menjelaskan bagaimana mengembangkan sebuah platform berbasis Web, dan bilamana ditambahkan fitur AJAX, berubah menjadi Web 2.0 Platform.
Tetapi tentu saja kita tidak dapat memaksakan kombinasi komponen penyusun framework, seperti yang terulas dibab 1, ada beberapa kombinasi berbasis MVC yang dikembangkan seperti JBoss dengan Seamnya, Oracle juga memiliki dengan ADFnya, lalu Alfresco juga memiliki, serta buku ini membahas kombinasi lain.
Semua kombinasi ini memungkinkan dikembangkannya solusi yang lebih baik daripada pengembangan tradisional dengan model 1 menggunakan JSP, yang bukan hanya lebih lambat tetapi juga kotor.
Kemungkinkan ada aplikasi yang dikembangkan disalah satu perusahaan dan sudah stabil baik itu dengan framework MVC atau dengan JSP, berkemungkinan ditemukan. MalahanMalahan sebenarnya sebuah solusi dapat dikembangkan bukan dengan teknologi Java. Akibatnya muncul banyak lautan informasi yang tidak terintegrasi, yang mana perpindahan data dari satu lautan informasi ke lautan informasi akan memberikan value yang lebih besar, sebagai contoh adalah birokrasi pemerintahaan, akan semakin baik dengan adanya integrasi sistem, yang mana mungkin saja departemen A mengembangkan dengan FoxPro, departemen B dengan Oracle Developer dan departemen C baru
menggunakan MVC. Semua ini adalah kebebasan memilih dariSemua ini adalah kebebasan memilih dari sang pemakai sistem.
Pulau Informasi
Telah muncul sebuah teknologi yang memungkinkan pulau- pulau informasi dapat saling bertukar data, dan hebatnya teknologi ini memungkinkan terjadi pertukaran data terhadap teknologi yang tidak rukun seperti .NET dan Java, PHP dengan Python. Teknologi ini disebut Web Services, tetapi evolusinya akhirnya berubah menjadi SOA singkatan dari Services Oriented Architecture.
SOA ini adalah sebuah jargon yang sedikit membingungkan, karena berdiri dari sebuah kata services yang berarti pelayanan. Dimana setiap vendor punya hak untuk menganggap setiap bagian kecil komponennya adalah SOA, hal ini karena bersifat melayani.
berkembang sangat pesat adalah sebuah teknologi open yang merupakan turunan dari XML, yang dikelola oleh W3C, yaitu SOAP.
SOAP merupakan sebuah meta data yang bekerja seperti amplop dalam surat menyurat, yang bekerja diatas protokol TCP/IP, tetapi banyak juga yang mengextendnya sehingga berjalan diatas protocol HTTP.
Mekanisme yang berjalan diatas HTTP ini yang membuat SOAP menjadi sebuah teknologi yang hot, sampai tahun 2005 dianggap tahun SOA Internasional.
Berikut ini adalah diagram bagaimana SOAP bekerja antara satu sistem dengan sistem lain. Implementasi SOAP ini terhadap pulau-pulau informasi memungkinkan data berpindah dan terjadi interoperabilitas.
Arsitektur dasar dari SOA untuk Interoperabilitas SOAP dalam SOA, bekerja seperti halnya request dan response pada HTML, tetapi tentu saja format yang dikirm bukan berdasarkan skema HTML, tetapi SOAP.
departemen perhubungan, yang merupakan salah satu kasus pengembangan PASIR. PASIR adalah inisiatif seperti SOA yang bermula dari gerakan IGOS, tetapi akhirnya menjadi salah satu dari inisiatif Open Aptel di Depkominfo. Skema ini merupakan salah satu dari prototype yang didanai oleh CIDA (Canada Indonesia Development Aid).
Ke-3 entitas itu adalah Pelabuhan/Galangan Kapal, PT Pelindo dan Departemen Perhubungan. Dimana data dari galangan kapal dikirim ke pelindo, terus dilanjutkan ke departemen perhubungan menggunakan teknologi SOAP.
Prototype Interoperabilitas didalam Departemen Perhubungan Sebenarnya prototype diatas merupakan prototype yang paling sederhana dari implementasi SOA. Berikut adalah stack dari SOA yang sedan dikembangkan didalam projek PASIR, yang mana diagram tersebut dikembangkan oleh Sun Microsystems.
WebServices Stack dari Sun Microsystems
SOAP bekerja untuk tujuan point-to-point, tetapi untuk sebuah mekanisme interoperabilitas yang lebih komplek, yang mana setiap informasi akan dapat diproses bilamana melakukan fetching terhadap lebih dari SOAP listener, diperlukan sebuah standar baru bernama BPEL. BPEL ini seperti halnya workflow dalam organisasi, yang memonitor dan menentukan logika bilamana proses request ke sebuah layanan menggunakan SOAP telah selesai.
Adapun leveling dari semua layanan yang dianggap sebagai fondasi web services adalah sebagai berikut:
Stack Spesifikasi Web Services Interopabilitas dari WS-I Terkadang dalam implementasi sebenarnya, terkadang
diperlukan banyak sekali layanan web services., setiap layanan yang dideskripsikan dalam bentuk WSDL (Web Services Description Language) ini menjadi sangat membingungkan, karena setiap pihak dapat membuat URLnya sendiri-sendiri dan tidak ada aturannya. Untuk itu lahirlah UDDI, yang secara awam dapat dikatakan sebagai tempat untuk mendaftarkan URL dari WSDL.
Bilamana UDDI telah dikembangkan, artinya setiap request hanya perlu melakukan pemetaan di UDDI tersebut. Cara kerjanya mirip dengan manajemen domain, seperti .com, .org diatur oleh InterNIC, sedangkan .or.id, atau .co.id dimanage di IDNIC.
Sebaiknya tentu saja bilamana implementasi web services telah banyak, hal ini untuk membuat URL WSDL yang tidak enak dibaca mata, menjadi lebih manusia.
Cara Kerja UDDI dalam proses request dan response pada solusi SOA
Berikut adalah diagram bagaimana tiga layanan berbasis SOAP yang diproses menjadi sebuah informasi menggunakan sebuah BPEL, yang menghasilkan sebuah konsolidasi layanan.
Interaksi BPEL dalam SOA
Inisiatif BPEL merupakan salah satu mekanisme untuk pengembangan solusi Single Windows atau centralisasi operasional. Berikut adalah bentuk dari BPEL, yang mana bilamana kita sedikit cerdik, dapat menggunakan skema BPEL sebagai single window monitoring system
BPEL dengan sumber informasi (SOA)
Object Wrapper
Memang banyak sekali teknologi dibalik SOA, malah berdasarkan pengalaman penulis terhadap dunia IT. Semua teknologi tersebut suka atau tidak suka harus diadopsi, dan ini tentu saja memerlukan resource yang sangat besar untuk mengembangkannya, belum lagi model implementasi yang dapat bermacam-macam. Tentu saja, ini diluar dari kemungkinan sistem dihajar oleh para hacker (Indonesia adalah negara no. 1 didunia untuk urusan per-hacker-an). Ini yang membuat implementasi Web Services menjadi lebih rentan lagi. Akibatnya implementasi SOAP untuk level yang lebih tinggi salah satunya Web Services Security harus dipasang.
point. Hanyalah satu konsep sederhana untuk membuat semua ini menjadi lebih mudah dimengerti, semuanya balik lagi ke POJO (Plain Old Java Objek). Yang mana dalam pengembanganYang mana dalam pengembangan MVC, lebih cenderung disebut sebagai Model.
POJO ini ternyata yang disimpan didalam server. POJO iniPOJO ini yang ternyata yang diakses oleh client pengakses Web Services. Jadi dengan lain kata Web Services adalah sebuah pembungkus objek (Object Wrapper) yang membuat POJO ini berubah menjadi SOAP.
Yang mana, karena SOAP ini merupakan sebuah standar terbuka, membuat SOAP yang diwrap, dimana didalam wrapper tersebut adalah POJO, membuat POJO tersebut dapat diakses oleh aplikasi apapun baik itu .NET, Java, Python ataupun PHP. POJO yang diakses via SOAP ini, akan menjadi sebuah plain object juga untuk pengaksesnya.
POJO di Server (Java) WebServices Wrapper Objek di Client (.NET)
Proses Wrapping POJO ke .NET
WebServices merubah sebuah POJO menjadi object teknologi .NET
Wrapper ini ternyata merubah objek dari teknologi pembuatnya misalnya Java, menjadi teknologi lain yang mungkin tidak dapat memanggil objek tersebut bilamana dipasang dalam satu server, menjadi bagian dari teknologi yang mengaksesnya. Sebagai contoh adalah, bilamana kita telah mempunyai aplikasi manajemen kontak dengan Java, dan kita hendak mengembangkan versi berikutnya menggunakan.NET yang
bekerja mencatat peluang perusahaan. Sayangnya kita tidak ingin aplikasi yang telah ada dibuat ulang. Dimana aplikasiDimana aplikasi CRM yang diinginkan adalah kombinasi peluang (.NET) dan nama kontak (Java).
ContactPerson (Java) WebServices Wrapper Opportunity (.NET) Informasi
Pengolahan Informasi menggunakan Web Services Bilamana kasus diatas dilakukan tanpa web services. Hal yang mungkin dilakukan adalah merubah objek Contact yang dikembangkan dengan Java, menjadi COM atau .NET compliance, sehingga aplikasi .NET dapat menggunakannya untuk kebutuhan pemorosesan aplikasi peluang perusahaan yang dikembangkan.
Bagaimana bilamana ternyata setelah itu, kita mengembangkan aplikasi berikutnya dengan Ruby, misalnya aplikasi e-
procurement, apa yang akan terjadi? Apakah kita harus merubah semua aplikasi Java dan .NET menjadi sebuah komponen yang dikenal Ruby, tentu saja tidak mimpi buruk yang akan terjadi. Web Service datang dengan merubah setiap objek yang dikembangkan teknologi lain, menjadi dapat diakses oleh teknologi lain, dan tanpa perlu merubah menjadi komponen yang dikenal, hanya dirubah menjadi Web Services, maka secara otomatis komponen tersebut dapat digunakan.
kita mencari teknologi wrapper yang ada.
Yang lebih hebat, Web Services ini berjalan pada port 80, yaitu port HTTP. Tentu saja ini artinya kita dapat memasang aplikasi Web Services pada internet. Dengan kombinasi HTTPS dan Web Services yang diencrypt atau diberikan signature (XML Signature), ataupun ditambahakan spesisikasi implementasi Web Services Security, membuat komunikasi antara komponent Java, .NET dan Ruby menjadi lebih aman.
Tentu saja, bilamana dilakukan dengan wrapper tradisional seperti COM converter, akan sangat sulit sekali.
Mengembangkan Web Services Sendiri
Berikut adalah sebuah POJO atau JavaBean yang akan dirubah menjadi Web Services yang akan dibaca oleh aplikasi lain. Komponen POJO sumber:
package org.blueoxygen.gemilang; public SoapServer {
private String name=”BBook2”; public String getName() {
returns name; }
public setName(String name) { this.name=name;
} }
Sedangkan pengakses adalah sebuah aplikasi Java juga, berikut adalah cuplikan kodenya
public static void main(String[] args){ Service service = new Service(); Call call;
call = (Call) service.createCall(); call.setTargetEndpointAddress( ”http://localhost:5794/AxisTest/services/ SoapServer ”); try { System.out.println(”SetNAme”); call.setOperationName(”setName”); call.invoke(new Object[]{ new String(”Leo”) }); System.out.println(”GetNAme”); call.setOperationName(”getName”);
Object name = call.invoke(new Object[]{}); System.out.println(”Client:”+name); } catch (RemoteException e) { e.printStackTrace(); } } catch (ServiceException e) { e.printStackTrace(); } } }
Bilamana kita lihat secara kasat mata, apakah 2 kode diatas dapat berinteraksi? Jawabannya tidak ada hubungannya. dengan merubahnya menjadi sebuah Web Services, objek POJO kita dapat diakses atau lebih disebut juga di invoke. Dengan merubah POJO pertama menjadi sebuah Web Services, membuat aplikasi lain dengan mengacu pada http:// localhost:5794/AxisTest/services/SoapServer , membuat aplikasi dapat mengakses POJO yang berada diserver. Tentu saja, ada perbedaan yang mencolok terjadi, bilamana kita mengembangkan semua objek dalam satu kontainer, dan aplikasi adalah aplikasi Desktop seperti Postila, tentu saja POJO yang diakses akan terus aktif dan isinya akan dapat dipakai oleh seluruh aplikasi, sampai aplikasinya dimatikan.
mekanisme Web Services, akan kembali ke nilai awalnya, alias isi dari variable name pada kasus diatas adalah BBook2, akan terus BBook2.
Hal ini terjadi karena Web Services bekerja seperti halnya request dan response pada HTML. Jadi dengan lain kata Web Services client diatas mirip dengan cara kerja browser, hanya dalam kasus browser, yang dihasilkan adalah hasil final, sedangkan dalam Web Services yang dihasilkan adalah objek. Untuk mengatasi hal ini, setiap POJO yang ditaruh didalam server Web Services harus disimpan didalam session.
Mengembangkan SOAP dengan Eclipse Calisto
SOAP adalah satuan terkecil dari pengembangan aplikasi berbasis Web Services yang paling umum dilakukan. Sebenarnya mekanisme pengerjaan SOAP adalah merubah sebuah objek menjadi berbasis SOAP. Jadi dapat dikatakanJadi dapat dikatakan SOAP adalah mekanisme mengakses objek dengan
menggunakan XML.
Cara Kerja Interaksi antara aplikasi berbasis SOAP Dikarenakan mekanisme pengerjaan adalah berbasis XML, dan implementasi SOAP API dapat dilakukan oleh banyak pihak menggunakan teknologi yang bermacam-macam. Hal ini dikarenakan XML yang menyusun SOAP adalah sebuah flat file biasa.
Berikut adalah sebuah objek Buku, yang akan dibungkus dan dirubah menjadi sebuah SOAP, yang kemudian diakses oleh aplikasi lain.
package org.blueoxygen.bbook2.webservices; public class Buku {
private String title = ”Cara Cepat
Mengembangkan Java Enterprise dengan Metode MVC”; private String author =”Frans Thamura”; private String isbn =”999-123123”; public String getAuthor() {
return author; }
public void setAuthor(String author) { this.author = author;
}
public String getIsbn() { return isbn;
}
public void setIsbn(String isbn) { this.isbn = isbn;
}
public String getTitle() { return title;
}
public void setTitle(String title) { this.title = title;
} }
Setelah objek Buku dibuat, klik kananlah file tersebut, dan pilihlah Web Services, untuk masuk ke wizard wrapping dari objek Java menjadi sebuah SOAP.
Menu untuk merubah objek menjadi Web Services Sebuah wizard akan muncul, dan ada 2 implementasi yang memungkinkan yaitu top down atau bottom up. Bilamana dari objek pilihlah bottom up, bilamana dari WSDL, pilihlah top down.
