عناوين



 اخبار


برگزیده


امنيت


مقاله


گزارش و گفتگو


ياداشت


اخبار شرکتها


همايشها



فراخوانها و آئين نامه ها


عکس و ویدئو

 
  خدمات



نسخه موبایل



خروجی پیامک



خروجی RSS



عضویت در خبرنامه ها

 

راهنما
تبليغات


 

سفارش آگهی
مقاله




لینک ثابت || اضافه شده توسط آرش کریم بیگی|| نسخه قابل چاپ || بازگشت به صفحه اصلی || آرش کریم بیگی

برای عضویت در خبرنامه پیامکی ایستنا اینجا را کلیک کنید. برای عضوریت در خبرنامه روزانه ایمیلی ایستنا؛ نشانی پست الکترونیکی خود را در فرم زیر وارد نمایید. پس از آن به صورت خودکار ایمیلی به نشانی شما ارسال میشود، برای تکمیل عضویت خود و تایید صحت نشانی پست الکترونیک وارد شده، می بایست بر روی لینکی که در این ایمیل برایتان ارسال شده کلیک نمایید. پس از آن پیامی مبنی بر تکمیل عضویت شما در خبرنامه روزانه  ایمیلی ایستنا نمایش داده میشود.

سه شنبه، 11 مردادماه 1384

04:27 PM

August 02, 2005


مقدمه ای بر Dot NET Remoting

  سعید احمدلوئی
ماهنامه شبکه - تیر ۱۳۸۴ شماره 55

اشاره :

همان‌گونه كه می‌دانید وب‌سرویس‌ها امكانی جهت دسترسی به اشیاء و توابع از طریق شبكه را فراهم می‌كنند (در این زمینه می‌توانید به مقاله وب سرویس‌ها و XML در شماره 52 ماهنامه‌شبكه مراجعه نمایید.) وب سرویس‌ها سیستمی بسیار ساده دارند و از آن‌ها می‌توان به عنوان ابزاری جهت برقراری ارتباط بین سیستم‌های با Platformهای مختلف استفاده كرد، ولی با تمام قابلیت‌ها و امكاناتی كه وب‌سرویس‌ها دارند این تكنولوژی در برخی موارد به اندازه كافی انعطاف‌پذیر و سریع نیست و لذا پاسخگوی گروه خاصی از نیازها نیست. بزرگترین عاملی كه این محدودیت را ایجاد می‌كند نیاز وب سرویس‌ها به IIS و یا به عبارت دیگر ASP.NET runtime می‌باشد. جهت فائق‌آمدن به این مسایل می‌توان از Dot NET Remoting استفاده كرد. در واقع Dot NET Remoting هم دقیقاً همان سرویسی را فراهم می‌كند كه وب سرویس‌ها فراهم می‌كنند ولی دارای ویژگی‌های خاصی می‌باشد كه انعطاف و سرعت زیادی نسبت به وب سرویس‌های عادی فراهم می‌كند.




 



مقدمه‌
به‌طور كلی اگر ساختار یك وب سرویس، (منظور از وب سرویس در اینجا NET ASP . وب‌سرویس می‌باشد) را بررسی كنیم همواره دو جزء در ساختار آن وجود دارد: جزء اول همان كلاس‌هایی می‌باشد كه درست می‌كنید. به عبارت دیگر در داخل این كلاس‌ها منطق‌‌كاری وب‌سرویس و توابع عمومی و خصوصی وب سرویس قرار می‌گیرند و پس از كامپایل، این كلاس‌ها به یك dll تبدیل می‌شوند. جزء بعدی یك وب سرویس كه همواره موردنیاز می‌باشد برنامه‌ای است كه به یك پورت سیستم گوش می‌دهد و درخواست‌های كلاینت‌ها را می‌گیرد و به جزء اول می‌دهد و پس از پردازش پاسخ را گرفته و به كلاینت ارسال می‌كند. در تولید وب‌سرویس‌های عادی تقریباً تمام تمركز روی جزء‌ اول یعنی كلاس‌های آن است. جزء بعدی همان IIS است كه كافی است در برخی موارد تنظیمات خاصی روی آن انجام دهیم. با استفاده از NET Remoting. سیستم‌هایی جهت دسترسی از طریق شبكه فراهم خواهیم كرد كه در واقع دو بخش یك وب سرویس در آن‌ها هم وجود دارد، ولی این‌بار می‌توانیم ازIIS استفاده نكنیم و خودمان برنامه میزبان (منظور برنامه‌ای كه به شبكه گوش می‌دهد و تبادل اطلاعاتی بین كلاینت‌ها و كلاس‌های ما را فراهم می‌كند) را بنویسیم. با این توصیف در واقع می‌توان گفت كه ASP.NET Web Serviceها نوع ساده‌شده‌ای از سیستم‌هایی هستند كه توسط NET Remoting. می‌توان تولید كرد چرا كه در استفاده از ASP.NETWeb Serviceها مجبور به استفاده از IIS به عنوان برنامه میزبان هستیم.
قبل از این‌كه شروع به پیاده‌سازی یك نمونه كامل نماییم، با یك دید كلی اجزاء سیستم‌ پیاده‌سازی شده توسط NET Remoting را مورد بررسی قرار می‌دهیم.


برای مشاهده تصویر در اندازه واقعی
روی آن كلیك كنید


كلاس‌ها
در سمت سرور، remote object همان كلاس‌هایی می‌باشند كه منطق اصلی كاری را تشكیل می‌دهند. این كلاس‌ها به صورت یك dll روی سرور قرار می‌گیرند و توابع public این كلاس‌ها هستند كه در نهایت از طریق كلاینت‌‌ها فراخوانی شده و مورد استفاده قرار می‌گیرند. Formatter كلاسی است كه پاسخ‌های سرور (مقادیر ارسالی از remote object) را كه به صورت یك سری اشیاء می‌باشند را گرفته و با كدبندی خاصی به یك سری از بایت‌ها تبدیل می‌كند كه مناسب جهت ارسال از طریق شبكه می‌باشد. همچنین درخواست‌هایی را هم كه كلاینت ارسال می‌كند از كدبندی خاص آن خارج كرده و تبدیل به یك شیء می‌كند كه قابل‌فهم برای remote object می‌باشد. سمت كلاینت نیزformatter دقیقاً همین كار را انجام می‌دهد ولی جهت عكس. به عملیات تبدیل یك شیء به فرمتی قابل‌ارسال و یا نگهداری كه توسط Formatter انجام می‌شود Serialize و به عكس این عمل Deserialize می‌گویند. Channel های سمت كلاینت و سرور پروتكل ارتباطی بین كلاینت و سرور و تنظیمات مربوط به آن را تعیین می‌كنند. این‌ها در واقع همان برنامه میزبان هستند كه در سمت سرور در حالت Listening قرار دارد و در سمت كلاینت به صورت كلاینت می‌باشند. اما كلاس Proxy كه فقط در سمت كلاینت وجود دارد كلاسی است كه دقیقاً مانند كلاس‌های داخل remote object می‌باشد. كلاینت قادر به فراخوانی توابع remote object به صورت مستقیم و بی‌واسطه نیست چرا كه remote object روی سیستم دیگری در شبكه قرار دارد و لذا كلاسی تحت عنوان كلی Proxy با همان توابع Public كه remote object  فراهم می‌كند در سمت كلاینت ایجاد می‌شود كه از دید كلاینت همانند سایر كلاس‌های عادی می‌باشد؛ ولی وقتی كلاینت تابعی از این كلاس‌ را فراخوانی می‌كند این تابع یك پیام جهت فراخوانی تابع مشابه خود درremote object ایجاد كرده و ارسال می‌كند و پس از دریافت پاسخ، نتیجه را در اختیار كلاینت قرار می‌دهد.
توجه داشته باشید كه تمام این كلاس‌ها به طور كامل در اختیار شما می‌باشند و شما می‌توانید هر تغییر منطقی موردنیاز را در هر كدام از این كلاس‌ها اعمال كنید و این همان انعطاف‌پذیری كاملی می‌باشد كه NET Remoting . در اختیار شما قرار می‌دهد. البته تولید تمام این كلاس‌ها احتمالاً برای برخی زیاد هم خوشایند نخواهد بود. چرا كه قطعاً زمان زیادی صرف تولید و اشكال‌زدایی آن‌ها می‌شود. جهت رفع این مشكل می‌توانید از NET. كمك بگیرید چرا كه اگر نیازی به قابلیت‌های خاص در این سا ختار ندارید.  دات‌نت تمام این كلاس‌ها را با رفتار عادی آن‌ها برای شما تولید می‌كند؛ مگر دو كلاس كه می‌بایستی شما آن‌ها را تولید كنید. همان‌طور كه حدس زدید یكی كلاس remote object  می‌باشد كه رفتار اصلی سیستم شما و قابلیت‌هایی كه می‌خواهید ارایه دهید در این كلاس قرار دارد و دیگری برنامه یا كلاس میزبان می‌باشد كه قسمت channel را فراهم می‌كند.
در بیشتر موارد هدف استفاده از NET Remoting . بی‌نیاز شدن از IIS یا ASP.NET Runtime می‌باشد. در ادامه مثال كاملی كه در آن به جای IIS از یك برنامه console استفاده می‌شود را بررسی می‌كنیم. به‌عبارت دیگر برنامه میزبان یك console Application می‌باشد. در مثال ارایه شده برنامه كلاینت و سرور به صورت console می‌باشند تا ضمن حفظ سادگی، رفتار دقیق كلاینت و سرور قابل مشاهده باشد. بدیهی است در صورت تمایل می‌توانید با انجام چند تغییر جزیی آن‌ها را به برنامه‌های windows form تبدیل كنید. در ادامه راهنمایی‌هایی هم جهت این تبدیل آورده شده است. (كدهای آماده مثال را می‌توانید از سایت ماهنامه شبكه دانلود كنید).


یك مثال
به مثال زیر توجه كنید. همان‌طور كه اشاره شد Remote Object كلاس یا كلاس‌هایی است كه منطق اصلی موردنظر سیستم در آن قرار دارد. در این‌جا یك كتابخانه ساده (dll) یا یك تابع عمومی را به عنوان remote object  پیاده‌سازی می‌كنیم.
همان‌طور كه ملاحظه می‌كنید از توابع console استفاده شده تا پیام‌های مناسبی هنگام فراخوانی سازنده كلاس و یا تابع Hello در خروجی command Prompt چاپ شود. برای تولید این remote object می‌توانید یك پروژه از نوع classlibrary درNET. ایجاد كرده و كد مربوط را در كلاسی كه به صورت پیش‌فرضNET . در پروژه ایجاد می‌كند بنویسید و یا می‌توانید كد را در یك فایل متنی ساده تایپ كنید و با پسوند.cs  ذخیره كنید و با استفاده از دستور زیر آن را كامپایل كنید: .Csc/t:library/out:My Remote object
dll My Remote object.cs 
   توجه داشته باشید كه remote object از این كلاس ارث‌بری كند (كلاس Marshal By Refobject  قابلیت‌های خاصی به كلاسی كه از او ارث‌بری كند می‌دهد تا آن كلاس جهت ارایه سرویس‌های ماندگار در حافظه (lifetime) بهینه شود).






using System;
using System.Runtime.Remoting;


namespace Client
{
class Client
{
static void Main(string[] args)
{
   RemotingConfiguration.Configure("Client.exe.config");
   MyRemoteObject.MyRemoteObject obj=new
                             MyRemoteObject.MyRemoteObject();
   Console.WriteLine(obj.Hello());
   Console.ReadLine();
}
}
}



Remote Server

قسمت بعدی پیاده‌سازی remote server و به عبارت دیگر، برنامه میزبان می‌باشد، برنامه میزبان و remote object را می‌توانید در یك فایل یا اسمبلی پیاده‌سازی كنید، ولی استفاده از دو فایل متفاوت قابلیت استفاده مجدد
(reuse ability) سیستم را بالا می‌برد.
وظیفه برنامه میزبان، درست كردن یك كانال ارتباطی و گوش دادن به یك پورت سیستم می‌باشد تا به این وسیله درخواست‌های كلاینت‌ها را گرفته و به remote object بدهد. كانال ارتباطی remote server یا برنامه میزبان را می‌توان با استفاده از فایل پیكربندی و یا با استفاده از برنامه‌نویسی تنظیم نمود كه هر كدام معایب و مزایای خاصی دارد. وقتی كه از فایل پیكربندی (configuration file) استفاده می‌شود، كدنویسی لازم در برنامه میزبان به حداقل می‌رسد و همچنین جهت تعویض تنظیمات كانال (به عنوان مثال شماره پورت، یا پروتكل و یا ...) نیازی به دستكاری كدبرنامه و كامپایل مجدد آن ندارید، بلكه فقط كافی‌است تنظیمات موردنظر را در فایل پیكربندی انجام دهید. فایل پیكربندی فایلی است با فرمت XML كه اطلاعات كانال را در آن قرار می‌دهند. برنامه میزبان هنگام اجرا، اطلاعات فایل پیكربندی را خوانده و با توجه به تنظیماتی كه در آن ثبت شده، كانال ارتباطی را ایجاد می‌كند، البته در صورتی كه از فایل پیكربندی استفاده نكنید نیز مزیت خاصی خواهید داشت و آن تغییر دادن تنظیمات كانال در زمان اجرا توسط برنامه می‌باشد. در این‌جا جهت تولید برنامه میزبان از فایل پیكربندی استفاده خواهیم كرد.
اسم فایل پیكربندی را همنام با فایل اجرایی برنامه میزبان بگذارید با پسوند config. در این صورت نام فایل Simpleserver.config خواهد شد. كدهای داخل این فایل به صورت زیر می‌باشند.





<configuration>
<system.runtime.remoting>
<application name="Client">
<client url="tcp://localhost:9000/Server">
<wellknown
type="MyRemoteObject.MyRemoteObject, MyRemoteObject"
url="tcp://localhost:9000/MyRemoteObject"/>
</client>
<channels>
<channel ref="tcp client" />
</channels>
</application>
</system.runtime.remoting>
</configuration>


همان‌طور كه ملاحظه می‌كنید اطلاعات كانال و remote object در داخل عنصرsystem.runtime.remoting  قرار دارد. عنصر application در فیلد name ، نام سرور را مشخص می‌كند و در داخل عنصر service  مشخصات remote object قرار دارد دو فیلد wellknown و mode مربوط به دسته‌بندی remote objectها می‌باشد كه در ادامه دسته‌بندی و انواع مختلف remote objectها را توضیح خواهم داد. فعلاً  این دو فیلد را همین‌گونه بپذیرید. در فیلد type مشخص می‌شود كه این سرویس مربوط به كدام remote object می‌باشد. در این فیلد به زیرساخت NET Remoting. گفته می‌شود كه در كدام اسمبلی و در چه كلاس و namespaceای در آن اسمبلی remote object قرار دارد. اگر به فایل توجه كنید، مقدار رشته‌ای فیلد type با كاما (,) دو قسمت شده است قسمت اول namespace و كلاس مربوط به remote object را مشخص می‌كند و قسمت دوم نام اسمبلی مربوط به remote object را.
(درNET. كدهای نوشته شده در بسته‌های خاصی به نام assembly بسته‌بندی می‌شوند. هر اسمبلی دستوراتی به زبان IL و یك سری metadata دارد كه NET runtime. با استفاده از این اطلاعات آن را اجرا می‌كند. توجه داشته باشید كه یك اسمبلی می‌تواند در چند فایل باشد و یا برعكس چند اسمبلی در یك فایل. در اینجا اسمبلی remote object ما در در داخل یك فایل همنام با اسمبلی آن قرار دارد.) در فیلد Object Url آدرسی را مشخص می‌كنیم كه قرار است كلاینت‌ها جهت دسترسی به remote object این آدرس را بدهند. بعداً در فایل پیكربندی برنامه كلاینت خواهید دید كه فیلدی با نام Url وجود دارد كه آدرس remote object را در آن خواهیم نوشت. در این آدرس پس از مشخص كردن پروتكل و IP آدرس كامپیوتری كه برنامه میزبان در آن قرار  دارد، مقداری كه به فیلد Object Url داده‌ایم را در آن قرار خواهیم داد. فیلد Object Url می‌تواند یك URL كامل باشد بدین صورت كه remote object در روی سیستم دیگری در وب قرار دارد و یا حتی remote object خود یك وب سرویس می‌باشد. در اینجا به این فیلد فقط نام اسمبلی remote object را می‌دهیم و كلاینت هم در فایل پیكربندی خود در فیلد Url از همین نام استفاده خواهد كرد.
اگر دقت كرده باشید، متوجه شده‌اید كه مشخصات remote object در داخل عنصر قرار گرفته است. در واقع جالب است بدانید كه در داخل عنصر<>service به هر تعداد remote object و یا به عبارت دیگر سرویس كه بخواهیم می‌توانیم معرفی كنیم؛ به شرط این‌كه به هر كدام از آن‌ها كانال خاصی اختصاص دهیم و به‌طور كلی از عهده مدیریت چنین سیستمی برآییم. در چنین حالتی یك برنامه میزبان درخواست‌های استفاده از چندین remote object را گرفته و handel می‌كند.
عنصر channels تنظیمات مربوط به كانال یا كانال‌های ارتباطی را در خود دارد. در اینجا فقط از یك كانال استفاده خواهیم كرد و به جای ایجاد كانال جدید، از كانال‌های تعریف‌شده در Machine.config استفاده می‌كنیم. جهت این‌كار از فیلد channel ref و سپس ازid كانال تعریف شده در machine.config استفاده می‌كنیم. فیلد port هم شماره پورتی كه برنامه میزبان به آن گوش خواهد داد را مشخص می‌كند. فایل machine.config فایل XMLای است كه تنظیمات ویژه‌ای در سطح سیستم در آن قرار دارد، از جمله كانال‌هایی كه به صورت پیش‌فرض در آن تعریف شده‌اند این فایل در مسیر Microsoft.NET Frameuork CONFIG درSystem Root  قرار دارد.
 با دیدن قسمتی كه در آن كانال tcp client تعریف شده است، متوجه می‌شوید كه تعریف كانال جدید در فایل پیكربندی برنامه میزبان كار چندان دشواری نیست. ضمناً علاوه براین كانال پنج كانال دیگر نیز در این فایل تعریف شده‌اند كه از كانال tcp client در پیاده‌سازی برنامه كلاینت استفاده خواهیم كرد. با وجود فایل پیكربندی، تمام كاری كه برنامه میزبان باید انجام دهد، خواندن محتویات فایل پیكربندی و ایجاد كانال و قرار دادن آن در حالت listining جهت دریافت درخواست‌های كلاینت‌ها می‌باشد. برای انجام تمام این كارها كافی‌است یك تابع static كه در كلاس Remoting Configuration قرار دارد را فراخوانی كنیم و نام فایل پیكربندی را به عنوان آرگومان به آن بدهیم.
برنامه میزبان را به هر صورتی كه بخواهید می‌توانید پیاده‌سازی كنید. در اینجا برنامه Console پیاده‌سازی می‌كنیم. در صورت تمایل می‌توانید یك برنامه windows Form ساده بنویسید كه همین كار را انجام دهد. نكته‌ای كه در هر حال باید به خاطر داشته باشید این  است كه تا وقتی برنامه میزبان در حال اجراست و به كانال گوش می‌دهد، كلاینت‌ها می‌توانند از remote object استفاده كنند و به محض این‌كه برنامه میزبان از حالت اجرا خارج شود، امكان دسترسی به remote object توسط كلاینت‌ها وجود نخواهد داشت. این موضوع موجب می‌شود كه انتخاب برنامه میزبان از نوع برنامه‌های سرویس (windows service) كه همیشه در حال اجرا هستند، مناسب باشد. با این وجود در این‌جا برای سادگی از یك برنامه console استفاده خواهیم كرد كه تا زمانی كه كاربر كلید Enter را نزند، برنامه در حالت اجرا باقی خواهد ماند و خواست ما تأمین می‌شود. كد برنامه میزبان به دو صورت زیر می‌باشد:





//MyRemoteObject.cs

using System;
namespace MyRemoteObject
{
public class MyRemoteObject : System.MarshalByRefObject
{
public MyRemoteObject()
{
Console.WriteLine("Constructor called");
}

public string Hello()
{
Console.WriteLine("Hello called");
return "Hello, .NET Client!";
}
}
}



همان‌طور كه ملاحظه می‌كنید، این برنامه فقط شامل یك فراخوانی ساده تابع configure می‌باشد كه نام فایل پیكربندی به عنوان آرگومان به آن داده شده است. تابع ()Readline تا زمانی كه كاربر كلید Enter را نزده است، منتظر می‌ماند. از این رو برنامه هم در حال اجرا باقی خواهد ماند. پس از كامپایل و درست كردن فایل exe برنامه میزبان توجه داشته باشید كه لازم است فایل پیكربندی و dll. مربوط به remote object را كه قبلاً ساخته بودید، به مسیری كه برنامه میزبان در آن قرار دارد كپی كنید.



Client Program
برنامه كلاینت قرار است از remote object تولید شده در قسمت قبل استفاده كند. این برنامه هم مانند سرور از یك فایل پیكربندی و یك فایل exe. تشكیل شده است. نام فایل پیكربندی برنامه كلاینت را هم به صورت قبل با اضافه كردن config. به نام فایل exe آن بسازید. این فایل url مربوط به remote object پروتكل و شماره پورت و نام سیستمی را كه remote object روی آن قرار دارد مشخص می‌كند. این فایل به صورت زیر می‌باشد:





//SimpleServer.cs

using System;
using System.Runtime.Remoting;

namespace Server
{
class SimpleServer
{
            static void Main(string[] args)
      {
RemotingConfiguration.Configure("SimpleServer.exe.config");
Console.WriteLine("Press return to exit");
Console.ReadLine();
      }
}
}


 


اطلاعات موجود در این فایل مشخص هستند. فقط در مورد channel توجه كنید كه این‌بار از tcp client تعریف شده در machine config استفاده شده است. همانند برنامه سرور در كلاینت هم با استفاده از تابع configure فایل پیكربندی خوانده شده و تنظیمات لازم انجام می‌گیرد و در خط بعد یك object از كلاس remote object تعریف شده و تابع ()Hello آن فراخوانی می‌شود. برای تولید برنامه كلاینت هم مانند قبل می‌توانید از .NET استفاده كرده و در صورت تمایل یك برنامه windows form  بنویسید و یا در یك فایل متنی ساده كد لازم را بنویسید و از كامپایلر#C  برای تولید exe. آن استفاده كنید. توجه داشته باشید كه برنامه كلاینت لازم استreference ای به remote object داشته باشد. برای این‌كار اگر از NET. استفاده می‌كنید، با كلیك راست درsolution explorer و انتخاب Add reference ، می‌توانید reference را اضافه كنید و اگر از كامپایل خط فرمان #C استفاده می‌كنید، دستور كامپایل فایل به صورت زیر خواهد بود:
Csc/target:exe/reference My RemoteObjcet.dll
 Simple Client.cs 
سؤال مهمی كه در این‌جا پیش می‌آید این است كه آیا چنانچه بعد از نصب سیستم (كلاینت‌ها و سرور و remote) object بخواهیم تغییر خاصی در منطق كاری remote object (و نه در رابط كاربری آن یعنی توابع عمومی كه توسط كلاینت‌ها استفاده می‌شوند) بدهیم، آیا لازم است نسخه جدید remote object را به تمام سیستم‌هایی كه برنامه كلاینت در آن نصب شده انتقال دهیم؟ بدیهی است كه این‌كار لازم نیست؛ چرا كه اگر این‌گونه باشد، استفاده از
NET remoting. معنی و مفهوم خود را از دست می‌دهد. لازم است در هنگام تولید برنامه كلاینت referenceای به remote object در آن ایجاد كنید و برنامه كلاینت را بنویسید. هنگام نصب برنامه كلاینت، remote object  هم با آن روی سیستم نصب خواهد شد، ولی در ادامه چنانچه نیاز به ارتقاء remote object داشته باشید، كافی ‌است remote object جدید را روی سرور نصب كنید. كلاینت‌ها به صورت اتوماتیك از remote object جدید استفاده خواهند كرد كد برنامه كلاینت به صورت زیر می‌باشد:




<configuration>
<system.runtime.remoting>
<application name="SimpleServer">
<service>
<wellknown
mode="SingleCall"
type="MyRemoteObject.MyRemoteObject, MyRemoteObject"
objectUri="MyRemoteObject"/>
</service>
<channels>
<channel ref="tcp server" port="9000" />
</channels>
</application>
</system.runtime.remoting>
</configuration>



پس از ساختن فایل exe. برنامه كلاینت سیستم آماده تست می‌باشد. برای تست ابتدا برنامه سرور را اجرا كنید تا كانال سمت سرور را ساخته و در حالت listening قرار دهد. سپس كلاینت را اجرا كنید. اگر همه چیز تا اینجا درست باشد، سیستم كلاینت مقدار بازگشتی از تابع Hello مربوط به remote object را چاپ خواهد كرد. ضمناً در سمت سرور نیز فراخوانی انجام شده و تابع Hello در پنجره مربوط به سرور اعلان خواهد شد.
در این‌جا لیست كامل فایل‌هایی را كه برای این سیستم درست كردیم می‌توانید ببینید. 
























توضیحات


Assembly


Source file 


Class


كلاس مربوط به Remote object كه تابع Hello () در آن می‌باشد.


My Remote
Object.dll 


  My Remote Object.cs


My Remote object


برنامه میزبان كه كانال ارتباطی سرور را با استفاده از اطلاعات موجود در فایل پیكربندی ایجاد می‌كند.


 Simple
Server.exe


 Simple Server.cs


Simple Server


برنامه كلاینت كه از سرویس استفاده می‌كند. این برنامه اطلاعات لازم را از فایل پیكربندی client.exe.confing  گرفته و به سرور وصل می‌شود.


Simple Chient.exe


Simple Chient.cs

SimpleChient

 همان‌طور كه قبلاً اشاره شد، remote objectها دارای دسته‌بندی خاصی می‌باشند كه در این قسمت به صورت مختصر آن‌ها را توضیح می‌دهیم. به ‌طور كلی remote objectها به دو دسته كلی well-known و client-activated تقسیم می‌شوند. نوع well-known خود در دو حالت می‌تواند مورد استفاده قرار گیرد:
Singleton و.SingleCall (مثالی كه توضیح داده شد، از نوع well-known و دسته singlecall بود.) نوع well-known همان‌طور كه از نامش هم پیداست، اشیایی شناخته شده هستند كه با Url شان آدرس‌دهی می‌شوند remote objectهای وwellknown (Single Singleton) Call  و به صورت Stateless هستند؛ یعنی هربار كه كلاینت تابعی از remote object را فراخوانی می‌كند، هیچ‌گونه سابقه‌ای از این فراخوانی نگهداری نمی‌شود و در فراخوانی بعدی نمی‌توانید هیچ‌گونه استنادی به فراخوانی‌های قبلی بكنید. تفاوت Singleton و Single Call نیز در این است كه در حالت Single Call شی remote object در فراخوانی هر تابع ساخته می‌شود و پس از فراخوانی از بین می‌رود تا فراخوانی تابع بعدی، ولی در حالت Singleton فقط یك Object ایجاد می‌شود و تمام فراخوانی‌ها از طریق آن object صورت می‌پذیرند. لذا می‌توان از این حالت جهت اطلاع‌رسانی عمومی به تمام كلاینت‌ها استفاده كرد. جهت درك نوع singleton ، می‌توانید نوع Singleton را مانند متدها یا propertyهای static در كلاس تصور كنید كه بین تمام اشیای آن كلاس به اشتراك گذاشته می‌شوند. البته این مطلب فقط جهت درك singleton می‌باشد و هیچ‌گونه ارتباطی بین این دو مقوله وجود ندارد. تفاوت عمده remote objectهای clientactivated عمده با نوع قبلی در این است كه به صورت statefull هستند و می‌توانید به سابقه فراخوانی‌های قبلی استناد كنید. البته در استفاده از آن‌ها همیشه به خاطر داشته باشید كه مقداردهی به یك property ، نیازمند یك ارتباط شبكه‌ای با remote object می‌باشد. لذا جهت دستیابی به كارایی قابل قبول، سعی كنید همیشه با حداقل فراخوانی‌های متدها وproperty های remote object  به هدف خود برسید. اشیا Client activated توسط Url  شناسایی نمی‌شوند، بلكه NET Runtime. هنگام درخواست كلاینت باتوجه به نوع كلاس درخواستی شی‌ موردنظر را تشخیص داده و یك instance از آن می‌سازد.
تعیین نوع remote object و مد آن در فایل پیكربندی انجام می‌شود و كلیت كاركرد و سیستم NET Remoting.  برای تمام این انواع به همان صورت می‌باشد كه توضیح داده شد. لذا در مورد انواع مختلف remote objcetها نگران نباشید. بدیهی است سیستم NET Remoting. بسیار فراتر از آن است كه در یك مقاله به تشریح تمام جوانب آن پرداخت. با این وجود در این مقاله تا حد امكان مفاهیم به صورت ساده ارایه شدند و اكنون می‌توانید سرویس‌های ساده مبتنی بر NET Remoting. را پیاده‌سازی كنید.


 


منابع:
         1-MSDN  
         2- Wrox Press) C Web Service)
     


فهرست آخرین عناوین

 
    تبليغات  
 







 
  سفارش آگهی