Home برمجة جافا برمجة التطبيقات الموزعه RMI بجافا
برمجة التطبيقات الموزعه RMI بجافا

برمجة التطبيقات الموزعه RMI بجافا

1.04K
3

بسم الله الرحمن الرحيم .

التطبيقات الشبكيه عاده تكون لنوعين من البرامج:

  • الأول يهتم بكيفيه تبادل الملفات والبيانات بين الClient والـ Server ويتم التعامل مع هذا النوع باستخدام بروتكولات FTP,SMTP,HTTP وغيرها من البروتكولات.
  • النوع الثاني من التطبيقات يهتم بكيفيه تشغيل برنامج أو داله في الجهاز الأخر مثل Telnet و Remote Procedure Call أختصارا RPC .

لغه جافا من اللغات الموجهه للكائنات OO ، وبالتالي سوف تطبق مفهوم RPC ولكن عن طريق الكائنات ، ومن هنا جائت تقنيات الـ Distributed Object والتي تسمح لي باستدعاء داله موجوده في كائن بعيد بدون الدخول في تفاصيل ارسال واستقبال البيانات …

والطريقه الأولى و التقليديه في كتابه برامج الشكبات Client-Server معروفه لدى الأغلب ، حيث يقوم العميل (مثلا طالب) بتعبئه Form ويرسل البيانات الى الخادم ، والذي يقوم بمعالجتها ويرجع النتيجه أو تخزينها للأستفاده منها لاحقا …

الشكل التالي بين Classical Client-Server Model :

RMI1

لكي يقوم المبرمج ببرمجه برنامج مثل هذا عليه أن يقوم بتحديد عده امور مهمه :

  • طريقه برمجه الـ Client-Server ، هل هم بالأعتماد على TCP-Socket أو UDP-Socket.
  • كيفيه ارسال البيانات الى الجهه الأخرى بصوره مفهمومه للجهه الأخرى Formatted Understandable Data
  • كيفيه عمل parse للرساله القادمه واستخلاص المعلومات منها ..

كل هذه الأمور على المبرمج أن يضعها في الأعتبار قبل و أثناء كتابه البرنامج ، والا فلن يعمل بالشكل المطلوب ..فمثلا لو قام الطالب Client بالضفط على زر Delete .. يجب أن تذهب هذه المعلومه الى الطرف الأخر بطريقه ما .. ويقوم الطرف الأخر بمعرفه هذه المعلومه والقيام بالوظيفه المطلوبه …ويرجع النتيجه بطريقه مفهومه يفهمها الكلاينت .

الذي نريده هنا هو ميكانيكه تسمح لي عمل نفس الـ Client-Server بدون الحاجه الى تلك الخطوات أعلاه ، فقط أقوم بالضغط على الزر ولا أهتم بكيفيه الأرسال ، ولا كيفيه فهم المعلومه ولا توجد حاجه لparse ولا غيره ، أيضا قد يكون الخادم مكتوب باللغه أخرى مثلا سي++. المشكله هنا أن الكائن الذي يقوم بهذا العمل غير موجود لدينا في الجهاز المحلي ..

الحل سوف يكون عن طريق عمل “واجهه تستطيع التعامل مع الخادم” Proxy في جهه العميل ، وعندما نضغط على ذالك الزر يقوم العميل باستدعاء الداله الموجوده في الـ Proxy .. وبعدها يقوم هذا الـ Proxy بالأتصال مع الخادم بطريقه يعرفها هو … بنفس الأمر السيرفر قد لا يعلم عن الكلاينت شيء ، لذلك يكون فيه Proxy هو الأخر يتخاطب مع الكلاينت .. أي أن الـ Server-Proxy يقوم بالتخاطب مع الـ client-Proxy .

أنظر الصوره التاليه لتبين لك :
RMI2

هنا طريقه التخاطب بين تلك الـ Proxies قد يعتمد على التنقيه المستخدمه ، وأشهر ثلاث تقنيات هما :
RMI , CORBA , SOAP

RMI :
أختصار لـ Remote Method Invocation وتعتمد على فكره أستدعاء الكلاينت (يعمل في JVM) لداله في كائن بعيد موجود في الخادم (يعمل على JMV مختلفه) ، ويشترط أن يكون الخادم والعميل مكتوبين بجافا ، وتستخدم هذه التقنيه RMI Protocol لتطبيق التخاطب الذي يتعامل مع TCP Socket .وباستخدام RMI سوف نعطي العميل الشعور بأنه لا وجود لكائنات بعيده .. بالضبط كأنه يتعامل مع كائن محلى ، وهذه أحد ميزات الـ RMI .

CORBA :
أختصار لـ Comman Object Request Borker Architecture ..
وظيفتها نفس وظفيه الـ RMI وهي أستدعاء داله في كائن بعيد ، لكن يمكن أن يكون الكائن البعيد مكتوب بأي لغه لا يهم .. وتستخدم CORBA بروتكول يسمى Internet Inter-ORB Protocol واختصارا IIOP .

SOAP :
أختصار لـ Simple Object Access Protocol
وهي تقريبا نفس وظيفه CORBA ، ولكن تعتمد في عملها على ملفات XML .

CORBA و SOAP تعمل على أي لغه لا يشترط جافا ، وهنا سوف نستخدم لغه خاصه لوصف الدوال الموجوده في السيرفر والتي يستطيع الكلاينت التعامل معها .. في CORBA نستخدم لغه تسمى Interface Defenition Langauge واختصارا IDL (يمكن أن نستخدم RMI مع بروتكول IIOP ولن نحتاج الى IDL) . أما في SOAP نستخدم Web Services Description Language أختصارا WSDL . طبعا هذه ليست لغات كجافا أو سي ، لكنها فقط لغه لوصف الـ Interface الذي يستطيع أستخدامه الكلاينت …

طبعا أسهل هذه التقنيات هي RMI وهي موضوع حديثنا اليوم ، أما CORBA فهي تحتاج موضوع اخر لها هي والـSOAP والتي تستخدم عند العمل مع Web-Service .

RMI Conecpt
بنظره سريعه في أي كود RMI ، سوف نجد أنه يبعدنا تماما من التفاصيل ، فعندما نريد أن نستدعي داله موجوده في الخادم Server ، كل ما على أن أكتب سطر واحد وسأحصل على Reference لهذا الكائن . بعدها أستدعى الداله بشكل عادي كما لو أنها كانت Local . اذا كانت هناك قيمه مرسله Parameters و قيم راجعه return Value ، ستذهب بطريقه ما الى المكان الصحيح وبدون تدخل منك .. فعلا RMI تجعل الحياه أكثر سهوله .

أنظر للصوره التاليه والتي توضح هذه العمليه بشكل Abstract :
RMI3

لندخل الى العمق أكثر ولنرى كيف يقوم RMI بارسال القيم المرسله والراجعه .. أولا عندما يقوم الكلاينت باستدعاء داله موجوده في كائن بعيد سوف يقوم client باستدعاء الداله stub الموجوده في Proxy لديه .. ويمرر لها المتغيرات المطلوب ارسالها .. بعد ذلك يبدأ الـ Stub بعمل معالجه لتلك المتغيرات حتى يرسلها .. فلن يرسلها هكذا .. هذه العمليه تسمى Parameter Marshalling .

في عمليه الـ Marshalling سوف ينظر أولا الى نوع المتغير أو الكائن ، فاذا كان متغير عادي Primitve Data Type فيقوم بارساله كما هو بالطبع بعد تحويله الى بايت Byte بترميز يعرف بـ Big-Endian ..

أما اذا كان المتغير هو كائن reference فلا يمكن أن يرسل بهذه الطريقه ، لأنه يمكن أن يحتوي على كائنات أخرى فيه وتلك الكائنات تحتوي أيضا على كائنات وهكذا . لذلك في عمليه ارسال الكائن سوف نقوم بترميزه بـ serialization وبالتالي تذهب البايتات بطريقه معينه متسلسله الى الجهه الأخرى .وعندما تصل الى الجهه الثانيه سوف يقوم بتجميع هذه البايتات بعمليه تدعى De-Serialization . لذلك في حاله التعامل مع الكائنات (قيم مرسله أو راجعه) يجب أن يكون الكائن لديك يطبق impelements الـ serialization .

الأن بعدما أنتهي الـ stub من عمليه Encoded سوف يرسل هذه البايتات الى الجهه الثانيه ، ويقوم الReceiver Object باستقبال هذه البايتات وتجميعها unmarshals the parameters وبعدها يقوم يتحديد الكائن المراد ثم استدعاء الداله المراده وفي حال كان هناك قيمه راجعه منها يقوم هذا الـ receiver object بعمل Marshals لهذه القيمه الراجعه ويعيدها الى Stub الذي يقوم بعمليه unmarshals للقيمه الراجعه ويرجعها الى الكلاينت الذي استدعى الـ Stub .

الصوره التاليه توضح عمليه Parameter Marshalling :
RMI4

ربما تبدوا العمليه معقده وغير مفهومه ، لكن كما ذكرت لا حاجه للمبرمج بمعرفه تلك الخطوات ، لأن من ميزات RMI هي عمل أخفاء لكل هذه التفاصيل Good Tranceparency .

RMI Programming Steps :
هناك خطوات معينه للبرمجه في RMI سوف نذكرها هنا بشكل سريع وسوف تتضح بشكل أكبر عندما تنتاول الأمثله ان شاء الله .

أولا الخادم server :
عمل ملف Interface نضع فيه جميع الدوال التي نريد العميل أن يستدعيها .
نقوم بعمل ملف Impl للأنترفيس أعلاه ونقوم بتعريف الدوال التي صرحنا عنها .
نقوم بعمل ملف Server ونقوم بعمل Object من الملف Impl ونقوم بتسجيله في ملف يسمى registry باسم ما .
الأن الـ server جاهز لأتصال العميل واستدعاء الدوال من الكائن الموجود به .

ثانيا الكلاينت Client :
نقوم بالأتصال بملف registry ونطلب الأسم الذي كتبه السيرفر عند تسجيله للكائن .
سوف نحصل على ذلك الكائن ومنه نستدعي الداله المطلوبه .. (حتى يتضح لك سوف نحصل على Special Reference للكائن وعندما نستدعي الداله سوف يستدعي الداله الصحيحه وتنفذ هناك في السيرفر وترجع القيمه الراجعه لدينا) .

طبعا مع التعامل مع الـ Exception المناسبه .. وهي في حالتنا هذه RemoteException .. وهكذا تكون أصبحت خبير في RMI Programming.

Hello RMI World :
نأخذ الأن مثال على RMI Programming .. ونبدأ بالمثال الشهير Hello World . نريد أن نكتب كائن يعمل في السيرفر يحتوي على داله ترجع Hello ، ويقوم العميل باستدعاء هذه الداله عن بعد ..

نبدأ بالبرمجه في جهه الخادم :
سوف نحتاج أولا الى Interface يحتوي على جميع الدوال التي نريد العميل استدعائها وهنا فقط سوف تكون لدينا داله واحده وهي طباعه ..هذا الـ Interface يجب أن يقوم بعمل وراثه من الكلاس Remote حتى يقوم كلاس أخر (يمثل الكائن البعيد) بعمل تطبيق لهذا الأنترفيس .. اضافه الى أن الدوال التي سنكتبها في هذا الـ Interface يجب أن تقوم بعمل Throws لنوع معين من الException هو RemoteException لأنه قد تحدث مشاكل اثناء استدعاء الداله مثلا قطع الأتصال مع الخادم أو انهيار بالشبكه أو أيه مشكله أخرى .. لذلك جميع الدوال سوف تتعامل مع هذا الـ Exception .

جميع الكلاسات الخاصه ببرمجه RMI موجوده في الباكج java.rmi .. لنرى الأن ملف Interface ولنطلق عليه Hello :

أنتهت الخطوه الأولى ، الأن نقوم بكتابه كلاس يطبق هذا الـInterface ، بالاضافه الى الوراثه من UnicastRemoteObject وهو الكلاس الخاص بأمور الـ Marshalling وارسال واستقبال البيانات ..وهو موجود في الباكج java.rmi.server

لنرى ملف HelloImpl (جرت العاده أن تكون نهايه هذا الملف بـ Impl) :

الخطوه الثالثه وهي كتابه السيرفر Server ، وهنا سوف نقوم بعمل كائن من HelloImpl وندخل هذا الكائن في الـ registry ونعطيه أي اسم ما، وبالطبع الكلاينت يجب أن يكون لديه هذا الأسم لكي يحصل على الـ reference فيما بعد ..

الداله :

هي التي تقوم باضافه سجل في ملف registry يحتوي على اسم الكائن وعنوانه Reference . طبعا هذه الخدمه Registry سو ف نقوم بتشغيلها قبل أن يعمل السيرفر حتى تتم اضافه هذا السجل فيه .. يمكنك عن طريق هذه الخدمه أن تسجل كائن باسم ما ، ويقوم الكلاينت فيما بعد بالأتصال بهذه الخدمه بالأسم المعين ليحصل على الكائن .. طبعا الأضافه في ملف Registry تتم فقط من جهه السيرفر .الكلاينت يطلب من الـ Registry كائن عن طريق الأسم ..

ملف Server ، لاحظ أنه بعد عمل rebind سوف نقوم بطباعه جمله تدل أن السيرفر يعمل الأن وفي حال اتصال …

الأن الى هنا أنتهينا من البرمجه في جهه الخادم .. نأتي الأن لجهه العميل ..

كل ما علينا في جهه الكلاينت الحصول على reference للكائن ، ومن ثم استدعاء تلك الداله ، فقط .. ويتم الحصول على الكائن من خلال الداله lookUp الموجوده في الكلاس Naming ..

الأن بعد الحصول على reference للكائن سوف يكون نوعه Object ، لذلك نقوم بعمل cast الى النوع Hello .. ومن ثم نستدعي الداله بشكل عادي

في البدايه وللتبسيط وقبل أن نرى موضوع RMI Deployment ، ضع كل الملفات في مجلد واحد ، نريد أن نختبر البرنامج في Local Machine .

الأن قم أولا بترجمه جميع الملفات:
javac *.java
الأن ستخرج لك 4 ملفات .class

قم بترجمه ملف HelloImpl.class باستخدام المترجم الخاص بـ rmi :
rmic HelloImpl
(من غير كتابه الأمتداد) ..

الناتج هنا سوف يكون ملف Stub باسم HelloImpl_Stub.class . هذا الملف يجب أن يتواجد عند الكلاينت حتى يعمل البرنامج بشكل صحيح هو والملف Hello.class (لأننا في الكلاينت سوف نقوم بعمل Cast لهذا النوع) .. لذلك عليك أن نتسخ هذين الملفات الى الكلاينت في حال كان مجلد الكلاينت في مكان أخر أو في جهاز ثاني .. حاليا انسى الكلام واستمر على أساس أنهم جميعهم في نفس المسار ، وبعد قليل نتناول هذا الموضوع بشكل أوسع .

الأن (في جهه السيرفر ، لكننا حاليا نعمل وجميعهم في جهاز واحد ) قم بتشغيل ملف rmiregistry .. وذلك من خلال سطر الأوامر أكتب :
rmiregistry

ولن يكون هناك مؤشر أو جمله طباعه تدل على أنه يعمل .. فقط ستجد أن title Bar لسطر الأوامر أصبح يحتوي على rmiregistry وهو دليل على عمل هذه الخدمه ..

الأن شغل الخادم في نافذه اوامر جديده :
java server

وستجد أن الجمله Binding Complete …..تم طباعتها على الشاشه ..وهكذا يكون السيرفر يعمل ، والخدمه registry تعمل ايضا .. لن تستطيع ايقافها الا بالضفط على CTRL+C .

أخيرا شغل ملف الكلاينت :
java Client

وستجد جمله Hello Distributed Computing امامك في الشاشه (حيث تم استدعاء الداله getHelloMessage في السيرفر ، والناتج من هذه الداله هذا الString الذي تم طباعته في الكلاينت ) ..

تأكد من فهم ماذا حصل ،، تم استدعاء الداله getHelloMessage الموجوده في السيرفر ، وانتفذت هناك والقيمه الراجعه رجعت للعميل ، الذي قام بطباعتها على الشاشه .. هذه هي RMI بمنتهى البساطه  .

Bank Service
نأخذ مثال أخر لتأكيد فهم الموضوع ، على مثال لعميل يريد أن يدخل بياناته لدى البنك ، ويقوم بالبحث عن معلوماته من خلال الأسم .. هذه الدوال سوف تكون في السيرفر ويقوم الكلاينت باستدعاء هذه الدوال من بعد ، ويمرر لها المعاملات وترجع له الناتج ..

ملف BankAccount وهو يمثل حساب العميل في البنك .. لاحظ أنه يطبق الأنترفيس Serializable.. وهكذا لجميع الكائنات في RMI يجب أن تكون مطبقه لهذا الأنترفيس والى فلن تستطيع ارسالها

ملف BankAccountInterface :

ملف BankAccountImpl :

ملف BankServer ولن يختلف عن السيرفر في المثال السابق :

ملف BankClient وسوف نقوم باستدعاء الدوال

لتشغيل الملفات ، أكتب هذه الأوامر في سطر الأوامر ، وقد تحتاج الى 3 نوافذ أحدها لـ registry والأخرى للخادم والثالثه للعميل :
javac *.java
rmic BankAccountImpl
registry
java BankServer
java BankClient

واستمتع بالنتائج  ..

في حال لاحظت المثالين السابقين ان جميع الملفات كانت في جهاز واحد ، طبعا الأمر غير مفيد بشكل كبير ، نحن نريد أن يكون كل من السيرفر والكلاينت يعمل في جهاز منفصل عن الأخر .. لذلك يجب أن نفصل ملفات السيرفر في جهاز وملفات الكلاينت في جهاز ..

لكن ما هي ملفات السيرفر -في المثال السابق- :
BankAccount.java
BankAccountImpl.java
BankAccountInterface.java
BankServer.java

وبعد الترجمه سوف يخرج لنا :
BankAccount.class
BankAccountInterface.class
BankAccountImpl.class
BankServer.class
BankAccountImpl_Stub.class

أما ملفات الكلاينت :
BankClient.java

ولن نستطيع ترجمه الكلاينت (الذي يعمل في جهاز منفصل ) والسبب أنه يحتوي على عمليه كاست من Object الى الكائن BankAccountInterface وهو لا يملكه ، أيضا كما ذكرنا أن الStub هو الذي يتعامل حقيقه مع السيرفر ونحن هنا لا نملك ملف BankAccountImpl_Stub.class .. لذلك يجب أن يتوفر للكلاينت هذين الملفين حتى يعمل …

السؤال الأن كيف يمكن أن نتقل ملفات class هذه الى الجهاز الثاني ؟
بالطبع يمكن أن تقوم بارسالها بشكل عادي ، أي تقوم بعمل نسخ ولصق لهذه الملفات في الكلاينت ، وهكذا كل شيء سيعمل بشكل سليم 100%،

لكن في حال كان الجهاز الثاني بعيد ، فلن نستطيع ذلك .. الحل هو تحميل هذه الكلاسات من مكان ما (web server ) وقت تشغيل العميل Loading Classes at Runtime .. أي أننا سنقوم بتحميل الملفات وقت تشغيل العميل ،

Dynamic code downloading 
أحد ميزات لغه جافا هي أنك تستطيع تحميل كود Byte Code (ملفات .class) من موقع URL وتنفذه في جهازك … مثلا عندما تقوم بفتح Applet فإن الـ JVM الموجوده في متصفح الأنترنت تقوم أولا بتحميل الByte Code من السيرفر الى جهازك ، ومن ثم تبدأ في تنفيذه ..

RMI قامت بتطيق نفس الفكره ، حيث تستطيع باستخدام RMI API (وليس JVM كما في الأبليت) بتحميل الكلاسات الموجوده في الجهاز البعيد ، وهنا نحن نريد تحميل ملف Stub الذي يجب أن يكون موجود لدى الكلاينت حتى يعمل بشكل صحيح ..

وتستطيع تحميل الكلاسات من الجهاز البعيد عن طريق تحديد الموقع في CodeBase .. هذه الcodebase يمكن أن نعتبرها مصدر للكود ، ويقوم العميل عندما يبدأ في العمل بالذهاب الى هذا المكان وتحميل الكود ويبدأ العمل بعدها . ويكمن التعامل مع codebase في الأبليت أو الApplication العادي .

حاليا نريد تحميل كلاس Stub (واي كلاسات ثانيه في حال أحتاج العميل لذلك ، مثلا القيمه الراجعه من السيرفر كائن غير معروف لدي الكلاينت) ، هنا سنقوم بتحديد موقع الكلاسات عندما نشغل السيرفر .. وعندما يتصل الكلاينت بالسيرفر سوف يبحث لديه في classPath ، فاذا لم يجد الكلاسات فسوف يذهب الى ذلك المكان ويقوم بتحميل الكلاسات التي يحتاجها ..

يقوم السيرفر بتحديد موقع الكلاسات عن طريق :

كود:
java.rmi.server.codebase=http://MyHost/MyFile/

نقوم بكتابتها وقت تشغيل السيرفر ، بالمعامل -D .. لا تنسى / في الأخر ..

الصور التاليه ، تشرح طريقه العمل بشكل مبسط وجيد …
codebase-1

هنا الصوره السابقه تشرح كيف يقوم الأبليت بتحميل ملفات الكلاسات التي يحتاجها ثم يقوم بتنفيذها .
codebase-2

هنا نوضح الصوره السابقه الكثير من الأمور ، تبدأ بتحديد الخادم موقع ملفات الكلاسات ، بعدها (الخطوه1) يقوم بتسجل اسم الكائن ، بعدها يقوم الكلاينت بأخذ الكائن الراجع بعد طلبه ، ويقوم بتحميل ملف Stub من المكان الذي حدده الخادم ويعود للكلاينت ومنه في الصوره القادمه) يقوم باستدعاء الداله البعيده ..
codebase-3

طبعا يمكن أن يرسل الكلاينت كائن غير معروف للسيرفر ، هنا في هذه الحاله سوف يضطر الكلاينت أن يحدد للسيرفر موقع الكلاس لهذا الكائن حتى يقوم بتحميله ، يعني أي جهه تحدد للأخرى موقع تحميل الكلاسات للكائنات التي لا تعرفها الجهه … الصوره التاليه توضح ذلك .

codebase-4
هناك مسأله بسيطه وهي أن الكلاينت (في Application ) لا يستطيع تحميل الكلاسات بشكل مباشر لأنها قد تحتوي على كود خبيث -هي من أعدادات اللغه الأفتراضيه- ، لذلك يجب أن تحدد له ذلك ، وهو موضوع RMI Security .

RMI Security
في حال كانت جميع الكلاسات متوفره في الجهازين ، فلن توجد مشكله لأننا لن نحمل أي كود من أي جهه .. لكن في حال أحتاج الكلاينت لكلاس من السيرفر غير موجود في الكلاينت ، سوف يرسل له السيرفر هذا الكلاس ولكن سوف يبدأ هذا الكائن بالعمل مباشره بدون تدخل منك فورا بعد عمليه Deserialization .. وبالطبع مثل هذا قد يمثل خطوره لذلك لغه جافا بالوضع الأفتراضي لها لا تسمح لك بهذا (ما عدا في الأبليت) .

المسؤول عن تحميل هذه الكلاسات هو SecureClassLoader ويجب أن نحدد لهذا الكائن حدود عمله restrictions موجوده في java.policy ، ويمكن أن نغير فيها عن طريق الأداه policytool .. أيضا هناك الكائن RMISecurityManager (وهو أبن لـ SecurityManager) ويمكن عن طريقه أن نتحكم بـ security policy . وهو الذي يسمح في الحقيقه للـ Applet بالعمل وتحميل الملفات، لذلك لكي نستطيع تحميل الكلاسات يجب أن نقوم بعمل كائن من RMISecurityManager .

اذا يمكننا أن نتحكم بـ security policy عن طريق الأداه policytool أو عن طريق العمل مع الكائن RMISecurityManager .. لكن العمل المباشر مع هذا الكائن لن يفيد كثيرا لأنه يعتمد على الأعدادات الأفتراضيه في security policy ، لذلك يمكن أن ننشيء Security Manager خاص بنا يسمح بكل شيء وهو عن طريق وراثه الكلاس RMISecurityManager واعاده تعريف الداله checkPermission ..

مثال :

الأن عندما يبدأ الكلاينت العمل يجب أن نحدد له ما يفعله عن طريق الداله setSecurityManager ونمرر له الكائن SecurityManager أو أي Subclass منه .

Fibonacci Computing 
المثال الأخير (شامل لكل المفاهيم ان شاء الله) وهو لسيرفر لديه داله تحسب رقم الحد الفلاني في سلسله Fibonacci الشهيره .. ونريد بأن يعمل على جهازين منفصلين ، وقد تمت تجربته بين نظام windows Server2003 و Windows Xp ..

الغرض من البرنامج هو أن يقوم العميل باستدعاء داله حساب Fibonacci في السيرفر ويمرر لها رقم ، وترجع هذه الداله الناتج ويطبع لدى الكلاينت .. نريد أن يكون الكلاينت مره Application ومره Applet ..

نبدأ من جهه الخادم :
سوف يكون لديه ثلاثه ملفات :
Fibonacci هو الأنترفيس
FibonacciImpl هو تطبيق لهذا الأنترفيس
FibonacciServer هو ملف السيرفر

ملف Fibonacci.java :

ملف FibonacciImpl.java :

ملف FibonacciServer.java :

نقوم في السيرفر بترجمه هذه الملفات :
javac *.java

ونقوم بتفح مترجم rmi :
rmic FibonacciImpl

الأن خرجت الملفات :
Fibonacci.class
FibonacciImpl.class
FibonacciServer.class
FibonacciImpl_Stub.class

نقوم الأن بنقل ملفات الـ Class التي سوف يقوم الكلاينت بتحميلها من هناك .. ننقلها في web-Server .. بعدها أحذف ملف FibonacciImpl_Stub.class من المجلد الحالي ، فقط دع هذا الملف في الويب سيرفر ، حتى عندما نشغل السيرفر يتصل بهذا الملف ..

ونشغل ملف registry :
rmiregistry

وأخيرا نشغل الخادم :
java – Djava.rmi.server.codebase=http://MySite/file/ FibonacciServer

الأن نبدأ العمل في الكلاينت :
سوف يكون لديه ثلاثه ملفات :
Fibonacci.java هو الأنترفيس
ZeroSecurityManager.java
FibonacciClient.java

ملف الأنترفيس هو نفسه الذي في السيرفر ويجب أن يكون هنا ، حتى يتم عمل Compiler للـFibonacciClient.java .
ملف ZeroSecurityManager.java عرضنا كوده في الأعلى ..

FibonacciClient.java :

الأن :
ترجم الملفات الثلاثه :
javac *.java

وشغل الكلاينت :
java FibonacciClient

وسترى المخرج أخييييرا على الشاشه  .

في حال أردنا العمل على Applet ، نكتب ملف AppletFibonacci.java ونضعه في السيرفر ، ونترجمه ، وننقل ملف الكلاس الى الويب سيرفر مع بقيه الكلاسات .. بالأضافه الى صفحه html يتصل من خلالها العميل ..

AppletFibonacci.java

HTML Page :

بعد ترجمه AppletFibonacci ضع ملف الكلاس في السيرفر هو وصفحه الـ HTML ، وسوف تتم العمليه بنجاح ..

الأن ترجم في السيرفر :
java FibonacciServer
لا داعى لوجود codebase لأن الأبليت سوف يحمل الملفات بنفسه ..

وفي الكلاينت أدخل على صفحه HTML الموجوده بالسيرفر من خلال متصفح الأنترنت
RMI5

الى هنا نكون أنهينا الموضوع وليس بشكل كامل ، فموضوع الـ security موضوع متداخل كثيرا وبه الكثير من الأمور الغامضه .. اضافه الى أن تحميل كود من الجهه الثانيه غير مضمون كثيرا ، فقد تحصل مشاكل مثلا قطع الأتصال أو مشكله في اعدادك للبرنامج ، لذلك اذا استطعت نقل الكلاسات يدويا فهذا أفضل بكثير ويخرجك من جميع هذه المتاهات .

المصادر :
Dynamic code downloading using RMI
Java Network Programming, 3rd Edition
Introduction to Network Programming in java
Core Java 2 , Part II

(1043)

وجدي عصام مهندس برمجيات مهتم بعلوم الحاسب وبالأخص مجال الخوارزميات وهندسة البرمجيات وحماية التطبيقات،

Comment(3)

  1. جميل جميل. نقل الكلاسات عبر الـ codebase، و CORBA-IIOP-IDL معلومات جديد بالنسبة لي. شكراً وجدي.

    لدي بعض الملاحظات هنا:

    1- ابتداءً من جافا 5، يمكن الاستغناء عن rmic كما هو مذكور في هذه الصفحة: http://docs.oracle.com/javase/tutorial/rmi/overview.html
    2- الـ port الافتراضي الذي يستخدمه الـ rmiregistry هو 1099، ومن الممكن تغييره.
    3- في المثال الأول، يمكن للكلاس HelloImpl يرث كلاس آخر غير UnicastRemoteObject، ولكن في هذه الحالة يجب أن يطبق Serializable ويتم تغيير كود السيرفر إلى:

    ;()Hello myObject = new HelloImpl
    ;(Hello stub = (Hello) UnicastRemoteObject.exportObject(myObject, 0
    ;”String objectName = “rmi://” + HOST + “/MyHello
    ;(Naming.rebind(objectName, myObject

    4- عند تشغيل الـ rmiregistry، يجب أن يكون تعريف جميع الـ interface موجود في الـ CLASSPATH الخاص بالـ rmiregistry’s session حتى تتجنب الخطأ ClassNotFoundException.
    5- يمكن تجاهل النقطة السابقة باستخدام embedded RMI registry، مثال:

    ;(Registry registry = LocateRegistry.createRegistry(1099
    ;(registry.rebind(name, obj

    6- استخدم JApplet بدلاً من Applet.
    7- بالنسبة لطرق التخاطب الثلاثة اللتي ذكرتها، ألا يعتبر الـ Rest من ضمنها؟

    مجهود رائع يا وجدي 🙂

LEAVE YOUR COMMENT

لن يتم نشر عنوان بريدك الإلكتروني. الحقول الإلزامية مشار إليها بـ *

مشاركة