DISTRIBUTED OBJECT AND COMPONENT

DISTRIBUTED SYSTEMS Concept and Design – Fifth Edition
George Coulouris
Cambridge University
Jean Dollimore
formerly of Queen Mary, University of London
Tim Kindberg
matter 2 media
Gordon Blair
Lancaster University

Sebuah solusi middleware lengkap harus menyajikan abstraksi pemrograman tingkat tinggi seperti serta abstrak lebih kompleksitas yang mendasari yang terlibat dalam sistem terdistribusi.
Bab ini meneliti dua dari abstraksi pemrograman yang paling penting, yaitu objek terdistribusi dan komponen, dan platform middleware juga membahas terkait termasuk CORBA, JavaBeans Enterprise dan Fractal.

CORBA adalah desain middleware yang memungkinkan program aplikasi untuk berkomunikasi
dengan satu terlepas lain dari bahasa pemrograman mereka, hardware dan platform perangkat lunak, jaringan mereka berkomunikasi melalui dan pelaksana mereka.Aplikasi yang dibangun dari objek CORBA, yang mengimplementasikan antarmuka yang didefinisikan dalam definisi bahasa antarmuka CORBA, IDL. Seperti Java RMI, CORBA mendukung transparan doa metode pada objek jarak jauh. Komponen middleware yang mendukung RMI disebut permintaan objek broker, atau ORB. middleware berbasis komponen telah muncul sebagai evolusi alami dari didistribusikan benda, memberikan dukungan untuk mengelola dependensi antara komponen, menyembunyikan rincian tingkat rendah terkait dengan middleware, mengelola kompleksitas membangun aplikasi terdistribusi dengan sifat non-fungsional yang sesuai seperti keamanan, dan mendukung strategi penyebaran yang tepat. teknologi kunci di daerah ini mencakup Enterprise JavaBeans dan Fractal.









8.1 PENDAHULUAN
Bab-bab sebelumnya diperkenalkan blok bangunan dasar fundamental untuk
sistem terdistribusi dalam hal komunikasi dan dukungan sistem operasi. Ini bab ternyata untuk menyelesaikan solusi middleware, menyajikan objek terdistribusi dan komponen sebagai dua dari gaya yang paling penting ofmiddleware digunakan saat ini.Diskusi diikuti dalam Bab 9 dan 10 dengan pertimbangan pendekatan alternatif berdasarkan pada layanan web dan solusi peer-to-peer.Sebagaimana dibahas dalam Bab 2, tugas middleware adalah untuk memberikan tingkat yang lebih tinggi pemrograman abstraksi untuk pengembangan sistem terdistribusi dan, melalui
layering, abstrak lebih heterogenitas dalam infrastruktur dasar untuk mempromosikan interoperabilitas dan portabilitas.



Didistribusikan objek middleware

Kunci karakteristik objek terdistribusi adalah bahwa mereka
memungkinkan Anda untuk mengadopsi model pemrograman berorientasi objek untuk pengembangan sistem terdistribusi dan, melalui ini, menyembunyikan kompleksitas yang mendasari didistribusikan Dalam pendekatan ini, entitas berkomunikasi diwakili oleh objek.Benda berkomunikasi terutama dengan menggunakan doa metode remote, butalso mungkin menggunakan paradigma komunikasi alternatif (seperti acara-acara didistribusikan). ini relatif Pendekatan sederhana memiliki sejumlah manfaat penting, termasuk yang berikut:
Theencapsulationinherent dalam solusi berbasis obyek cocok untuk didistribusikan
Properti terkait data abstractionprovides pemisahan bersih antara spesifikasi dari sebuah objek dan pelaksanaannya, yang memungkinkan programmer untuk menangani hanya dalam hal interface dan tidak peduli dengan rincian pelaksanaan seperti bahasa pemrograman dan sistem operasi yang digunakan.
Pendekatan ini juga cocok untuk extensiblesolutions dynamicand lebih, untuk Misalnya dengan memungkinkan pengenalan objek baru atau penggantian satuobjek dengan objek lain (kompatibel).Berbagai solusi middleware berdasarkan objek terdistribusi yang tersedia, termasuk Java RMI dan CORBA. Kami merangkum fitur kunci dari objek terdistribusi dalam Bagian 2 dan memberikan studi kasus rinci CORBA dalam Bagian 8.3.middleware.
solusi berbasis komponen berbasis komponen telah dikembangkan untuk
mengatasi sejumlah keterbatasan yang telah diamati untuk pengembang aplikasi
bekerja dengan didistribusikan objek middleware: dependensi implisi t: antarmuka Obyek tidak menggambarkan apa pelaksanaan sebuah benda bergantung pada, membuat sistem berbasis objek sulit untuk berkembang (terutama untuk pengembang pihak ketiga) dan kemudian mengelola. kompleksitas pemrograman Pemrograman didistribusikan objek middleware mengarah keperlu menguasai banyak detail tingkat rendah yang terkait dengan implementasi Kurangnya pemisahan keprihatinan distribusi:


Pengembang aplikasi wajib pertimbangkan rincian kekhawatiran seperti keamanan.
Penanganan kegagalan dan concurrency,yang sangat mirip dari satu aplikasi ke aplikasi lain.
Tidak ada dukungan untuk penyebaran: Obyek berbasis middleware menyediakan sedikit atau tidak ada dukungan untuk penyebaran (potentiallycomplex) konfigurasi objek.solusi berbasis komponen dapat dipahami sebagai evolusi alami dari pendekatan berbasis objek, membangun warisan yang kuat dari karya sebelumnya. bagian 8.4 membahas pemikiran ini inmore rinci dan memperkenalkan fitur kunci dari pendekatan berbasis komponen.

Bagian 8.5 kemudian menyajikan dua studi kasus yang kontras dari solusi berbasis komponen, JavaBeans Enterprise dan Fractal, dengan mantan korban yang solusi yang komprehensif yang abstrak lebih banyak dari isu-isu kunci dalam mengembangkan aplikasi terdistribusi dan yang terakhir mewakili solusi yang lebih ringan sering digunakan untuk membangun teknologi middleware lebih kompleks.


8.2 OBJEK TERDISTRIBUSI


Middleware berdasarkan objek terdistribusi dirancang untuk menyediakan model pemrograman berdasarkan prinsip-prinsip berorientasi objek dan thereforeto membawa manfaat dari pendekatan berorientasi objek untuk pemrograman terdistribusi.Emmerich [2000] melihat objek terdistribusi seperti evolusi alami dari tiga helai kegiatan:

Dalam sistem terdistribusi, middleware sebelumnya didasarkan pada model client server dan ada keinginan untuk abstraksi pemrograman yang lebih canggih.
Dalam bahasa pemrograman, pekerjaan sebelumnya dalam bahasa berorientasi objek seperti Simula-67 dan Smalltalk menyebabkan munculnya lebih utama dan berat
bahasa pemrograman yang digunakan seperti Java dan C ++ (bahasa yang digunakan secara luas dalam sistem terdistribusi).
Dalam rekayasa perangkat lunak, kemajuan yang signifikan dibuat dalam pengembangan metode desain berorientasi objek, yang mengarah ke munculnya Bersatu Pemodelan Language (UML) sebagai notasi industri-standar untuk menentukan(Berpotensi didistribusikan) sistem perangkat lunak berorientasi objek.
Dengan kata lain, melalui mengadopsi pendekatan berorientasi objek, sistem terdistribusi pengembang tidak hanya disediakan dengan abstraksi pemrograman lebih kaya (menggunakan familiar bahasa pemrograman seperti C ++ dan Java) tetapi juga dapat menggunakan berorientasi obyek prinsip-prinsip desain, alat dan teknik (termasuk UML) dalam pengembangan software sistem terdistribusi. Ini merupakan langkah maju yang besar di daerah di mana,sebelumnya, teknik desain seperti itu tidak tersedia. Sangat menarik untuk dicatat bahwa OMG, organisasi yang mengembangkan CORBA (lihat Bagian 8.3), juga mengelola standarisasi UML.
objek terdistribusi middlewareoffers abstraksi pemrograman berdasarkan prinsip-prinsip berorientasi objek. Memimpin contoh didistribusikan objek middleware mencakup Java RMI (dibahas dalam Bagian 5.5) dan CORBA (diperiksa secara mendalam pada Bagian 8.3 di bawah).Sementara Java RMI dan CORBA berbagi banyak kesamaan, ada satu perbedaan penting : penggunaan Java RMI dibatasi untuk pembangunan berbasis Java, sedangkan CORBA adalah solusi multi-bahasa memungkinkan objek yang ditulis dalam berbagai bahasa untuk beroperasi. (Bindings ada untuk C ++, Java, Python dan beberapa orang lain.)
Harus ditekankan bahwa pemrograman dengan objek terdistribusi adalah baik berbeda dari dan secara signifikan lebih kompleks daripada pemrograman berorientasi objek standar, seperti dirangkum di bawah ini.Perbedaan: Perbedaan Key antara objek dan objek terdistribusi sudah telah dibahas pada Bagian 5.4.1, dalam konteks RMI. Untuk kenyamanan, diskusi ini
diulang di sini dalam bentuk ringkasan (lihat Gambar 8.1 objek terdistribusi
Objek Terdistribusi objek Deskripsi objek terdistribusi referensi objek referensi objek remote referensi global yang unik untuk objek terdistribusi; dapat dilewatkan sebagai parameter.Antarmuka antarmuka remote Menyediakan spesifikasi abstrak dari metode yang dapat dipanggil pada objek remote; ditentukan menggunakan bahasa definisi antarmuka (IDL).Tindakan Distributed tindakan Diprakarsai bya metode doa,berpotensi menghasilkan doa rantai; doa jarak jauh menggunakan RMI.



Pengecualian Distributed pengecualian pengecualian tambahan yang dihasilkan dari
sifat didistribusikan dari sistem,termasuk kehilangan pesan atau proses kegagalan.
pengumpulan sampah koleksi Distributed sampah Diperpanjang skema untuk memastikan bahwa objek akan terus ada jika setidaknya salah satu referensi objek atau objek remote referensi ada untuk objek itu,jika tidak, itu harus dihapus. Membutuhkan sampah didistribusikan algoritma koleksi.

Perbedaan lainnya akan muncul ketika kita melihat secara rinci pada CORBA dalam Bagian 8.3. Ini termasuk:

Classis konsep mendasar dalam bahasa berorientasi objek tetapi tidak fitur
begitu menonjol dalam didistribusikan objek middleware. Sebagaimana dicatat dalam kasus CORBA studi, sulit untuk menyepakati interpretasi umum dari kelas dalam lingkungan yang heterogen di mana beberapa bahasa hidup berdampingan. Dalam dunia berorientasi objek secara lebih umum, kelas memiliki beberapa penafsiran, termasuk deskripsi perilaku yang terkait dengan sekelompok objek (template digunakan untuk membuat objek dari kelas), tempat untuk pergi untuk instantiate objek dengan diberikan perilaku (pabrik terkait) atau bahkan kelompok benda yang mematuhi perilaku itu. Sedangkan istilah 'kelas' dihindari, istilah yang lebih spesifik seperti 'Pabrik' dan 'Template' yang mudah digunakan (pabrik menjadi objek yang akan instantiate objek froma baru diberikan template).
Gaya inheritanceis signifikan berbeda dari yang ditawarkan di kebanyakan bahasa berorientasi objek. Secara khusus, didistribusikan objek middleware menawarkan antarmuka warisan, yang merupakan hubungan antara interface dimana antarmuka baru mewarisi metode tanda tangan dari antarmuka asli dan dapat menambahkan yang ekstra.


Sebaliknya, bahasa berorientasi objek seperti Smalltalk Penawaran pelaksanaan inheritanceas hubungan antara implementasi, dimana kelas baru (dihal ini) mewarisi pelaksanaan (dan karenanya perilaku) dari kelas yang asli dan dapat menambahkan perilaku ekstra. warisan implementasi jauh lebih sulit untuk melaksanakan, khususnya di sistem terdistribusi, karena kebutuhan untuk menyelesaikan perilaku executable yang benar pada saat runtime. Perhatikan, misalnya, tingkat heterogenitas yang mungkin ada dalam sistem terdistribusi, bersama-sama dengan kebutuhan untuk menerapkan solusi yang sangat scalable.
Wegner, dalam makalah mani pada objek-berorientasi bahasa [Wegner 1987], mendefinisikan objek orientasi sebagai objek + kelas + warisan. Dalam sistem terdistribusi, jelas interpretasi somewhatdifferent, dengan kedua kelas dan pewarisan dihindari atau disesuaikan.Yang tersisa adalah fokus yang kuat pada enkapsulasi dan abstraksi data, bersama-sama dengan link yang kuat untuk merancang metodologi seperti yang ditekankan di atas.kompleksitas yang ditambahkan: Karena kompleksitas menambahkan terlibat, terkaitdidistribusikan objek middleware harus menyediakan fungsionalitas tambahan, seperti yang dirangkum di bawah: komunikasi antar objek: Sebuah kerangka middleware objek terdistribusi harus menawarkan satu atau lebih mekanisme untuk objek untuk berkomunikasi di lingkungan terdistribusi. Hal ini biasanya disediakan oleh doa metode remote, meskipun didistribusikan objek middleware sering suplemen ini komunikasi withother paradigma (Misalnya, pendekatan tidak langsung seperti acara-acara didistribusikan). CORBA menyediakan acara layanan dan layanan notifikasi terkait, baik diimplementasikan sebagai layanan di atas dari middleware inti (lihat Bagian 8.3.4).Siklus hidup manajemen: manajemen siklus hidup berkaitan dengan penciptaan,migrasi dan penghapusan objek,dengan setiap langkah harus berurusan dengan didistribusikan sifat lingkungan yg mendasarinya.Aktivasi dan deaktivasi: Dalam implementasi non-terdistribusi, sering bisa diasumsikan bahwa benda aktif sepanjang waktu saat proses yang berisi mereka berjalan.Dalam sistem terdistribusi, namun, ini tidak dapat dianggap sebagai angka benda mungkin sangat besar, dan karena itu akan menjadi boros sumber daya untuk memiliki semua benda tersedia setiap saat. Selain itu, node tuan benda mungkin tidak tersedia untuk periode waktu.

Aktivasi adalah proses pembuatan suatu objek aktif dalam didistribusikan lingkungan dengan menyediakan sumber daya yang diperlukan untuk itu untuk memproses masuk doa - efektif,menempatkan objek dalam memori virtual dan memberikan yang benang yang diperlukan untuk mengeksekusi. Penonaktifan kemudian proses yang berlawanan, render keberatan sementara tidak dapat memproses doa. Kegigihan: Objek biasanya memiliki negara, dan penting untuk mempertahankan negara inidi kemungkinan siklus aktivasi dan deaktivasi dan memang kegagalan sistem.

Didistribusikan objek middleware karena itu harus menawarkan manajemen persistensi untuk benda stateful.Layanan tambahan: Kerangka distributedobject middleware yang komprehensif juga harus memberikan dukungan untuk rentang ofdistributed layanan sistem dipertimbangkan dalam buku ini, termasuk penamaan, keamanan dan layanan transaksi.





8.3 STUDI KASUS : CORBA





Manajemen Obyek Group (OMG) dibentuk pada tahun 1989 dengan tujuan untuk mendorong adopsi didistribusikan inorder sistem objek untuk mendapatkan manfaat dari object-oriented pemrograman untuk pengembangan perangkat lunak dan untuk memanfaatkan sistem terdistribusi, yang yang menjadi meluas. Untuk mencapai tujuan-tujuannya, OMG menganjurkan penggunaan open sistem berbasis pada antarmuka berorientasi objek standar. Sistem ini akan dibangun dari perangkat keras yang heterogen, jaringan komputer, sistem operasi dan pemrograman bahasa.
Motivasi penting adalah untuk memungkinkan objek terdistribusi untuk diterapkan di bahasa pemrograman dan untuk dapat berkomunikasi dengan satu sama lain.

Oleh karena itu dirancang suatu bahasa antarmuka yang independen dari setiap tertentu bahasa implementasi.Mereka memperkenalkan sebuah metafora, theobject permintaan broker (ORB), yang berperan untuk
membantu klien untuk memanggil metode pada objek (mengikuti gaya RMI, seperti yang diperkenalkan diBab 5). Peran ini melibatkan lokasi objek, mengaktifkan objek jika diperlukan dan kemudian berkomunikasi permintaan klien ke objek, yang membawa keluar dan balasan.Bagian ini menyajikan studi kasus OMG'sCommon Object Request Broker Arsitektur (CORBA), membangun objek konsep permintaan broker ini. Presentasi berfokus pada CORBA 2 spesifikasi (inovasi utama dalam penggantinya, CORBA 3, adalah pengenalan model komponen, seperti yang dibahas dalam Bagian 8.4). Komponen utama dari bahasa-independen kerangka RMI CORBA adalah
pengikut :



Bahasa definisi antarmuka dikenal sebagai IDL, yang dijelaskan secara rincidalam Bagian 8.3.1
Arsitektur, yang dibahas dalam Bagian 8.3.2.
Representasi data eksternal, yang disebut CDR, yang dijelaskan dalam Bagian 4.3.1 -juga mendefinisikan format khusus untuk pesan dalam protokol request-reply dan pesan untuk bertanya tentang lokasi objek, untuk membatalkan permintaan dan untuk melaporkan kesalahan.
Bentuk standar untuk referensi objek remote, yang dijelaskan dalam Bagian 8.3.3.Arsitektur CORBA juga memungkinkan untuk layanan CORBA - satu set layanan generik yang berguna untuk aplikasi Ini diperkenalkan secara singkat dalam Bagian 8.3.4
(Versi yang lebih lengkap dari studi kasus ini, termasuk pertimbangan rinci dari CORBA layanan, dapat ditemukan di situs web pendamping [www.cdk5.net]).
Bagian 8.3.5 juga berisi contoh pengembangan klien dan server menggunakan
CORBA.Untuk koleksi menarik dari artikel pada CORBA, melihat masalah CACMspecial
[Seetharamanan 1998].
8.3.1 CORBA RMI


Pemrograman dalam sistem RMI multi-bahasa seperti CORBA RMI membutuhkan lebih dari
programmer dari pemrograman dalam sistem RMI single-bahasa seperti Java RMI.
mengikuti konsep baru perlu dipelajari:

Model objek yang ditawarkan oleh CORBA.
Ia antarmuka bahasa definisi.
Pemetaan ke bahasa implementasi.
aspek lain dari pemrograman CORBA adalah similarto yang dibahas dalam Bab 5. Dalam khususnya, programmer mendefinisikan remote interface untuk objek remote dan kemudian menggunakan compiler antarmuka untuk menghasilkan yang sesuai proxy dan kerangka. namun dalam CORBA, proxy dihasilkan dalam bahasa klien dan kerangka di server Model objek CORBA.
The CORBA objek Model ini mirip dengan yang dijelaskan di Bagian 5.4.1, tapi klien tidak selalu benda - klien dapat program apapun yang mengirimkan pesan permintaan ke objek remote dan menerima balasan. Istilah objek CORBA digunakan untuk merujuk ke objek remote. Dengan demikian, objek CORBA mengimplementasikan antarmuka IDL,
memiliki referensi objek remote dan mampu menanggapi doa dari metode dalam IDL yang Sebuah objek CORBA dapat diimplementasikan oleh bahasa yang tidak berorientasi obyek - misalnya, tanpa konsep kelas. Karena bahasa implementasi
akan memiliki pengertian yang berbeda kelas, atau bahkan tidak sama sekali, konsep kelas tidak ada di CORBA (lihat juga pembahasan dalam Bagian 8.2). Oleh karena itu kelas tidak dapat didefinisikan di CORBA IDL, yang berarti bahwa contoh kelas tidak dapat disahkan sebagai argumen.Namun, struktur data dari berbagai jenis dan kompleksitas sewenang-wenang dapat disahkan sebagai argumen.CORBA IDL.


Sebuah antarmuka CORBA IDL menentukan nama dan satu set metode yang
klien dapat meminta. Sebagai contoh awal, Gambar 8.2 menunjukkan dua antarmuka bernama Shape (Baris 3) dan ShapeList (baris 5), yang IDL versi dari interface didefinisikan dalam Gambar 16. Ini didahului oleh definisi dari dua struct, yang digunakan sebagai jenis parameter dalam mendefinisikan metode. Perhatikan khususnya bahwa GraphicalObjectis didefinisikan sebagai struct,sedangkan itu kelas dalam contoh Java RMI. Sebuah komponen yang jenis structhas satu set bidang yang mengandung nilai-nilai dari berbagai jenis, seperti variabel instance dari objek,tetapi tidak memiliki metode.
Secara lebih rinci, CORBA IDL menyediakan fasilitas untuk mendefinisikan modul,
antarmuka, jenis, atribut dan metode tanda tangan. Wecan melihat contoh semua
di atas, selain dari modul, di Angka 5,8 dan 8,2. CORBA IDL memiliki leksikal yang sama aturan sebagai C ++ namun memiliki kata kunci tambahan untuk mendukung distribusi, misalnya, antarmuka,apapun, atribut, di, luar, InOut, readonlyand menimbulkan. Hal ini juga memungkinkan standar C ++ Fasilitas preprocessing. Lihat, misalnya, typedeffor Allin Gambar
struct Rectangle {1
lebar panjang;
tinggi panjang;
x panjang;
y panjang;
};
struct GraphicalObject {2
Jenis string;
melampirkan persegi panjang;
boolean isFilled;
};
antarmuka Shape {3
getVersion panjang ();
GraphicalObject getAllState (); // Mengembalikan keadaan GraphicalObject
};
typedef urutan <Shape, 100> Semua; 4
antarmuka ShapeList {5
pengecualian FullException {}; 6
Bentuk newShape (di GraphicalObject g) menimbulkan (FullException); 7
Semua allShapes (); // Mengembalikan urutan referensi objek remote 8
getVersion panjang ();
};
Tata IDL adalah bagian dari ANSI C ++ dengan konstruksi tambahan untuk
Metode dukungan tanda tangan. Kami berikan di sini hanya gambaran singkat dari IDL. A berguna contoh gambaran dan banyak diberikan di Baker [1997] dan Henning dan Vinoski Spesifikasi lengkap adalah availableon situs OMG web [OMG 2002a].
modul IDL: Modul membangun memungkinkan antarmuka dan jenis definisi lain IDL ke
dikelompokkan dalam unit logis. Sebuah moduledefines lingkup penamaan, yang mencegah nama didefinisikan dalam sebuah modul dari bentrok dengan nama didefinisikan di luar itu. Sebagai contoh,definisi antarmuka Shapeand ShapeListcould milik modul yang disebut Whiteboard, seperti yang ditunjukkan pada Gambar 8.3.
IDL antarmuka: Sebagaimana telah kita lihat, antarmuka IDL menjelaskan metode yang
tersedia di objek CORBA yang menerapkan antarmuka yang. Klien dari objek CORBA
dapat dikembangkan hanya dari pengetahuan tentang antarmuka IDL nya. Dari studi kami contoh, pembaca akan melihat bahwa antarmuka mendefinisikan seperangkat operasi dan atribut dan umumnya tergantung pada satu set jenis didefinisikan dengan itu. Sebagai contoh, PersonListinterface pada Gambar 5.2 mendefinisikan atribut dan tiga metode anddepends pada jenis Person.
Metode IDL: Bentuk umum dari metode tanda tangan adalah:
[Oneway] <return_type> <method_name> (paramater1, ..., parameterL)
[Kenaikan gaji (except1, ..., exceptN)] [konteks (name1, ..., nameM)];
Gambar 8.3 IDL modul Whiteboard
modul Whiteboard {
struct Rectangle {
...};
struct GraphicalObject {
...};
antarmuka Shape {
...};
typedef urutan <Shape, 100> Semua;
antarmuka ShapeList {
...};
};
dimana ekspresi dalam kurung adalah opsional. Untuk contoh metode
signature yang berisi hanya bagian yang diperlukan, pertimbangkan:
membatalkan getPerson (nama string, keluar Orang p);Parameter diberi label seperti dalam, outor InOut, dimana nilai dari suatu inparameter adalah lulus dari klien ke objek CORBA dipanggil dan nilai sebuah outparameter dilewatkan kembali dari objek CORBA yang dipanggil ke klien. Parameter dicap sebagai inoutare jarang digunakan, tetapi mereka menunjukkan bahwa nilai parameter dapat dilewatkan di kedua
arah. Jenis kembali dapat ditetapkan sebagai voidif tidak ada nilai yang harus dikembalikan. Angka 5.8 mengilustrasikan contoh sederhana dari penggunaan kata kunci tersebut.

Pada Gambar 8.2, garis 7, yang parameter newShapeis sebuah inparameter untuk menunjukkan bahwa argumen harus lulus dari client ke server dalam pesan permintaan. Nilai kembali memberikan keluar tambahan parameter - dapat diindikasikan sebagai voidif ada outparameter.Parameter mungkin salah satu dari tipe primitif, seperti longor boolean, atau salah satu jenis dibangun, seperti structor array (informasi lebih lanjut tentang IDL primitif dan jenis dibangun dapat ditemukan di bawah). contoh kita menunjukkan definisi dari dua garis structsin 1 dan 2. Urutan dan array didefinisikan dalam typedef, seperti yang ditunjukkan pada baris 4, yang menunjukkan urutan elemen tipe Bentuk panjang 100. Semantik parameter passing adalah sebagai berikut:
Melewati objek CORBA: Apa parameter yang tipe ditentukan oleh nama sebuah
IDL antarmuka, seperti nilai kembali Shapein baris 7, adalah referensi ke CORBA sebuah objek dan nilai referensi objek remote dilewatkan.
Melewati CORBA primitif dan dibangun jenis: Argumen primitif dan
jenis dibangun disalin dan diteruskan oleh nilai. Pada saat kedatangan, nilai baru dibuat
dalam proses penerima. Misalnya, struct GraphicalObjectpassed sebagai
Argumen (sejalan 7) menghasilkan salinan baru ini structat server. Kedua bentuk parameter passing digabungkan dalam metode allShapes (sejalan 8),
yang kembali jenis adalah array dari tipe bentuk-yaitu, sebuah array dari objek remote
referensi. Nilai kembali adalah salinan dari array di mana setiap elemen adalah
referensi objek remote.Semantik Doa: Remote doa di CORBA memiliki semantik di-paling-oncecall sebagai default. Namun, IDL dapat menentukan bahwa pemanggilan metode tertentu memiliki maybesemantics dengan menggunakan onewaykeyword tersebut. klien tidak memblokir oneway permintaan, yang dapat digunakan hanya untuk metode yang tidak mengembalikan hasil. Untuk contoh dari onewayrequest, lihat contoh di callback pada akhir Bagian 8.3.5.
Pengecualian dalam CORBA IDL: CORBA IDL memungkinkan pengecualian untuk didefinisikan dalam interface dan dilemparkan oleh metode mereka. The raisesexpression opsional menunjukkan user-defined pengecualian yang dapat dinaikkan untuk mengakhiri eksekusi metode ini. Pertimbangkan Berikut contoh dari Gambar 8.2:
pengecualian FullException {};
Bentuk newShape (di GraphicalObject g) menimbulkan (FullException);
Metode newShapespecifies dengan raisesexpression bahwa mungkin meningkatkan pengecualian disebut FullException, yang didefinisikan dalam ShapeListinterface. Dalam contoh kita,pengecualian tidak mengandung variabel. Namun, pengecualian dapat didefinisikan mengandung variabel, misalnya: pengecualian FullException {GraphicalObject g}; Ketika pengecualian yang berisi variabel dinaikkan, server dapat menggunakan variabel untuk kembali informasi kepada klien tentang konteks pengecualian.



CORBA juga dapat menghasilkan pengecualian sistem yang berkaitan dengan masalah dengan server(Seperti mereka terlalu sibuk atau tidak dapat mengaktifkan benda), masalah dengan komunikasi dan client-side masalah. program klien harus menangani didefinisikan pengguna dan sistem pengecualian. The contextexpression opsional digunakan untuk memasok pemetaan dari nama string untuk nilai string. Lihat Baker [1997] untuk penjelasan konteks.
Jenis IDL: IDL mendukung 15 jenis primitif, yang meliputi pendek (16-bit), panjang (32-bit),unsigned short, unsigned long, float (32-bit), double (64-bit), char, boolean (TRUE,
SALAH), oktet (8-bit) dan setiap (yang dapat mewakili semua jenis primitif atau dibangun).Konstanta sebagian besar tipe primitif dan string konstan dapat dinyatakan menggunakan constkeyword. IDL menyediakan tipe khusus yang disebut Object, yang nilainya jauh referensi objek. Jika parameter atau hasil adalah tipe Object, maka sesuai
Argumen bisa merujuk ke objek CORBA.jenis dibangun IDL ini, yang semuanya lewat nilai dalam argumen dan hasil,dijelaskan pada Gambar 8.4. Semua array atau urutan digunakan sebagai argumen harus didefinisikan intypedefs. Tak satu pun dari tipe data primitif atau dibangun dapat berisi referensi.
CORBA juga mendukung lewat benda non-CORBA oleh nilai [OMG 2002c].
Obyek non-CORBA adalah objek-seperti dalam arti bahwa mereka memiliki kedua atribut dan metode. Namun, mereka adalah objek murni lokal dalam operasi mereka tidak bisa secara remote. Fasilitas pass-by-value menyediakan kemampuan untuk melewati salinan dari objek non-CORBA antara klien dan server.
Hal ini dicapai oleh selain IDL jenis yang disebut valuetypefor mewakili
benda non-CORBA. Sebuah valuetypeis sebuah structwith metode tambahan tanda tangan (seperti orang-orang dari sebuah antarmuka), dan valuetypearguments dan hasil yang disahkan oleh nilai. Itu adalah,negara akan diteruskan ke situs remote dan digunakan untuk menghasilkan objek baru di tempat tujuan.
Metode objek baru ini dapat dipanggil secara lokal, menyebabkan negara untuk
menyimpang dari keadaan objek asli. Melewati pelaksanaan metode Gambar 8.4 IDL dibangun jenis Jenis Contoh Gunakan Urutan typedef urutan <Shape, 100> Semua; typedef urut <Shape> Semua;urutan dibatasi dan tidak dibatasi of Shapes Mendefinisikan tipe untuk variabel-panjang urutan elemen dari IDL tertentu mengetik. Sebuah batas atas panjang mungkin ditentukan.
String nama string;
typedef tali <8> SmallString;urutan terbatas dan dibatasi karakter Mendefinisikan urutan karakter,diakhiri dengan karakter null. Sebuah atas terikat pada panjang mungkin
ditentukan.
Array typedef oktet uniqueID [12];
typedef GraphicalObject GO [10] [8];
Mendefinisikan jenis untuk multi-dimensi tetap-panjang urutan elemen dari ditentukan jenis IDL.record struct GraphicalObject {Jenis string;melampirkan persegi panjang; boolean isFilled;

};
Mendefinisikan tipe untuk catatan yang berisi kelompok entitas terkait.
enumerasi enum Rand
(Exp, Nomor, Nama);
Tipe enumerasi di IDL peta tipe
nama ke sebuah set kecil nilai integer.
serikat serikat Exp switch (Rand) {
kasus Exp: string suara;
Kasus Nomor: panjang n;
Kasus Nama: string s;
};
IDL discriminatedunion memungkinkan seseorangdari himpunan jenis akan disahkan sebagai argumen. header adalah parameter oleh enum, yang menentukan yang anggota sedang digunakan.
Tidak begitu mudah, karena klien dan server dapat menggunakan bahasa yang berbeda.
Namun, jika klien dan server keduanya dilaksanakan di Jawa, kode dapat download. Untuk implementasi umum di C ++, kode yang diperlukan akan perlu hadir di kedua klien dan server.Fasilitas ini berguna ketika beneficialto menempatkan salinan suatu objek di klien Proses untuk memungkinkannya untuk menerima doa lokal. Namun, itu tidak membuat kita lebih dekat setiap untuk melewati objek CORBA oleh nilai.Atribut: interface IDL dapat memiliki atribut serta metode. Atribut seperti bidang public class di Jawa. Atribut dapat didefinisikan sebagai readonlywhere sesuai. Itu atribut pribadi ke obyek CORBA, tetapi untuk setiap atribut menyatakan, sepasang metode accessor dihasilkan secara otomatis oleh compiler IDL: satu untuk mengambil nilai atribut dan yang lain untuk mengaturnya. Untuk readonlyattributes, hanya getter
Metode disediakan. Sebagai contoh, PersonListinterface didefinisikan pada Gambar 5.2 meliputi
definisi berikut atribut: dibaca atribut tali listname;Warisan: antarmuka IDL dapat diperpanjang melalui warisan antarmuka, sebagaimana didefinisikan dalam Bagian 8.2 di atas. Misalnya, jika antarmuka Bextends antarmuka A, ini berarti bahwa hal itu mungkin menambahkan baru jenis, konstanta, pengecualian, metode dan atribut untuk orang-orang dari A.



Diperpanjang antarmuka dapat mendefinisikan jenis, konstanta dan pengecualian tetapi tidak diperbolehkan untuk mendefinisikan kembali metode. Sebuah nilai tipe diperpanjang berlaku sebagai nilai parameter atau hasil dari Jenis orang tua. Misalnya, jenis bis berlaku sebagai nilai parameter atau hasil dari Jenis A. Selain itu, sebuah antarmuka IDL dapat memperpanjang lebih dari satu antarmuka. Sebagai contoh, interfaceZhere meluas baik Band C:
antarmuka A {};
antarmuka B: A {};
antarmuka C {};
antarmuka Z: B, C {};
Ini berarti bahwa Zhas semua komponen dari kedua B dan C (selain dari yang itu mengubah), serta orang-orang mendefinisikan sebagai ekstensi.
Ketika sebuah antarmuka seperti Zextends lebih dari satu antarmuka, ada kemungkinan
bahwa mungkin mewarisi jenis, konstan atau pengecualian dengan nama yang sama dari dua yang berbeda interface. Misalnya, bahwa kedua Band Cdefine jenis yang disebut Q; penggunaan Q di Zinterface akan ambigu kecuali nama scoped seperti B :: Qor C :: Qis diberikan.IDL tidak mengizinkan sebuah antarmuka untuk mewarisi metode atau atribut dengan nama-nama umum dari dua antarmuka yang berbeda. Semua antarmuka IDL mewarisi dari jenis Object, yang menyiratkan bahwa semua IDL interface yang kompatibel dengan tipe Object yang meliputi objek remote referensi. Hal ini memungkinkan untuk mendefinisikan operasi IDL yang dapat mengambil sebagai argumen atau kembali sebagai hasilnya referensi objek remote dari jenis apa pun. The bindand tekad operasi di layanan Penamaan.
Jenis pengidentifikasi IDL: Seperti yang akan kita lihat pada bagian 8.3.2, jenis pengenal yang dihasilkan oleh IDL compiler untuk setiap jenis di sebuah antarmuka IDL. Misalnya, jenis IDL untuk interfaceShape (Gambar 8.3) mungkin:
IDL: Whiteboard / Shape: 1.0
Contoh ini menunjukkan bahwa nama jenis IDL memiliki tiga bagian - awalan IDL, nama jenis dan nomor versi. Sejak pengidentifikasi antarmuka digunakan sebagai kunci untuk mengakses antarmuka definisi dalam repositori antarmuka (dijelaskan dalam Bagian 8.3.2), programmer harus memastikan bahwa mereka memberikan pemetaan yang unik untuk antarmuka sendiri. Programmer dapat menggunakan IDL awalan pragma untuk awalan string tambahan untuk nama jenis dalam rangka untuk membedakan jenis mereka sendiri dari orang lain.
IDL pragma arahan: ini memungkinkan tambahan, properti non-IDL yang akan ditentukan untuk komponen dalam sebuah antarmuka IDL (lihat Henning dan Vinoski. properti ini termasuk, misalnya, menetapkan bahwa antarmuka akan digunakan hanya secara lokal, atau memasok nilai ID antarmuka repositori. Setiap pragma diperkenalkan oleh #pragmaand menentukan jenisnya, misalnya:Versi #pragma Whiteboard 2.3 pemetaan bahasa CORBA.



Pemetaan dari jenis di IDL untuk jenis dalam diberikan
bahasa pemrograman cukup mudah. Misalnya, di Jawa tipe primitif
di IDL dipetakan ke tipe primitif yang sesuai dalam bahasa itu. Struct, enum
andunionsare dipetakan ke kelas Java; urutan dan array dalam IDL dipetakan ke
array di Jawa. Pengecualian IDL dipetakan ke kelas Java yang menyediakan contoh
variabel untuk bidang pengecualian dan konstruktor. Pemetaan di C ++ adalah sama langsung.
Namun, beberapa kesulitan muncul dengan pemetaan semantik parameter-lewat
dari IDL ke orang-orang Jawa. Secara khusus, IDL memungkinkan metode untuk kembali beberapa terpisah nilai-nilai melalui parameter output, sedangkan Java hanya dapat memiliki hasil tunggal.


Pemegang kelas disediakan untuk mengatasi perbedaan ini, tetapi hal ini membutuhkan programmer untuk memanfaatkan mereka, yang sama sekali tidak mudah. Misalnya, metode ini getPersonin Gambar 5.2 didefinisikan dalam IDL sebagai berikut:
membatalkan getPerson (nama string, keluar Orang p);Di Jawa, metode setara akan didefinisikan sebagai: membatalkan getPerson (String nama, PersonHolder p);dan klien harus memberikan contoh PersonHolder sebagai argumen nya doa.



Kelas Pemegang memiliki instance variable yang memegang nilai argumen untuk klien untuk mengakses dengan RMI ketika doa mengembalikan. Ini juga memiliki metode untuk mengirimkan argumen antara server dan client.Meskipun C ++ implementasi CORBA dapat menangani dan parameter inout secara alamiah, C ++ programmer menderita yang berbeda dari masalah dengan parameter, berhubungan dengan manajemen penyimpanan. Kesulitan-kesulitan ini muncul ketika objek referensi dan entitas variabel-panjang seperti string atau urutan dikirimkan sebagai argumen.
Misalnya, di Orbix [Baker 1997] ORB terus jumlah referensi untuk jarak jauh objek dan proxy dan melepaskan mereka ketika mereka tidak lagi diperlukan. Ini menyediakan programmer dengan metode untuk melepaskan atau duplikasi mereka. Setiap kali server
Metode telah selesai mengeksekusi, yang outarguments dan hasil dilepaskan dan programmer harus menduplikasi mereka jika mereka masih akan dibutuhkan. Sebagai contoh, C ++ hamba menerapkan ShapeListinterface akan perlu menduplikasi referensi dikembalikan oleh metode allShapes. referensi objek diteruskan ke klien harus dilepaskan ketika mereka tidak lagi diperlukan. Aturan yang sama berlaku untuk parameter variabel-panjang.Secara umum, programmer menggunakan IDL tidak hanya harus belajar notasi IDL itu sendiri tetapi juga memiliki pemahaman tentang bagaimana parameter yang dipetakan ke parameter dari bahasa implementasi.
Asynchronous RMI

CORBA mendukung bentuk asynchronous RMI yang memungkinkan klien untuk membuat permintaan doa non blocking pada objek CORBA [OMG 2004e]. Ini dimaksudkan untuk diterapkan di klien. Oleh karena itu server umumnya tidak menyadari apakah itu dipanggil serentak atau asynchronous. (Satu pengecualian adalah Layanan transaksi, yang tidak perlu menyadari perbedaan.)Asynchronous RMI menambahkan dua varian baru untuk semantik doa SIMLR:
Callback, di mana klien menggunakan parameter tambahan untuk lulus referensi untuk callback dengan setiap permintaan sehingga server dapat menelepon kembali dengan hasil.
Polling, di mana server mengembalikan objek jenis nilai yang dapat digunakan untuk polling atau menunggu balasan.










Gambar 8.5 Komponen utama dari arsitektur CORBA





Ada gambar Arsitektur asynchronous RMI memungkinkan agen perantara untuk digunakan untuk memastikan bahwa permintaan tersebut dilakukan dan, jika perlu, untuk menyimpan jawabannya. Oleh karena itu sesuai untuk digunakan dalam lingkungan di mana klien dapat menjadi sementara terputus - seperti, misalnya, klien menggunakan laptop di kereta api.


8.3.2 ARSITEKTUR CORBA


Arsitektur CORBA dirancang tosupport peran permintaan objek broker yang memungkinkan klien untuk memanggil metode dalam objek remote, di mana kedua klien dan server dapat diimplementasikan dalam berbagai bahasa pemrograman.Komponen utama dari arsitektur CORBA illustratedin Gambar 8.5.
Angka ini harus dibandingkan dengan Gambar 5.15, dalam hal ini akan dicatat bahwa arsitektur CORBA berisi tiga komponen tambahan: adaptor objek,pelaksanaan repositori dan repositori antarmuka.CORBA menyediakan untuk kedua doa statis dan dinamis. doa statis digunakan ketika remote interface dari objek CORB diketahui pada waktu kompilasi,memungkinkan bertopik klien dan kerangka server yang akan digunakan. Jika remote interface tidak diketahui pada waktu kompilasi, doa dinamis harus digunakan. Kebanyakan programmer lebih suka menggunakan doa statis karena memberikan model pemrograman yang lebih alami.

Kita sekarang membahas komponen arsitektur, meninggalkan mereka yang peduli dengan doa dinamis sampai terakhir.
ORB inti

Peran inti ORB mencakup semua fungsi dari modul komunikasi dari Gambar 5.15. Selain itu, inti ORB menyediakan sebuah antarmuka yang meliputi:
Operasi memungkinkan untuk memulai dan berhenti
Operasi untuk mengkonversi antara referensi objek remote dan string.
Operasi untuk menyediakan daftar argumen untuk permintaan menggunakan dynamicinvocation.obyek adaptor.
Peran anobject adapteris untuk menjembatani kesenjangan antara CORBA objek dengan IDL antarmuka dan antarmuka bahasa pemrograman.
Kelas hamba yang sesuai. Peran ini juga termasuk yang dari referensi terpencil dan modul operator pada Gambar 5.15.


Adaptor objek memiliki tugas sebagai berikut :

Ini menciptakan referensi objek remote untuk objek CORBA (lihat Bagian 8.3.3).
Ini kiriman setiap RMI melalui kerangka untuk hamba yang sesuai.
Ini mengaktifkan dan menonaktifkan pegawai.
Adaptor objek memberikan setiap objek CORBA nama objek yang unik, yang merupakan bagian dari referensi objek remote-nya. Nama yang sama digunakan setiap kali sebuah objek diaktifkan. Itu nama objek dapat ditentukan oleh program aplikasi atau dihasilkan oleh obyek adaptor.
Setiap objek CORBA terdaftar dengan adaptor objeknya, yang membuat remote objek tabel yang memetakan nama-nama CORBA objek untuk pegawai mereka.
Setiap adapter objek juga memiliki nama sendiri, yang merupakan bagian dari objek remote
referensi dari semua objek CORBA itu berhasil. Nama ini mungkin baik ditentukan
dengan program aplikasi atau dihasilkan secara otomatis.Objek adapter portabel.



The CORBA standar untuk adapter objek disebut
Portabel Object Adapter (POA). Hal ini disebut portable karena memungkinkan aplikasi dan pegawai yang akan dijalankan pada ORB yang dihasilkan oleh pengembang yang berbeda [Vinoski 1998]. Ini adalah dicapai melalui standarisasi kelas kerangka dan interaksi antara POA dan pegawai.POA mendukung objek CORBA dengan dua macam yang berbeda dari masa hidup:

Mereka yang tahan dibatasi untuk yang dari proses di mana pelayan mereka
adalah yang dipakai.
Mereka yang tahan dapat span instantiations pegawai di beberapa proses.
Mantan memiliki referensi objek sementara dan yang terakhir memiliki objek terus-menerus referensi (lihat Bagian 8.3.3).
POA memungkinkan objek CORBA harus dipakai secara transparan; dan di samping itu memisahkan penciptaan CORBA objek dari penciptaan th, servantsthat menerapkan benda-benda. Server aplikasi seperti database dengan sejumlah besar objek CORBA dapat membuat pegawai pada permintaan, hanya saat obyek diakses. Di hal ini, mereka dapat menggunakan kunci database untuk nama objek, atau mereka mungkin menggunakan satu hamba untuk mendukung semua benda-benda ini.
Selain itu, adalah mungkin untuk menentukan kebijakan untuk POA, misalnya, apakah harus memberikan sebuah thread terpisah untuk setiap doa, apakah referensi objek harus terus-menerus atau sementara dan apakah harus ada hamba terpisah untuk setiap CORBA objek. default adalah bahwa seorang hamba tunggal dapat mewakili semua CORBA yang
objek untuk POA nya.
Perhatikan bahwa implementasi CORBA menyediakan interface untuk fungsi
POA dan inti ORB melalui pseudo-benda, diberi nama ini karena mereka
tidak dapat digunakan seperti benda CORBA biasa; misalnya, mereka tidak bisa lulus sebagai argumen di SIMLR. Mereka, meskipun, memiliki antarmuka IDL dan diimplementasikan sebagai perpustakaan. POA pseudo-objek termasuk, misalnya, salah satu metode untuk mengaktifkan POAmanagerand metode lain, servant_to_reference, untuk mendaftar CORBA sebuah obyek; ORB pseudo-objek termasuk metode init, yang harus dipanggil untuk menginisialisasi ORB, metode resolve_initial_references, yang digunakan untuk mencari layanan seperti layanan Penamaan dan akar POA, dan metode lain yang memungkinkan konversi antara referensi objek remote dan string.



Kerangka
kelas Skeleton dihasilkan dalam bahasa server oleh IDL
Seperti dijelaskan dalam Bagian 5.4.2, metode remote doa yang dikirim melalui kerangka yang tepat untuk seorang hamba tertentu, dan kerangka unmarshals yang argumen dalam pesan permintaan dan marsekal pengecualian dan hasil dalam pesan balasan.
Bertopik klien / proxy ini dalam bahasa klien. Kelas proxy (untuk bahasa object-oriented) atau satu set prosedur rintisan (untuk bahasa prosedural) yang dihasilkan dari antarmuka IDL oleh compiler IDL untuk bahasa klien. Seperti sebelumnya, klien bertopik / proxy marshal argumen dalam permintaan doa dan pengecualian unmarshal dan hasil dalam balasan.
Implementasi repositori.
Sebuah repositori implementasi bertanggung jawab untuk mengaktifkan
server terdaftar pada permintaan dan untuk mencari server yang sedang berjalan. Itu objek nama adapter digunakan untuk merujuk ke server saat mendaftar dan mengaktifkan mereka.
Repositori pelaksanaan menyimpan pemetaan dari nama-nama adapter objek untuk nama path dari file yang berisi implementasi objek. implementasi objek dan nama objek adapter umumnya terdaftar repositori pelaksanaan ketika program server yang diinstal.


Ketika implementasi objek diaktifkan di server, nama host dan port jumlah server ditambahkan ke pemetaan:entri implementasi repositori:objek nama adaptor pathname dari obyek pelaksanaan hostname dan nomor port server Tidak semua benda CORBA harus diaktifkan pada permintaan. Beberapa objek, misalnya objek callback dibuat oleh klien, berjalan sekali dan tidak ada lagi ketika mereka tidak lagi dibutuhkan. Mereka tidak menggunakan repositori implementasi.
Repositori pelaksanaan umumnya memungkinkan informasi tambahan untuk disimpan tentang setiap server, seperti informasi kontrol akses untuk yang diperbolehkan untuk mengaktifkannya atau untuk memanggil operasinya. Hal ini dimungkinkan untuk mereplikasi informasi dalam pelaksanaan repositori untuk menyediakan ketersediaan atau toleransi kesalahan.

Antarmuka repositori
Peran repositori antarmuka adalah untuk memberikan informasi tentang terdaftar antarmuka IDL untuk klien dan server yang memerlukannya. Untuk antarmuka jenis tertentu dapat menyediakan nama-nama metode dan, untuk setiap metode, nama dan jenis argumen dan pengecualian. Dengan demikian, repositori antarmuka menambahkan fasilitas untuk refleksi untuk CORBA. Misalkan sebuah program klien menerima referensi remote ke
objek CORBA baru. Jika klien tidak memiliki proxy untuk itu, dapat meminta repositori antarmuka tentang metode objek dan jenis parameter masing-masing membutuhkan. Ketika sebuah compiler IDL memproses sebuah antarmuka, itu menetapkan jenis pada setiap IDL ketik itu pertemuan.



Untuk setiap antarmuka yang terdaftar dengan itu, repositori antarmuka menyediakan pemetaan antara jenis identifier antarmuka itu dan antarmuka itu sendiri.
Dengan demikian, jenis identifier dari sebuah antarmuka kadang-kadang disebut repositori IDbecause itu dapat digunakan sebagai kunci untuk antarmuka IDL terdaftar di repositori antarmuka.Setiap CORBA referensi objek remote termasuk slot yang berisi jenis identifier antarmuka, memungkinkan klien yang terus menanyakan jenisnya antarmuka
gudang. Aplikasi yang menggunakan static (biasa) doa dengan proxy client
dan IDL kerangka tidak memerlukan repositori antarmuka. Tidak semua ORB menyediakan antarmuka repositori.

Doa antarmuka dinamis
Seperti yang disarankan dalam Bagian 5.5, dalam beberapa aplikasi itu mungkin diperlukan untuk membangun sebuah program klien tanpa mengetahui semua kelas proxy itu perlu di masa depan. Sebagai contoh, sebuah browser objek mungkin perlu untuk menampilkan informasi tentang semua CORBA objek yang tersedia dalam berbagai server dalam didistribusikan sistem.

Hal ini tidak layak untuk program tersebut untuk memasukkan proxy untuk semua benda-benda ini,terutama sebagai objek baru dapat ditambahkan ke sistem seiring berjalannya waktu. CORBA tidak memungkinkan kelas untuk proxy untuk download atruntime, seperti di Jawa RMI. dinamika
antarmuka doa adalah alternatif CORBA ini.Antarmuka doa dinamis memungkinkan clientsto membuat doa dinamis pada benda remoteCORBA. Hal ini digunakan ketika tidak praktis untuk mempekerjakan proxy.

Klien dapat memperoleh dari repositori antarmuka informasi yang diperlukan tentang metode tersedia untuk objek CORBA diberikan. Klien dapat menggunakan ini informationto membangun sebuah doa dengan argumen yang sesuai dan mengirimkannya ke server.

kerangka dinamis.
Sekali lagi, seperti yang dijelaskan dalam Bagian 5.5, mungkin perlu untuk menambah server objek CORBA yang antarmuka tidak diketahui ketika server disusun.Jika server menggunakan kerangka dinamis, maka dapat menerima pemanggilan pada interface dari CORBA objek yang tidak memiliki kerangka. Ketika kerangka dinamis menerima doa, itu memeriksa isi permintaan untuk menemukan objek target, metode akan dipanggil dan argumen. Ini kemudian memanggil target.

Kode warisan
Istilah warisan coderefers untuk kode yang ada yang tidak dirancang dengan
objek terdistribusi dalam pikiran. Sepotong kode warisan dapat dibuat menjadi objek CORBA dengan mendefinisikan sebuah antarmuka IDL untuk itu dan memberikan implementasi yang tepat objek adaptor dan kerangka yang diperlukan.




8.3.3 CORBA REFERENSI OBJEK REMOTE



CORBA menentukan format untuk referensi objek remote yang cocok untuk digunakan apakah atau tidak objek remote akan diaktifkan oleh repositori implementasi. Referensi menggunakan format ini disebut referensi objek interoperable (iors).

Pengikut Angka ini didasarkan pada Henning [1998], yang berisi account yang lebih rinci dari iors:

Format IOR
IDL jenis antarmuka ID Protocol dan rincian alamat Object kunci
repositori antarmuka
identifier atau jenis
host domain IIOP
nama
nomor port nama nama adaptor objek
Melangkah melalui berbagai bidang:

Bidang pertama dari sebuah IOR menentukan jenis identifier dari antarmuka IDL dari CORBA objek. Perhatikan bahwa jika ORB memiliki repositori antarmuka, nama jenis ini juga identifier antarmuka repositori dari antarmuka IDL, yang memungkinkan definisi IDL untuk antarmuka yang akan diambil pada saat runtime.
Bidang kedua menentukan protokol transport dan rincian yang diperlukan oleh protokol transport tertentu untuk mengidentifikasi server. Secara khusus, protokol Internet Inter-ORB (IIOP) menggunakan TCP, di mana alamat server terdiri dari sebuah host
nama domain dan nomor port [OMG 2004a].
Bidang ketiga digunakan oleh ORB untuk mengidentifikasi objek CORBA. Ini terdiri dari nama dari adaptor objek di server dan nama objek dari objek CORBA ditentukan oleh adaptor objek.Transient IORsfor CORBA objek terakhir hanya selama proses yang host mereka
benda, whereaspersistent IORslast antara aktivasi dari objek CORBA.


SEBUAH transient IOR berisi rincian alamat server hosting objek CORBA,sedangkan IOR gigih berisi rincian alamat repositori pelaksanaan dengan yang terdaftar. Dalam kedua kasus, ORB klien mengirimkan pesan permintaan ke server yang rinciannya alamat yang diberikan dalam IOR. Berikut adalah bagaimana IOR digunakan untuk
menemukan hamba yang mewakili objek CORBA dalam dua kasus:
Iors transien: Server ORB inti menerima pesan permintaan yang berisi
objek nama adaptor dan nama objek dari target. Ia menggunakan nama objek adaptor untuk menemukan adaptor objek, yang menggunakan nama objek untuk mencari hamba.
Iors Persistent:

Sebuah repositori pelaksanaan menerima permintaan tersebut. Itu ekstrak keberatan nama adaptor dari IOR dalam permintaan. Asalkan adaptor objek namanya dalam tabel nya, ia mencoba jika perlu untuk mengaktifkan objek CORBA di host alamat yang ditentukan dalam tabel nya. Setelah objek CORBA telah diaktifkan,implementasi repositori mengembalikan rincian alamat kepada ORB klien, yang menggunakan mereka sebagai tujuan untuk pesan permintaan RMI, yang meliputi adaptor objek nama dan nama objek. Ini memungkinkan server inti ORB untuk mencari objek adaptor, yang menggunakan nama objek untuk mencari hamba, seperti sebelumnya.
Bidang kedua dari IOR dapat diulang sehingga untuk menentukan nama domain host dan nomor port lebih dari satu tujuan, untuk memungkinkan sebuah objek atau implementasi repositori untuk direplikasi di beberapa lokasi yang berbeda.
Balasan pesan dalam protokol request-reply berisi informasi header yang memungkinkan prosedur di atas untuk iors gigih untuk dilakukan. Secara khusus, itu termasuk entri status itu dapat menunjukkan apakah permintaan tersebut harus diteruskan ke server yang berbeda, dalam hal tubuh balasan mencakup IOR yang berisi alamat server dari objek yang baru diaktifkan.


8.3.4 LAYANAN CORBA


CORBA termasuk spesifikasi untuk layanan yang mungkin diperlukan oleh objek terdistribusi.Secara khusus, layanan Penamaan merupakan tambahan penting untuk ORB apapun, seperti yang akan kita lihat di contoh pemrograman dalam Bagian 8.3.5. Indeks untuk dokumentasi pada semua layanan dapat ditemukan di OMG situs web [www.omg.org]. Banyak CORBA jasa dijelaskan dalam Orfaliet al. [1996, 1997]. Ringkasan Layanan CORBA kunci termasuk dalam Gambar 8.6. Rincian lebih lanjut dari layanan tersebut dapat ditemukan di pendamping
situs web [www.cdk5.net/corba].Gambar 8.6 CORBA Layanan
CORBA Layanan Peran Rincian lebih lanjut layanan penamaan Mendukung penamaan di CORBA, dalam nama pemetaan khususnya untuk
referensi objek remote dalam konteks penamaan yang diberikan (lihat Bab 9).
[OMG 2004b] layanan perdagangan Sedangkan layanan Penamaan memungkinkan objek yang akan terletak nama, layanan Perdagangan memungkinkan mereka untuk ditemukan dengan atribut; yaitu, itu adalah layanan direktori. yang mendasari Database mengelola pemetaan jenis layanan dan terkait atribut ke referensi objek remote.
[OMG 2000a,Henning dan Vinoski 1999]
Layanan acara Memungkinkan obyek yang menarik untuk berkomunikasi pemberitahuan ke pelanggan menggunakan metode remote CORBA biasa
doa (lihat Bab 6 untuk lebih lanjut tentang layanan acara umumnya).
[Farley 1998,OMG 2004c]
Pemberitahuan
Layanan èMemperluas layanan acara dengan kemampuan ditambahkan termasuk
kemampuan untuk menentukan filter mengungkapkan peristiwa yang menarik dan
juga untuk menentukan keandalan dan pemesanan sifat channel acara yang mendasari.
layanan keamanan Mendukung berbagai mekanisme keamanan termasuk
otentikasi, kontrol akses, komunikasi yang aman,audit dan nonrepudiation (lihat Bab 11).[Blakely tahun 1999,Baker 1997,OMG 2002b]
Transaksi
Layanan èMendukung penciptaan kedua transaksi datar dan bersarang (sebagai
didefinisikan dalam Bab 16 dan 17).[OMG 2003]
concurrency
KontrolèMenggunakan kunci untuk menerapkan kontrol konkurensi untuk akses
objek CORBA (dapat digunakan melalui layanan transaksi atau sebagai layanan independen).[OMG 2000b]
Negara terus-menerus
layanan èMenawarkan toko objek terus-menerus untuk CORBA, yang digunakan untuk menyimpan dan mengembalikan keadaan objek CORBA (implementasi yang
diambil dari gudang implementasi).[OMG 2002d]
Layanan siklus hidup èMendefinisikan konvensi untuk membuat, menghapus, menyalin dan objek bergerak CORBA; misalnya, bagaimana menggunakan pabrik-pabrik untuk membuat objek.


8.3.5 CORBA CLIENT DAN SERVER



Bagian ini menjelaskan langkah-langkah yang diperlukan untuk menghasilkan program client dan server yang menggunakan yang ShapeListinterfaces IDL Shapeand ditunjukkan pada Gambar 8.2. Hal ini diikuti oleh
pembahasan callback di CORBA. Kami menggunakan Java sebagai bahasa klien dan server, tapi Pendekatan ini serupa untuk otherlanguages. Compiler antarmuka idljcan diterapkan antarmuka CORBA untuk menghasilkan item berikut:

Interface Java setara - dua per antarmuka IDL. Nama Java pertama
antarmuka berakhir di Operations- antarmuka ini hanya mendefinisikan operasi di IDL Antarmuka Java kedua memiliki nama yang sama dengan antarmuka IDL dan Gambar 8.7 interface Java yang dihasilkan oleh idljfrom CORBA antarmuka ShapeList ShapeListOperations antarmuka publik { Bentuk newShape (GraphicalObject g) melempar ShapeListPackage.FullException;
Bentuk [] allShapes (); int getVersion (); }
antarmuka ShapeList publik meluas ShapeListOperations, org.omg.CORBA.Object,org.omg.CORBA.portable.IDLEntity {}
Kerangka server untuk setiap idlinterface. Nama-nama kelas kerangka berakhir di POA- misalnya, ShapeListPOA.
Kelas proxy atau bertopik klien, satu untuk setiap antarmuka IDL. Nama-nama ini Kelas berakhir di Stub- misalnya, _ShapeListStub.
Sebuah kelas Java untuk sesuai dengan masing-masing structsdefined dengan antarmuka IDL.Dalam contoh kita, kelas Rectangleand GraphicalObjectare dihasilkan. Setiap Kelas ini berisi deklarasi satu variabel contoh untuk masing-masing bidang di sesuai structand sepasang konstruktor, tapi tidak ada metode lain.
Kelas disebut pembantu dan pemegang, satu untuk masing-masing jenis didefinisikan dalam IDL Sebuah kelas pembantu berisi narrowmethod, yang digunakan untuk dilemparkan ke bawah dari referensi objek yang diberikan untuk kelas mana ia berasal, yang lebih rendah ke bawah hirarki kelas. Sebagai contoh, narrowmethod di ShapeHelpercasts ke classShape. Kelas pemegang menangani inoutarguments outand, yang tidak dapat dipetakan langsung ontoJava. Lihat Latihan 8.9 untuk contoh penggunaan pemegang.


Program Server.
Program server harus berisi implementasi dari satu atau lebih antarmuka IDL. Untuk server yang ditulis dalam bahasa berorientasi objek seperti Java atau C ++, antarmuka ini diimplementasikan sebagai kelas hamba. CORBA objek adalah contoh dari Kelas hamba.
Ketika server menciptakan sebuah instance dari kelas hamba, harus mendaftar dengan POA, yang membuat contoh menjadi objek CORBA dan memberikan objek remote referensi. Kecuali hal ini dilakukan, objek CORBA tidak akan dapat menerima terpencil doa. Pembaca yang mempelajari Bab 5 hati-hati mungkin menyadari bahwa mendaftarkan objek dengan POA yang menyebabkan untuk disimpan di setara CORBA remote meja objek.
Dalam contoh kita, server berisi implementationsof antarmuka Shapeand ShapeListin bentuk dua kelas hamba, bersama-sama dengan kelas server yang berisi aninitializationsection (lihat Bagian 5.4.2) di mainmethod nya:

Kelas hamba: Setiap kelas hamba memperpanjang kelas kerangka yang sesuai dan mengimplementasikan metode antarmuka IDL menggunakan metode tanda tangan didefinisikan dalam Gambar 8.8



ShapeListServantclass dari program server Java untuk CORBA antarmuka ShapeList impor org.omg.CORBA *.;
impor org.omg.PortableServer.POA;
kelas ShapeListServant meluas ShapeListPOA {
POA theRootpoa swasta;
Bentuk swasta thelist [];
Versi int swasta;
private static int n = 0;
ShapeListServant publik (POA rootpoa) {
theRootpoa = rootpoa;
// Inisialisasi variabel instan lainnya
}
Bentuk umum newShape (GraphicalObject g) melempar ShapeListPackage.FullException {1
Versi ++;
Bentuk s = null;
ShapeServant shapeRef = baru ShapeServant (g, versi);
try {
org.omg.CORBA.Object ref = theRootpoa.servant_to_reference (shapeRef); 2
s = ShapeHelper.narrow (ref);
} Catch (Exception e) {}
if (n> = 100) membuang ShapeListPackage.FullException baru ();
thelist [n ++] = s;
kembali s;
}
Bentuk umum [] allShapes () {...}
public int getVersion () {...}
}
antarmuka Java setara. Kelas hamba yang mengimplementasikan ShapeList antarmuka bernama ShapeListServant, meskipun nama lain bisa saja terpilih. garis yang ditunjukkan pada Gambar 8.8.Consider metode newShapein jalur 1,yang merupakan metode pabrik karena menciptakan Shapeobjects. Untuk membuat Shapeobject objek CORBA, itu terdaftar dengan POA dengan cara servant_to_reference nya metode, seperti yang ditunjukkan pada baris 2, yang menggunakan referensi ke POA akar yang disahkan pada melalui konstruktor ketika hamba itu dibuat. versi lengkap antarmuka IDL dan kelas klien dan server dalam contoh ini tersedia di www.cdk5.net/corba.server: Themainmethod di ShapeListServer kelas server ditunjukkan pada Gambar 8.9.



Ini pertama menciptakan dan menginisialisasi ORB (baris 1), kemudian mendapat referensi ke akar POA dan mengaktifkan POAManager (lines2 & 3). Kemudian menciptakan sebuah instance dari ShapeListServant, yang hanya objek Java (line 4), dan dalam melakukan ini melewati pada mengacu pada POA root. Ini kemudian membuat menjadi objek CORBA dengan mendaftar dengan POA (baris 5). Setelah ini, register server dengan layanan Penamaan. Kemudian menunggu permintaan klien masuk (baris 10).Gambar 8.9 Java kelas ShapeListServer
impor org.omg.CosNaming *.;
impor org.omg.CosNaming.NamingContextPackage *.;
impor org.omg.CORBA *.;
impor org.omg.PortableServer *.;
public class ShapeListServer {
public static void main (String args []) {
mencoba{
ORB orb = ORB.init (args, null); 1
POA rootpoa = POAHelper.narrow (orb.resolve_initial_references ( "RootPOA")); 2
rootpoa.the_POAManager () mengaktifkan ().; 3
ShapeListServant SLSRef = baru ShapeListServant (rootpoa); 4
org.omg.CORBA.Object ref = rootpoa.servant_to_reference (SLSRef); 5
ShapeList SLRef = ShapeListHelper.narrow (ref);
org.omg.CORBA.Object objRef = orb.resolve_initial_references ( "nameservice");
NamingContext ncRef = NamingContextHelper.narrow (objRef); 6
NameComponent nc = newNameComponent ( "ShapeList", ""); 7
NameComponent path [] = {nc}; 8
ncRef.rebind (jalan, SLRef); 9
orb.run (); 10
} Catch (Exception e) {...}
}
}
Sebuah server menggunakan layanan Penamaan pertama mendapat konteks akar penamaan menggunakan NamingContextHelper (baris 6). Konteks penamaan mendefinisikan ruang lingkup di mana satu set nama berlaku (masing-masing nama dalam konteks harus unik). Server kemudian membuat NameComponent (line 7), dengan NameComponentbeing obyek mewakili nama di CORBA. Ini memiliki dua bagian, sebuah nameand jenis; kindfield yang murni deskriptif (lapangan digunakan oleh aplikasi dan tidak ditafsirkan oleh layanan penamaan). Nama bisa senyawa dan diwakili oleh pathto objek di grafik penamaan. Dalam contoh ini, senyawa penamaan tidak digunakan; bukan, jalan terdiri dari satu nama seperti yang didefinisikan sejalan 8. Akhirnya, server menggunakan rebind yang metode layanan penamaan (jalur 9), yang mencatat nama dan remote object Pasangan referensi dalam konteks yang tepat. Klien melakukan langkah-langkah yang sama tetapi menggunakan resolvemethod seperti yang ditunjukkan pada Gambar 8.10, baris 2.
Program klien

Program Contoh klien shownin Gambar 8.10. Ini menciptakan dan menginisialisasi sebuah ORB (baris 1), maka kontak layanan Penamaan untuk mendapatkan referensi ke terpencil ShapeListobject dengan menggunakan resolvemethod nya (baris 2). Setelah itu memanggil nya Metode allShapes (garis 3) untuk mendapatkan urutan referensi objek remote untuk semua Shapescurrently diadakan di server. Kemudian memanggil getAllStatemethod (baris 4),memberikan sebagai argumen pertama terpencil referensi obyek di urutan kembali; itu Hasil disediakan sebagai contoh dari GraphicalObjectclass.Gambar 8.10 Java clientprogram untuk CORBA antarmuka Shapeand ShapeList
impor org.omg.CosNaming *.;
impor org.omg.CosNaming.NamingContextPackage *.;
impor org.omg.CORBA *.;
public class ShapeListClient {
public static void main (String args []) {
mencoba{
ORB orb = ORB.init (args, null); 1
omg.CORBA.Object objRef =
orb.resolve_initial_references ( "nameservice");
NamingContext ncRef = NamingContextHelper.narrow (objRef);
NameComponent nc = NameComponent baru ( "ShapeList", "");
NameComponent path [] = {nc};
ShapeList shapeListRef =
ShapeListHelper.narrow (ncRef.resolve (path)); 2
Bentuk [] slist = shapeListRef.allShapes (); 3
GraphicalObject g = slist [0] .getAllState (); 4
} Catch (org.omg.CORBA.SystemException e) {...} 5
}
}
ThegetAllStatemethod tampaknya bertentangan pernyataan kami sebelumnya bahwa benda tidak bisa melewati nilai di CORBA, karena kedua klien dan server kesepakatan dalam kasus dari GraphicalObject kelas. Namun, tidak ada kontradiksi: objek CORBA mengembalikan struct, dan klien menggunakan bahasa yang berbeda mungkin melihatnya secara berbeda. Untuk Misalnya, dalam bahasa C ++ klien akan melihatnya sebagai sebuah struct. Bahkan di Jawa,kelas yang dihasilkan GraphicalObjectis lebih seperti structbecause tidak memiliki metode.
Program klien harus selalu menangkap CORBA SystemExceptions, yang melaporkan kesalahan karena distribusi (lihat baris 5). program klien juga harus menangkap pengecualian didefinisikan dalam antarmuka IDL, seperti FullExceptionthrown oleh newShapemethod.Contoh ini menggambarkan penggunaan narrowoperation itu: resolveoperation dari layanan Penamaan mengembalikan nilai bertipe Object, dan jenis ini dipersempit sesuai dengan
Jenis tertentu yang diperlukan - (ShapeList).
Callback

callback dapat diimplementasikan dalam CORBA dengan cara yang sama dengan yang dijelaskan untuk Java RMI dalam Bagian 5.5.1. Sebagai contoh, WhiteboardCallback antarmuka dapat didefinisikan sebagai berikut:
antarmuka WhiteboardCallback { oneway kekosongan callback (dalam versi int);
};
Interface ini diimplementasikan sebagai objek CORBA oleh klien, memungkinkan server untuk mengirim klien nomor versi setiap kali objek baru ditambahkan. Tapi sebelum server dapat melakukan hal ini, klien perlu menginformasikan server dari referensi objek remote-nya obyek. Untuk membuat ini mungkin, ShapeListinterface membutuhkan metode tambahan seperti asregisterand deregister, sebagai berikut: int register (di WhiteboardCallback callback);
kekosongan deregister (di int callbackId);Setelah klien memperoleh referensi ke ShapeListobject dan menciptakan sebuah instance dari WhiteboardCallback, menggunakan registermethod dari ShapeListto menginformasikan server yang itu tertarik untuk menerima callback.



Objek ShapeList di server bertanggung jawab untuk menjaga daftar klien tertarik dan memberitahukan semua dari mereka setiap kali versi Jumlah meningkat ketika objek baru ditambahkan. callbackmethod dinyatakan sebagai onewayso bahwa server dapat menggunakan panggilan asynchronous untuk menghindari keterlambatan karena memberitahukan setiap klien.







8.4 DARI OBJEK UNTUK KOMPONEN


Didistribusikan objek middleware telah banyak digunakan di berbagai aplikasi, termasuk daerah ditampilkan dalam Bab 1: keuangan dan perdagangan,kesehatan, pendidikan, transportasi dan logistik dan sebagainya. Teknik-teknik yang tergabung dalam CORBA dan platform terkait telah terbukti berhasil dalam menanggulangi banyak kunci isu yang terkait dengan pemrograman terdistribusi, terutama terkait untuk mengatasi heterogenitas dan memungkinkan portabilitas dan interoperabilitas sistem terdistribusi perangkat lunak.



Berbagai layanan yang menyertai platform seperti juga mendorong pengembangan perangkat lunak yang aman dan dapat diandalkan.Namun, sejumlah kekurangan telah beenidentified. Hal ini telah menyebabkan munculnya apa yang akan kita mendefinisikan menjadi pendekatan berbasis komponen, sebagai natural evolusi dari komputasi objek terdistribusi. Bagian ini grafik transisi ini,membahas persyaratan yang menyebabkan pendekatan berbasis komponen dan menyediakan definisi komponen sebelum memeriksa secara lebih mendalam gaya pendekatan berbasis komponen yang diterapkan dalam sistem terdistribusi. Ini diikuti dengan Bagian 8.5 yang menyajikan dua studi kasus yang kontras dari komponen teknologi, Enterprise JavaBeans dan Fractal.
Masalah dengan middleware berorientasi objek :

Seperti disebutkan di atas, komponen berbasis pendekatan muncul untuk mengatasi masalah yang diidentifikasi dengan komputasi objek terdistribusi.Masalah yang tercantum dalam Bagian 8.1 dan dibahas lebih rinci di bawah.

Dependensi implisit: Sebuah objek terdistribusi menawarkan contractto sebuah dunia luar dalam hal antarmuka (interface atau) yang menawarkan untuk lingkungan terdistribusi. Kontrak
merupakan perjanjian yang mengikat antara penyedia objek dan pengguna yang
keberatan dalam hal perilaku yang diharapkan. Hal ini sering diasumsikan bahwa interface tersebut memberikan kontrak lengkap untuk penggelaran dan penggunaan objek ini. Namun, hal ini tidak kasus. Masalah muncul dari fakta bahwa internal (encapsulated) perilaku dari objek tersembunyi. Sebagai contoh, sebuah objek dapat berkomunikasi dengan objek lain atau terkait layanan sistem terdistribusi melalui metode remote doa atau lainnya paradigma komunikasi. Jika kita melihat kembali server dan client program CORBA
ditunjukkan pada Gambar 8.9 dan Gambar 8.10, masing-masing, kita melihat bahwa server mengeluarkan callback untuk klien, tapi ini tidak jelas dari antarmuka yang didefinisikan pada server.Juga, sedangkan kedua klien dan server berkomunikasi dengan layanan nama, sekali lagi ini tidak terlihat dari pandangan eksternal objek yang (seperti yang ditawarkan oleh interface).
Lebih umum, objek tertentu dapat membuat panggilan sewenang-wenang untuk aplikasi-tingkat lainnya benda atau layanan sistem terdistribusi yang menawarkan penamaan, ketekunan, konkurensi control, transaksi, keamanan dan sebagainya, dan ini tidak ditangkap dalam tampilan eksternal konfigurasi.

Dependensi implisit dalam konfigurasi didistribusikan membuatnya sulit untuk memastikan komposisi yang aman dari konfigurasi, untuk menggantikan satu objek dengan lain, dan untuk pengembang pihak ketiga untuk melaksanakan satu elemen tertentu dalam didistribusikan konfigurasi.Persyaratan: Dari ini, ada persyaratan yang jelas untuk menentukan tidak hanya antarmuka yang ditawarkan oleh sebuah objek tetapi juga dependensi yang objek telah di lain objek dalam konfigurasi terdistribusi.Interaksi dengan middleware: Meskipun tujuan transparansi, jelas bahwa dalam menggunakan didistribusikan middleware objek programmer terkena banyak relatif rendah tingkat Rincian terkait dengan arsitektur middleware. Sekali lagi, contoh client-server ditunjukkan pada Gambar 8.9 dan 8.10 memberikan gambaran tentang ini.

Despitethis menjadi agak aplikasi sederhana, ada banyak panggilan terkait CORBA yang benar-benar penting untuk pengoperasian aplikasi. Ini termasuk panggilan terkait dengan penamaan (sebagai disebutkan di atas), dengan POA dan ke inti ORB. Dalam contoh yang lebih kompleks, ini dapat mencakup kode sewenang-wenang canggih dalam hal penciptaan dan manajemen referensi objek, manajemen siklus hidup objek, aktivasi dan kebijakan pasif,pengelolaan negara gigih dan kebijakan untuk pemetaan ke platform yang mendasari sumber daya seperti benang.

Semua ini dapat sangat cepat menjadi gangguan dari Tujuan utama dari kode, yang adalah untuk menciptakan sebuah aplikasi tertentu. Ini semua terlalu terbukti dari contoh yang disebutkan di atas, di mana kode aktual yang terkait dengan papan tulis aplikasi yang minimal dan disisipkan dengan kode yang terkait dengan kekhawatiran sistem terdistribusi.Persyaratan: Ada kebutuhan yang jelas untuk menyederhanakan pemrograman terdistribusi aplikasi, untuk menyajikan pemisahan bersih keprihatinan antara kode yang berhubungan dengan operasi dalam kerangka middleware dan kode yang terkait dengan aplikasi tersebut, dan untuk memungkinkan programmer untuk fokus secara eksklusif pada yang terakhir.Kurangnya pemisahan keprihatinan distribusi: Programmer menggunakan objek terdistribusi middleware juga harus berhadapan secara eksplisit dengan kekhawatiran non-fungsional yang terkait dengan isu-isu seperti keamanan, transaksi, koordinasi dan replikasi. Dalam teknologi seperti CORBA dan RMI, ini dicapai dengan memasukkan panggilan sesuai dengan terkait didistribusikan layanan sistem dalam objek. Ini memiliki dua dampak:

Programmer harus memiliki pengetahuan yang mendalam tentang rincian lengkap dari semua terkait layanan sistem terdistribusi.
Pelaksanaan untuk kode aplikasi willcontain diberikan objek bersama
panggilan ke layanan sistem terdistribusi dan antarmuka middleware yang mendasari(Seperti yang disebutkan di atas). The kekusutan yang dihasilkan dari kekhawatiran lebih lanjut meningkatkan kompleksitas pemrograman sistem terdistribusi.
Persyaratan: The pemisahan keprihatinan disinggung di atas harus memperpanjang juga untuk berurusan dengan berbagai layanan sistem terdistribusi, dan kompleksitas berurusan dengan layanan tersebut harus disembunyikan sedapat mungkin dari programmer.Tidak ada dukungan untuk penyebaran: Sementara teknologi seperti CORBA dan Java RMI membuatnya mungkin untuk mengembangkan konfigurasi didistribusikan sewenang-wenang objek, tidak ada dukungan untuk penyebaran konfigurasi tersebut. Sebaliknya, benda harus dikerahkan secara manual pada mesin individu.



Hal ini dapat menjadi proses melelahkan dan rawan kesalahan, terutama dengan penyebaran skala besar yang terdiri dari banyak objek yang tersebar di fisik arsitektur dengan sejumlah besar (berpotensi heterogen) node. Sebagai tambahannya secara fisik menempatkan objek, objek juga harus diaktifkan dan binding yang tepat diciptakan untuk benda-benda lain. Karena kurangnya dukungan untuk penyebaran, pengembang pasti resor untuk strategi ad hoc untuk penyebaran, yang kemudian tidak portabel untuk lainnya

lingkungan.
Kebutuhan: platform Middleware harus memberikan dukungan intrinsik untuk penyebaran sehingga perangkat lunak yang didistribusikan dapat diinstal dan digunakan dalam sama cara sebagai perangkat lunak untuk mesin tunggal, dengan kompleksitas penyebaran tersembunyi dari pengguna.Keempat persyaratan telah menyebabkan munculnya pendekatan berbasis komponen untuk terdistribusi pengembangan sistem, di samping munculnya komponen berbasis middleware, termasuk gaya middleware disebut sebagai server aplikasi.Perhatikan bahwa meskipun pendekatan berbasis komponen hanya memperoleh kepentingan di tahun terakhir, akar mereka dapat ditelusuri kembali ke proyek-proyek sebelumnya menangani konfigurasi ulang dalam sistem terdistribusi (seperti Proyek Conic di Imperial College London [Magee dan Sloman 1989]).

Inti dari komponen
Untuk keperluan diskusi ini, kita mengadopsi definisi komponen yang disediakan oleh Szyperski dalam bukunya tentang komponen perangkat lunak [Szyperski 2002]:
Komponen: Sebuah komponen perangkat lunak adalah unit ofcomposition dengan kontrak antarmuka yang ditentukan dan konteks eksplisit dependensi saja.Dalam definisi klasik ini, kata 'hanya' mengacu pada fakta bahwa setiap konteks dependensi harus eksplisit - yaitu, tidak ada dependensi implisit hadir.komponen perangkat lunak adalah objek terdistribusi seperti di bahwa mereka dikemasunit komposisi, tetapi komponen tertentu menentukan kedua antarmuka yang diberikan kepada dunia luar dan dependensinya pada komponen lain dalam lingkungan terdistribusi.
Dependensi juga direpresentasikan sebagai interface. Lebih khusus, komponen adalah ditentukan dalam hal kontrak, yang meliputi:

Satu set yang tersedia interfaces- yaitu, antarmuka yang menawarkan komponen sebagai layanan untuk komponen lainnya.
Satu set yang dibutuhkan interfaces- yaitu, dependensi bahwa komponen ini memiliki di hal komponen lain yang harus hadir dan terhubung dengan komponen ini untuk itu berfungsi dengan benar.Dalam konfigurasi komponen tertentu, setiap antarmuka diperlukan harus terikat dengan tersedia antarmuka dari komponen lain. Hal ini juga disebut sebagai perangkat lunak




Arsitektur contoh software blok modul layanan file layanan direktori Layanan flat file modul perangkat antarmuka diperlukan antarmuka yang tersedia architectureconsisting komponen, interface dan koneksi antara interface.Kita bisa melihat contoh konfigurasi seperti pada Gambar 8.11. Contoh arsitektur perangkat lunakblok modul layanan file layanan direktori ,Layanan flat file,modul perangkat antarmuka diperlukan antarmuka yang tersedia Contoh ini menunjukkan arsitektur sistem file sederhana menyediakan sebuah antarmuka untuk pengguna lain dan pada gilirannya membutuhkan koneksi ke komponen layanan direktori dan komponen layanan flat file.

Angka tersebut juga menunjukkan koneksi tambahan untuk blok dan perangkat modul, menangkap arsitektur keseluruhan sistem file tertentu. (Kami akan menyelidiki sebenarnya arsitektur sistem file terdistribusi dalam Bab 12.)Antarmuka mungkin gaya yang berbeda. Secara khusus, banyak komponen berbasis pendekatan menawarkan dua gaya antarmuka:

interfacessupporting doa metode remote, seperti dalam CORBA dan Java RMI.
interfacessupporting peristiwa didistribusikan (seperti dibahas dalam Bab 6).Kami akan melihat contoh baik gaya antarmuka ketika kita melihat Enterprise JavaBeans dalam Bagian 8.5.1.


Pemrograman dalam sistem berbasis komponen yang bersangkutan dengan perkembangan
komponen dan komposisi mereka. Tujuannya adalah untuk mendukung gaya software pembangunan yang sejajar pengembangan perangkat keras dalam menggunakan komponen off-the-rak dan menyusun mereka bersama-sama untuk mengembangkan layanan yang lebih canggih: bergerak dari pengembangan perangkat lunak untuk perakitan perangkat lunak. Oleh karena itu pendekatan ini mendukung pengembangan pihak ketiga komponen perangkat lunak dan juga membuat lebih mudah untuk menyesuaikan sistem konfigurasi pada saat runtime, dengan mengganti salah satu komponen dengan yang lain itu adalah tepat Pertandingan dalam hal interface yang disediakan dan diperlukan.



Perhatikan bahwa pendukung berbasis komponen approachesplace penekanan yang signifikan penggunaan ini komposisi dan melihat ini sebagai terbersih pendekatan toconstructing kompleks sistem perangkat lunak. Secara khusus, mereka menganjurkan komposisi atas warisan, melihat warisan sebagai menciptakan bentuk bentuk tambahan dari ketergantungan implisit (kali ini antara











kelas). Hal ini dapat menyebabkan masalah seperti masalah kelas dasar rapuh, di mana perubahan untuk kelas dasar mungkin memiliki dampak yang tak terduga untuk benda-benda lain di bagian bawah warisan hierarki [Szyperski 2002].Sejauh ini, kita telah membahas persyaratan pertama disorot di atas (dalam hal membuat semua dependensi eksplisit), tetapi tidak berikutnya tiga, yang merujuk menyederhanakan pengembangan dan penyebaran aplikasi terdistribusi. tingkat lebih lanjut dukungan ini akan menjadi jelas ketika kita meneliti bagaimana pendekatan berbasis komponen memiliki berkembang di masyarakat sistem terdistribusi.
Komponen dan sistem terdistribusi
Gambar 8.12 Struktur wadah antarmuka siklus Hidup Eksternal (disediakan)interface komponen Panggilan ke eksternal sistem terdistribusi layanan Penangkapan doa masuk Berbagai middleware berbasis komponenteknologi telah muncul, termasuk JavaBeans Enterprise (dibahas dalam Bagian 8.5.1 bawah) dan CORBA



Komponen Model (CCM) [Wang et al.2001], sebuah evolusi CORBA dari objek berbasis ke platform berbasis komponen. Komponen berbasis middleware dibangun di atas filosofi ditangkap atas, tetapi juga menambahkan dukungan signifikan untuk pengembangan sistem terdistribusi dan penyebaran, seperti dibahas di bawah.Wadah: Konsep containersis benar-benar pusat untuk komponen berbasismiddleware. Kontainer mendukung pola umum yang sering dihadapi dalam didistribusikan aplikasi, yang terdiri dari:

afront-end client (mungkin web-based).
wadah memegang satu atau lebih componentsthat menerapkan aplikasi atau logika bisnis.
systemservices yang mengelola data yang terkait dalam penyimpanan persisten.(Hal ini analog dengan model thethree-tier dijelaskan dalam Bagian 2.3.2.)Tugas wadah yang menyediakan dikelola server-side hosting yang lingkungan untuk komponen dan untuk memberikan pemisahan yang diperlukan dari keprihatinan disinggung di atas, di mana komponen berurusan dengan masalah aplikasi dan wadah server aplikasi Teknologi Dikembangkan oleh Rincian lebih lanjut WebSphere Application Server IBM [www.ibm.com]Enterprise JavaBeans SUN [java.sun.com XII] Spring Framework SpringSource(Sebuah divisi dari VMware)
[Www.springsource.org] JBoss JBoss Komunitas [www.jboss.org]


CORBA Komponen Model OMG [Wang et al.2001] Jonas OW2 Konsorsium [jonas.ow2.org] GlassFish SUN [glassfish.dev.java.net] penawaran dengan sistem terdistribusi dan masalah middleware, memastikan bahwa non-fungsional sifat yang dicapai. Struktur keseluruhan wadah ditunjukkan pada Gambar 8.12.Hal ini menunjukkan sejumlah komponen dikemas dalam wadah; wadah tidak menyediakan akses langsung ke komponen melainkan memotong masuk doa dan kemudian mengambil tindakan yang tepat untuk memastikan sifat yang diinginkan dari aplikasi terdistribusi dipertahankan. Jika kita mengambil kasus CORBA, misalnya, ini akan mencakup:

mengelola interaksi dengan mendasari ORB inti dan fungsi POA dan menyembunyikan ini pengembang aplikasi entirelyfrom.
mengelola panggilan untuk tepat layanan sistem terdistribusi, termasuk keamanan dan layanan transaksi, untuk memberikan sifat non-fungsional yang dibutuhkan dari aplikasi, lagi transparan untuk programmer. Secara bersama-sama, ini secara signifikan dapat menyederhanakan pengembangan terdistribusi aplikasi, memungkinkan pengembang komponen untuk fokus secara eksklusif pada kekhawatiran level aplikasi. Misalnya, dengan pendekatan kontainer, semua panggilan terkait POA ditampilkan dalam Angka 8,8 dan 8,9 akan dibuat oleh wadah dan bukan oleh Demikian pula, melalui mekanisme intersepsi, wadah bisa mengeluarkan Urutan berpotensi kompleks panggilan untuk tepat layanan sistem terdistribusi ke menerapkan sifat non-fungsional yang diperlukan.


Sebagai ilustrasi dari titik terakhir, mempertimbangkan pelaksanaan kebijakan manajemen sederhana untuk menangani bersamaan akses ke komponen. Ini dapat diimplementasikan dengan cara yang transparan dengan komponen dengan mencegat doa masuk pada antarmuka eksternal, memperoleh kunci yang terkait dengan komponen yang mendasari dan kemudian melanjutkan dengan panggilan operasi yang mendasari pada komponen itu sendiri, memastikan mengunci dilepaskan ketika Doa selesai (kita akan berbicara lebih banyak tentang kunci dalam Bagian 16.4, tapi untuk sekarang pemahaman umum akan cukup).



Middleware yang mendukung pola wadah dan pemisahan keprihatinan tersirat oleh pola ini dikenal sebagai server aplikasi. Ini gaya terdistribusi pemrograman digunakan secara luas dalam industri saat ini. Berbagai macam aplikasi server sekarang tersedia; ringkasan tentang pendekatan kunci disajikan pada Gambar 8.13Gambar 8.13 Aplikasi server Teknologi Dikembangkan oleh Rincian lebih lanjut WebSphere Application Server IBM [www.ibm.com]Enterprise JavaBeans SUN [java.sun.com XII]Spring Framework SpringSource(Sebuah divisi dari VMware) [Www.springsource.org]JBoss JBoss Komunitas [www.jboss.org] CORBA Komponen Model OMG [Wang et al.2001]Jonas OW2 Konsorsium [jonas.ow2.org]GlassFish SUN [glassfish.dev.java.net]
. Bagian 8.5.1 meneliti spesifikasi Enterprise JavaBeans sebagai contoh aplikasi Server.Dukungan untuk penyebaran: middleware berbasis komponen memberikan dukungan untuk penyebaran konfigurasi komponen; rilis dari perangkat lunak dikemas sebagai perangkat lunak arsitektur (komponen dan interkoneksi mereka) bersama-sama dengan penyebaran descriptorsthat sepenuhnya menggambarkan bagaimana konfigurasi harus ditempatkan dalam didistribusikan lingkungan.Perhatikan bahwa komponen dikerahkan ke dalam wadah, dan deskriptor penyebaran diinterpretasikan oleh kontainer untuk menetapkan kebijakan yang diperlukan untuk mendasari middleware dan layanan sistem terdistribusi. Oleh karena itu Sebuah kontainer yang diberikan mencakup jumlah komponen yang membutuhkan konfigurasi yang sama dalam hal didistribusikan dukungan sistem.deskriptor penyebaran biasanya ditulis dalam XML dan termasuk yang cukup informasi untuk memastikan bahwa:

Komponen terhubung dengan benar menggunakan protokol yang sesuai dan terkait.
Dukungan middleware.
Middleware yang mendasari dan platform dikonfigurasi untuk memberikan tingkat yang tepat dukungan untuk konfigurasi komponen (misalnya, dalam CORBA, ini akan termasuk mengkonfigurasi POA).
Layanan sistem terdistribusi terkait ditetapkan untuk memberikan tingkat yang tepat dari keamanan, dukungan transaksi dan sebagainya.
Alat juga disediakan untuk menafsirkan deskriptor penyebaran dan memastikan benar penyebaran dalam arsitektur fisik yang diberikan.
Studi 8.5 Kasus: JavaBeans Enterprise dan Fractal Keuntungan dari server aplikasi adalah bahwa mereka memberikan dukungan yang komprehensif untuk satu gaya pemrograman terdistribusi - pendekatan tiga-tier seperti yang dijelaskan di atas – dan sebagian besar kompleksitas yang terkait pemrograman withdistributed tersembunyi dari
pengguna.



Kerugiannya adalah bahwa pendekatan ini baik preskriptif dan kelas berat : preskriptif dalam arti bahwa pendekatan mengamanatkan bahwa gaya tertentu dari sistem arsitektur dan kelas berat dalam aplikasi server software besar dan kompleks sistem yang pasti membawa overhead dalam hal kinerja dan sumber daya Persyaratan. Pendekatan ini bekerja terbaik pada mesin server high-end.Untuk mengatasi ini, lebih dilucuti-down dan gaya minimal komponen pemrograman juga diterapkan dalam sistem terdistribusi. Kami menyebut gaya ini sebagai ringan Komponen modelsto membedakan mereka dari aplikasi yang jauh lebih berat arsitektur Server. Pada bagian ini, kita presenttwo studi kasus dari komponen teknologi: Enterprise JavaBeans, contoh terkemuka dari server aplikasi Pendekatan, dan Fractal, contoh arsitektur komponen ringan.







8.5.1  JAVABEANS PERUSAHAN




Enterprise JavaBeans (EJB) [java.sun.com XII] adalah spesifikasi dari server-side,dikelola komponen arsitektur dan elemen utama dari Java Platform, Kewirausahaan Edition (Java EE), satu set spesifikasi untuk pemrograman client-server.

Lain spesifikasi meliputi Java RMI dan JMS, yang ditampilkan dalam buku ini (di Bab 5 dan 6, masing-masing).EJB didefinisikan sebagai model komponen server-side karena mendukung pengembangan gaya klasik aplikasi, di mana jumlah berpotensi besar klien berinteraksi dengan sejumlah layanan diwujudkan melalui komponen atau konfigurasi
komponen. Komponen, yang dikenal sebagai beansin EJB, dimaksudkan untuk menangkap aplikasi (atau bisnis) logika, sebagaimana didefinisikan dalam Bab 2, dengan EJB juga mendukung pemisahan antara logika aplikasi ini dan penyimpanan persisten dalam sebuah database back-end. Dengan kata lain, EJB memberikan dukungan langsung untuk tiga-tier arsitektur diperkenalkan dalam Bagian 2.3.2.EJB managedin arti bahwa pola kontainer diperkenalkan di atas (di Bagian 8.4) digunakan untuk menyediakan dukungan untuk layanan sistem terdistribusi kunci termasuk transaksi, keamanan dan dukungan siklus hidup.



Biasanya, wadah menyuntikkan tepat panggilan ke layanan terkait untuk memberikan sifat yang diperlukan, dan penggunaan manajer transaksi atau jasa keamanan benar-benar tersembunyi dari pengembang Kacang terkait (wadah yang dikelola). Hal ini juga mungkin bagi pengembang kacang untuk mengambil lebih banyak kontrol atas operasi ini (kacang-dikelola).

Tujuan dari EJB adalah untuk mempertahankan pemisahan yang kuat dari keprihatinan antara berbagai peran yang terlibat dalam mengembangkan aplikasi terdistribusi. Spesifikasi EJB mengidentifikasi peran utama sebagai berikut:

thebean penyedia, yang mengembangkan logika aplikasi dari komponen (s);
assembler theapplication, yang merakit kacang ke dalam konfigurasi aplikasi;
yang deployer, yang mengambil perakitan aplikasi tertentu dan memastikan dapat benar dikerahkan dalam lingkungan operasional yang diberikan;
penyedia layanan, yang merupakan spesialis dalam sistem terdistribusi mendasar layanan seperti manajemen transaksi dan menetapkan tingkat yang diinginkan dukungan di daerah-daerah;
penyedia kegigihan, yang merupakan spesialis dalam data persisten pemetaan untuk mendasari database dan dalam mengelola hubungan ini pada saat runtime;
penyedia kontainer, yang dibangun di atas dua peran di atas dan bertanggung jawab untuk benar mengkonfigurasi kontainer dengan tingkat yang diperlukan dari sistem terdistribusi dukungan dalam hal sifat non-fungsional yang terkait dengan, misalnya, transaksi
dan keamanan serta dukungan yang diinginkan untuk kegigihan;
administrator sistem, yang bertanggung jawab untuk memantau penyebaran di runtime dan membuat penyesuaian untuk memastikan operasi yang benar.Perhatikan bahwa EJB adalah arsitektur heavyweightcomponent inthe akal diperkenalkan di atas.
Ada kompleksitas software signifikan, khususnya yang berkaitan dengan manajemen kontainer. Dengan demikian, pendekatan ini preskriptif dan ditujukan untuk kelas tertentu aplikasi saja. Seperti disebutkan di atas, EJB adalah sangat cocok untuk aplikasi yang ikuti arsitektur tiga-tier didasarkan pada database back-end diakses melalui layanan antarmuka yang ditawarkan oleh tingkat menengah (logika aplikasi).

Misalnya, gaya ini arsitektur umum di banyak aplikasi eCommerce di mana database mempertahankan Informasi tentang stok barang, harga dan ketersediaan, sedangkan penawaran tingkat menengah interface untuk menelusuri saham dan membeli item yang dipilih. Ini biasanya besar dan sistem yang kompleks yang memerlukan dukungan dalam hal layanan sistem terdistribusi, dan karenanya overhead yang terkait dengan manajemen kontainer fullyjustified. Kami akan menggunakan contoh eShopthroughout bagian ini sebagai motivasi dan untuk menggambarkan penggunaan EJB dalam pengaturan ini. kelas-kelas lain dari aplikasi tidak akan mengikuti pola ini, dan karenanya EJB adalah sebuah teknologi yang tidak pantas untuk aplikasi tersebut. Contohnya termasuk peer-to-peer struktur yang hanya tidak mengikuti tieredmodel ini dan aplikasi yang lebih ringan berjalan pada perangkat embedded di mana overhead EJB tidak dapat dibenarkan. Pada bagian ini, kita fokus pada fitur EJB 3.0 [java.sun.com XII], dirilis pada tahun 2006. Sebuah jumlah yang sangat besar implementasi EJB 3.0 tersedia baik komersial dan dari konsorsium open source. Memimpin contoh termasuk Spring, JBoss, Jonas dan GlassFish.



Para model komponen EJB

A bean in EJB adalah komponen menawarkan satu atau lebih bisnis interfacesto klien potensial dari komponen itu, di mana antarmuka dapat berupa terpencil, membutuhkan penggunaan middleware komunikasi yang tepat (seperti RMI atau JMS), atau lokal, dalam hal ini lebih langsung, dan karenanya efisien, binding yang mungkin.Berkaitan kembali ke terminologi diperkenalkan dalam Bagian 8.4, antarmuka bisnis setara dengan antarmuka yang tersedia (kita akan melihat interface bagaimana EJB mendukung diperlukan bawah, di ayat pada ketergantungan suntikan). Sebuah bean diberikan diwakili oleh set bisnis jarak jauh dan lokal interface bersama-sama dengan classthat bean terkait mengimplementasikan interface.



Dua gaya utama kacang didukung dalam EJB 3.0 spesifikasi: Sesi kacang: A kacang sesi adalah komponen implementinga tugas tertentu dalam logika aplikasi dari layanan, misalnya untuk melakukan pembelian di eShop kami aplikasi. Sebuah kacang sesi berlangsung selama layanan dan memelihara menjalankan percakapan dengan klien selama sesi. kacang sesi bisa berupa stateful, mempertahankan negara percakapan terkait (seperti saat ini status transaksi eCommerce), atau tanpa kewarganegaraan, dalam hal tidak ada negara adalah dipertahankan. kacang sesi stateful menyiratkan percakapan dengan klien tunggal dan mempertahankan keadaan percakapan tersebut. Sebaliknya, kacang tanpa kewarganegaraan dapat memiliki banyak percakapan bersamaan dengan klien yang berbeda. Negara terkait dengan stateful kacang mungkin atau mungkin tidak terus-menerus, seperti yang kita bahas di bawah.kacang pesan-driven: Klien berinteraksi dengan kacang sesi menggunakan lokal atau remote doa.



Kami telah melihat seluruh buku ini bahwa paradigma komunikasi lainnya juga penting untuk pengembangan sistem terdistribusi, termasuk tidak langsung paradigma komunikasi. Konsep kacang pesan-driven diperkenalkan di EJB 2.0 untuk mendukung komunikasi tidak langsung dan, khususnya, kemungkinan untuk berinteraksi dengan komponen baik menggunakan antrian pesan atau topik, bangunan langsung pada fungsi yang ditawarkan oleh JMS (ingat bahwa kedua antrian dan topik adalah entitas-kelas di JMS mewakili perantara alternatif untuk pesan – melihat Bagian 6.4.3). Dalam kacang pesan-drive, interface bisnis akan direalisasikan sebagai antarmuka pendengar-gaya yang mencerminkan sifat-event dari kacang terkait.
POJOs dan anotasi

Tugas pemrograman di EJB telah disederhanakan secara signifikan melalui penggunaan Enterprise JavaBeanPOJOs (plain objek Java tua)bersama-sama dengan penjelasan Java Enterprise JavaBean. Sebuah bean (yang pelaksanaannya antarmuka bisnis kacang) adalah polos objek Java tua: terdiri dari aplikasi logika ditulis hanya di Jawa tanpa kode lain yang berkaitan dengan itu menjadi kacang. Anotasi kemudian digunakan untuk memastikan perilaku yang benar dalam konteks EJB. Dengan kata lain, kacang adalah POJO dilengkapi dengan anotasi.Anotasi diperkenalkan di Jawa 1.5 sebagai mekanisme untuk menghubungkan metadata dengan paket, class, metode, parameter dan variabel. metadata ini maka dapat digunakan oleh kerangka kerja untuk memastikan perilaku yang benar atau penafsiran terkait dengan bagian dari program. Sebagai contoh, penjelasan digunakan untuk memperkenalkan kacang dari gaya tertentu. Sebagai contoh, berikut adalah contoh definisi kacang dijelaskan(Mewakili gaya utama kacang di EJB 3.0):
public class @Stateful eShop mengimplementasikan Pesanan {...}
public class @Stateless CalculatorBean mengimplementasikan Kalkulator {...}
@MessageDriven SharePrice public class mengimplementasikan MessageListener {...}
Anotasi juga digunakan untuk menunjukkan apakah antarmuka bisnis jarak jauh (@Remote)
atau lokal (@Local). Contoh berikut memperkenalkan Ordersinterface sebagai remote
antarmuka dan Calculatorinterface dari CalculatorBeanas antarmuka lokal saja:
@Remote Pesanan antarmuka publik {...}
@Local Antarmuka publik Kalkulator {...}
Seperti yang akan menjadi jelas, penjelasan yang digunakan di seluruh EJB, menyediakan spesifikasi bagaimana program harus ditafsirkan dalam konteks EJB.Dalam deskripsi yang mengikuti kita akan mengembangkan eShopexample sebagai ilustrasi ekstensif menggunakan anotasi di objek pemrograman kacang (di cas ini,
kacang sesi).

Enterprise JavaBean kontainer di EJB

EJB mengadopsi pendekatan berbasis kontainer sebagai dijelaskan dalam Bagian 8.4. Kacang kontainer deployedto, dan kontainer memberikan implisit manajemen sistem terdistribusi menggunakan intersepsi. Dengan cara ini, wadah memberikan kebijakan yang diperlukan di daerah-daerah termasuk manajemen transaksi, keamanan,ketekunan dan siklus hidup manajemen memungkinkan pengembang kacang untuk fokus secara eksklusif
pada logika aplikasi. Wadah karena itu harus dikonfigurasi dengan yang diperlukan tingkat dukungan. Dalam versi sekarang, EJB telah dilengkapi dengan standar umum kebijakan dan pengembang hanya perlu mengambil tindakan jika default ini tidak cukup(Disebut sebagai konfigurasi dengan exceptionin spesifikasi [java.sun.com XII]).
Sejumlah besar anotasi didefinisikan untuk mengontrol berbagai aspek disebutkan di atas. Kami menggambarkan penggunaan mereka dengan berfokus pada transaksi Enterprise JavaBean
manajemen dan mendorong pembaca untuk juga melihat EJB 3.0 spesifikasi untuk Transaksi akan diperkenalkan inChapters 16 dan 17. Secara garis besar,meskipun, peran mereka adalah untuk memastikan bahwa semua benda (atau, dalam konteks ini, komponen) berhasiloleh satu server (atau beberapa server dalam kasus transaksi terdistribusi) tetap di keadaan konsisten terlepas dari akses bersamaan dari beberapa klien dan dalam hal kegagalan server. Mereka mencapai ini dengan memungkinkan urutan operasi yang akan dieksekusi atom, dalam urutan operasi baik selesai dengan sukses dengan cara yang bebas dari campur tangan dari akses bersamaan lain, atau dengan adanya kegagalan(Seperti, kecelakaan server), tidak berpengaruh sama sekali Kembali ke eShopexample kami,mekanisme transaksi akan memastikan, misalnya, bahwa dua pembelian bersamaan tidak Hasil di satu item yang dijual dua kali dan bahwa server crash tidak memungkinkan sistem untuk masuk ke keadaan tidak konsisten di mana item telah dibayar untuk tetapi tidak ditugaskan ke pembeli.Mekanisme untuk mencapai transaksi relatif kompleks, maka dua bab yang ditujukan ke daerah ini nanti dalam buku ini. Namun demikian, konsep keseluruhan relatif mudah, dan pemahaman intuitif akan cukup untuk memahami bagaimanaEJB mengelola transaksi. Hal penting untuk diingat adalah bahwa transaksi mengacu urutan operasi, dan bahwa urutan harus diidentifikasi secara jelas untuk layanan manajemen transaksi untuk melakukan tugasnya. Transaksi di EJB berlaku untuk setiap gaya kacang, termasuk kedua sesi kacang dan kacang pesan-driven.
Hal pertama untuk menyatakan apakah transaksi yang terkait dengan perusahaan kacang harus kacang-dikelola atau wadah yang dikelola. Hal ini  dicapai dengan mengasosiasikan berikut penjelasan dengan kelas terkait, masing-masing:
@TransactionManagement (BEAN)
@TransactionManagement (CONTAINER)
transaksi Bean dikelola adalah yang paling mudah untuk memahami. Dalam hal ini,pengembang kacang bertanggung jawab untuk secara eksplisit mengidentifikasi urutan operasi menjadi termasuk dalam transaksi. Hal ini dicapai dengan secara eksplisit termasuk dua metode dari antarmuka Jawa javax.transaction.UserTransaction- User.Transaction.begin yang andUserTransaction.commitmethods - dalam kode kacang. Ini dapat digunakan baik pada klien atau server akhir dari interaksi. Fragmen kode berikut menggambarkan penggunaan ini kacang-managedapproach di eShopexample:
@Stateful
@TransactionManagement (BEAN)
public class eShop mengimplementasikan Pesanan {
@Resource Javax.transaction.UserTransaction ut;
public void MakeOrder (...) {
ut.begin ();
...
ut.commit ();
}
}
Untuk batas tertentu, namun, ini adalah bertentangan dengan semangat pendekatan wadah seperti itu
membutuhkan masuknya kode transaksi terkait dalam kacang. Alternatif,wadah yang dikelola transaksi, menyingkirkan kebutuhan untuk kode eksplisit ini dengan memungkinkan wadah untuk menentukan kapan untuk memulai dan menyelesaikan transaksi. Hal ini dicapai melalui asosiasi dari demarcationpolicy diberikan dengan eksekusi kacang. Sekali lagi, ini adalah dicapai declaratively dengan mengaitkan anotasi yang sesuai dengan metode yang diberikan
dalam kelas kacang. Sebagai contoh, perhatikan potongan kode berikut:
public class @Stateful eShop mengimplementasikan Pesanan {...
@TransactionAttribute (DIBUTUHKAN)
public void MakeOrder (...) {...
}
}
Hal ini menunjukkan asosiasi dari REQUIREDpolicy dengan MakeOrdermethod. Ini sates kebijakan bahwa metode terkait harus dilakukan dalam transaksi. Untuk memahami kebijakan ini, perlu untuk menyadari bahwa transaksi dapat dimulai oleh pemanggil atau mungkin menjadi tanggung jawab kacang itu sendiri. The REQUIREDpolicy memulai baru transaksi jika perlu - yaitu, jika penelepon tidak memberikan konteks transaksi menunjukkan pekerjaan sudah dilaksanakan dalam transaksi. Ini dan lainnya kebijakan dirangkum dalam Gambar 8.14 Gambar 8.14 Transaksi atribut di EJB.atribut Kebijakan DIBUTUHKAN Jika klien memiliki berjalan transaksi yang terkait, melaksanakan dalam transaksi ini; jika tidak, memulai transaksi baru.REQUIRES_NEW Selalu memulai transaksi baru untuk doa ini.DUKUNG Jika klien memiliki transaksi yang terkait, melaksanakan Metode dalam konteks transaksi ini; jika tidak, panggilan hasil tanpa dukungan transaksi.
NOT_SUPPORTED Jika klien panggilan metode dari dalam transaksi, maka transaksi ini ditangguhkan sebelum memanggil metode dan kembali setelah itu - yaitu, metode dipanggil dikecualikan dari transaksi.WAJIB Metode terkait harus dipanggil dari dalam klien
transaksi; jika tidak, eksepsi dilemparkan.PERNAH Metode terkait tidak harus dipanggil dari dalam transaksi klien; jika hal ini berusaha, eksepsi dilemparkan.Perhatikan bahwa, secara default, transactionsare wadah yang dikelola di EJB.



Ketergantungan injeksi: Contoh di atas juga menggambarkan peran furtherimportant dari kontainer: Enterprise JavaBean injeksi ketergantungan. Ketergantungan injeksi adalah Pola umum dalam pemrograman dimana pihak ketiga, dalam hal ini wadah, adalah bertanggung jawab untuk mengelola dan menyelesaikan hubungan antara komponen dan yang dependensi (interface yang diperlukan, dalam terminologi Bagian 8.4). Khususnya,di EJB 3.0, komponen mengacu ketergantungan menggunakan anotasi dan kontainer bertanggung jawab untuk menyelesaikan penjelasan ini dan memastikan bahwa, pada saat runtime, yang terkait atribut mengacu pada objek yang tepat.



Hal ini biasanya dilaksanakan oleh kontainer menggunakan refleksi.Misalnya, dalam fragmen kode di atas, @Resourceannotation menunjukkan ketergantungan objek Onan komponen ini menerapkan UserTransaction yang antarmuka. Ini hanya harus ada untuk konfigurasi masuk akal. Ketergantungan injeksi kedua bendera ketergantungan ini dan memastikan bahwa, ketika komponen yang benar konfigurasi dikerahkan, utrefers atribut yang berhubungan dengan sumber daya eksternal yang tepat.
Enterprise JavaBean Interception

Enterprise JavaBeans spesifikasi memungkinkan programmer untuk mencegat dua jenis operasi pada kacang untuk mengubah default tingkah laku :
Metode panggilan terkait dengan antarmuka bisnis;
peristiwa siklus hidup.
Kami melihat satu per satu di bawah ini.
Intersepsi metode: Mekanisme ini digunakan di mana perlu untuk mengaitkan tindakan tertentu atau serangkaian tindakan dengan panggilan masuk pada antarmuka bisnis. Ini berlaku sama untuk doa masuk pada kacang sesi atau peristiwa yang masuk pada Pesan-driven kacang. Seperti yang telah kita lihat, intersepsi digunakan secara luas dalam EJB arsitektur untuk memberikan manajemen implisit. Hal ini memungkinkan pengembang aplikasi untuk memperpanjang penggunaan intersepsi ke domain-spesifik masalah yang lebih tidak disediakan oleh
Perhatikan contoh berjalan dari eShop. Misalkan ada kebutuhan dalam eShop untuk melaksanakan penebangan semua operasi yang dilakukan pada sistem, misalnya untuk tujuan audit. Intersepsi memungkinkan programmer untuk memperkenalkan layanan tersebut tanpa mengubah logika aplikasi yang terkandung dalam kacang. Sebagai contoh kedua,Mekanisme intersepsi dapat digunakan untuk mencegah pelanggan tertentu dari membuat
pembelian di eShop (misalnya, jika mereka telah gagal pada pembayaran sebelumnya).
Ada beberapa cara bergaul pencegat dengan kacang yang diberikan, termasuk
mengaitkan kelas intersepsi dengan kelas kacang yang diberikan atau metode individual (menggunakan penjelasan @Interceptors), atau bergaul metode intersepsi dengan kelas tertentu (Menggunakan @AroundInvoke penjelasan). Demi kesederhanaan, kita fokus pada yang terakhir Mekanisme dan kembali ke contoh kita dari eShop:
@Stateful
public class eShop mengimplementasikan Pesanan {
public void MakeOrder (...) {...
}
@AroundInvoke
Obyek publik log (InvocationContext ctx) throws Exception {
System.out.println ( "Metode berikut ini dipanggil:" + Ctx.getMethod () getName ()); kembali invocationContext.proceed ();
}
}
anotasi @AroundInvokeintroduces pencegat pada kelas eShopbean.Itu Metode interceptor harus memiliki sintaks berikut:
Obyek <methodName> (javax.ejb.InvocationContext)
Metode ini kemudian disebut setiap kali ada metode bisnis dipanggil eShop.parameter yang terkait menambahkan secara signifikan terhadap kemampuan pencegat oleh menyediakan kedua metadata yang terkait dengan doa yang sedang disadap (misalnya,
referensi untuk kacang, metode dipanggil dan parameter aktual yang terkait dengan Signature Gunakan Obyek publik getTarget () Mengembalikan contoh kacang yang terkait dengan doa masuk atau acara Metode publik GetMethod () Mengembalikan metode yang dipanggil Obyek publik [] getParameters () Mengembalikan set parameter yang terkait dengan metode bisnis dicegat kekosongan setParameters publik Object [] params).
Memungkinkan parameter ditetapkan tobe diubah oleh interceptor, dengan asumsi jenis kebenaran adalah dipelihara Obyek publik melanjutkan () throws Pengecualian Eksekusi berlangsung pencegat tonext dalam rantai(Jika ada) atau metode yang telah dicegat doa) dan kemampuan juga terbatas untuk menengahi - yaitu, untuk mengubah parameter sebelum metode dijalankan. Baris terakhir metode, panggilan untuk melanjutkan, pengembalian kontrol kembali ke metode dicegat (atau ke pencegat berikutnya dalam rantai jika lebih dari satu interceptor didefinisikan).

Metode utama yang terkait dengan konteks doa dirangkum dalam Gambar 8.15Gambar 8.15 konteks Doa di EJB Signature Gunakan Obyek publik getTarget () Mengembalikan contoh kacang yang terkait dengan doa masuk atau acara Metode publik GetMethod () Mengembalikan metode yang dipanggil Obyek publik [] getParameters () Mengembalikan set parameter yang terkait dengan metode bisnis dicegat kekosongan setParameters publik (Object [] params).



Memungkinkan parameter ditetapkan tobe diubah oleh interceptor, dengan asumsi jenis kebenaran adalahdipelihara Obyek publik melanjutkan () throws Pengecualian Eksekusi berlangsung pencegat tonext dalam rantai (Jika ada) atau metode yang telah dicegat.Intersepsi peristiwa siklus hidup: Mekanisme serupa dapat digunakan untuk mencegat dan bereaksi terhadap peristiwa siklus hidup terkait dengan komponen. Secara khusus, spesifikasi EJB memungkinkan pengembang kacang untuk mengasosiasikan pencegat dengan penciptaan dan penghapusan komponen menggunakan anotasi berikut, masing-masing:
@PostConstruct
@PreDestroy
Penjelasan terkait metode withgiven di kelas kacang, dengan efek yang metode ini akan dipanggil ketika peristiwa siklus hidup terkait terjadi. Sebagai contoh,dalam kode fragmen bawah dari eShop, TidyUpwill disebut sebelum Komponen hancur:
@Stateful
public class eShop mengimplementasikan Pesanan {...
public void MakeOrder (...) {...}...
@PreDestroy Kekosongan TidyUp () {...}}
}

penjelasan ini umumnya digunakan untuk melepaskan resourcescurrently digunakan oleh eShop kelas, misalnya, membuka file atau soket yang berhubungan dengan eShopimplementation tersebut.
Demikian pula, TidyUpcould digunakan untuk memastikan data kunci yang terkait dengan eShopis ditulis ke database back-end.
Jika kacang adalah stateful, juga memungkinkan untuk menangkap aktivasi dan pasif Peristiwa menggunakan @PostActivateand @PrePassivate. Sekali lagi, ini memungkinkan tindakan utama untuk menjadi diambil dalam hubungan dengan peristiwa siklus hidup ini - misalnya, memastikan percakapan negara terkait dengan sesi disimpan dalam database sebelum kacang adalah pasif.
Anotasi digunakan di seluruh EJB 3.0 untuk memberikan yang konsisten dan sederhana model pemrograman dimana pengembang komponen membangun logika aplikasi di POJOs dan kemudian menghias ini, dimana tepat, dengan penjelasan meta level tambahanyang ditafsirkan oleh kerangka kontainer.


8.5.2 FRACTAL




Seperti disebutkan di atas, Fractal adalah model komponen ringan yang membawa manfaat pemrograman berbasis komponen untuk pengembangan sistem terdistribusi [Bruneton et al. 2006, fractal.ow2.org I]. Fraktal memberikan dukungan untuk pemrograman dengan interface, dengan manfaat yang terkait dalam hal pemisahan interface dan pelaksanaan (manfaat juga disediakan oleh objek terdistribusi). Fraktal berjalan lebih jauh,meskipun, dan mendukung eksplisit representationof arsitektur perangkat lunak dari sistem, menghindari masalah dependensi implisit dibahas dalam Bagian 8.4. Itu Pendekatan ini sengaja minimal, tanpa dukungan untuk tambahan komponen terkait fungsi seperti penyebaran, pola kontainer penuh atau diperkaya
model pemrograman yang ditawarkan oleh server aplikasi. Fraktal digunakan untuk membangun lebih sistem perangkat lunak yang kompleks (termasuk sistem middleware seperti dibahas di bawah) menggunakan model komponen sebagai blok bangunan dasar, sehingga perangkat lunak yang memiliki jelas
komponen berbasis arsitektur dan yang configurableand juga reconfigurableat
runtime untuk sesuai dengan lingkungan operasional dan kebutuhan saat ini.
Fraktal mendefinisikan model pemrograman dan, dengan demikian, adalah pemrograman bahasa-agnostik. Implementasi model ini tersedia dalam beberapa berbeda bahasa, termasuk:

Julia dan AOKell (berbasis Java, dengan yang terakhir juga menawarkan dukungan untuk pemrograman berorientasi aspek);
Cecilia dan Berpikir (C-based);
FracNet (NET-based);
FracTalk (Smalltalk-based);
Julio (Python-based).
Julia dan Cecilia diperlakukan sebagai implementasi referensi dari Fraktal didukung oleh konsorsium OW2 [www.ow2.org], open source komunitas perangkat lunak untuk middleware sistem terdistribusi yang mendorong dan mempromosikan filosofi berbasis komponen untuk pembangunan perangkat lunak tersebut. Untuk saat ini, Fractal telah digunakan dalam pembangunan berbagai platform middleware termasuk Pikirkan (dikonfigurasi kernel sistem operasi), MIMPI (platform middleware mendukung berbagai bentuk komunikasi tidak langsung), Jasmine (alat yang mendukung pemantauan dan pengelolaan SOAplatforms), GOTM (menawarkan transaksi yang fleksibel manajemen) dan Proaktif (platform middleware untuk komputasi Grid). Fraktal juga dasar Grid Komponen Model (GCM), yang telah berpengaruh dalam
pengembangan standar associatedETSI [Baude et al. 2009]. Rincian lebih lanjut dari semua proyek-proyek ini dapat ditemukan di situs web OW2 [www.ow2.org].Perhatikan bahwa beberapa model komponen ringan lainnya telah dikembangkan khusus untuk sistem terdistribusi. Kami memiliki dua - OpenCOM dan OSGI - di dalam kotak pada halaman berikutnya.
Model komponen inti :

Komponen di Fractal menawarkan satu atau lebih interface,
dengan dua jenis antarmuka yang tersedia:
interface server, yang mendukung operationalinvocations masuk (setara dengan interface tersedia dalam terminologi Bagian 8.4);
antarmuka klien, yang mendukung doa keluar (setara dengan yang dibutuhkan interface).Sebuah antarmuka merupakan implementasi dari jenis antarmuka, yang mendefinisikan operasi yang didukung oleh antarmuka itu.Binding di Fractal: Untuk mengaktifkan komposisi, Fractal mendukung bindingsbetween
Dua gaya yang mengikat yang didukung oleh model:
binding Primitif: Gaya sederhana mengikat adalah mengikat primitif, yang merupakan pemetaan langsung antara satu antarmuka klien dan satu antarmuka server dalam yang sama
mengatasi ruang, dengan asumsi jenis yang kompatibel. binding primitif dapat diimplementasikan secara efisien dalam lingkungan bahasa tertentu, misalnya melalui direct referensi objek.binding komposit: Fractal juga mendukung binding komposit, yang sewenang-wenang arsitektur perangkat lunak yang kompleks (yang terdiri dari komponen dan binding)menerapkan komunikasi antara sejumlah antarmuka berpotensi pada mesin yang berbeda. Misalnya, jika Anda menerapkan koneksi CORBA di Fraktal, pengikatan akan terdiri dari komponen yang mewakili inti elemen arsitektur di CORBA, termasuk proxy, inti ORB, adapter objek,
kerangka dan hamba (mirroring arsitektur pada Gambar 8.5).
binding komposit sendiri komponen di Fractal, dan ini penting
karena dua alasan:
Sebuah sistem yang dikembangkan menggunakan Fractal sepenuhnya dikonfigurasi dalam hal komponen interkoneksi andtheir. Misalnya, konfigurasi dapat dibentuk dimana komponen berinteraksi menggunakan komposit mengikat melaksanakan salah satu paradigma komunikasi dibahas dalam Bab 5 dan 6 (remote doa atau
tidak langsung, point-to-point atau multipartai, dan sebagainya). Jika komunikasi yang diberikan Paradigma belum tersedia, dapat dikembangkan di Fractal dan kemudian membuat tersedia untuk pengembang masa depan sebagai komponen.
Setelah didirikan, setiap aspek dari arsitektur perangkat lunak dapat ulang di runtime, termasuk binding komposit. Hal ini sangat berguna untuk dapat beradaptasi struktur komunikasi saat runtime, misalnya untuk memperkenalkan tingkat tambahan dari keamanan atau untuk mengubah pelaksanaan menjadi lebih terukur sebagai suatu sistem tumbuh di ukuran.







OpenCOM

OpenCOM [Coulson et al. 2008] adalah model komponen ringan dengan tujuan yang sangat mirip dengan fraktal. OpenCOM adalah komponen minimal dan terbuka Model yang dirancang untuk menjadi andoperating lingkungan independen domain-; bahwa adalah, teknologi komponen cukup fleksibel untuk diterapkan dalam konteks apapun termasuk daerah menuntut seperti jaringan sensor nirkabel terbatas sumber daya.


OpenCOM juga dirancang untuk menawarkan biaya overhead diabaikan dalam hal kinerja dan persyaratan memori, yang memungkinkan untuk digunakan dalam situasi di mana kinerja adalah penting - misalnya, dalam implementasi router.Arsitektur keseluruhan OpenCOM terdiri dari runtime kernel minimal mendukung operasi komponen dasar termasuk bongkar muat sebuah komponen, dan mengikat komponen bersama-sama. Ini thenenhanced dengan opsional reflektif dan platform ekstensi, yang mendukung pemuatan dinamis reflektif kemampuan dan juga model yang berbeda yang mendukung operasi platform kunci,termasuk semantik loading dan mengikat. Oleh karena itu ekstensi konseptual mirip dengan kontroler di Fractal.



OpenCOM telah digunakan dalam pengembangan berbagai eksperimen platform middleware, termasuk ReMMoC [Rahmat et al. 2003], yang menawarkan layanan Penemuan di lingkungan komputasi di mana-mana yang sangat heterogen (lihat Bab19), dan GridKIT [Rahmat et al. 2008], sebuah eksperimen, sangat dapat dikonfigurasi dan kerangka middleware reconfigurable untuk Grid computing, yang juga dilengkapi dengan Kerangka hamparan terbuka untuk pembangunan virtualizations jaringan sewenang-wenang termasuk lapisan peer-to-peer terstruktur dan tidak terstruktur.
OSGi

OSGi [www.osgi.org] adalah spesifikasi dari middleware berbasis Java
Platform dikelola oleh organisasi standar terbuka, OSGi Alliance. Sebuah angka
implementasi dari spesifikasi ini ada, termasuk Equinox, Knopflerfish, Felix
dan Concierge. Platform ini mendukung siklus hidup andsubsequent penyebaran
manajemen dan adaptasi dari sistem perangkat lunak modular diatur sebagai
communicatingbundles (mirip dengan komponen). Bundel berkomunikasi melalui satu
atau lebih layanan antarmuka dengan layanan publishedin registri layanan, sehingga
mendukung dinamis mengikat. Sebagai unit manajemen siklus hidup, bundel diberikan bisa
diinstal, mulai, diaktifkan, berhenti dan dihapus. Bundel juga bisa dinamis dikerahkan saat runtime, dan bundel yang ada diperbarui. OSGi awalnya dikembangkan untuk pemrograman gateway layanan (maka nama asli Buka Layanan Gateway i) tetapi sekarang digunakan dalam berbagai aplikasi domain,termasuk dalam pemrograman ponsel, sebagai middleware untuk komputasi Grid dan juga sebagai plug-in arsitektur di Pengembangan Eclipse Integrated
Environment (IDE), multi-bahasa pengembangan perangkat lunak frameworkfor populer.
OSGi menargetkan penyebaran dan manajemen konfigurasi terpusat dari software, misalnya yang berada di satu perangkat atau pada server. Sebuah didistribusikan pelaksanaan OSGI, R-OSGi, juga telah dikembangkan [Rellermeyer et al.2007]. Hal ini memungkinkan arsitektur perangkat lunak untuk didistribusikan pada batas layanan di konfigurasi jaringan yang sewenang-wenang. R-OSGi menggunakan pola proxy, pertama diperkenalkan pada Bab 2, untuk memperoleh distribusi transparan pada batas tersebut.














Kita melihat lebih detail pada dukungan untuk konfigurasi ulang pada ayat pada membran dan pengendali bawah.


Komposisi hirarkis: Model komponen hirarkis dalam komponen terdiri dari serangkaian subkomponen dan binding terkait, di mana subkomponen sendiri mungkin komposit. Sebagai contoh, ORB inti di atas Misalnya bisa lebih terurai, mengingat kompleksitas yang melekat. komposisi adalah didukung oleh Fractal Arsitektur Description Language (ADL), yang kami memperkenalkan
dengan contoh sederhana yang menunjukkan penciptaan komponen yang mengandung dua subkomponen yang berinteraksi secara client-server:
<Nama definisi = "cs.ClientServer">
<Nama interface = "r" role = "server"
signature = "java.lang.Runnable" />
<Nama komponen = "pemanggil" definition = "hw.CallerImpl" />
<Nama komponen = "callee" definition = "hw.CalleeImpl" />
<Mengikat client = "this.r" server = "caller.r" />
<Mengikat client = "caller.s" server = "callee.s" />
</ Definisi>
Fraktal ADL didasarkan pada XML. Contoh ini menunjukkan cs.ClientServerwith komponen dua subkomponen, pemanggil dan callee; binding diciptakan antara antarmuka klien,this.r (yaitu, antarmuka r didefinisikan pada cs.ClientServer komponen yang mengandung), dan yang caller.rinterface terkait (interface r didefinisikan pada komponen pemanggil), dan antara antarmuka klien caller.sand yang callee.s Server antarmuka yang sesuai. Itu konfigurasi yang terkait diilustrasikan pada Gambar 8.16.

Fraktal juga mendukung berbagi, dimana komponen tertentu dapat dibagi di seluruh
beberapa arsitektur perangkat lunak. Para pengembang Fractal berpendapat bahwa ini diperlukan untuk setia mewakili arsitektur sistem termasuk akses ke sumber daya yang mendasari bahwa secara fundamental bersama, seperti koneksi TCP. Sebagai contoh lebih lanjut, itu akan menjadi mungkin untuk callee (komponen server) untuk dibagikan di beberapa konfigurasi.

Membran dan pengendali

Dalam pelaksanaannya, komponen terdiri dari membran,
yang mendefinisikan kemampuan kontrol yang terkait dengan komponen melalui serangkaian controller, dan juga konten terkait - subkomponen (dan binding) yang membuat arsitektur. Interface dapat internal ke membran dan karenanya hanya.




terlihat komponen dalam bagian konten, atau eksternal dan karenanya terlihat lain
komponen. Struktur ini diilustrasikan pada Gambar 8.17.
Gambar 8.17 Struktur komponen Fractal
antarmuka kontrol
Selaput
antarmuka klien
Server interface
kadar
controller
Konsep membran sangat penting untuk pendekatan Fractal; membran menyediakan
rezim kontrol dikonfigurasi untuk set dikemas komponen (konten). Di
Dengan kata lain, himpunan pengendali mendefinisikan kemampuan kontrol dan terkait
semantik untuk komponen ini. Dengan mengubah set pengendali, wealso mengubah
kemampuan.
Controller dapat digunakan untuk berbagai keperluan:

Salah satu kegunaan penting dari pengendali adalah untuk menerapkan manajemen siklus hidup,termasuk operasi yang terkait dengan aktivasi dan pasif seperti menangguhkan,melanjutkan dan pos pemeriksaan. Misalnya, Fractal mendukung LifeCycleController mendukung tiga metode, startFc, stopFcn getState, yang mengimplementasikan tiga fungsi tersebut, masing-masing. Hal ini sangat penting dalam kasus di mana pengaturan ulang konfigurasi dari arsitektur perangkat lunak yang mendasari sedang dilakukan saat runtime. Mempertimbangkan
contoh sederhana dari konfigurasi client-server di atas dan kira server diganti secara dinamis oleh server ditingkatkan (mungkin salah satu mendukung multi-threading untuk meningkatkan throughput yang).Dalam hal ini, untuk menghindari inkonsistensi, akan sangat membantu untuk menangguhkan konfigurasi, menggantikan callee komponen dengan yang baru, dan kemudian melanjutkan konfigurasi.
Controller juga menawarkan kemampuan refleksi (lihat Bab 2). Khususnya,
kemampuan introspeksi disediakan melalui dua interface, Komponen dan
ContentController, yang mendukung introspeksi (penemuan dinamis) dari
antarmuka yang terkait dengan komponen dan langkah melalui arsitektur dari
komponen struktur komposit masing-masing. Antarmuka penuh untuk dua
kontroler ditunjukkan pada Gambar 8.18. Introspeksi lagi penting untuk mendukung rekonfigurasi dinamis. Kembali ke contoh client-server kami, adalah mungkin,melalui antarmuka di atas, untuk menemukan arsitektur yang tepat dari yang mendasari Komponen konfigurasi (dalam kasus ini, konfigurasi yang sederhana terdiri dari dua


Komponen dan ContentControllerInterfaces di Fractal
antarmuka publik Komponen {
Object [] getFcInterfaces ();
Obyek getFcInterface (String itfName);
Ketik getFcType ();
}
antarmuka publik ContentController {
Object [] getFcInternalInterfaces ();
Obyek getFcInterfaceInterface (String fname);
Komponen [] getFcSubComponents ();
kekosongan addFcSubComponent (Component c);
kekosongan dihapus subkomponen (Component c);
}
komponen) dan juga untuk memastikan bahwa pengganti calleecomponent mendukung tepatnya antarmuka yang sama dengan yang lama.

Controller dapat diperkenalkan untuk menawarkan kemampuan intersepsi mencerminkan Kemampuan yang ditawarkan di EJB dan dilaporkan dalam Pasal 8.5.1 di atas. Intersepsi adalah mekanisme yang kuat dengan banyak kegunaan. Pada bagian EJB, misalnya disediakan menggunakan intersepsi untuk melaksanakan penebangan. Misalnya, intersepsi bisa digunakan dalam contoh client-server untuk log semua panggilan yang dikeluarkan oleh komponen pemanggil di dengan cara yang akan benar-benar transparan untuk kedua pemanggil dan callee. SEBUAH penggunaan lebih lanjut dari intersepsi adalah untuk menerapkan kebijakan kontrol akses hanya mengizinkan sebuah doa untuk melanjutkan jika kepala sekolah diberikan memiliki hak untuk mengakses sumber daya yang diberikan
(Lihat Bagian 11.2.4).
Setelah mempelajari peran relatif membran dan pengendali, sekarang mungkin untuk berhubungan membran untuk kontainer, seperti yang diperkenalkan dalam Bagian 8.4 dan dalam studi kasus EJB Membran, seperti kontainer, menyediakan tempat untuk penyebaran komponen;
kedua teknik juga mendukung pengelolaan sistem terdistribusi implisit, kontainer membuat panggilan implisit untuk layanan sistem terdistribusi dan membran melalui mereka kontroler konstituen. Membran, meskipun, secara signifikan lebih fleksibel:
Dalam hal refleksi, dukungan dapat berkisar dari kotak hitam komponen mana struktur internal tersembunyi, melalui pendekatan introspeksi mana terbatas Kemampuan yang ditawarkan (dinamis menemukan interface), untuk maju refleksi fitur pendukung introspeksi penuh dan memberikan dukungan yang melekat untuk adaptasi berikutnya struktur internal.
Dalam hal mendukung kekhawatiran non-fungsional, di satu ekstrim, membran dapat memberikan tidak lebih dari enkapsulasi sederhana komponen (jika, misalnya,pengendali minimal dikerahkan); di ekstrim lainnya, mereka dapat mendukung sepenuhnya manajemen sistem terdistribusi matang komponen, termasuk dukungan untuk transaksi dan keamanan dalam server aplikasi, tetapi dalam benar-benar dikonfigurasi dan reconfigurable cara.


Karena fleksibilitas yang melekat ini, Fractal disebut model komponen sebagai AOpen.
Sebuah contoh bekerja dari pelaksanaan Fractal lengkap dapat ditemukan di
tutorial secara online [fractal.ow2.org II]. Contoh ini menunjukkan bagaimana Fractal dapat digunakan untuk menerapkan dikonfigurasi, minimal HTTP server disebut Comanche.


8.6 RINGKASAN
Bab ini telah memeriksa desain solusi middleware lengkap berbasis di sekitar
objek terdistribusi dan komponen. Seperti sekarang akan menjadi jelas, mereka mewakili alam evolusi dalam berpikir tentang abstraksi pemrograman tersebut. objek terdistribusi adalah penting dalam hal membawa manfaat enkapsulasi dan abstraksi data untuk sistem terdistribusi, dan serta alat terkait dan teknik dari bidang
berorientasi objek desain. Oleh karena itu objek terdistribusi merupakan langkah maju yang signifikan dari pendekatan sebelumnya berdasarkan langsung pada model client-server. Dalam menerapkan Pendekatan objek terdistribusi, namun, sejumlah keterbatasan yang signifikan telah muncul dan ini telah disajikan dan dianalisis dalam bab ini. Singkatnya, itu sering terlalu kompleks dalam praktek untuk menggunakan solusi middleware seperti CORBA untuk canggih aplikasi terdistribusi dan layanan, terutama ketika berhadapan dengan canggih sifat sistem seperti seperti, misalnya, ketergantungan (toleransi kesalahan dan
keamanan).
komponen teknologi mengatasi keterbatasan ini, melalui intrinsik mereka
pemisahan keprihatinan antara logika aplikasi dan manajemen sistem terdistribusi.
Identifikasi eksplisit dependensi juga membantu dalam hal mendukung pihak ketiga
komposisi sistem terdistribusi. Bab ini meneliti EJB 3.0 spesifikasi
yang telah membuat langkah lebih jauh ke depan dalam hal menyederhanakan sistem terdistribusi pembangunan melalui pendekatan yang menekankan penggunaan benda Java tua polos dengan kompleksitas dikelola declaratively melalui penggunaan penjelasan Jawa. Seperti yang kita lihat, teknologi yang lebih ringan seperti Fractal dan OpenCOM juga telah diperkenalkan untuk membawa manfaat pemrograman berbasis komponen untuk pengembangan platform middleware sendiri, dengan sedikit overhead ditambahkan dalam hal kinerja.
komponen teknologi yang penting untuk pengembangan didistribusikan aplikasi, tapi seperti teknologi apapun, mereka memiliki kekuatan dan kelemahan mereka. Untuk
Misalnya, pendekatan komponen cukup preskriptif dan paling cocok untuk aplikasi
yang secara alami menyerupai arsitektur tiga-tier. Untuk menawarkan perspektif yang lebih luas di berbagai platform middleware yang tersedia, dua bab berikutnya meneliti alternatif pendekatan berdasarkan penerapan standar berbasis web (layanan web) dan sistem peer-topeer.
LATIHAN
8.1 Tugas Bag adalah obyek yang menyimpan (key, value) pasangan. Kunci adalah string dan nilai yang urutan byte. interface-nya memberikan metode jarak jauh berikut:
pairOut, dengan dua parameter di mana klien menentukan kunci dan nilai untuk disimpan.
Pairin, yang parameter pertama memungkinkan klien untuk menentukan kunci dari pasangan untuk menjadi dihapus dari Task Bag. Nilai dalam pasangan dipasok ke klien melalui parameter kedua. Jika tidak ada pasangan yang cocok tersedia, eksepsi dilemparkan.
readPair, yang sama dengan pairInexcept bahwa pasangan ini tetap dalam Task Bag.
Gunakan CORBA IDL untuk mendefinisikan antarmuka dari Task Bag. Mendefinisikan pengecualian yang dapat dibuang setiap kali ada salah satu operasi tidak dapat dilakukan. pengecualian Anda harus mengembalikan integer yang menunjukkan jumlah masalah dan string yang menjelaskan masalah. Tugas Bag antarmuka harus mendefinisikan atribut tunggal memberikan jumlah
tugas dalam tas. halaman 341
8.2 Menentukan tanda tangan alternatif untuk metode pairInand readPair, yang nilai kembali menunjukkan bila tidak ada pasangan yang cocok tersedia. Nilai kembali harus didefinisikan sebagai tipe enumerasi yang nilai bisa ok dan menunggu. Diskusikan manfaat relatif dari dua pendekatan alternatif. Pendekatan yang akan Anda gunakan untuk menunjukkan kesalahan seperti kunci yang berisi karakter ilegal? halaman 342
8.3 Yang satu metode dalam antarmuka Task Bag bisa didefinisikan sebagai oneway a operasi? Berikan aturan umum mengenai parameter dan pengecualian dari oneway metode. Dengan cara apa arti dari onewaykeyword yang berbeda dari
Sisa dari IDL? halaman 342
8.4 IDL Jenis serikat dapat digunakan untuk parameter yang akan harus lulus salah satu dari kecil jumlah jenis. Menggunakannya untuk menentukan jenis parameter yang kadang kosong dan kadang-kadang memiliki nilai tipe. halaman 345
8.5 Dalam Gambar 8.2 Jenis All didefinisikan sebagai urutan panjang tetap. Mendefinisikan ini sebagai array panjang yang sama. Memberikan beberapa rekomendasi untuk pilihan antara array dan urutan dalam antarmuka IDL. halaman 345
8.6 Tugas Bag dimaksudkan untuk digunakan dengan bekerja sama klien, beberapa di antaranya menambahkan pasangan(Menggambarkan tugas) dan lain-lain yang menghapusnya (dan melaksanakan tugas-tugas yang dijelaskan).
Ketika klien diinformasikan bahwa tidak ada pasangan yang cocok tersedia, itu tidak dapat melanjutkan nya bekerja sampai pasangan menjadi tersedia. Mendefinisikan antarmuka callback yang tepat untuk digunakan dalam situasi ini. halaman 357
8.7 Jelaskan modifikasi yang diperlukan untuk antarmuka Task Bag untuk memungkinkan callback untuk menjadi bekas. halaman 357
8,8 Manakah dari parameter metode dalam antarmuka Tugas Bag yang disahkan oleh nilai dan yang disahkan oleh referensi? halaman 343
8,9 Gunakan compiler Java IDL untuk memproses antarmuka Anda didefinisikan dalam Latihan 8.1. Memeriksa definisi tanda tangan untuk metode pairInand readPairin yang dihasilkan setara java dari antarmuka IDL. Lihat juga di definisi yang dihasilkan dari pemegang metode untuk argumen nilai untuk metode pairInand readPair. Sekarang memberikan contoh yang menunjukkan bagaimana klien akan memanggil pairInmethod, menjelaskan bagaimana hal itu akan memperoleh nilai yang dikembalikan melalui argumen kedua. halaman 346
8.10 Berikan contoh untuk menunjukkan bagaimana klien Java akan mengakses atribut memberikan nomor tugas dalam objek Task Bag. Dalam apa yang menghormati tidak atribut berbeda dari sebuah contoh variabel dari sebuah objek? halaman 345
8.11 Jelaskan mengapa interface ke objek remote secara umum dan objek CORBA di tertentu tidak menyediakan konstruktor. Menjelaskan bagaimana objek CORBA dapat dibuat dalam tidak adanya konstruktor. Bab 5 dan halaman 355
8.12 Mendefinisikan interface Task Bag dari Latihan 8.1 di IDL sehingga membuat penggunaan struct untuk mewakili pasangan, yang terdiri dari Key dan Nilai a. Perhatikan bahwa tidak ada kebutuhan untuk menggunakan typedefto mendefinisikan struct. halaman 345
8.13 Diskusikan fungsi repositori pelaksanaan dari sudut pandang
skalabilitas dan toleransi kesalahan. Halaman 350, halaman 351
8.14 Sejauh mana mungkin benda CORBA bermigrasi dari satu server ke yang lain?
Halaman 350, halaman 351
8.15 Jelaskan hati-hati bagaimana middleware berbasis komponen pada umumnya dan EJB khususnya dapat mengatasi keterbatasan kunci didistribusikan objek middleware. Memberikan contoh untuk menggambarkan jawaban Anda. halaman 358-364
8.16 Diskusikan apakah arsitektur EJB akan cocok untuk menerapkan secara besar-besaran multiplayer online game (domain aplikasi awalnya diperkenalkan dalam Bagian 1.2.2).Apa yang akan menjadi kekuatan dan kelemahan dari menggunakan EJB dalam domain ini? halaman 364
8.17 Akan Fractal menjadi pilihan implementasi yang lebih cocok untuk domain MMOG?Membenarkan jawaban Anda. halaman 372
8.18 Jelaskan bagaimana filosofi berbasis kontainer dapat diadopsi untuk menyediakan migrasi transparansi untuk komponen terdistribusi. Halaman 362, 362
8.19 Bagaimana Anda mencapai efek yang sama di Fractal? halaman 375
8.20 Pertimbangkan pelaksanaan Java RMI sebagai komposit mengikat dalam Fractal. Diskusikan sejauh mana seperti mengikat dapat menjadi dikonfigurasi dan reconfigurable.
Bab 5, halaman 373.