معماري سرويس گرا (SOA) روشي جديد و در حال تكامل براي ساخت برنامه هاي توزيع شده با Distributed Applicationاست. سرويس ها اجزاي توزيع شده با رابط هاي تعريف شده و مشخص هستند كه پيغام هاي XMIL را پردازش وتبادل مي كنند. با رويكرد سرويس گرا مي توان راه حل هاي را ارائه داد كه به مرز دامنه هاي سازمان، شركت يا دپارتمان محدود نيستند. با استفاده از SOA مي توان در شركتي كه داراي سيستم ها و برنامه هاي كاربردي مختلف روي پلتفرم هاي متفاوت است، يك راه حل يك پارچه سازي با استقلال زياد(loosly coupled) ساخت كه جريان يكنواخت و ناهماهنگ كار را تضمين كند.
هر كس كه از سايت هاي تجارت الكترونيكي به صورت آنلاين خريد كرده باشد، با مفهوم سرويس ها آشنا است. وقتي كه سفارش تا ن را داديد، بايد اطلاعات كارت اعتباري تان را ارايه كنيد كه به طور معمول توسط يك فراهم كننده سرويس ثانويه، تاييد و شارژ مي شود. وقتي كه سفارش پذيرفته شد، شركت سفارش گيرنده با يك شركت فراهم كننده سرويس حمل ونقل فراهم مي كند و در نهايت كالاي شما تحويلتان مي شود. نياز به معماري سرويس گرا از جنبه اي ديگر نيز به نحوه بارزي در برنامه هاي كاربرديeCommerce مشهود است. اگر مثلا جزء(componet) مربوط به پرداخت با كارت اعتباري offline و يا غير فعال باشد،‌قرار نيست كه فرايند فروش متوقف شود. بلكه سفارش ها بايستي پذيرفته شوند وعمليات پرداخت به وقت ديگري موكول شود.
مثل ساير معماري هاي توزيع شده،‌ SOA ساخت برنامه هاي كاربردي با استفاده اجزايي كه در domainهاي جدا از هم را قرار دارند را ممكن مي سازد . SOA از سرويس هاي وب به عنوان نقاط ورود برنامه كاربردي استفاده مي كند كه از لحاظ مفهومي معادل همان اجزاي proxy و stub در سيستم هاي توزيع شده سنتي مبتني بر اجزاء هستند . با اين تفاوت كه در اين جا ارتباط بين سرويس وب و استفاده كننده خيلي آزاداترانه ومستقل تر (loosely coupled) است .به علاوه SOA به خاطر در بر داشتن فاكتورهايي كه اهميت حياتي در تجارت دارند ، نيز منحصر به فرد است . فاكتورهايي نظير: قابليت اطمينان سرويس،‌ جامعيت پيام ، يكساني تراكنش و امنيت پيام . در امور تجاري واقعي نمي توان روي سرويس هايي كه يك درخواست را فقط به خاطر اين كه بتوانند بفهمند،‌ پردازش مي كنند حساب كرد . در امور تجاري به قطعيت و اطمينان بيشتري نياز است. واضح است كه سيستم هاي مختلف ممكن است بعضي اوقات غير فعال باشند و يا پاسخگويي آن ها در دفعات مختلف متفاوت باشد . با وجود اين هيچكدام از اين موارد نبايد براي كنار گذاشتن ياعدم پاسخ به يك درخواست باشند.
علاوه بر آن نبايد دليلي براي كنار گذاشتن يا عدم پاسخ به يك درخواست باشند واضح است كه سيستم هاي مختلف ممكن است بعضي اوقات غير فعال باشند و يا پاسخگويي آن ها در دفعات مختلف ، متفاوت باشد. با وجود اين ،‌هيچ كدام ازاين موارد نبايد دليلي براي كنار گذاشتن يا عدم پاسخ به يك درخواست باشند. علاوه بر آن نبايد هيچ ابهامي در نحوه فراخواني يك سرويس وجود داشه باشد. اگر سيستمي توانايي هاي خود را در قالب سرويسي روي وب ارائه كند. در آن صورت نحوه فراخواني آن سرويس بايد به طور واضح مستند سازي و اعلام شود . بسياري از مسائل دسترس پذيري و مقياس پذيري برنامه هاي كاربردي امروزي در SOA حل شده است كه احتمال نقض آن در هر مر حله اي از جريان كار بسيار زياد است.در SOA فرض بر اين است كه خطا وجود دارد و مي تواند بيفتد ، بنابراين استراتژي هايي براي مثال اگر يك سرويس نتواند يك پيغام را در مرحله اول بپذيرد . اين معماري طوري طراحي شده است كه مجددا پيام را بفرستد . واگر يك سرويس به طور كامل قابل دسترس نباشد، (كه هرگز نبايد در يك سيستم SOA پايدار انفاق بيفتد ) آن وقت معماري طوري طراحي شده است كه روي دادن خطاهايي كه ممنجر به قطع كامل در خواست سرويس مي شود،‌امكان پذير نباشد. SOA قابليت اطمينان را افزايش مي دهد، چون خطاهاي موقت در بخشي از جريان كار نمي توانند كل فرايند تجاري را از كار بياندازند .
به بيان كلي،‌ SOA فرايندي تكامل يافته را ارائه مي نمايد و ازاين نظر مي تواند ان را بلوغ سريس هاي وب و تكنولوژي هاي يكپارچه سازي به حساب آورد . در SOA به اين امر توجه شده است كه سيستم هاي با اهميت حياتي كه بر مبناي تكنولوژي هاي توزيع شده ساخته مي شوند. بايد تضمين هاي خاصي را تامين نمايند . در اين گونه سيستم ها بايد اين اطمينان وجود داشته باشد كه در خواست هاي سرويس به طور صحيح مسير دهي و هدايت مي شوند، در زمان مناسب به آن ها پاسخ داده مي شود، و اين سرويس ها به طور واضح و دقيق سياست هاي ارتباطي و رابط هاي خود را اعلام مي كنند.

سرويس ها چيستند ؟
بسياري از ما آنقدر با تكنولوژي هاي سرويس هاي وب آشنا هستيم كه اغلب در باره اين كه خود سرويس ها واقعا چه هستند، فكر نمي كنيم. در ادامه سه تعريف مي آوريم كه در كنار يكديگر ماهيت يك سرويس راشرح مي دهند:
1-سرويس ها اجزاء مستقلي هستند كه پيغام هاي XML با ساختار مشخص و خوش تعريف(Well-defined) را پردازش مي كنند.
2-سرويس ها داراي رابط هاي خوش تعريف هستند كه به وسيله يك سند مبتني بر XML كه سند Web Service Description Language (WSDL) خوانده مي شود، به اين سند گاهي قرارداد WSDL نيز گفته مي شود. محتويات اين سند،‌عمليات (متدهايي) كه توسط سرويس ارائه مي شود را شرح مي دهد. از جمله اطلاعات مربوط به انواع داده، اطلاعات نحوه اتصال به سرويس، جهت يافتن و ارتباط با عمليات سرويس وب.
3-سرويس ها داراي نقاط انتهايي(Endpoint) هستند كه استفاده كنندگان از و ساير سرويس ها مي توانند بر اساس آدرس سرويس (معمولا URL ) به آن ها متصل شوند. اين همان چيزي است كه ارتباط(جفت شدن) آزادانه خوانده مي شود.

مشخصه هاي سرويس هاي وب و WS-IBasic Profile
برنامه هاي كاربردي SOA نياز به پشتيباني و امكانات زير ساختي زيادي دارند. از جمله امكانات ارسال و دريافت مختلفي ، زير ساخت امنيتي و پشتيباني براي پيام رساني مطمئن. شركت هاي مختلفي، از جمله IBM و مايكروسافت،‌براي ارائه مشخصه هاي استانداردي كه دامنه گسترده تكنولوژي هاي زير ساخت SOA را پوشش دهد، با يكديگر همكاري مي كنند.
متاسفانه مشخصه هاي سرويس هاي وب در محيطي ارايه مي شوند و توسعه مي يابند كه شركت هاي دخيل در آن بيشتر رقيب هستند تا شريك. رقابت هاي ميان شركت ها باعث مي شود كه نتواند بر سر استانداردهاي صحيح و مناسب به توافق برسند. اغلب،‌گروههاي مختلف شركت ها، براي موارد يكسان ، استاندارهاي متفاوتي را دنبال مي كنند . سازمان هاي غير انتفاعي مثل OASIS گرد همايي هايي براي همكاري در ارايه و توسعه استانداردها و مشخصه هاي سرويس هاي وب برگزار مي كنند.( براي اطلاعات بيشتر درباره OASIS به
http://www. Oasisopen.org مراجعه كنيد.)

معرفي WS-IBasic Profile
سازمان(WS-I)Web Services Interoperability يك هدف اصلي دارد و آن را ارائه مشخصه هاي استانداردي است كه سرويس هاي وب بتوانند با استفاده از آن روي پلتفرم هاي مختلف با هم تعامل داشته باشند. به بيان ديگر، هدف اين سازمان اين است كه سرويس هاي وب بتوانند با هم كار كنند،‌بدون توجه به اين كه تحت چه سكوي كاري عمل مي كنند و يا با استفاده از چه ابزارهايي ايجاد شده اند . اين مشخصه هاي سرويس هاي وب زمينه هاي گسترده اي را پوشش مي دهند، از پروتكل هاي نقل و انتقال داده تا امنيت كه مجموعه آن ها تحت عنوان پروفايل پايه WS-I جمع آوري شده اند.
مشخصه هاي سرويس هاي وب به طور عمده در گروههاي زير دسته بندي مي شوند:
نقل و انتقال (Tranport )
اين گروه از مشخصه ها، پروتكل هاي ارتباطي براي انتقال داده هاي خام بين سرويس هاي وب را تعريف مي كنند و پروتكل هاي HTTP، HTTPS و SMTP را شامل مي شوند.

پيغام رساني (Messaging)

اين گروه از مشخصه ها تعيين مي كنند كه پيغام هاي XMIL كه سرويس هاي وب تبادل مي كنند. چه فرمتي بايد داشته باشند. اين گروه مشخصه هاي SOAP براي نحوه رمز گذاري پيغام و مشخصه هاي XMIL و XSD براي كلمات كليدي پيغام (vocablury) . را شامل مي شود. مشخصه هاي آدرس دهي سرويس هاي وب نيز در اين گروه قرار دارد . اين مشخصه ها اطلاعا ت مقصد پيغام را از پروتكل نقل و انتقال داده ها، مستقل مي سازد . براي مثال مي توان با استفاده از مشخصه هاي آدرس دهي سرويس هاي وب، چندين مقصد براي يك پيغام XMIL تعريف كرد.

تشريح (Description)
اين گروه شامل مشخصه هايي براي تشريح و توضيح يك سرويس وب است . مشخصه هاي اصلي اين گروه WSDL ( براي قرارداد سرويس ) و XSD ( براي تعريف شماهاي نوع داده) هستند. اين گروه همچنين مشخصه سياست گذاري سرويس وب) WS-Policy )را شامل مي شود كه سياست گذاري هايي كه يك سرويس وب به هنگام ارتباط با يك سرويس گيرنده( كلاينت) اعمال مي كند و تشريح مي كند. براي مثال يك سرويس ممكن است شرايط خاصي براي فراخواني عملياتش داشته باشد. مشخصه WS-Policy به سرويس وب اين امكان مي دهد كه به سرويس گيرنده هاي احتمالي بگويد براي اجراي يك درخواست سرويس موفق بايد از چجه قوانيني تبعيت كنند. نهايتا،‌ در اين گروه مشخصه UDDI براي يافتن ( description) سرويس هاي وب گنجانده شد ه است.

ضمانت هاي سرويس (Service Assurances)
سرويس هاي وب نبايد فقط به سادگي پيغام هاي XMIL را رد و بدل كنند. اين سرويس ها بايد تضميني براي سرويس گيرنده داشته باشند كه اولا پيغام به نحوي ايمن منتقل خواهد شد، ثانيا اين كه سرويس گيرنده بايد حتما پاسخي دريافت كند، حتي اگر در نقطه اي از جريان كار، نقصي پيش آمده باشد. اين گروه از مشخصه ها شامل مشخصه امنيت سرويس وب ( براي تضمين رسيدن پيغام ها) مشخصه پيغام رساني مطمئن سرويس وب ( براي تضمين رسيدن پيغام ها در شبكه هاي ناپايدار و بدون قابليت اطمينان) و تعداد زيادي از مشخصه هاي مربوط به تراكنش است.

تركيب سرويس (Service Composition)
مجموعه گسترده مشخصه هاي WS-I Basic Profile را نمي توان به طور كامل در هر سرويس وب پياده كرد. به همين خاطر، توسعه دهندگان بايد مشخصه هايي كه براي يك سرويس خاص مهم و مناسب هستند را انتخاب و در آن سرويس پياده كنند. براي تامين اين هدف،‌ سرويس ها داراي ويژگي تركيب سرويس هستند . كه به توسعه دهندگان اجازه مي دهد مشخصه هاي مختلف را براي هر سرويس انتخاب كنند و آن ها را در سند WSDL گرد آوري و ثبت كنند.


در ادامه بحث ،تعدادي از مهمترين مشخصه هاي سرويس هاي وب و اهداف آن را بيان مي كنيم:

WS-Seccurity (امنيت سرويس وب ): مشخصه اي جامع كه مجموعه اي از تكنولوژي هاي متداول امنيتي را تحت پوشش دارد، از جمله امضاهاي ديجيتال و رمز گذاري مبتني بر نشانه هاي امنيتي،شامل گواهي هاي X.509


WS-Policy (سياستگذاري سرويس وب ): به سرويس هاي وب امكان مي دهد نيازها، ترجيحات(‌preferences ) و توانايي هاي خود را براساس مجموعه اي از فاكتورها بيان و مستند سازي مي كند كنند. البته تمركز بيشتر با فاكتورهاي امنيتي است . براي مثال سياستگذاري يك سرويس وب مي تواند شامل نيازهاي امنيتي آن، نظير رمز گذاري و امضاي ديجيتال بر اساس يك گواهي X.509 باشد.
WS-Adressing (آدرس دهي سرويس وب): نقاط انتهايي سرويس را در يك پيغام مشخص مي كندو امكان update شدن اين نقاط انتهايي را در مواردي كه پيغام بين دو يا چند سرويس منتقل مي شود، فراهم مي سازد. اين مشخصه به طور گسترده در حال جايگزيني مشخصه قديمي تر WS-Routing (مسير دهي سرويس وب )است.


WS-Messaging (پيغام رساني سرويس وب): امكان پشتيباني از ساير پروتكل هاي كانال ارتباطي، نظير TCP ، را در كنار HTTP براي سرويس وب فراهم مي سازد. اين مشخصه ساخت و توسعه نرم افزارهاي پيغام رساني، از جمله برنامه هاي كاربردي غير همزمان كه با استفاده از SOAP روي HTTP ارتباط برقرار مي كنند، را تسهيل مي كند.


WS-Secure Conversation(مكالمه ايمن سرويس وب): با استفاده از نشانه هاي امنيتي (Security tokens) ارتباطات مورد اعتماد براي جلسات كاري فراهم مي كند.


WS-Reliable Messaging (پيغام رساني مطمئن سرويس وب): مكانيسم هايي براي تضمين اطمينان از رسيدن پيغام،حتي در صورتي كه يك يا چند سرويس در زنجيره سرويس ها قابل دسترس نباشند ، را فراهم مي سازد. اين مشخصه شامل روش هايي براي اعلام رسيدن پيغام است، به طوري كه فرستنده بتواند بفهمد كه آيا گيرنده در دريافت پيغام موفق بوده است يا نه.
با معرفي و ثبت مشخصه هاي جديد و بهبود مشخصه هاي قبلي ، مشخصه هاي سرويس هاي وب دائما در حال تكامل هستند. البته، مجموعه مشخصه هاي پايه اي كه در مقاله بيان شد، احتمالا براي مدتي به عنوان زير بناي اصلي مشخصه هاي سرويس هاي وب باقي خواهند ماند،‌ چرا كه اين مشخصه ها نيازهاي اصلي و بنيادي برنامه هاي كاربردي سرويس گرا را پوشش مي دهند.

معرفي .NET Web Services Enhancements 2.0 for
Web Services Enhancements (WSE) 2.0 مجموعه اي از ابزارهاي مديريت شده تحت .NET را جهت پياده سازي مشخصه هاي سرويس هاي وب براي توسعه دهندگان فراهم آورده است. WSE جهت فراهم آوردن پشتيباني بيشتر زيرساختي، فراتر از آنچه كه در حال حاضر به وسيله چهارچوب كاري دات نت تامين مي شود،‌براي راه حل ها ي SOA ارايه شده است. به كمك WSE همچنين زير ساخت پردازشي براي ميزباني سرويس هاي وبي كه WS-Specification را پياده سازس مي كنند، فراهم مي آورد. براي مثال، WSE به شما امكان مي دهد كه به آساني سرويس هاي وبي بسازيد كه رمز گذاري و امضاهاي ديجيتال را روي درخواست ها و پاسخ هاي سرويس وب اعمال مي كنند. در نهايت،‌WSE يك ابزار بهره وري است كه براي هدايت توسعه دهندگان دات نت به سمت نسخه آينده Indigo طراحي شده است .Indigo از محصولات آينده مايكروسافت است كه پشتيباني يك پارچه براي برنامه هاي كاربردي پيغام رساني و سرويس گرا را هم فراهم مي آورد.
WSE يك محصول در حال تكامل است و در حال حاضر تمام مشخصه هاي سرويس هاي وب را پشتيباني نمي كند، ولي بسياري از مشخصه هاي مهم نظير WS-Seccurity و WS-Policyپشتيباني مي نمايد . به خاطر داشته باشيد كه SOA تحت تاثير مجموعه اي از استانداردها و مشخصه هاي فني است كه خودشان در حال تغيير هستند . نگارش هاي WSE براي هماهنگي با نسخه هاي جديد اين استانداردها و تكنولوژي ها بايد چرخه انتشار انعطاف پذيري داشته باشند. به همين خاطر مايكروسافت تصميم گرفته است كه چرخه انتشار WSE از چرخه انتشار نگارش هاي .NET Framework جدا كند،‌تا بتواند انتشار نگارش هاي اين محصول را با انعطاف پذيري بيشتري برنامه ريزي كند.


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

خدمتهاي وب به عنوان پايه معماري خدمت گرا: سير تكامل و رشد XML، با پيدايش خدمت هاي وب همراه بود. يك خدمت وب بهترين راه حل براي پياده سازي معماري خدمت گرا است، مخصوصا وقتي ديدگاه استفاده از كل كاربران اينترنت به عنوان كاربران بالقوه خدمت مطرح باشد. شما پايه كار خود را بر پروتكل HTTP بنا مي نهيد، پروتكلي كه از همه پروتكل هاي ديگر روي اينترنت قابل دسترس تر است. با نگاه به قابلتهاي سيستم هاي نرم افزاري مبتني بر معماري خدمت گرا، شما متوجه خواهيد شد كه خدمت هاي وب بسياري از موارد مطرح شده در بالا را رعايت مي كنند اما تعدادي از اصول مطرح شده را هم زير پا مي گذارند كه آن را بررسي مي كنيم:

- كارايي: XML كه عنصر اصلي سازنده خدمتهاي وب است، نسبت به ساير مكانيزم هاي انتقال اطلاعات (binary) از سربار بسيآر زيادي برخودار است.
- قابليت اطمينان در تراكنش ها: اگر شما در يك تراكنش از يك خدمت وب استفاده كنيد، چگونه مي توانيد صحت تراكنش را تضمين كنيد در حالي كه تمام كارهاي شما مبتني بر اينترنت و پروتكل HTTP است؟
- امنيت: شما چگونه مي توانيد كاربران خدمت خود را تصديق هويت كنيد تا بعد از آن بتواند صلاحيت آنها را در استفاده از خدمت تان مورد بررسي قرار دهيد؟ همچنين يك نكته منفي ديگر در مورد خدمت هاي وب در حال حاضر، عدم پشتيباني اكثر محيط هاي توليد نرم افزار (IDE) براي توليد و استفاده از آنها است و در عين حال فراهم كردن قابلتهايي مانند كمك به برنامه نويس در استفاده از متدها و غيره يا پيدا كردن خطاها در زمان كامپايل و نه زمان اجرا. بنابراين، مگر اينكه موارد فوق به نحوي حل نگردد، ممكن است استفاده از خدمت هاي وب به عنوان پايه معماري خدمت گرا مورد سوال قرار گيرد. البته در هر حال خدمت هاي وب از اين نظر كه طيف كاربران بالقوه آنها اينترنت است بسيار مورد توجه هستند. در حال حاضر هم در اكثر سازمانها براي تمامي نرم افزار ها يك واسط بصورت وب خدمت جهت فراهم كردن استفاده از آن براي سازمانهاي همكار فراهم مي شود و يا حتي در داخل سازمان و در مواردي كه استفاده از نرم افزار مذبور در داخل سازمان بسيار استفاده شود، با توجه به مشكلات كارايي خدمت هاي وب، يك واسط بصورت يكي از تكنولوژي هاي برنامه نويسي مبتني بر Component مانند COM و يا CORBA براي نرم افزار ايجاد مي شود. آماده شدن براي معماري خدمت گرا: همانطوري كه ذكر شد، با وجود اينكه تعدادي نكات منفي در استفاده از خدمتهاي وب به عنوان پايه معماري خدمت گرا وجود دارد اما اين موارد قابل حل هستند.

براي مثال در مورد بحث كارايي، مي توان از پردازنده اي قدرتمند تر استفاده كرد و يا مشكل امنيت را مي توان با استفاده از زيرساختهاي مبتني بر رمزنگاري هاي نامتقارن حل كرد. در هر حال اگر شما تا بحال براي معماري خدمت گرا آماده نشده ايد، در هر حال لازم است تا به اين سمت پيش رويد زيرا همانطور كه در ابتداي اين مقاله اشاره شد، نرم افزارهاي مبتني بر اين معماري، نسل غالب سالهاي آينده خواهند بود. بدين منظور بايد اندكي تفكر خود را در مورد طراحي نرم افزار، تغيير دهيد. در زير به مهمترين آنها اشاره مي شود:
- سعي كنيد با خدمت دهنده هاي خود از طريق واسط هاي چاق ارتباط برقرار كنيد و از استفاده از واسط هاي پرحرف بپرهيزيد. به عبارت ديگر سعي كنيد عملياتي كه شامل چندين فراخواني است از طريق يك فراخواني انجام دهيد. هر بايت اطلاعاتي كه شما روي اينترنت مي فرستيد محسوس است زيرا روي اينترنت اولا پهناي باند محدود است و همچنين در مورد هر انتقال بايد عمليات تحليل نام و مسيريابي انجام شود.
- سعي كنيد حتي الامكان اطلاعات مربوط به وضعيت را در سمت خدمت دهنده نگهداري نكنيد. سعي كنيد اين كار را به استفاده كنندگان واگذار كنيد. براي مثال اگر شما يك سازمان باشيد كه تعداد زيادي مراجعه كننده دارد و شما نياز به اطلاعات مراجعه كننده ها داريد، اگر بخواهيد خودتان تمام اطلاعات مربوط به مراجعه كنندگان خود را نگهداري كنيد به يك انبار بسيار بزرگ نياز خواهيد داشت . بهتر است از مراجعه كنندگان خود بخواهيد كه اطلاعات خودشان را نگهداري كنند، نه خود سازمان شما بخواهد آنها را نگهداري كند.
- سعي كنيد از واسط هاي بسيار خوش تعريف براي خدمت هاي خود استفاده كنيد زيرا وقتي شما پايه خود را بر خدمتهاي وب بنا نهاديد شما لازم داريد اين واسط ها را در اختيار استفاده كنندگان از خدمت خود قرار دهيد. (از طريق WSDLخدمت وب خود)
- سعي كنيد به سمت استفاده از روشهاي غيرهمزمان براي فراخواني هاي خود پيش رويد زيرا بسياري از خدمت ها به استفاده كنندگان خود بصورت غيرهمزمان خدمت مي دهند(مانند خدمت هاي وب) بنابراين براي خدمت گيرندگان بهتر است از اين روش تبعيت كنند. اين روش مناسبي نيست كه خدمت گيرنده به علت اينكه خدمت دهنده هنوز پردازش را شروع نكرده است ، بلاك شود. به عبارت ديگر سعي كنيد ديد خود را از حالت درخواست/پاسخ (مطرح در معماري Client/Server) به ديد مبتني بر پيام تغيير دهيد؛ يعني وقتي كه خدمت گيرنده يك پيام را براي خدمت دهنده ارسال كرد خدمت دهنده بعد از مدتي از طريق يك پيام به خدمت گيرنده پاسخ خواهد داد.
- براي تصديق هويت و كنترل دسترسي به روشهاي ديگر فكر كنيد. مكانيزهاي امنيتي در مورد خدمت هاي وب متفاوت است. در مورد مكانيزهاي امنيتي مورد استفاده از روشهاي خاص يك پلتفرم استفاده نكنيد زيرا قابليت تعامل سيستم شما را با ساير خدمت ها بخطر مي اندازد(مانند Integrated Windows Authentication) اخيرا هم يك گسترش در مشخصات خدمت هاي وب با نام ws-security بوجود آمده است كه از آن جهت پياده سازي امنيت در سروي هاي وب استفاده مي شود.
- از پلتفرمي استفاده كنيد كه به شما اجازه دهد بطور همزمان چندين نسخه از يك خدمت را در كنار هم نگه داريد (مراجعه كنيد به قابليتهاي سيستم هاي نرم افزاري مبتني بر معماري خدمت گرا) همچنين به ياد داشته باشيد تكنولوژيهايي مانند COM ,CORBA,RMI در حيطه خود فنآوري هاي موفقي بوده و هستند و تعداد بسيار زياد سيستمهايي كه از اين معماري ها استفاده مي كنند اين موضوع را نشان مي دهد. خدمت هاي وب شامل مفاهيمي هستند كه در مورد اين تكنولوژي ها وجود ندارد، اما اين به اين معني نيست كه خدمت هاي وب در زماني كوتاه جايگزين اين فنآوري ها خواهند بود؛ و بنابراين سعي كنيد در كنار اين تكنولوژي ها از خدمت هاي وب بهره جوييد. نتيجه گيري: معماري خدمت گرا از آخرين فن آوري هاي بوجود آمده در توليد نرم افزار است، كه علاوه بر رعايت دو اصل همبستگي زياد و چسبندگي كم نيازهاي تكنولوژيكي امروز بشر را برآورده مي سازد. با توجه به بوجود آمدن شركتهاي چند مليتي، ظهور خدمات الكترونيك و پيچيده شدن امور گوناگون و مخصوصا مجتمع سازي سيستم هاي نرم افزاري گوناگون EAI، اين معماري توانسته بخوبي از عهده اين پديده هاي نوين بر آيد.

        

نوشتن دیدگاه


تصویر امنیتی
تصویر امنیتی جدید

شما اینجا هستید:   SOASOA DIAGRMA