اطلاعاتی و فناوری است، این قوانین ناظر بر چگونگی استفاده از منابع نرم‌افزاری و فناوری می‌باشد. طراح و پیاده سازان سیستم‌های اطلاعاتی و متخصصان فناوری مسئول کنترل و اعمال این نوع قوانین هستند.
از نگاه این لایه، هدف معماری سرویسگرا در نهایت حل معضل تعامل پذیری بین سیستم‌های اطلاعاتی با فناوری ها و سکوهای مختلف است و این امر با کمک تعریف پروتکل‌های مستقل از سکو و استاندارد و ایجاد سرویس‌های وب مهیا می‌شود.
2-4-7-عوامل بحرانی موفقیت 35سرویسگرایی
برای حصول اطمینان رسیدن به اهداف سازمانی، در حوزه‌های تعریف شده هر یک از این عوامل بحرانی، داشتن کارائی خوب و بالا برای موفقیت‌آمیز بودن پیاده‌سازی سرویسگرا لازم است. بدین‌سان عوامل بحرانی موفقیت هم چون متغیرهای نهفته‌ای هستند که با تجزیه و تحلیل متغیرهای خاص سازمانی به دست می‌آیند. پیاده‌سازی سرویسگرا همانند یک پروژه فناوری اطلاعات است پس عوامل مدیرتی پروژه‌های فناوری اطلاعات مثل «شامل کردن تمامی ذی‌نفعان»، «طراحی خوب برای داشتن اساس و پایه قوی»، «اتخاذ36 رویکرد تدریجی»، «حمایت مدیریت ارشد و پشتیبانی قوی»، «آموزش کارکنان برای درک و یادگیری»، «برقرری اتصال مابین فناوری اطلاعات و کسب و و کار»، «موضوعات و مسائل امنیتی» و … همگی از موارد برشمرده شده بحرانی می‌باشند.
Vegter در [22] طبقه‌بندی خود سه عامل «قابلیت استفاده مجدد سرویس‌ها»، «پیچیدگی سرویسگرایی»، «حاکمیت 37فرایندهای اتخاذ سرویسگرایی” را در صدر عوامل می‌داند. [22]
1-تمرکز روی قابلیت استفاده مجدد سرویس‌ها: این ویژگی منجر به افزایش چابکی و نرخ بازگشت سرمایه و صرفه‌جویی در هزینه‌ها می‌شود اما چون سرویس باید طوری ساخته شود که قابلیت استفاده مجدد داشته باشد، خیلی از شرکت‌ها موفق نمی‌شوند. [22]
2-تمرکز روی کاهش پیچیدگی: پیاده‌سازی سرویسگرایی به روش اشتباه موجب افزایش پیچیدگی سازمان می‌شود. برنامه‌های کاربردی سنتی شامل قطعاتی است که توسط سازندگان آن‌ها با اطمینان از درستی عملکرد نرم‌افزار به یکدیگر اتصال یافته است؛ اما در سرویسگرایی تمامی برنامه‌ها و برنامه‌های کاربردی کنترل و مدیریت داده 38،مجددا به هم اتصال می‌یابند39 تا آنجا که کلیه سرویس‌ها با یکدیگر ترکیب می‌شوند تا برنامه‌های جدید را بسازند.از طرفی هر سرویس از لحاظ ” بارگذاری40″،”زمان پاسخ‌گویی”،”ظرفیت 41سرویس” باید کنترل و نظارت شود. [22]
3- حاکمیت سرویسگرایی: حاکمیت بدین معناست که کار هر کسی با دیگران در ارتباط است و تلاش‌های جداگانه موثر نیست. حاکمیت سرویسگرایی بیشتر در ارتباط با مدیریت وابستگی‌های سازمان است. جا کمیت در مورد تصیمیم‌گیری نیست اما راهنمایی‌هایی در ارتباط با تصمیم‌گیرنده و انسجام تصمیم‌ها می‌دهد. سرویسگرایی رویکردی تدریجی است و تمامی مراحل آن باید نظارت و بازبینی شوند. حاکمیت در جهت هدایت تلاش‌های فناوری اطلاعات برای حصول اطمینان از تطبیق کارایی کسب و کار بر فناوری اطلاعات است. هم ترازی فناوری با کسب و کار باعث تحقق مزایای وعده داده شده، بهره‌برداری از فرصت ها و رسیدن به ماکزیم فواید سرویسگرایی می‌شود. حاکمیت همچون مکمل فناوری اطلاعات می‌باشد که رابطه‌ای فشرده مابین کسب و کار در جهت حمایت از مؤلفه‌ها و سرویس‌های فناوری ایجاد می‌کند. با در نظر گرفتن میزان توجه سازمان به مجموعه موارد زیر، میزان حاکمیت سازمان اندازه‌گیری می‌شود:
1-داشتن یک معماری مرجع و تشریح دقیق لایه‌ها، به لاک‌های معماری و الگوهای تعاملی سرویس‌ها.2-بیان دقیق نقش‌ها و مسئولیت‌ها و تدوین توافق‌نامه‌ها.3-رسیدن به یک جامعیت در مورد واژگان تخصصی این حوزه 4-مدیریت سرویس‌ها و قرارداد ها 5-نظارت بر سرویس‌ها 6-مدیریت پیکربندی و تغییرات سرویس‌ها. [22]
2-4-8-برخی چالش‌های مطرح در حوزه سرویسگرایی
معماری سرویسگرا چالش‌های زیادی را در چگونگی استفاده از سرویس‌ها و تعامل آن‌ها با یکدیگر، پیچیدگی در مدیریت تغییر، تست و استقرار سرویس‌ها ایجاد می‌کند. موفقیت معماری سرویسگرا وابستگی زیادی به توانایی سازمان در مدیریت پیچیدگی و رسیدن به بلوغ لازم و ایجاد زیرساخت مناسب در قالب مکانیزم‌های کنترلی و اجرای جهت نگهداری از محیط سرویسگرایی دارد. [44]
دنیای سرویسگرایی مبتنی بر سرویس‌هاست و محاسبات کامپیوتری هم به نیازهای عمکلردی و غیر عملکردی و تعامل با سرویس‌ها بستگی دارد. سرویس‌ها نمی‌توانند به طور خودکار با یکدیگر در ارتباط باشند و به مکانیزم‌هایی برای کشف، مذاکره، فراخوانی، ترکیب و نظارت … در معماری سرویسگرا نیازمند هستند. از طرفی برنامه‌ها و واسط‌هایی باید برای برطرف کردن ناهماهنگی‌های موجود بین داده ها، پروتکل‌ها و فرایند ها برای برقراری تعامل بین سرویس‌ها وجود داشته باشد. در اینجا چند چالش به اختصار عنوان می‌شود.
1-طراحی قابلیت استفاده مجدد سرویس با چالش‌هایی از قبیل زیر مواجه است:1-از آنجا که سرویس در سایر فرایند ها استفاده می‌شود با تغییراتی در واسط‌ها همراه می‌باشد 2-منبع داده سرویس‌ها معمولاً به اندازه کافی عام42 طراحی نمی‌شود 3-نیازمندی‌های مرتبط با امنیت، یکپارچه‌سازی و کارائی ممکن است دست خوش تغییراتی شود.4-از آنجا که سرویس‌ها مالکان متفاوتی دارند برای استفاده از سرویس آن‌ها باید از میزان کیفیت سرویس اطمینان حاصل کرد و حتی ممکن است نیاز به اعمال تغییرایت در سرویس داشته بام اما مالکان برای ایجاد تغییرات محدودیت‌هایی قائل باشد. از جمله راه‌حل‌های مواجه با این مشکلات وجود سه ویژگی زیر کمک زیادی به حل چالش‌ها می‌کند: قابلیت تعمیم43، قابلیت پیکربندی44 و قابلیت توسعه45. [22]
با توجه به اینکه تا چه حد سازمان بر زیر عوامل زیر تمرکز می‌کند، قابلیت استفاده مجدد اندازه‌گیری می‌شود:1-باید واژه‌نامه وسیع و گسترده‌ای در زمینه سرویسگرایی ایجاد شود 2-یک مرکز تعالی عالی برای حاکمیت سرویسگرایی باشد 3-یک متدولوژی خوش‌تعریف برای بهبود سرویس و جمع‌آوری نیازهای کاربری، لازم است 5-اولویت دادن به توسعه سرویس‌های قابل استفاده مجدد بر توسعه سرویس‌های انفرادی. [22]
2-برای رفع چالش‌ها در جهت تمرکز بر کاهش پیچیدگی سرویسگرایی عوامل زیر راه گشا می‌باشد: طبق پیشنهاد IBM باید منطق کسب و کار و پردازش جدا از 46ESB نگه داری شود بدین منظور سرویس‌ها از لحاظ “کارائی”،”مقیاس‌پذیری” و “پایداری47” در سطح گسترده‌تری تست و آزمایش شوند.از طرفی شرکت ها باید استاندارد ها و مشخصات و ابزارهای مخصوص به خود را داشته باشند .میزان اندازه گیری پیچیدگی سازمان با توجه سازمان به زیر عوامل زیر قابل اندازه‌گیری است:1-به دلیل گستردگی استانداردهای سرویسگرایی با توافق از استانداردهایی هم چون SOAP, WSDL , WS-I Basic UDDI, WS-Security ,WS-BPEL ,BPMN, WSRP ,XML Schema استفاده شود.2-کنترل و نظارت بیشتر سرویس‌ها بر بارگذاری”،”زمان پاسخ‌گویی”،”ظرفیت سرویس‌ها3-نگهداری منطق کسب و کار نرم‌افزار ها به طور مجزا از ESB4-استفاده از رویکرد سرویسگرایی فدرال چند دامنه 48در سازمان‌های بزرگ. [22]
2-4-9-گام‌های متدولوژی بهبود مداوم برای معماری سرویسگرا
در حین پیاده‌سازی معماری سرویسگرا در سازمان وضعیت فناوری اطلاعات سازمان و همچنین وضعیت سازمان هر دو تغییر می‌کند. [22] معماری سرویسگرا هم اکنون دارای یک متدولوژی مدون و مورد قبول نبوده و آنچه هم اکنون تحت عنوان روش وجود دارد در حقیقت راهنمائی ها و تمرین‌هایی در این حوزه محسوب می‌شوند. نمونه‌ای از گام‌های متودولوژی همان طور که در شکل (3) می‌بینیم در ادامه بیان‌شده است. [19]
شکل (3)-گام‌های متدولوژی بهبود مداوم برای معماری سرویسگرا [19]
1-تعریف و طراحی سرویس: این مهم‌ترین مرحله در متدولوژی بوده و نیازمندی‌های مربوط به آن از طریق مشتریان داخلی، صاحبان حرفه و شرکاء تجاری بد ست می‌آید. برای تعریف سرویس سه روش وجود دارد: تعریف و پیاده سازی سرویس‌های جدید بر اساس نیازمندی‌ها، تعریف سرویس‌های جدید بر اساس مؤلفه‌ها یا سیستم‌های اطلاعاتی موجود، تعریف سرویس‌ها با ترکیب سرویس‌های موجود. در این راستا طراح سرویس، مدلی را که شامل تعریف و توصیف سرویس‌های مورد نیازاست به کمک زبان‌های موجود مدل‌سازی می‌نماید، وی همچنین باید طریقه پیاده‌سازی و چگونگی ایجاد این سرویس‌ها را تجزیه و تحلیل کند.
2-طراحی کیفیت سرویس: در این گام بهترین سکو و فناوری برای پیاده‌سازی و استقرار سرویس‌ها مدنظر قرار می‌گیرد و شاخص‌هایی مانند قابلیت اطمینان، امنیت، در دسترس بودن و کارائی مورد بررسی قرار گرفته و روش تحقق شاخص‌های کیفیت سرویس را تعیین می‌نماید.
3-پیاده‌سازی و استقرار سرویس‌ها: در این گام بر حسب مدل‌های تهیه شده در گام‌های قبلی، سرویس‌ها پیاده‌سازی و مستقر می‌شوند. در پیاده‌سازی بایست به موضوعاتی چون پیکربندی، مدیریت نسخه ها و رضایتمندی از سرویس ها توجه شود. برآورده نمودن نیازهای کیفیت سرویس نظیر قابلیت اطمینان، امنیت و کارائی نیز از وظایف این فاز است، فعالیت‌های مربوط به تست قبل از استقرار سرویس‌ها ضروری است.
4-هم نواسازی سرویس‌ها: اگرچه از نظر هزینه و زمان هم نواسازی سرویس‌ها بسیار مقرون به صرفه و مطلوب بوده و یکی از اهداف معماری سرویسگرا نیز ایجاد واحدهای قابل استفاده مجدد می‌باشد ولی این گونه سرویس‌های ترکیبی دارای مسائل خاص خود هستند چرا که دارای ارتباط و وابستگی محکمی با سایر سرویس‌ها بوده و می‌بایست موارد مهمی مد نظر قرار گیرد بطوریکه سرویس گیرنده تفاوتی بین این سرویس‌ها و سرویس‌های پایه احساس نکند.
5-انتشار سرویس‌ها: سرویس‌ها در اختیار سرویس گیرندگان قرار می‌گیرد، توصیفات فنی و غیر فنی سرویس‌ها باید تعیین شود.
6-معاهده سطح سرویس: شامل توافق‌های بین منتشرکنندگان و دریافت کنندگان سرویس است و جنبه‌های مختلفی از جمله قابلیت اطمینان، امنیت و کارائی را در بر می‌گیرد.
7-مدیریت و دیده بانی سرویس‌ها: شامل مواردی چون کنترل و دیده بانی کارائی سرویس‌ها، تحلیل گزارشات و آمارها و هماهنگ کردن مستمر سرویس‌ها بر طبق معاهده سطح سرویس است.
8-میزان کردن سرویس‌ها: این گام به تنظیم سرویس‌ها در راستای رفع نواقص و ارتقاء شاخص‌های کارائی اختصاص دارد، داده‌های مورد نیاز برای این منظور از گام قبل بد ست آورده می‌شود. [19]
با توجه به نکات بیان‌شده معماری سرویسگرا، این معماری هم موضوعی فنی است و هم نوعی سبک تفکر، مبتنی بر اتصال سست است و از پیام رسانی استفاده می‌کند، قادر به ساخت سیستم‌های ترکیبی است، از مؤلفه‌های قابل استفاده مجدد (سرویس) تشکیل شده است. [24]
2-5-آشنایی مقدماتی با مبحث فازی
2-5-1- مبحث فازی و استدلال تقریبی
منطق فازی در سال 1965 از سوی پروفسور لطفی زاده استاد دانشگاه برکلی کالیفرنیا، از طریق چاپ مقاله‌ای با عنوان «مجموعه‌های فازی» معرفی شد. منطق فازی معتقد است که ابهام در ماهیت علم است. بر خلاف دیگران که معتقدند که باید تقریب‌ها را دقیق‌تر کرد تا بهره‌وری افزایش یابد، لطفی زاده معتقد است که باید به دنبال ساختن مدل‌هایی بود که ابهام را به عنوان بخشی از سیستم مدل کند. نظریه فازی برای بیان و تشریح عدم قطعیت و عدم دقت در رویدادها بکار می‌رود؛ و کلید اصلی نظریه فازی از منسطق چند ارزشی بو جود آمده است. [27]
عدم اطمینان (ابهام) زمانی ایجاد می‌شود که اطلاعات ناقص باشند اما اطلاعات به شیوه‌های مختلف ناقص و ناکارا مد می‌شوند. ماهیت عدم قطعیت (عدم اطمینان) با توجه به مسئله مورد بررسی می‌بایست توسط تحلیل گر مشخص شود؛ زیرا عدم اطمینان می‌تواند ناشی از «شانس (تصادفی بودن)»، «ابهام»، «کمبود دانش آگاهی» و یا «از عدم دقت» و ابهام ناشی از ناسازگاری (تعارض یا ناهمگنی و اختلاف)، عدم بیان صریح و یا تمایز روشن، گنگ و مغشوش بودن اطلاعات و … باشد. [27]
2-5-2-نظریه فازی
ریاضیات فازی یک فرا مجموعه از منطق بولی است که بر مفهوم درستی نسبی، دلالت
