جايگاه مصرف کنندگان و کارگزاران سرويس ها ی وب New Page 1



ساير




 

 

 

SAKHA RAVESH CO.

 ا مروز

 سه شنبه  8  فروردين  1396  2017  Mar.  28   Tuesday ToDay
صفحه اصلی  مقالات نکته هادايره المعارف خودآموزها | تازه ها خود آزمون ها    
  نسخه قابل چاپ  

    5 4 3 2 1 

 عنوان

 نويسنده

  مشاهده

 تعداد آراء

 امتياز

 معماری سرويس های وب ( بخش دوم )

 مديريت وب

14351

16

3

با توجه به جایگاه داده در عصر حاضر و  لزوم نگاه جامع به این مقوله مهم ، بر آن شدیم تا محوریت فعالیت های خود را بر  روی این موضوع متمرکز نمائیم . از این رو گروه فابک با شعار فناوری اطلاعات برای کسب وکار شکل گرفت و  خدمات خود  را از طریق  سایت www.fabak.ir  به مخاطبان محترم عرضه می نماید

 

معماری سرويس های وب

معماری سرويس های وب ( بخش دوم )
در بخش اول اين مقاله
، به مفاهيم اوليه در رابطه با معماری سرويس های وب اشاره و  پس از تبين جايگاه ارائه دهنده سرويس ، مصرف کننده سرويس و کارگزار سرويس در معماری فوق ، به تشريح نقش و وظايف ارائه دهنده  سرويس  پرداخته گرديد . در اين بخش به  بررسی نقش و جايگاه مصرف کنندگان و کارگزاران  سرويس ها ی وب ، خواهيم پرداخت .

مصرف کننده سرويس
در اين بخش با حداقل قابليت های موردنياز يک مصرف کننده سرويس وب بمنظور استفاده از يک سرويس وب ، نحوه يافتن يک سرويس وب توسط مصرف کننده سرويس وب ، نقش پروکسی ها در پياده سازی مصرف کنندگان سرويس وب ونحوه استفاده از پروکسی ها بمنظور فراخوانی غيرهمزمان سرويس های وب  ، آشنا خواهيم شد .

حداقل توانائی :  بمنظور استفاده از سرويس وب ، يک مصرف کننده سرويس وب ، می بايست متدهائی از سرويس وب را بهمراه پارامترهای مورد نياز و بکمک استفاده از پروتکل های موجود ( مثلا" SOAP ) و حمايت شده توسط سرويس مورد نظر را فراخوانی نمايد . فرمت دهی مناسب پيام ها  قبل از ارسال  برای يک سرويس وب ، آشنائی و برخورد مناسب با  جزئيات پروتکل هائی که سرويس وب حمايت می نمايد، از جمله مواردی می باشند که می تواند چالش هائی را در زمينه سرويس های وب بدنبال داشته باشد. فريمورک دات نت با ارائه  کلاس هائی در اين زمينه ، اکثر جزئيات سطح پائين را کپسوله می نمايد . کپسوله نمودن جزئيات سطح پائين ، ضرورت پياده سازی زيرساخت را از پياده کنندگان سلب و آنان را از اين فعاليت معاف می نمايد .

مکان يابی سرويس : قبل از امکان استفاده از يک سرويس وب ،مصرف کننده می بايست قادر به يافتن آن باشد . يکی از راهکارهای موجود در اين زمينه درج کد بصورت دستی ( برخوردی کاملا" ايستا )   در مصرف کننده سرويس وب و در هنگام طراحی است .در چنين مواردی آدرس سرويس ارائه شده بصورت مستقيم در برنامه مصرف کننده سرويس درج خواهد شد . يکی ديگر از راهکارهای موجود در اين زمينه ، امکان يافتن پويای يک سرويس وب توسط مصرف کننده سرويس وب  و در زمان اجراء است . بدين ترتيب ، مصرف کننده سرويس وب دارای انعطاف لازم در خصوص انتخاب بين سرويس های وب رقيب  با عملکرد مشابه و بر اساس ويژگی هائی خاص نظير قيمت و کارآئی ، خواهد بود . روش استاندارد برای يافتن سرويس های وب ، تشريح سرويس و خدمات ارائه شده توسط آنان ، استفاده از يک ريجستری  UDDI  است . ( Universal Description,Discovery, and Integration )

پروکسی ها : در زمان پياده سازی يک مصرف کننده سرويس وب ، پياده کنندگان می توانند زمان خود را صرف افزايش بهره وری نموده و خود را درگير موارد زير ننمايند .

  • فعاليت و در گير شدن در ارتباط  با پروتکل های زيربنائی

  • پارسينگ بايت ها بمنظور استخراج داده

  • بررسی صحت و اعتبار داده های ورودی ( دريافتی )

  • ايجاد و ساخت بسته های اطلاعاتی بمنظور خروجی


عليرغم توصيه های انجام شده ، اغلب پياده کنندگان بمنظور انجام عمليات فوق ، وقت خود را صرف انجام فعاليت های فوق می نمايند ، چراکه در اين رابطه کد از قبل ايجاد شده ای وجود ندارد. يکی از رويکردهای متداول در اين زمينه (هندل نمودن فعاليت ها ی فوق ) ، کپسوله سازی و يا پنهان نمودن جزئيات پياده سازی در کلاسی  است  که بعنوان يک پروکسی برای سرويس وب ، رفتار می نمايد . کلاس های پروکسی علاوه بر  پنهان سازی جزئيات پياده سازی ، يک مدل برنامه نويسی شناخته شده را بمنظور فراخوانی متدهای اشياء در اختيار پياده کنندگان قرار خواهند داد. تنها مسئله مرتبط با روش فوق ، پياده سازی يک کلاس پروکسی برای هر اينترفيس سرويس وبی خواهد بود که يک مصرف کننده سرويس وب از آن بمنظور ارتباط استفاده خواهد کرد . مايکروسافت در اين رابطه ابزاری با نام Wsdl.exe را ارائه که می توان از آن بمنظور پياده سازی کلاس های پروکسی سرويس وب استفاده نمود. باتوجه به اينکه، يک اينترفيس سرويس وب با استفاده از XML تعريف می گردد ، شايسته تر است که ابزارهائی را ايجاد که قادر به توليد اتوماتيک کلاس های پروکسی باشند .

فراخوانی غيرهمزمان : با توجه به اينکه  دستيابی به سرويس های وب عموما" از طريق شبکه ها ( نظير اينترنت )  که عمدتا" قابليت اطمينان و سرعت شبکه های محلی را ندارند ،ميسر می گردد ، شايد مناسبتر باشد که مصرف کنندگان سرويس  وب ، بگونه ای پياده سازی گردند که قادر به ايجاد فراخوانی غيرهمزمان به سرويس های وب باشند . پروکسی ها ئی که با استفاده از Wsdl.exe توليد و ايجاد می گردند ، اين امکان را به صدازنندگان  سرويس خواهند داد که فراخوانی غيرهمزمان به يک سرويس وب را داشته باشند. کلاس پروکسی با ترکيب RunTime ، مسئوليت برخورد با  جزئيات مديريت Thread pool ،  اتمام يک متد callback notification  و ساير موارد مرتبط را برعهده خواهند داشت .

نمونه هائی از مصرف کنندگان سرويس وب : برنامه های تجاری ( زمينه های متعدد تجاری ) اولين کاربران و متقاضيان سرويس های وب می باشند ولی تعداد زيادی فعاليت تجاری ديگر نيز وجود دارد که می توانند بعنوان مصرف کنندگان سرويس وب مطرح گردند . روزنامه های Online و  ASP :Application Service Provider  ،  دو نمونه در اين زمينه  می باشند . يک روزنامه Online ، ممکن است از جندين سرويس وب خبری بمنظور تامين اخبار نشريه خود استفاده نمايد . اخبار ورودی می توانند قالب بندی  و فيلتر شده و  برای آنان فهرست توصيفی تهيه و قابليت جستجو بر روی آنان با توجه به خواست مصرف کننده ايجاد گردد . يک ASP ممکن است سرويس های وب متعددی را ميزبان  و يا خود راسا" اقدام به توليد سرويس های وب مورد نياز و ارائه آنان به مشتريان مربوطه نمايد.

کارگزار سرويس وب
همانگونه که يک معماری مبتنی بر سرويس نيازمند يک کارگزار سرويس است ، يک معماری سرويس وب ، نيز نيازمند يک کارگزار سرويس خواهد بود. بمنظور تسهيل در ارتباط ، بنگاههای تجاری نيازمند يک راه حل جامع و فراگير بمنظور نشر اطلاعات خود به هر يک از مشتريان و يا شرکاء تجاری خود در سطح جهان می باشند .يک کارگزار سرويس وب ، هم با ارائه دهنده سرويس وب و هم با مصرف کننده سرويس وب ارتباط تا زمينه استفاده از امکانات ارائه شده توسط  ارائه دهندگان سرويس های وب و استفاده از سرويس های وب ارئه شده برای مصرف کنندگان سرويس های وب ، فراهم گردد. سازمان ها با نشر اطلاعات مرتبط  با سرويس ها و خدمات تجاری خود ، به پتانسيل های زير دست خواهند يافت :

  • امکان يافتن سريع همکاران تجاری از بين ميليون ها  بنگاه تجاری Online
  • تعريف نحوه مديريت فعاليت های تجاری پس از يافتن بنگاههای تجاری مورد نظر
  • ايجاد يک رويکرد گسترده صنعتی برای فعاليت های تجاری که  ارتباط و همبستگی سريع و آسان با مشتريان و شرکاء تجاری بر روی اينترنت را بدنبال خواهد داشت .در اين رابطه ، سازمانها قادر به ارائه اطلاعات مشترک در ارتباط با محصولات و خدمات خود بوده و امکان حق انتخاب در رابطه با گزينش نوع ارتباط با ساير فرآيندهای تجاری و سيستم ها نيز فراهم می گردد .

ارتباط بين کارگزار سرويس وب و ارائه دهنده سرويس وب : کارگزاران بمنظور ارائه صحيح سرويس های وب از ارائه دهندگان سرويس های وب درخواست اطلاعات متنوعی در رابطه با سرويس ارائه شده را خواهند داشت . اطلاعات اخذ شده بمنزله شناسنامه يک سرويس وب خواهد بود که پس از ارائه و تائيد و طی مراحل مربوطه در ريجستری UDDI ذخيره تا امکان در اختيار قرار دادن آنان برای مصرف کنند گان سرويس های وب فراهم گردد .کارگزاران سرويس های وب ، اطلاعات عمومی زير را در ارتباط با يک سرويس وب منتشر خواهند کرد :

  • اطلاعات طبقه بندی شده ای که امکان  گروه بندی سرويس وب را فراهم نمايد .

  • اطلاعات مورد نياز بمنظور ارتباط با  سرويس وب

  • شرح خدمات ارائه شده توسط سرويس های وب

  • لينک های مورد نياز بمنظور استفاده از ساير مستندات که شامل اطلاعاتی در رابطه با سرويس وب است .

  • آدرس ( مکان )  نهائی سرويس های وب . آدرس های  فوق ، عموما" بصورت URL)Uniform Resource Locators) بوده و مکان و موقعيت سرويس های وب اعلام  شده را مشخص می نمايند . با توجه به عدم توانائی ذخيره سازی تمامی اطلاعات بر روی رسانه های ذخيره سازی کارگزار سرويس وب ، از اشاره گرهائی  خاص در اين زمينه استفاده که باعث تسهيل در يافتن اطلاعات تکميلی و مورد نياز در ارتباط با سرويس وب خواهد بود. ماهيت برخی از اطلاعات مرتبط با يک سرويس وب نيز بگونه ای است که امکان استقرار آنان بر روی کارگزار وجود نداشته و می بايست از لينک های مورد نظر و معرفی شده توسط کارگزار بمنظور اخذ اطلاعات تکميلی استفاده گردد (اطلاعات مرتبط با ملزومات مورد نياز برای تائيد اعتبار) .

ارتباط بين کارگزار و مصرف کننده سرويس : اولين و در عين حال مهمترين نوع ارتباط بين مصرف کنندگان سرويس وب و کارگزار سرويس وب ، جستجو برای يافتن سرويس وب است . کارگزاران می بايست تسهيلات لازم در خصوص جستجوی سرويس های وب  را فراهم تا امکان يافتن آنان بسادگی و با سرعت مناسب برای مصرف کنندگان ، فراهم گردد .

ريجسترهای UDDI : کارگزاران ، بمنظور ارائه سرويس های وب از رويکردهای متعددی استفاده می شود . يکی از ساده ترين رويکردهای موجود در اين زمينه ، استفاده از يک روش خاص با توجه به هدف مورد نظر برای مبادله اطلاعات و الزام تمامی همکاران  تجاری برای تبعيت از آن است . در اين رويکرد ،عملا" به يک کارگزار نياز نخواهد بود . مثلا" برخی سازمانها از مبادله اطلاعات الکترونيکی ( EDI:Electronic Data Interchange )  استفاده و بسادگی مستندات EDI مورد نياز همکاران تجاری  را بر روی سايت سازمان خود قرار می دهند .در رابطه با رويکرد فوق ، می بايست به اين نکته ( مسئله) اشاره نمود که روش فوق ، مکانيزم مناسب و ساده ای  برای يافتن فعاليت های تجاری خارجی و سازگار با فعاليت تجاری سازمان مربوطه ، نخواهد بود .
يکی ديگر از رويکردهای موجود در اين زمينه ، الزام تمامی همکاران تجاری برای استقرار يک فايل خاص بمنظور تشريح سرويس وب بر روی سايت های خود می باشد . در ادامه جستجو کننده وب می تواند بصورت اتوماتيک به يک URL ريجستر شده، دستيابی و ايندکس مناسبی از هر يک از فايل های تشريح سرويس های وب که بر روی هر يک از سايت ها پيدا می نمايد ، ايجاد نمايد . يک کارگزار سرويس وب می تواند در ادامه يک Portal را ايجاد که امکان دستيابی به ايندکس هائی که جستجو کننده وب آنها را ايجاد نموده است ، فراهم گردد. اتکاء و وابستگی به جستجو کنندگان وب برای ارائه ايندکس های سرويس های وب دارای مسائل مشابهی با روش استاندارد موتورهای جستجو است  که ما امروزه با آن سروکار داريم . مشکل اساسی رويکرد فوق ، عدم وجود مکانيزم لازم بمنظور اطمينان از انسجام و يکنواختی در فرمت  تشريح سرويس و رديابی آسان و آگاهی از زمان مورد نظر دررابطه تغييرات اعمال شده است .  همانگونه که ممکن است يک موتور جستجوی وب تعداد زيادی لينک غير معتبر را برگرداند ، استفاده از روش فوق در ارتباط با سرويس های وب نيز ممکن است نتايج غير معتبری در ارتباط با  تشريح سرويس ها را ارائه نمايد.
رويکرد کارگزاری ، که در ارتباط با سرويس های وب انتخاب شده است ، مبتنی بر يک ريجستری توزيع شده از بنگاههای تجاری و تشريح سرويس های مربوطه آنان با فرمت XML است . راه حل ارائه شده بمنظور پياده سازی رويکرد فوق و برطرف نمودن مسئله يافتن سرويس های وب ،  UDDI ) Universal Description,Discovery, and Integration ) ناميده می شود .
UDDI ، مشخصه ای  برای اطلاعات مبتنی بر وب توزيع شده از سرويس های وب ريجستر شده است . با استفاده از  UDDI ،  بنگاه های تجاری قادر به ريجستر نمودن اطلاعات مرتبط با سرويس های خود بوده و بنگاه های تجاری متقاضی ، قادر به يافتن و استفاده از سرويس های وب خواهند بود . عنصر اساسی در  يک ريجستری  UDDI ، فايلی است که موجوديت يک بنگاه تجاری را بهمراه سرويس های وب مربوطه آن تشريح می نمايد . اطلاعات مورد نظر بمنظور ريجستر نمودن يک فعاليت تجاری از سه بخش اساسی تشکيل شده است : 

  • آدرس  بنگاه تجاری و  اطلاعات  لازم بمنظور ارتباط 

  • ليست طبقه بندی صنعتی  منطبق بر  استاندارد های موجود

  • اطلاعات فنی در رابطه با سرويس های وب عرضه شده توسط بنگاه تجاری . اطلاعات فوق ، شامل مرجع لازم به مشخصه های اينترفيس سرويس وب ، پتانسيل ها واشاره گرهائی به فايل های متعدد اطلاعاتی است.

مدل برنامه نويسی سرويس های وب
بمنظور پياده سازی و يا استفاده از يک سرويس وب ، لازم است با ويژگی های اساسی مدل برنامه نويسی سرويس های وب آشنا شويم .

پروتکل های وب : اولين ويژگی مدل برنامه نويسی سرويس های وب ، پروتکل ارتباطی است که معمولا"  HTTP خواهد بود. پروتکل HTTP ، بطور ذاتی مفهوم استفاده از يک متد را حمايت نمی نمايد . با توجه به محدوديت فوق ، مصرف کنندگان سرويس های وب اغلب از XML-Based SOAP ، بر روی HTTP برای فراخوانی ( صدا زدن ) متدهای سرويس های وب استفاده می نمايند . بنابراين ، لازم است پياده کنندگان  دارای دانش  مناسبی  در ارتباط با پروتکل  HTTP و SOAP باشند .

StateLess : اکثر پياده کنندگان با يک مدل شی Stateful آشنائی لازم را دارند. بعبارت ديگر ، نمونه ای از يک کلاس ايجاد و در ادامه عمليات متفاوتی بر روی شی انجام خواهدشد . بين هر فراخوانی متد ، شی وضعيت خود را نگهداری می نمايد . در يک محيط stateless ، شی وضعيت خود را بين فراخوانی ها ، نگهداری نمی نمايد. هر وضعيتی که می بايست بين فراخوانی ها نگهداری گردد ، در يک بانک اطلاعاتی و يا کوکی ذخيره می گردد . سرويس های وب اشيائی با رويکردهای سنتی نمی باشند. زمانيکه از  ASP.NET بمنظور پياده سازی يک سرويس وب استفاده می گردد ، می توان از يک کلاس سی شارپ بمنظور پياده سازی آن استفاده نمود. صفحات ASP.NET  برای مراجعه به کلاس فوق ، از يک فايل با انشعاب asmx . استفاده می نمايند. زمانيکه صفحه پردازش می گردد ، يک نمونه از کلاس ايجاد می گردد . مدت زمان حيات  صفحه asmx . ، به عمر شی نتيجه محدود و يک نمونه شی متفاوت ديگر ساير فراخوانی ها به متد را پاسخ خواهد داد بنابراين ، کلاس هائی که يک سرويس وب را پياده سازی می نمايند ، Stateless خواهند بود . با اينکه طراحی سيستم های Stateless در مرحله اول مشکل تر بنظر می آيد ولی همزمان با افزايش حجم عملياتی سيستم ، توان آنان در سرويس دهی افزايش خواهد يافت .

Loosely coupled .  در يک برنامه غير توزيع شده ، اگر هر يک از منابع نرم افزاری مورد نياز، نظير يک تابع کتابخانه ای در يک DLL)Dynamic Link Library) ، زمانيکه يک برنامه فعال می گردد در دسترس باشند ، امکان دستيابی به منابع فوق در مدت زمان حيات نرم افزار  ، ميسر خواهد بود . برای برنامه های توزيع شده ، خصوصا" برنامه های توزيع شده ای که از منابع نرم افزاری بر روی اينترنت استفاده می نمايند ،  ممکن است منابع نرم افزاری مورد نياز همواره در دسترس نباشند. برنامه های توزيع شده که با استفاده از سرويس های وب پياده سازی می گردند ، می بايست دارای انعطاف لازم و بمراتب بيشتری در ارتباط با منابع نرم افزاری غيرقابل دسترس حتی در زمان اجراء باشند . بنابراين ، راه حل های مبتنی بر سرويس های وب ، می بايست دارای پتانسيل لازم بمنظور پيکربندی مجدد و پويای خود  باشند (در موارديکه منبع مورد نياز دردسترس نمی باشد ) .

فرمت عمومی داده
فرمت عمومی داده  در سرويس های وب ، XML است  . در اين رابطه ذکر نکات زير ضروری است :

  • پروتکل SOAP  مبتنی بر XML است .

  • داده برگردانده شده از يک سرويس وب ، يک سند XML است .

  • سرويس های وب با استفاده از اسناد XML در يک ريجستری UDDI ريجستر می گردند .

  • برنامه های ASP.NET با استفاده از فايل های پيکربندی XML پيکربندی می گردند .



جستجو

مقالات                 
دايره المعارف       
دوره های آموزشی


 

 

مشاهده گروه ها



              

 

 تهيه شده در شرکت سخا روش -  1382