مقاله در مورد معماری سرویس گرا

بخشی از مقاله

معماری سرویس گرا

معماري سرویس گرا به عنوان يكي از آخرين دستاوردها در توليد نرم افزار، به نظر مي رسد، در سالهاي آتي معماري غالب صنعت فناوري اطلاعات و ارتباطات باشد. علت بوجود آمدن اين معماري، ايده اي بود كه در ذهن تعدادي از معماران آن وجود داشت و آن نرم افزار به عنوان سرویس بود.

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

واژه های کلیدی
SOA = Service Oriented Architecture,
SOE = Service Oriented Enterprise,
SOI = Service Oriented Infrastructure,

MDA = Minimum Descent Altitude,
XML = Extensible Markup Language,
خوش تعريف = Well-defined,
WSDL = Web Service Description Language,
SGML = Standard Generalized Markup Language,

واحدهای نرم افزاری آماده در شبكه = Network-available Software Unit,
سرویس های سطح کسب و کار = Business-level services,

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

ساختمان مي توانند از آن بهره برداري كنند. در جهان امروز طيف مخاطباني كه بالقوه مي توانند از سرویس شما استفاده كنند، كل كاربران روي شبكه اينترنت است. بنابراين بايد مكانيزمي بوجود مي آمد، كه مي توانست پاسخگوي اين محيط جديد (اينترنت) و كاربران آن باشد و بنابراين معماري سرویس گرا بوجود آمد.
اين معماري توسط دو شركت IBM , Microsoft بوجود آمد، كه هر دو شركت طي سالهاي اخير از حاميان اصلي سرویس هاي وب و عامل بسياري از ابداعات جديد در حيطه ی سرویس هاي وب، مانند UDDI ,WSE بوده اند.
قابل ذكر است، كه در آخرين معماري در حال توسعه، در توليد نرم افزار كه هنوز هم در مرحله

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

سرويس ها چه هستند؟
بسياري از ما آنقدر با تكنولوژي هاي سرويس هاي وب آشنا هستيم كه اغلب درباره اين كه خود سرويس ها واقعا چه هستند، فكر نمي كنيم. هر كس كه از سايت هاي تجارت الكترونيكي به صورت آنلاين خريد كرده باشد، با مفهوم سرويس ها آشنا است. وقتي كه سفارش تا ن را داديد، بايد اطلاعات كارت اعتباري تان را ارايه كنيد كه به طور معمول توسط يك فراهم كننده سرويس ثانويه، تاييد و شارژ مي شود. وقتي كه سفارش پذيرفته شد، شركت سفارش گيرنده با يك شركت فراهم كننده سرويس حمل ونقل سرویستان را فراهم مي كند و در نهايت كالاي شما تحويلتان مي شود.
در ادامه سه تعريف مي آوريم كه در كنار يكديگر ماهيت يك سرويس راشرح مي دهند:
۱- سرويس ها اجزاء مستقلي هستند كه پيغام هاي XML با ساختار مشخص و خوش تعريف را پردازش مي‏كنند.
• XML ساده ترین ورژن SGML استاندارد برای ایجاد و طراحی سند های HTML است(مناسب برای استفاده در سایت های اینتر نتی).
• SGML يك استاندارد مديريت اطلاعات است كه در سال 1986 به وسيله سازمان بين المللى استاندارد سازى (ISO) معرفى گرديد و وسيله اى است براى ارائه اسناد مستقل از يك سيستم يا برنامه كاربردى خاص ضمن به كارگيرى اطلاعاتى چون قالب بندى، شاخص دهى و حفظ اطلاعات پيوندى در اسناد.
۲- سرويس ها داراي رابط هاي خوش تعريف هستند كه به وسيله يك سند مبتني بر XML كه سند
WSDLخوانده مي شود، به اين سند گاهي قرارداد WSDL نيز گفته مي شود، پردازش می شوند. محتويات اين سند،‌ عملياتی (متدهايي) كه توسط سرويس ارائه مي شود را شرح مي دهد. از

جمله اطلاعات مربوط به انواع داده، اطلاعات نحوه اتصال به سرويس، جهت يافتن و ارتباط با عمليات سرويس وب.
۳- سرويس ها داراي نقاط انتهايي (Endpoint)هستند كه استفاده كنندگان از ساير سرويس ها مي‏توانند بر اساس آدرس سرويس (URL)معمولاً به آن ها متصل شوند. اين همان چيزي است كه ارتباط(جفت شدن) آزادانه خوانده مي شود.

 هایی هستند که بر اساس بکارگیری چند سرویس ساده ( یا ترکیبی) ایجاد می شوند. برای مثال، ممکن است سیستم توزیع شده ای بر اساس چند سرویس ساده صدور صورتحساب، ثبت سفارش، مدیریت روابط مشتری و... سرویس های ترکیبی گسترده تری در ارتباط با حرفه اي خاص ایجاد نماید.
پس می توان گفت: سرويس ها اجزاي توزيع شده با رابط هاي تعريف شده و مشخص هستند كه پيغام هاي XML را پردازش و تبادل مي كنند.

معماري سرويس
چندين مصرف‌كننده سرويس مي‌توانند با ارسال پيام اقدام به فراخواني سرويس‌ها نمايند. اين پيام‌ها معمولا توسط يك گذرگاه سرويس تغيير شكل داده شده و به سوي سرويس مناسب هدايت مي‌گردند. معماري سرويس مي‌تواند يك موتور قواعد تجاري را فراهم سازد كه امكان تلفيق قواعد تجاري در يك سرويس يا چندين سرويس را عملي سازد. معماري سرويس مزبور همچنين يك زيربناي مديريت سرويس فراهم مي‌آورد كه سرويس‌ها و اعمالي از قبيل بازرسي، پرداخت صورتحساب، و واقعه‌نگاري (logging) را مديريت مي‌نمايد. به علاوه، اين معماري انعطاف‌پذيري ناشي از دارا بودن فرايندهاي تجاري تغيير پذير را به سازمان‌ها ارزاني مي‌دارد، فرايندهايي كه نيازمندي‌هاي تنظيمي همانند Sarbanes Oxley (SOX) را مد نظر قرار مي‌دهند، و سرويس‌هاي اختصاصي را بدون تحت تاثير قرار دادن ساير سرويس‌ها تغيير مي‌دهند.

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

آنهاست؛ بدين معني كه رابط سرويس، مستقل از پياده‌سازي است.
تعاریف گوناگونی از معماری سرویس گرا ارائه شده است كه از جمله آنها می توان به تعاریف زیر اشاره كرد:
1. مجموعه قوانین، سیاست ها و چارچوب هایی كه نرم افزارها را قادر می سازد تا عملكرد خود را از طریق مجموعه سرویس های مجزا و در عین حال مربوط به هم در اختیار سایر درخواست

كنندگان قرار دهند تا بتوانند بدون اطلاع از نحوه پیاده سازی و تنها از طریق رابط های استاندارد و تعریف شده، این سرویس ها را پیدا كرده و فراخوانی نمایند.
2. روشی برای ساخت سیستم های توزیع شده ای است که در آنها عملکرد سیستم بصورت سرویس در اختیار کاربران و یا سایر سرویس ها قرار می گیرد.
3. از دیگرتعاریف ارائه شده می توان به "واحدهای نرم افزاری آماده در شبكه (Network-available Software Unit) " یا "سرویس های سطح کسب و کار (Business-level services) " اشاره كرد.
معماري‌هاي سرويس‌گرا داراي خصوصيات اصلي زير هستند:
- سرويس ‌هاي SOA داراي رابط ‌هاي خود توصيف‌گر در اسناد XML مستقل از پلتفرم هستند. زبان توصيف سرويس‌هاي وب (WSDL) استاندارد به كار برده شده براي توصيف اين سرويس‌ها مي‌باشد.
- سرويس‌هاي SOA با پيام‌هايي كه رسماً توسط مدل XML (كه XSD نيز ناميده مي‌شود) تعريف شده‌اند ارتباط برقرار مي‌نمايند. ارتباط ميان مصرف‌كنندگان و فراهم‌كنندگان يا سرويس‌ها معمولا در محيط‌هاي ناهمگن رخ مي‌دهد، با دانش كم يا بدون هيچ دانشي در مورد فراهم‌كننده. پيام‌هاي مبادله شده ميان سرويس‌ها را مي‌توان به عنوان اسناد تجاري مهم پردازش شده در يك سازمان نگريست.
- سرويس‌هاي SOA توسط يك رجيستري كه به عنوان يك فهرست دايركتوري عمل مي‌كند نگهداري مي‌گردند. برنامه‌هاي كاربردي مي‌توانند سرويس‌ها را درون رجيستري جستجو نمايند و سرويس را فراخواني كنند. توصيف، تعريف، و يكپارچگي جهاني (UDDI) استانداردي است كه براي رجيستري سرويس مورد استفاده قرار گرفته است.

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

سرويس وب و استفاده كننده خيلي آزاداترانه ومستقل تر (loosely coupled) است. بعلاوه SOA به خاطر در بر داشتن فاكتورهايي كه اهميت حياتي در تجارت دارند، نيز منحصر به فرد است. فاكتورهايي نظير: قابليت اطمينان سرويس،‌ جامعيت پيام، يكساني تراكنش و امنيت پيام. در امور تجاري واقعي نمي توان روي سرويس هايي كه يك درخواست را فقط به خاطر اين كه بتوانند بفهمند،‌ پردازش مي كنند حساب كرد. در امور تجاري به قطعيت و اطمينان بيشتري نياز است. واضح است كه سيستم هاي مختلف ممكن است بعضي اوقات غير فعال باشند و يا پاسخگويي آ

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

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

جريان كار نمي توانند كل فرايند تجاري را از كار بياندازند.
در حال حاضر، تکنولوژی سرویس های وب(Web Services)و پیاده سازی نمونه های موفق از آن، نشان داده است که SOA می تواند به عنوان راه حلی عملی و دست یافتنی در طراحی سیستم های جدید و یکپارچه سازی سیستم های بزرگ موجود، مطرح گردد. البته ذکر تفاوت سرویس ها

ی وب و SOA در اینجا لازم به نظر می رسد:
سرویس های وب مجموعه ای از تکنولوژی هایی همچون XML,SOAP,WSDL و UDDI می باشد که امکان ارائه راه حل و برنامه نویسی جهت رفع مشکلی خاص را فراهم می نماید.
در حالی که SOA یک معماری است و از مجموعه مشخصی از تکنولوژی ها فراتر می باشد. اگرچ

ه SOA بر اساس این تکنولوژی ها راه حل ارائه می نماید، اما در عین حال مستقل از هر یک از آنها است.
آنچه اهمیت دارد تعریف سرویس به عنوان مهمترین عنصر این معماری می باشد.
سرویس، رفتار قرادادی تعریف شده ایست که هر قطعه ای می تواند آن را جهت استفاده سایر قطعات در سیستم تهیه و پیاده سازی نماید.
در این معماری، همه توابع به عنوان سرویس تعریف می گردند. این توابع شامل توابع کسب و کار (Business functions) و تراكنش های حرفه‌ای (Business transactions) می باشند كه تراكنش های حرفه ی خود شامل توابع سطح پایین (Low-level functions) و توابع سیستمی سرویس ها(System service functions) هستند.
سرویس ها بصورت مستقل طراحی و پیاده سازی شده و به عنوان جعبه سیاه عمل می نمایند. قطعات دیگر در خارج از این قطعه نیازی به دانستن نحوه انجام کار در این سرویس را ندارند و تنها به نتیجه آن نیازمندند.
قطعات، سرویس های خود را از طریق رابط ها (interface) در اختیار قطعات دیگر قرار می دهند که این رابط ها قابل دستیابی و فراخوانی هستند، بدون اینکه محل قرار گیری آنها اهمیت داشته باشد (رابط های محلی یا دور). در ضمن این رابط ها می توانند به همان نرم افزار كاربردی یا به آدرس

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

مهمترين مفاهيم و اصول در نظر گرفته شده در طراحي سرويس گرا به شرح زير مي باشد:
1- كپسوله سازي سرويس (service encapsulation) تاكيد بر متمركز كردن عمليات وابسته به داده در يك واحد (كپسول) مشخص و پنهان كردن پياده سازي و مكانيزم درون واحد نرم افزاري است.
2- اتصال آزاد بين سرويس ها (service loose coupling) تاكيد بر استقلال سرويس ها و كاهش وابستگي سرويس ها به يكديگر است فقط كافي است سرويس ها از وجود هم آگاه باشند.
3- قرارداد سرويس دهي (service contract) ارتباط بين سرويس ها بر اساس قرارداد تعريف شده اي است كه در اسناد فني بطور مشخص ذكر مي شود.
4- مجرد ساختن سرويس (service abstraction) تاكيد بر جدا كردن پياده سازي از رابط (جهان خارج) و پنهان كردن مكانيزم و نحوه انجام كار در درون واحد ارائه دهنده ی سرويس مي باشد.
5- استفاده مجدد و بازبكارگيري سرويس (service reusability) تاكيد بر طراحي سرويس ها به نحوي است كه بتوان آنها را در سامانه هاي مختلف بكار برد. با تاكيد بيشتر بر استفاده مجدد.
6- قابليت تركيب سرويس (service composability) به معني آنست كه سرويس ها به نحوي طراحي شوند كه با برخورداري از قابليت تركيب شدن ايجاد سرويس هاي مركب (كامپوزيت) امكان پذير باشد.
7- خودگرداني سرويس (service autonomy) عبارتست از قابليت و قدرت سرويس در بكارگيري و مديريت منابع خود بطور مستقل و همچنين كنترل كامل بر منطق پياده سازي خود.
8- بدون حالت بودن سرويس (service statelessness) به اين معني است كه سرويس بايد در مورد فعاليت هاي گذشته (فراخواني هاي گذشته) كمترين اطلاعات را نگهدارد و تاكيد بر طراحي سرويس بنحوي است كه حالت هاي وابسته به گذشته كمتري داشته باشد.
9- قابليت كشف شدن سرويس (service discoverability) به اين معني است كه سرويس بايد در يك محيط شبكه با استفاده از سازوكارهاي مناسب توسط برنامه هاي ديگر آشكار شود.
به بيان كلي،‌ SOA فرايندي تكامل يافته را ارائه مي نمايد و ازاين نظر مي تواند آن را بلوغ سروي

س هاي وب و تكنولوژي هاي يكپارچه سازي به حساب آورد. در SOA به اين امر توجه شده است كه سيستم هاي با اهميت حياتي كه بر مبناي تكنولوژي هاي توزيع شده ساخته مي شوند، بايد تضمين هاي خاصي را تامين نمايند. در اين گونه سيستم ها بايد اين اطمينان وجود داشته باشد كه در خواست هاي سرويس به طور صحيح مسير دهي و هدايت مي شوند، در زمان مناسب به

آن ها پاسخ داده مي شود، و اين سرويس ها به طور واضح و دقيق سياست هاي ارتباطي و رابط هاي خود را اعلام مي كنند.

شکل 1- SOA کارها را تغییر می دهد

SOAP, WSDL, UDDI
WSDL، UDDI و SOAP قطعات اساسي زيربناي SOA هستند WSDL .براي توصيف سرويس به كار برده شده است؛UDDI، براي ثبت و جستجوي سرويس‌ها وSOAP، به عنوان يك لايه نقل و انتقال جهت ارسال پيام‌ها ميان مصرف‌كننده سرويس و فراهم‌كننده سرويس. در حالي كه SOAP ساز و كار پيش‌فرض براي سرويس‌هاي وب است، تكنولوژي‌هاي جايگزين، انواع ديگري از انقيادها (binding) را براي يك سرويس تحقق مي‌بخشند. يك مصرف‌كننده مي‌تواند به جستجوي يك سرويس در رجيستري UDDI بپردازد، WSDL را براي سرويسي كه داراي توصيف است تهيه نمايد، و سرويس را از طريق SOAP فراخواني كند.

چرا SOA؟
واقعيت موجود در سازمان‌هاي IT اين است كه زيربنا در ميان سيستم‌هاي عامل، برنامه‌هاي كاربردي، نرم‌افزارهاي سيستمي، و زيربناي كاربردي به صورت ناهمگن است. برخي برنامه‌هاي كاربردي موجود براي اجراي فرايندهاي فعلي تجارت مورد استفاده قرار گرفته‌اند، بنابراين آغاز از صفر براي ساختن زيربناي جديد يك رويكرد قابل انتخاب محسوب نمي‌گردد. سازمان‌ها بايد به شكلي

سريع به تغييرات تجاري واكنش نشان دهند؛ از سرمايه‌هاي موجود در برنامه‌هاي كاربردي و زيربناي كاربردي به منظور تمركز بر روي نيازمندي‌هاي تجاري جديدتر استفاده نمايند؛ كانال‌هاي جديد تعامل با مشتريان، شركا، و تامين‌كنندگان را پشتيباني كنند؛ و يك معماري كه تجارت ارگانيك را پشتيباني نمايد به كار گيرند. SOA با طبيعت اتصال آزادانه خود به سازمان ‌ها امكان بهره‌گيري از سرويس‌هاي جديد يا ارتقاي سرويس‌هاي موجود را به شيوه‌اي قطعه‌ قطعه به منظور تمركز بر نيازمندي‌هاي تجاري فراهم مي‌آورد، امكاني را براي قابل استفاده نمودن سرويس‌ها در كانال‌هاي متفاوت فراهم

مي‌سازد، و سازمان موجود و برنامه‌هاي كاربردي نسل قبل را به عنوان سرويس‌ها ارائه مي‌كند، در نتيجه سرمايه‌هاي زيربناي IT موجود را حراست مي‌نمايد.
يك سازمان استفاده كننده از SOA مي‌تواند يك برنامه كاربردي مركب زنجيره تامين را با استفاده از مجموعه‌اي از برنامه‌هاي كاربردي موجود كه كاركرد خود را از طريق رابط‌هاي استاندارد ارائه مي‌دهند، ايجاد نمايد.

شکل 2 - مقایسه ی دو نوع معماری
SOA سرويس‌ وب نيست
آن گونه كه به نظر مي‌رسد در مورد ارتباط ميان SOA و سرويس‌هاي وب نوعي سردرگمي عمومي وجود دارد. در يكي از گزارش‌هاي Gartner مورخ آوريل 2003، Yefim V. Natis اين گونه تقاوت ميان آنها را شرح مي‌دهد: "سرويس‌هاي وب راجع به مشخصه‌هاي تكنولوژي هستند، در حالي كه SOA يك قاعده‌ي طراحي نرم‌افزار است."شايان ذكر است كه WSDL سرويس‌هاي وب يك استاندارد تعريف رابط مناسب SOA است: اين نقطه‌اي است كه سرويس‌هاي وب و SOA اساسا به يكديگر پيوند مي‌خورند. اساساً،SOA یك الگوي معماري است، در حالي كه سرويس‌هاي وب سرويس‌هاي پياده‌سازي شده توسط مجموعه‌اي از استانداردها مي‌باشند؛ سرويس‌هاي وب يكي از روش‌هايي است كه شما با استفاده از آن مي‌توانيد SOA را پياده‌سازي نماييد. مزيت پياده‌سازي SOA با سرويس‌هاي وب اين است كه شما به يك رويكرد بي‌طرفانه نسبت به پلات‌فرم به منظور دستيابي به سرويس‌ها و interoperability بهتر دست مي‌يابيد همچنان كه فروشندگان بيشتر و بيشتري مشخصه‌هاي بيشتر و بيشتري از سرويس‌هاي وب را پشتيباني مي‌نمايند.

معرفي 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)پيغام رساني مطمئن سرويس وب: مكانيسم هايي براي تضمين اطمينان از رسيدن پيغام، حتي در صورتي كه يك يا چند سرويس در زنجيره سرويس ها قابل دسترس نباشند، را فراهم مي سازد. اين مشخصه شامل روش هايي براي اعلام رسيدن پيغام است، به طوري كه فرستنده بتواند بفهمد كه آيا گيرنده در دريافت پيغام موفق بوده است يا نه

.
با معرفي و ثبت مشخصه هاي جديد و بهبود مشخصه هاي قبلي، مشخصه هاي سرويس هاي وب دائما ًدر حال تكامل هستند. البته، مجموعه مشخصه هاي پايه اي كه در این مقاله بيان شد، احتمالاً براي مدتي به عنوان زير بناي اصلي مشخصه هاي سرويس هاي وب باقي خواهند ماند،‌ چرا كه اين مشخصه ها نيازهاي اصلي و بنيادي برنامه هاي كاربردي سرويس گرا را پوشش مي دهند.

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

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

شکل 3 - معماری سرویس گرای مقدماتی

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

شده مستند گردیده است و نه تنها بوسیله خود تهیه کننده بلکه توسط سایر عواملی که از نحوه پیاده سازی آن خبر ندارند، نیز قابل استفاده و فراخوانی است. این ویژگی جعبه سیاه بودن سرویس از اصل ماژولاریتی در مهندسی نرم افزار به ارث رسیده است. البته سرویس با تعاریفی مانند ماژول، قطعه نرم افزاری یا شی تفاوت دارد، زیرا نه تنها در سطح برنامه ها و نرم افزارهای کاربردی، بلکه در سطح حرفه و حتی مابین سازمان ها نیز قابل بكارگیری و استفاده مجدد می باشد.
در واقع سرویس ها، نمایش عملکرد معنی داری از حرفه هستند که می توانند بنا به نیاز مشتری در سرویس ها و توابع بزرگتر یا جدید بکار گرفته شوند.
رابط ها به سادگی مکانیزمی جهت برقراری ارتباط بین سرویس و نرم افزارها یا سایر سرویس ها ایجاد می نمایند. از لحاظ تکنیکی، رابط سرویس ها، توضیحاتی در مورد نام و امضاء متدهای یک سرویس هستند که توسط درخواست کننده، قابل فراخوانی می باشند.
معماری سرویس گرای توسعه یافته
معماری سرویس گرای مقدماتی به برخی از مسائل موجود در یک معماری مبتنی بر سرویس نمی پردازد. از جمله این مسائل، مدیریت، هماهنگ سازی سرویس ها، متناسب کردن آنها، امنیت، مدیریت تراکنش ها و... می باشد. این نکات که در شکل 2 نمایش داده شده است، در معماری سرویس گرای توسعه یافته در نظر گرفته شده است.

شکل 4 - معماری سرویس گرای توسعه یافته

معماری مقدماتی در لایه پایینی این معماری لایه ای قرار گرفته است. لایه ترکیب سرویس در معماری توسعه یافته، شامل توابع و نقشهای لازم برای یکپارچه کردن چند سرویس به عنوان سرویس ترکیبی می باشد. سرویس ترکیبی بدست آمده، توسط Service Aggregator بعنوان یک سرویس مقدماتی استفاده می گردد و یا توسط درخواست کنندگان سرویس بکارگرفته می شود.
Service Aggregator تهیه کننده سرویسی است که سرویس های ارائه شده توسط سایر تهیه کنندگان را یکپارچه می نماید تا از آنها سرویس های جدید بسازد، همچنین مشخصات و کدهایی را تهیه می کند تا در مورد سرویس های ترکیبی عملیات زیر را انجام دهد:
- متناسب کردن: کنترل اجرای سرویس های ترکیب شده و مدیریت گردش داده ها در بین آنها و انتقال آن به خروجی.

- کنترل کردن: مجوز دادن به رخدادها و اطلاعات تولید شده توسط سرویس های ترکیبی جهت به اشتراک گذاشتن و منتشر کردن رخدادهای ترکیبی سطح بالاتر ( برای مثال از طریق فیلتر کردن و خلاصه سازی).
- مطابقت دادن: حصول اطمینان از حفظ جامعیت سرویس های ترکیبی از طریق تطبیق دادن

محدودیت ها و نوع پارامترهای سرویس های بکار رفته.
- ترکیب خواص سرویس ها: بکارگیری، مجتمع سازی و دسته بندی ویژگی های سرویس های ترکیب شده جهت بدست آوردن خواص ترکیبی جدید که دربردارنده کارایی، هزینه، امنیت، جامعیت، قیاس پذیری، در دسترس بودن و قابلیت اطمینان می باشد.
استانداردهای جدید ارائه شده با عنوان زبان اجرای پردازشهای حرفه برای سرویس های وب، تلاشی است که بر اساس XML، تعریف سرویس های وب جدید را که از ترکیب سرویس های موجود بدست می آیند، ارائه دهد. یک پردازش BPEL بصورت انتزاعی با ارجاع و اتصال به portTypeهای تعیین شده در WSDL ای ایجاد می شود كه در سرویسهای وب موجود در یک پردازش، تعریف شده است.
مدیریت نرم افزارهای کاربردی مهم و بحرانی تجارت الکترونیک، می بایست نظارت عمیق و جامعی در محیط های توزیع شده داشته باشد. خارج از دسترس بودن یک عنصر کلیدی در سیستم های توزیع شده، تاثیر منفی زیادی بر کل چرخه گذاشته و باعث بیرون رانده شدن ارائه کننده سرویس از بازار می شود.
برای رویارویی با چنین موقعیت هایی، سازمان ها نیاز به کنترل دائم سرویس و حصول اطمینان از سلامتی سیستم دارند. کارایی می بایست همیشه، در هر شرایطی و با هر بار کاری، در سطح قابل قبولی باشد.
برای مدیریت قسمتهای مهم و بحرانی و سرویس های ویژه، معماری توسعه یافته، در لایه مدیریت سرویس بعنوان بالاترین سطح، سرویس های مدیریت شده را ارائه کرده است.
این لایه شامل دو قسمت مدیریت عملکرد و مدیریت بازار می باشد. کارکرد مدیریت عملکرد بدین صورت است که قسمتهای مهم سیستم را پشتیبانی می نماید. این لایه جزئیاتی از کارایی سیستم را جهت ارزیابی آن ارائه می دهد و بدین صورت سازمان را قادر می سازد تا بر اساس وضعیت نرم افزار و تکمیل شدن تراکنش های حرفه، تصمیم گیری نماید. اپراتور سرویس، مسئول انجام امور مربوط به این واحد است. مدیریت عملکرد، قابلیت بسیار مهم و کلیدی است که می تواند صحت و کارایی کلی سیستم را کنترل نماید و بدین ترتیب از بروز مشکلات شدید و خطا در سرویس ها جلوگیری کند.
این خطاها ممکن است بر اثر اجتماع و هماهنگ سازی سرویس ها و بخاطر عدم رعایت توافق های در سطح سرویس (SLA) اتفاق بی افتد.
مدیریت و کنترل های مناسب باعث کاهش احتمال بروز چنین خطاهایی می شود؛ بدین ترتیب که صحت، پایداری و همچنین مناسب بودن ارتباط بین توابع بکار رفته در سرویس های ورودی و خروجی را بررسی و کنترل می نماید.
قسمت دیگر در لایه مدیریت، مدیریت بازار می باشد. مسئولیت این واحد ارائه پروتکل ها و قوانین استاندارد در سطح حرفه می باشد تا از این طریق امکان استفاده از سرویسهای تعبیه شده در بازارهای مختلف بوجود آید.

در ضمن برخی از تسهیلات و سرویسهای پایه برای امور مالی، تضمین کیفیت و... در این لایه قرار می گیرد تا از این طریق بازارهای مختلف بتوانند در کمترین زمان به سرویس ها دسترسی یابند.
این قسمت از لایه مدیریت، توسط سازندگان بازار که کنسرسیومی از شرکت های فعال د
می توان معماری سرویس گرا را روشی در جهت بهبود طراحی و استفاده از سیستم های نرم افزاری دانست، اگرچه مشكلات و چالش های پیش روی آن همچنان نیازمند بررسی تجارب گذشته و نیز ارائه راه حل مناسب پیرامون مسائل مطرح در این معماری می باشند.

معماري سرويس گرا در توليد نرم افزار
همان طور كه در عنوان آن مشخص است، به مفهومي در سطح معماري، اشاره مي كند و بنابراين در مورد چيزي پايه اي و اساسي در سطوح بالا است، كه پايه و اساس آن تجربيات بدست آمده در توليد سيستم هاي نرم افزاري مبتني بر CBD و دو اصل اساسي در صنعت مهندسي نرم افزار يعني توليد نرم افزار بصورت با همبستگي زياد و در عين حال با چسبندگي كم است. بنابراين ايده هاي برنامه نويسي سرویس گرا ايده اي جديد نيست و شما شايد قبلا از آن استفاده كرده باشيد. اما جمع آوري بهترين تجربيات از توليد چنين سيستم هايي بصورت مجتمع و ناظر به وضعيت تكنولوژيكي امروز بشر، كه همان مفاهيم مطرح شده در معماري سرویس گرا است چيز جديدي است.
مهندسان نرم افزار، هميشه گفته اند كه نرم افزار بايد به شكلي نوشته شود كه همبستگي زياد ولي در عين حال اتصال كمي داشته باشد. شركت هاي بزرگ نرم افزاري هم در جهت گام برداشتن براي رسيدن به اين دو اصل، تكنولوژي هايي را بوجود آوردند كه به برنامه نويسان اجازه دهد تا به اين دو هدف در توليد نرم افزارهاي خود تا حد زيادي دست يابند. براي مثال مي توان به تكنولوژي هايي مانند COM+ , CORBA و RMI و موارد ديگر، اشاره كرد. مشاهده كرديد كه موضوع برنامه نويسي سرویس گرا، مفهموم جديدي نيست و اين معماري تلاشي ديگر در جهت توليد نرم افزارهاي با همبستگي زياد و در عين حال با چسبندگي و اتصال كم است. ممكن است بپرسيد، پس چرا با وجود تكنولوژي هاي قدرتمندي چون CORBA ,COM+ ,RMI چيز جديدي بوجود آمد؟ مگر تكنولوژي هاي قبلي موفق نبودند؟ بله مهمترين اشكال در معماري هاي قدرتمندي چون موارد مذكور اين بود كه توليد كنندگان آنها سعي داشتند، كه تكنولوژي خود را بر بازار غالب نمايند. رويايي كه هرگز به حقيقت نمي پيوست.
بنابراين با توجه به اين موضوع كه اين تكنولوژي ها قادر به تعامل مناسب با يكديگر نبودند عملاً اصل همبستگي زياد بصورت خود بخود رد مي شد. البته معماري هاي مذكور اشكالات ديگري هم داشتند كه نسبت به مورد بالا از اهميت كمتري برخوردار است كه از جمله آنها مي توان به عدم هماهنگي با اصول امنيتي مورد استفاده در اينترنت اشاره كرد. البته بعدها راه حل هايي هم براي اين مشكل بوجود آمد) مانند (RPC Over HTTP اما به اين علت كه از روز اول، در طراحي اين تكنولوژي ها اين امر در نظر گرفته نشده بود، از كارايي مناسبي برخوردار نبودند. مفهموم همبستگي زياد و در عين حال با چسبندگي و اتصال كم، وقتي بخواهد در جهت ارزيابي يك

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

نيستند، اما سيستم هايي كه بر اساس معماري سرویس گرا طراحي و پياده سازي شده اند، نشان داده اند كه توانسته اند تا حد بسيار زيادي ويژگي هاي همبستگي زياد و در عين حال چسبندگي كم را بخوبي در خود ايجاد و حفظ كنند.
در چهار دهه اخیر، پیچیدگی نرم افزارها روز به روز بیشتر شده و تقاضا برای نرم افزارهای قدرتمندتر افزایش یافته است. در این میان، به نظر می رسد که روش های قدیمی جوابگوی نیازهای در حال رشد کنونی نیستند و نیاز به ایجاد و بکارگیری روش هایی است که بوسیله آنها بتوان بر این پیچیدگی ها در زمان هایی کوتاه تر غلبه کرد. از طرفی امكان كنار گذاشتن سیستم های نرم افزاری موجود که تا به حال مشغول سرویس دهی به مشتریان بوده اند، وجود ندارد و می بایست سیستم های جدید را بصورت یکپارچه و در کنار همین سیستم ها بوجود آورد. معماری سرویس گرا، با تکیه بر محاسبات توزیع شده و بر پایه شبکه ها و لایه های میانی و همچنین زبان هایی که تولید نرم افزارهای توزیع شده را فراهم می كنند، بعنوان راه حلی مناسب جهت از میان برداشتن مشکلات و مسائل مذكور مطرح گردیده است.
در روش فوق هدف فقط اینکه سیستمی داشته باشیم که بتواند سرویس بدهد نیست بگونه ای دیگر در این روش طراح مثلا به حسابداری به عنوان یک سیستم خاص نباید نگاه کند که به دیگرسیستم ها سرویس می دهد و کار حسابداری انجام می دهد بلکه باید به این شکل نگاه شود که مجوعه سرویس هایی آماده شود براساس فرآیند های سیستم حسابداری که این سرویسها در presentation layer ای می توانند توسط یک نرم افزار یا بصورت سناریو های مختلف در جاهای مختلف فرآخوانی شده و یک فرآیند یا بخشی از فرآیند مربوط به حسابداری راانجام دهند که می توانند هر بخشی از این فرآیند مربوط به یک کار یا سیستم باشد مثلا در سیستم های ERP درسازمانها می توان فرآیند درخواست جنس از یک مجتمع تولیدی را توسط مشتری در نظر بگیریم می توان سناریوئی چید تا درخواست مشتری بررسی, درصورت عدم وجود جنس درخواست

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