Service Oriented Architecture

در مدل "نرم افزار به عنوان سرويس" شما نرم افزار خود را بگونه اي طراحي مي کنيد که قابل استفاده توسط سيستم هاي ديگر باشد يعني  ديگران مي توانند براي استفاده از سرويس شما ثبت نام کنند و هر موقع که لازم داشتند از خدمات آن بهره ببرند، همانند حالتي که در مورد شبکه هاي تلويزيون کابلي[1] وجود دارد. تا زماني که شما به سرويس متصل هستيد، شما مي توانيد هر لحظه که خواستيد از سرويس استفاده کنيد.

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

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

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

معماري سرويس گرا چيست؟

همان طور که در عنوان آن مشخص است، به مفهومي در سطح  معماري، اشاره مي کند و بنابراين در مورد چيزي پايه اي و اساسي در سطوح بالا است، که پايه و اساس آن تجربيات بدست آمده در توليد سيستم هاي نرم افزاري مبتني بر[2] CBD و دو اصل اساسي در صنعت مهندسي نرم افزار يعني توليد نرم افزار بصورت

"با همبستگي زياد و در عين حال با چسبندگي کم"[3] است. بنابراين ايده هاي برنامه نويسي سرويس گرا ايده اي جديد نيست و شما شايد قبلا از آن استفاده کرده باشيد. اما جمع آوري بهترين تجربيات از توليد چنين سيستمهايي بصورت مجتمع و ناظر به وضعيت تکنولوژيکي امروز بشر، که همان مفاهيم مطرح شده در معماري سرويس گرا است چيز جديدي است. در زير بصورت دقيق تر اين بحث را ادامه مي دهيم

آيا توليد سيستم هاي سرويس گرا مفهوم جديدي است؟

مهندسان نرم افزار، هميشه مي گفتند و گفته اند که نرم افزار بايد به شکلي نوشته شود که همبستگي زياد ولي در عين حال اتصال کمي داشته باشد. شرکتهاي بزرگ نرم افزاري هم در جهت گام برداشتن براي رسيدن به اين دو اصل، تکنولوژي هايي را بوجود آوردند که به برنامه نويسان اجازه دهد تا به اين دو هدف در توليد نرم افزارهاي خود تا حد زيادي دست يابند. براي مثال مي توان به تکنولوژي هايي مانند [4]COM+[5], CORBA  و [6]RMI  و موارد ديگر، اشاره کرد. خوب پس مشاده کرديد که موضوع برنامه نويسي سرويس گرا، مفهموم جديدي نيست و اين معماري تلاشي ديگر در جهت توليد نرم افزارهاي با همبستگي زياد و در عين حال با چسبندگي و اتصال کم است.

ممکن است بپرسيد، پس چرا با وجود تکنولوژي هاي قدرتمندي چون CORBA,COM+,RMI چيز جديدي بوجود آمد؟ مگر تکنولوژي هاي قبلي موفق نبودند؟

بله مهمترين اشکال در معماري هاي قدرتمندي چون موارد مذکور اين بود که توليد کنندگان آنها سعي داشتند، که تکنولوژي خود را بر بازار غالب نمايند. رويايي که هرگز به حقيقت نمي پيوست. بنابراين با توجه به اين موضوع که اين تکنولوژيها قادر به تعامل مناسب با يکديگر نبودند عملا اصل همبستگي زياد بصورت خود بخود رد مي شد.

البته معماري هاي مذکور اشکالات ديگري هم داشتند که نسبت به مورد بالا از اهميت کمتري برخوردار است که از جمله آنها مي توان به عدم هماهنگي با اصول امنيتي مورد استفاده در اينترنت اشاره کرد.

البته بعدها راه حل هايي هم براي اين مشکل بوجود آمد (مانند RPC Over HTTP) اما به اين علت که از روز اول، در طراحي اين تکنولوژي ها اين امر در نظر گرفته نشده بود، از کارايي مناسبي برخوردار نبودند.

مفهموم همبستگي زياد و در عين حال با چسبندگي و اتصال کم، وقتي بخواهد در جهت ارزيابي يک سيستم نرم افزاري يا تکنولوژي، مورد استفاده قرار گيرد بسيار مبهم مي شود. حتي کسي مي تواند ايده هاي همبستگي و چسبندگي را باهم ترکيب کند!. براي جلوگيري از چنين ابهاماتي، شما مي تواند از ويژگي هاي معماري سرويس گرا به عنوان يک راه براي ارزيابي ميزان همبستگي و چسبندگي و اتصال يک سيستم نرم افزاري يا يک تکنولوژي استفاده کنيد. اگرچه مفاهيم مطرح شده در معماري سرويس گرا دقيقاً همان مفاهيم همبستگي زياد و در عين حال چسبندگي کم نيستند، اما سيستمهايي که بر اساس معماري سرويس گرا طراحي و پياده سازي شده اند، نشان داده اند که توانسته اند تا حد بسيار زيادي ويژگي هاي همبستگي زياد و در عين حال چسبندگي کم را بخوبي در خود ايجاد و حفظ کنند.

ويژگي هاي سيستم هاي نرم افزاري مبتني بر معماري سرويس گرا:

- استفاده کننده[7] از سرويس هيچ لزومي ندارد از جرئيات پياده سازي سرويس در سمت

سرويس دهنده[8] مطلع باشد

- محل سرويس دهنده بايد از نظر استفاده کننده از سرويس پنهان[9] باشد (در انجام امور مرتبط با استفاده از سرويس ) و تنها در زمان اجرا سرويس  گيرنده از مکان سرويس دهنده آگاه خواهد شد.

- نرم افزار مبتني بر معماري سرويس گرا بايد بتواند با نرم افزارهاي موجود روي ساير پلتفرم ها تعامل[10] داشته باشد.

- چندين نسخه از سرويس بايد بصورت همزمان در کنار هم فعاليت کنند زيرا با توجه به طيف گسترده استفده کنندگان در صورت بروزرساني سرويس در سمت سرويس دهنده، به سرعت امکان بروزرساني استفاده کنندگان سرويس وجود ندارد

همچنين تعدادي از ويژگي هايي که هر نرم افزار، اعم از اينکه مبتني بر اين معماري باشد يا نباشد، بايد داشته باشد به شرح زير است:

     - کارايي[11] زياد

- امنيت بالا (تضمين محرمانگي، صحت اطلاعات  و هميشه در دسترس بودن)[12] و همچنين کنترل دسترسي[13]

     - قابليت اطمينان[14] بالا بخصوص وقتي سر و کار با تراکنش هاي چند مرحله اي است.

سرويسهاي وب به عنوان پايه معماري سرويس گرا:

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

     - کارايي: XML که عنصر اصلي سازنده سرويسهاي وب است، نسبت به ساير مکانيزم هاي انتقال اطلاعات (binary) از سربار بسيآر زيادي برخودار است.

- قابليت اطمينان در تراکنش ها: اگر شما در يک تراکنش از يک سرويس وب استفاده کنيد، چگونه مي توانيد صحت تراکنش[16] را تضمين کنيد در حالي که تمام کارهاي شما مبتني بر اينترنت و پروتکل HTTP است؟

- امنيت: شما چگونه مي توانيد کاربران سرويس خود را تصديق هويت[17] کنيد  تا بعد از آن بتواند صلاحيت آنها را در استفاده از سرويس تان مورد بررسي قرار دهيد؟

همچنين يک نکته منفي ديگر در مورد سرويس هاي وب در حال حاضر، عدم پشتيباني اکثر محيط هاي توليد نرم افزار (IDE) براي توليد و استفاده از آنها است و در عين حال فراهم کردن قابلتهايي مانند کمک به برنامه نويس در استفاده از متدها و غيره يا پيدا کردن خطاها در زمان کامپايل و نه زمان اجرا.

بنابراين، مگر اينکه موارد فوق به نحوي حل نگردد، ممکن است استفاده از سرويس هاي وب به عنوان پايه معماري سرويس گرا مورد سوال قرار گيرد. البته در هر حال سرويس هاي وب از اين نظر که طيف کاربران بالقوه آنها اينترنت است بسيار مورد توجه هستند. در حال حاضر هم در اکثر سازمانها براي تمامي نرم افزار ها يک واسط بصورت  وب سرويس جهت فراهم کردن استفاده از آن براي سازمانهاي همکار فراهم مي شود و يا حتي در داخل سازمان و در مواردي که استفاده از نرم افزار مذبور در داخل سازمان بسيار استفاده شود، با توجه به مشکلات کارايي سرويس هاي وب، يک واسط بصورت يکي از تکنولوژي هاي برنامه نويسي مبتني بر Component مانند COM+ و يا CORBA براي نرم افزار ايجاد مي شود.

آماده شدن براي معماري سرويس گرا:

همانطوري که ذکر شد، با وجود اينکه تعدادي نکات منفي در استفاده از سرويسهاي وب به عنوان پايه معماري سرويس گرا وجود دارد اما اين موارد قابل حل هستند. براي مثال در مورد بحث کارايي، مي توان از پردازنده اي قدرتمند تر استفاده کرد و يا مشکل امنيت را مي توان با استفاده از زيرساختهاي مبتني بر رمزنگاري هاي نامتقارن حل کرد.

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

در زير به مهمترين آنها اشاره مي شود:

- سعي کنيد با سرويس دهنده هاي خود از طريق واسط هاي چاق[18] ارتباط برقرار کنيد و از استفاده از واسط هاي پرحرف[19] بپرهيزيد. به عبارت ديگر سعي کنيد عملياتي که شامل چندين فراخواني است از طريق يک فراخواني انجام دهيد. هر بايت اطلاعاتي که شما روي اينترنت مي فرستيد محسوس است زيرا روي اينترنت اولا پهناي باند محدود است و همچنين در مورد هر انتقال بايد عمليات تحليل نام[20] و مسيريابي انجام شود.

- سعي کنيد حتي الامکان اطلاعات مربوط به وضعيت[21] را در سمت سرويس دهنده نگهداري نکنيد. سعي کنيد اين کار را به استفاده کنندگان واگذار کنيد.

براي مثال  اگر شما يک سازمان باشيد که تعداد زيادي مراجعه کننده دارد و شما نياز به اطلاعات مراجعه کننده ها داريد، اگر بخواهيد خودتان تمام اطلاعات مربوط به مراجعه کنندگان خود را نگهداري کنيد به يک انبار بسيار بزرگ نياز خواهيد داشت . بهتر است از مراجعه کنندگان خود بخواهيد که اطلاعات خودشان را نگهداري کنند، نه خود سازمان شما بخواهد آنها را نگهداري کند.

- سعي کنيد از واسط هاي بسيار خوش تعريف براي سرويس هاي خود استفاده کنيد زيرا وقتي شما پايه خود را بر سرويسهاي وب بنا نهاديد شما لازم داريد اين واسط ها را در اختيار استفاده کنندگان از سرويس خود قرار دهيد. (از طريق [22]WSDLسرويس وب خود)

- سعي کنيد به سمت استفاده از روشهاي غيرهمزمان[23] براي فراخواني هاي خود پيش رويد زيرا بسياري از سرويس ها به استفاده کنندگان خود بصورت غيرهمزمان سرويس مي دهند(مانند سرويس هاي وب) بنابراين براي سرويس گيرندگان بهتر است از اين روش تبعيت کنند. اين روش مناسبي نيست که سرويس گيرنده به علت اينکه سرويس دهنده هنوز پردازش را شروع نکرده است ، بلاک شود.

به عبارت ديگر سعي کنيد ديد خود را از حالت درخواست/پاسخ (مطرح در معماري Client/Server)    به ديد مبتني بر پيام[24] تغيير دهيد؛ يعني وقتي که سرويس گيرنده يک پيام را براي سرويس دهنده ارسال کرد سرويس دهنده بعد از مدتي از طريق يک پيام به سرويس گيرنده پاسخ خواهد داد.

- براي تصديق هويت و کنترل دسترسي به روشهاي ديگر فکر کنيد. مکانيزهاي امنيتي در مورد سرويس هاي  وب متفاوت است. در مورد مکانيزهاي امنيتي مورد استفاده از روشهاي خاص يک پلتفرم استفاده نکنيد زيرا قابليت تعامل سيستم شما را با ساير سرويس ها بخطر مي اندازد(مانند Integrated Windows Authentication) اخيرا هم يک گسترش[25] در مشخصات سرويس هاي وب با نام ws-security بوجود آمده است که از آن جهت پياده سازي امنيت در سروي هاي وب استفاده مي شود.

- از پلتفرمي استفاده کنيد که به شما اجازه دهد بطور همزمان چندين نسخه از يک سرويس را در کنار هم نگه داريد (مراجعه کنيد به قابليتهاي سيستم هاي نرم افزاري مبتني بر معماري سرويس گرا)

همچنين به ياد داشته باشيد تکنولوژيهايي مانند COM+,CORBA,RMI در حيطه خود فنآوري هاي موفقي بوده و هستند و تعداد بسيار زياد سيستمهايي که از اين معماري ها استفاده مي کنند اين موضوع را نشان مي دهد. سرويس هاي وب شامل مفاهيمي هستند که در مورد اين تکنولوژي ها وجود ندارد، اما اين به اين معني نيست که سرويس هاي وب در زماني کوتاه جايگزين اين فنآوري ها خواهند بود؛ و بنابراين سعي کنيد در کنار اين تکنولوژي ها از سرويس هاي وب بهره جوييد.

 نتيجه گيري:

معماري سرويس گرا از آخرين فن آوري هاي بوجود آمده در توليد نرم افزار است، که علاوه بر رعايت دو اصل همبستگي زياد و چسبندگي کم نيازهاي تکنولوژيکي امروز بشر را برآورده مي سازد.

با توجه به بوجود آمدن شرکتهاي چند مليتي، ظهور خدمات الکترونيک و پيچيده شدن امور گوناگون و مخصوصا مجتمع سازي سيستم هاي نرم افزاري گوناگون [26]EAI، اين معماري توانسته بخوبي از عهده اين پديده هاي نوين بر آيد.