از سوي ديگر، با وجود رشد و توسعه سريع فناوري‌هاي اطلاعاتي و ارتباطي، نيازمندي‌هاي سازمان‌ها نيز به سرعت در حال افزايش است. آنچه به عنوان راهکاري مناسب براي غلبه بر پيچيدگي‌هاي روز‌افزون سيستم‌هاي اطلاعاتي مطرح مي‌گردد، استفاده از معماري نرم‌افزاري مناسب در توسعه و پياده‌سازي نرم‌افزار‌ها در اين قبيل سيستم‌ها است. معماري مبتني بر سرويس رويکرد جديدي در دنياي نرم‌افزار است که با رفع محدوديت‌ها و نواقص معماري‌هاي پيشين به عنوان بهترين گزينه در اين زمينه محسوب مي‌گردد. در اين مقاله سعي شده است مفاهيم و اصول پايه‌اي اين معماري به طور اجمالي مورد بررسي قرار گيرد. مقدمه سيستم‌هاي اطلاعاتي به سرعت در حال رشد هستند؛ سازمان‌ها نيازمند پاسخگويي سريع به نيازمندي‌هاي جديد کسب‌وکار هستند. اين در حالي است که معماري‌هاي نرم‌افزاري موجود به حد نهايي قابليت‌هاي خود رسيده‌اند. معماري مبتني بر سرويس SOA قدم تکاملي بعدي براي کمک به سازمان‌ها جهت مديريت چالش‌هاي پيچيده است. معماري مبتني بر سرويس حالت بلوغ يافته معماري مبتني بر اجزا، طراحي مبتني بر واسطه (شي‌گرا) و سيستم‌هاي توزيع ‌شده است. در معماري مبتني بر اجزا عملکرد کلي به کارهاي کوچک‌تري تقسيم مي‌شود که هر يک در يک جزء بسته‌بندي خواهند شد. يک سيستم توزيع‌شده، تعميمي از يک معماري مبتني بر اجزا است که به اجزائي که در موقعيت‌هاي فيزيکي مختلف وجود دارند، اشاره مي‌کند. مهم‌ترين مزيت معماري مبتني بر اجزا سهولت در استفاده مجدد و تغيير هدف اجزاي خاص و سهولت در امر نگهداري سيستم است. استفاده مجدد و تغيير هدف معمولاً مهم‌ترين پيشران‌هاي کسب‌و کار جهت استفاده از اين نوع معماري در دهه 90 ميلادي بوده است. بر اساس منطق معماري مبتني بر سرويس، سيستم‌هاي نرم‌افزاري بزرگ مي‌توانند از گردآوري مجموعه‌هايي از عملکردهاي مستقل و قابل استفاده مجدد تشکيل گردند. برخي از اين عمليات مي‌تواند از طريق سيستم‌هاي موجود و يا سيستم‌هاي ديگر فراهم گردد ولي ساير عمليات لازم بايد پياده‌سازي شوند. هر سرويس امکان دسترسي به مجموعه خوش‌ تعريفي از عمليات را مي‌دهد. سيستم به عنوان يک کل به صورت مجموعه‌اي از تعاملات بين اين سرويس‌ها طراحي مي‌شود. معماري مبتني بر سرويس، سرويس‌هايي را که سيستم از آنها تشکيل شده را تعريف ‌مي‌کند و تعاملات لازم بين سرويس‌ها جهت ارائه رفتار مشخص را توصيف ‌مي‌کند و در نهايت سرويس‌ها را به يک يا چند پياده‌سازي در تکنولوژي‌هاي خاص تصوير مي‌کند. SOA بر اساس استفاده از اشياء و اجزا توزيع شده است و قدم تکامل بعدي در محيط‌هاي محاسبه‌اي است. اين معماري در حال حاضر مدل مرجع استانداردي ندارد؛ اما پياده‌سازي‌هاي موجود مفاهيم مشترکي را مورد استفاده قرار مي‌دهند که در ادامه اين مفاهيم پايه مورد بررسي قرار مي‌گيرند. 2- مفاهيم اصلي در معماري مبتني بر سرويس در حال حاضر استاندارد مشخصي براي تعريف SOA وجود ندارد اما مواردي که در ادامه مي‌آيد مهم‌ترين و سازگارترين موارد در پياده‌سازي SOA هستند. 2-1- سرويس‌ يک سرويس رفتار تعريف شده قراردادي است که مي‌تواند به‌وسيله يک جزء براي استفاده جزء ديگر پياده‌سازي شده و فراهم گردد. 2-2- شرح سرويس شرح سرويس پارامترهاي فني، قيود و سياست‌هايي را شامل مي‌شود که قالب‌هاي لازم براي فراخواني سرويس را تعريف مي‌کند. هر سرويس بايد شامل تعريف سرويس در قالب استاندارد باشد. اين موضوع کاربردها و کاربران انساني را قادر مي‌سازد تا با بررسي شرح سرويس و تعيين موضوعاتي نظير اين‌ که سرويس چه کاري انجام مي‌دهد، چگونه به آن انتصاب مي‌يابند و اين‌که چه پروتکل‌هاي امنيتي (در صورت وجود) بايد به همراه آن مورد استفاده قرار گيرد، از آن سرويس استفاده کند. اين اعلان همچنين ممکن است شامل جزئياتي در مورد هر فرايند ضمني و ديگر واژه‌هاي کاري و قانوني باشد که ممکن است در زمان فراخواني سرويس اتفاق بيفتد. به عنوان مثال، اگر يک استفاده‌کننده سرويس، سرويسي را فراخواني کند که يک درخواست خريد را براي فراهم‌کننده سرويس ارسال نمايد، و اجرا موفقيت‌آميز باشد، اين موضوع ممکن است منجر به مسئوليت مالي نسبت به فراهم‌کننده سرويس يا بخش قانوني ديگر مي‌شود. در حاليکه طبيعت سرويس‌ها ممکن است تغيير کند، استاندارد مشترکي جهت اعلان يک سرويس هنگام تهيه يک زيرساخت مطلوب است. دو نمونه از چنين استانداردهاي موجود ebXML و WSDL هستند. 2-3- اعلان و يابش سرويس‌ها شرح سرويس بايد به شيوه‌اي قابل دسترسي در اختيار کاربران بالقوه قرار گيرد که به اين امر اعلان سرويس اطلاق مي‌شود. يابش، ‌زماني انجام مي‌شود که يک مشتري بالقوه اطلاعاتي در مورد وجود يک سرويس، پارامترهاي قابل اعمال و واژگان آن به دست آورد. يافتن، بحث تصديق هويت جهت اجراي سرويس را شامل نمي‌شود؛ گرچه اين جزئيات ممکن است در الگوي يافتن قرار گيرد. اجزاي اعلان و يابش در SOA به شيوه‌هاي مختلف از جمله استفاده از روش ثبات / مخزن و يا روش دايرکتوري سرويس قابل پياده سازي هستند. • پياده‌سازي به روش ثبات / مخزن يک ثبات / مخزن جزئي است که در آن کاربران امکان ذخيره و مديريت سرويس‌هاي لازم براي عملکرد سازمانشان را خواهند داشت. اين موضوع شامل سرويس‌هايي است که تسهيم بين بيش از يک کاربر (نظير xml schemas و شرح web-service) را فراهم مي‌آورد که به ثبات به گونه‌اي منتسب مي‌شود که ثبات در مورد تمامي رويدادهاي قابل ارزيابي نسبت به محصولات در مخزن اطلاع دارد. • پياده‌سازي به روش دايرکتوري دايرکتوري يک واسط است که اطلاعات انتساب به محصولات را فراهم مي‌آورد. افرادي که مالک محصولات هستند و يا آنها را کنترل مي‌کنند، مي‌توانند يک مدخل به دايرکتوري باز کرده تا به محصولات ارجاع داده و خود انتسابات به آن را توضيح دهند. ديگران ممکن است اين اطلاعات را بازيابي کرده و از آن جهت انتساب به محصولات استفاده کنند. مهم‌ترين مشکل دايرکتوري اين است که هيچ کنترل يا اطلاع‌رساني در صورت حذف، تغيير و جايگزين شدن يک محصول انجام نمي‌دهد و قادر به اعلام اين رويدادها به کاربران نيست. هر دو پياده‌سازي دايرکتوري و ثبات / مخزن امکان سازگاري با يکديگر را دارند. به اين معنا که عملکرد اجازه مي‌دهد که محتوا از يک پياده‌سازي توسط يک پياده‌سازي ديگر مورد ارجاع قرار گيرد. چندين استاندارد وجود دارد که پياده‌سازي‌ها دايرکتوري و ثبات / مخزن را دارند. رايج‌ترين استانداردها عبارتند از: • OASIS ebXML Registry-Repository Technical Specifications16 • OASIS Universal Description and Discovery Interface (UDDI) Technical Specification17.2 2-4- خصوصيات مدل داده‌اي مرتبط در هنگام فراخواني يک سرويس، پارامترهاي مشخصي ممکن است براي انجام درخواست سرويس مورد نياز باشد. سرويس همچنين ممکن است پارامترهايي را به کاربر سرويس بازگرداند. W3C WSDL يک نمونه شناخته شده از پياده‌سازي اين بخش است. 3- اصطلاحات رايج در معماري مبتني بر سرويس • فراهم‌کننده سرويس: يک موجوديت نرم‌افزاري که خصوصيات سرويس را پياده‌سازي مي‌کند. • درخواست‌کننده سرويس: يک موجوديت نرم‌افزاري که يک فراهم‌کنندة سرويس را فراخواني مي‌کند، به‌طور سنتي اين مورد به عنوان "کلاينت" شناخته مي‌شود؛ اما يک درخواست‌کننده سرويس مي‌تواند يک کاربر برنامه کاربردي و يا سرويس ديگر باشد. • موقيعت‌ياب سرويس: يک نوع خاص از فراهم‌کننده سرويس که به‌عنوان يک ثبات عمل مي‌کند و امکان جست‌وجوي واسطه‌هاي فراهم‌کننده سرويس و موقعيت سرويس را مي‌دهد. • واسط سرويس: يک نوع خاص از فراهم‌کننده سرويس است که مي‌تواند درخواست سرويس را به يک يا چند فراهم‌کننده سرويس منتقل کند. 4- چارچوب SOA 4-1- زيرساخت SOA 4-1-1- نقشه مفهومي شکل‌هاي 2 تا 4 نقشه‌هايي مفهومي هستند که مفاهيم پايه SOA را مستقل از معني و تکنولوژي‌ها تشريح مي‌کنند. نقشه‌هاي مفهومي غير رسمي بوده و نمايش گرافيکي از مفاهيم و رابطه بين آنها را شامل مي‌شود. شکل 2 مثالي از يک نقشة مفهومي است. شکل1- مثالي از نقشه مفهومي اغلب معماري‌هايي که SOA ناميده مي‌شوند، شامل يک فراهم‌کننده سرويس، يک کاربر سرويس و برخي زيرساخت‌هاي پيام‌رساني هستند. شکل2- مدل مرجع معماري مبتني بر سرويس پايه 4-1-2- مفاهيم اختياري و زيرساخت‌هاي SOA اشتراکي شکل3-مفاهيم اختياري براي SOA و نمايش تعامل آنها با مفاهيم پايه اين معماري جهت اجراي تعهدات در زمان اجرا، اغلب SOAها ممکن است شامل مفاهيمي اضافه بر آنچه در شکل 3 نشان داده شده است، باشند. مفاهيم ديگر کاربران سرويس، کلاينت سرويس، قرارداد پذيرش سرويس و فراخواني سرويس هستند. فراخواني يک سرويس يا وجود کاربر سرويس در مدل SOAالزامي نيست. فراهم‌کننده يک سرويس، قرارداد سرويس جهت استفاده آن و شرح سرويس را ارائه مي‌کند. شرح سرويس به مدل داده‌هاي مرتبط با فراخواني سرويس ارجاع مي‌کند. شرح سرويس از طريق يکي از چندين روش اعلان مي‌شود. کاربر سرويس خصوصيات سرويس را از طريق مکانيزم اعلان شناسايي مي‌کند. شناسايي، پذيرش قرارداد را شامل نمي‌شود. همچنين فراخواني سرويس را نيز القا نمي‌کند. اين امر صرفاً عملي براي پيدا کردن اطلاعات در مورد سرويس است. اين امر لزوماً در يک عمل اتفاق نمي‌افتد و ممکن است به تعدادي از کارها نياز داشته باشد. همچنين ممکن است از طريق وسايل غير الکترونيکي صورت پذيرد. شکل 4 ساير عملکردهاي خاص اختياري را حذف کرده و از پياده‌سازي‌هاي خاص نظير پيام‌رسانيSOAP ، WDSL و ebXML خودداري مي‌کند. 4-2- الگوهاي SOA شکل 5 يک الگوي ساده سرويس را نمايش مي‌دهد. در جايي که يک فراهم‌کننده سرويس، سرويس را پيشنهاد مي‌دهد و يک کاربر سرويس، از سرويس‌ها استفاده مي‌کند. چندين نوع از پروتکل‌هاي ارتباطي ممکن است زوج درخواست/ پاسخ را مورد استفاده قرار دهد و روش‌هاي متنوعي نظير سنکرون يا آسنکرون ممکن است استفاده شود. SOA به هيچ پروتکل ارتباطي خاص محدود نمي‌شود. شکل 5 الگوي "درخواست – پاسخ" را نمايش مي‌دهد. شکل4-الگوي پايه براي معماري مبتني بر سرويس 5- چرخه حيات SOA بر اساس طرح IBM، براي SOA مي‌توان يک چرخه حيات در نظر گرفت. در فاز "مدل" نيازمندي‌هاي کسب‌و کار جمع‌آوري شده و فرايندهاي کسب و کار آنها طراحي مي‌شود. بعد از بهينه شدن فرايندها، از طريق کنار هم قرار دادن سرويس‌هاي موجود و سرويس‌هاي جديد اين فرايندهاي کسب‌و کار شکل مي‌گيرد. سپس اين سرمايه‌ها در يک محيط امن و با قابليت تجميع بالا نصب مي‌شود. بعد از نصب فرايندهاي کسب و کار، کاربران IBM اين فرايندهاي کسب و کار را هم از منظر فني و هم از منظر فرايندهاي کسب و کار مورد نظارت و مديريت قرار مي‌دهند. اطلاعات جمع‌آوري شده در فاز مديريت به چرخه حيات بازخورد خواهد داشت تا بهبود پيوسته فرايندها را امکان‌پذير سازد. در زير همه اين مراحل در چرخه حيات، حاکميت و فرايندهايي هستند که رهنمود‌ها و افق‌هاي آينده را براي پروژه SOA فراهم مي‌کنند. شکل 5- چرخه حيات معماري مبتني بر سرويس 6-1- مرحله مدل‌سازي فاز مدل با جمع‌آوري و تحليل نيازمندي‌هاي کسب‌و کار آغاز مي‌شود که بعداً براي مدل کردن، شبيه‌سازي و بهينه کردن فرايندهاي کسب و کار مورد استفاده قرار مي‌گيرند. فرايندهاي کسب و کار حاصل براي طراحي سرويس‌هاي نرم‌افزاري مرتبط و سطوح سرويس جهت حمايت از اين فرايندها مورد استفاده قرار مي‌گيرند. در طول اين فاز، مدلي جهت ايجاد درک مشترک بين کسب و کار و فناوري اطلاعات در فرايندهاي کسب و کار، اهداف و خروجي‌ها استفاده مي‌شود. به علاوه اين مدل مي‌تواند اين اطمينان را به وجود آورد که کاربردهاي حاصل، نيازمندي‌هاي کسب و کار تعريف شده را براورده مي‌سازد. اين مدل همچنين مي‌تواند مبنايي جهت اندازه‌گيري کارآيي کسب و کار باشد. 6-2- مرحله گردآوري در طول فاز گردآوري، کتابخانه سرويس‌هاي موجود مي‌تواند جهت يافتن سرويس‌هاي مورد نظر و موجود در سازمان بررسي شود. در صورتي که سرويس مورد نظر يافت نشد اين امکان وجود دارد که يک سرويس جديد ايجاد و پس از تست به مجموعه افزوده شود. هنگامي که سرويس‌هاي مورد نياز فراهم شد، سرويس‌ها جهت پياده‌سازي فرايندهاي کسب‌و کار هماهنگ مي‌گردند. 6-3- مرحله نصب در طول فاز پياده‌سازي، مقياس و محيط زمان اجرا جهت تأمين نيازمندي‌هاي سطوح سرويس به وسيله فرايندهاي کسب‌وکار پيکربندي مي‌شود. پس از پيکربندي يک فرايند کسب‌وکار، امکان پياده‌سازي آن در يک محيط امن، مطمئن و مقياس‌پذير سرويس‌ها وجود خواهد داشت. محيط سرويس‌ها به گونه‌اي بهينه‌سازي مي‌شود که علاوه بر اجراي مطمئن فرايندهاي کسب‌وکار، امکان انعطاف‌پذيري جهت بروز کردن به طور پويا و در صورت تغيير نيازمندي‌هاي کسب‌وکار را فراهم مي‌آورد. اين رويکرد مبتني بر سرويس همچنين هزينه و پيچيدگي نگهداري سيستم را نيز کاهش مي‌دهد. 6-4- مرحله مديريت فاز مديريت شامل نظارت و نگهداري از زمان پاسخ و در دسترس بودن سرويس مي‌شود. همچنين مديريت منابع سرويس‌هاي زيرين در اين فاز انجام مي‌شود. درک کارايي زمان واقعي فرايندهاي کسب‌وکار امکان ايجاد بازخورد ضروري به مدل فرايند کسب و کار جهت بهبود دائمي را فراهم مي‌آورد. اين کار همچنين مديريت و نگهداري کنترل نسخه براي سرويس‌هاي تشکيل دهنده فرايندهاي کسب و کار را شامل مي‌شود. فاز مديريت در نهايت امکان اتخاذ تصميمات کسب و کار بهتر و سريع‌تر را فراهم مي‌سازد. 6-5- مرحله حاکميت و فرايندها حاکميت و فرايندها جهت موفقيت هر نوع پروژه SOA ضروري هستند. جهت تخمين موفقيت، ممکن است يک مرکز تعالي در کسب‌وکار، براي پياده‌سازي سياست‌هاي حاکميتي و دنبال کردن استانداردهاي حاکميتي بين‌المللي جهت اهداف کنترلي براي اطلاعات و تکنولوژي مرتبط ايجاد گردد. پياده‌سازي سياست‌هاي حاکميتي قوي مي‌تواند منجر به پروژه‌هاي SOA موفق گردد. 7- خصوصيات اساسي جهت استفادة بهينه از سرويس‌ها • درشت‌دانه بودن: عملکردها روي سرويس‌ها به طور متفاوت پياده‌سازي مي‌شوند تا کارآيي بيشتري را در برگيرند و بر روي مجموعه‌هاي داده‌اي بزرگ‌تر در مقايسه با طراحي مبتني بر اجزا عمل مي‌کند. (شکل 8) • طراحي مبتني بر واسط: سرويس‌ها، واسط‌هاي مجزا‌ ‌تعريف‌شده را پياده‌سازي مي‌کنند. مزيت اين امر آن است که چندين سرويس مي‌توانند يک واسط مشترک را پياده‌سازي کنند و يک سرويس مي‌تواند چندين واسط را پياده‌سازي کند. (شکل 9) • قابل يافت بودن: سرويس‌ها لازم است هم در زمان طراحي و هم در زمان اجرا قابل يافت باشند، نه تنها با شناسة يکتا بلکه همچنين با شناسة واسط و با نوع سرويس. • نمونه منفرد: بر خلاف توسعة مبتني بر جزء که از اجزا بر حسب نياز نمونه‌هايي ايجاد مي‌شود، هر سرويس يک نمونه منفرد و همواره در حال اجرا است که مجموعه‌اي از کلاينت‌ها با آن ارتباط برقرار مي‌کنند. • اتصال ست: سرويس‌ها با ديگر سرويس‌ها و کلاينت‌ها از طريق تبادل اطلاعات استاندارد xml با يکديگر در ارتباط هستند؛ اين ارتباط باعث کاهش وابستگي و جداسازي بر اساس پيام‌رساني مي‌شود. • آسنکرون: به طور کلي، سرويس‌ها از رويکرد انتقال پيام آسنکرون استفاده مي‌کنند. اما اين امر ضروري نيست. در بعضي مواقع در پياده‌سازي سرويس‌ها از انتقال پيام سنکرون نيز استفاده مي‌شود. در شکل‌هاي زير برخي از ويژگي‌هاي فوق نمايش داده شده است: شکل 6- تأکيد بر درشت‌دانه بودن در سرويس‌ها شکل 7- طراحي مبتني بر واسط در معماري سرويس‌گرا 8- مقياس‌پذيري از طريق رفتار آسنکرون و صف‌بندي بهتر است که از ماهيت آسنکرون در ‌سرويس‌ها استفاده شود. با توجه به سربار انتقال اضافه و همچنين اين انتظار که سرويس‌ها، ماهيتاً در فواصل فيزيکي دور از يکديگر خواهند بود، کاهش زمان انتظار درخواست‌کننده براي پاسخ بسيار اهميت دارد. از طريق آسنکرون کردن فراخواني يک سرويس، با يک پيام بازگشت مجزا، به درخواست‌کننده امکان ادامة اجرا تا زمان فراهم شدن پاسخ داده مي‌شود. البته اين به معناي اشتباه بودن رفتار سنکرون سرويس نيست، بلکه به اين معنا است که رفتار سرويس آسنکرون مطلوب است، به خصوص در جايي که هزينه‌هاي ارتباطي زياد است و يا تأخير شبکه قابل پيش‌بيني نيست. شکل8- روش سنکرون در مقابل روش آسنکرون با استفاده از فراخواني آسنکرون، به فراهم‌کننده اين امکان داده مي‌شود که از چندين رشتة کاري جهت مديريت چندين درخواست کلاينت استفاده کند. جهت اجراي فراخواني آسنکرون، درخواست‌کننده بايد نشاني بازگشت را به سرويس پياده‌ساز يک واسط ارسال کند. 9- جمع‌بندي معماري مبتني بر سرويس گام تکاملي بعدي در دنياي نرم‌افزار است. معماري‌هاي نرم‌افزاري فعلي قادر به حل تمامي مشکلات و چالش‌هاي فرا روي سازمان‌ها و سيستم‌هاي اطلاعاتي بزرگ و پيچيده نيستند. ويژگي‌هاي خاص معماري مبتني بر سرويس اين معماري را به عنوان بهترين گزينه براي اين موضوع مطرح کرده است.