دانلود پایان نامه

اجرا شوند، تعیین نمود.
سیستم حاکمیت معماری سرویس گرا تعریف می کند که سرویس ها چه حالت هایی دارند؟ چه عملیاتی بایستی برای حرکت از یک مرحله به مرحله بعد (انتقال) انجام شود؟ و در مورد فرایندها و روش ها ( چگونه) و نقش ها (به وسیله چه کسانی) تصمیم گیری می کند. برای مثال حاکمیت معماری سرویس گرا می تواند وضعیت سرویس ها ( شامل تعریف شده، سرمایه گذاری شده، مشخص شده، پیاده سازی شده، تایید شده، عملیاتی شده، منتشر شده، معلق شده) را تعریف نماید. پس از آن سرویس ها بایستی در چرخه حیات توسط زیر ساخت معماری پشتیبانی شوند تا اطمینان نمائیم که فرایند ها در جای خود دنبال شده، اجرا می شوند. رجیستری و انباره سرویس به کاربران اجازه می دهند تا عملیات لازم را روی سرویس ها انجام دهند. بنابراین چرخه عمر سرویس ها مرتبا در حال تغییر است. ابزار مدیریت سبد64 پروژه نیز لازم است تا کاربران و تنها آنهایی که مجوز دارند، سرویس ها را تغییر داده و به کاربران استفاده کننده، اطلاع رسانی کنند.
صاحب نظران و شرکت های فعال در زمینه معماری سرویس گرا چرخه های حیات مختلفی را برای سرویس ارائه نموده اند. با این وجود تمام ایده ها و مدل های ارائه شده، در برگیرنده فعالیت های مشترکی هستند که برای ایجاد یک سرویس از ابتدا تا انتها لازم است.
3.8.2 چرخه حیات سرویس
مدیریت چرخه حیات سرویس ، گسترش چرخه حیات توسعه نرم افزار سازمان است با اضافه کردن یا تاکید بر فعالیت های لازم برای چرخه حیات سرویس. مدیریت چرخه حیات سرویس در نظر گرفته شده در این تحقیق شامل فرایندهای زیر می باشد.
1) مدل کردن سرویس : شامل تعریف فعالیت ها برای مدل کردن سرویس است که تمام جوانب ضروری برای تعریف کامل یک قرار داد سرویس و راهنمای ساخت را در نظر می گیرد.
2) ساخت سرویس : شامل فعالیت های ساخت سرویس می باشد.این فرایند می تواند منجر به چندین استاندارد با هدف ارائه دستورالعمل برای زبان برنامه نویسی یا تکنولوژی مورد استفاده توسط سازمان،به منظور توسعه سرویس شود.
3) تست سرویس : فعالیت هایی برای تست سرویس را تعریف کرده و تمام جنبه های قرار داد سرویس از جمله تست هایی برای ارزیابی SLA را در نظر می گیرد.
4) انتشار سرویس : فعالیت هایی برای انتشار سرویس در رجیستری ها،گذرگاه سرویس سازمان و دیگر ابزار مدیریت سرویس که باید قبل مصرف سرویس توسعه یا پیکربندی شود.
5) استقرار سرویس : شامل فعالیت هایی برای گسترش سرویس در هر محیطی که چشم انداز سازمان را می سازد.
6) کم بها کردن و بی اثر کردن سرویس : فعالیتهایی برای کم بها کردن و بی اثر کردن سرویس،مخصوصا راجع به ارتباط با در خواست کننده سرویس را شامل می شود.
7) نگهداری سرویس: فعالیت هایی برای اجرای نگهداری های اصلاحی و تکاملی سرویس را شامل می شود.
3.8.3 نقاط کنترلی زمان طراحی سرویس
اجرای سیاست ها در زمان طراحی سرویس عمدتا مربوط به کنترل های رجیستری و انباره است. چون رجیستری و انباره، ثبت کننده تعاملات سرویس ها، دارایی ها، مشخصه ها و فراداده ها هستند، می توانند به عنوان یک نقطه بازرسی برای کنترل سیاست ها مدنظر قرار گیرند تا در آنها خط مشی ها و سیاست های تدوین شده مربوط به طراحی این مصنوعات ویژه اجرا شوند. وقتی دارایی های معماری سرویس گرا داخل رجیستری و انباره سرویس منتشر می شوند، سیستم می تواند به طور خودکار کنترل کند که آیا استاندارد های معماری تدوین شده، رعایت شده اند؟ با استفاده از پروتکل XML می توان به طور اتوماتیک دارایی های معماری سرویس گرا را با هم مرتبط ساخته و منتشر نمود. رجیستری و انباره همه جنبه های یک سرویس شامل شرح و توصیف سرویس را در بر می گیرند. برای مثال شما می توانید یک خط مشی را این گونه تنظیم نمائید:
منتشر کننده سرویس باید مطابق فرمت ارائه شده سرویس هایش را نامگذاری نماید.همچنین می توانید مستندات لازم که باید به شرح هر سرویس ضمیمه شود، را مشخص نموده و تعیین کنید که چه وقت و چطور از سرویس استفاده شود. حتی ممکن است الزام نمائید که این سیاست ها بایستی توسط نمایندگانی از مصرف کنندگان سرویس در یک کمیته مورد تایید قرار گیرند.
سیاست های زمان طراحی معمولا برای مصنوعاتی به کار برده می شوند که در برگیرنده فایل های WSDL ،تعاریف شماها، مدل های فرایند و مستند سازی پروژه ها هستند که در زمان ثبت در داخل رجیستری و انباره مورد بررسی قرار می گیرند. مواردی که بهتر است در یک نقطه بازرسی زمان طراحی سرویس ها مورد بررسی و کنترل قرار گیرد عبارتند از:
* مدیریت شناسه65: به منظور تشخیص مجوز ها و مسئولیت ها در انباره/ رجیستری ابتدا لازم است کاربرها، مشتریان سرویس و شرکای دیگر( برای مثال از طریق یک سیستم شناسه کاربری بر اساس ADAP یا دایرکتوری دیگر) شناسایی شوند.فرایند شناسایی برای سنجش کاربری، ثبت اطلاعات جهت ممیزی، افزودن نیازمندی های تایید( اینکه آیا لازم است قبل از به کارگیری یک سرویس، مدیر یا مسئول تایید نماید) و نیازمندی های مبتنی بر نقش یا فرد و دیگر فرایندهای حاکمیت ضروری و لازم است.
* کنترل دسترسی: علاوه بر مدیریت مشخصه، سیستم باید پیکر بندی و ساختار دسترسی مناسب را برای همه دارایی های انباره/ رجیستری پیشنهاد کند. این قابلیت باعث ایجاد امنیت در دارایی ها، خط مشی ها، فرایند های حاکمیت و طبقه بندی دارایی ها می گردد.
* اطلاع رسانی66 خودکار: توانایی برای تحریک تریگر هایی در زمان ایجاد، خواندن، ویرایش یا
حذف فعالیت ها در انباره/ رجیستری این امکان را فراهم می آورد تا فرایند هایی نظیر اعلام هشدار به کاربران مربوطه، کنترل اعتبار محتوا به صورت خودکار انجام گیرد. این تریگرها باید قبل و یا بعد از واکنش مورد نظر تحریک شوند. برای مثال سیاستی ممکن است تدوین شود که تضمین نماید قبل از ایجاد شیء مورد نظر در انباره، ثبت تاییدیه آن انجام شود.
* اعتبار سنجی67 محتوا شامل کنترل اعتبار WSDL، اعتبار سنجی شمای XML، تست برنامه و دیگر کنترل های مربوط به عملکرد آنها است. برای مثال سرویس باید دارای یک واسط خودش فرم و قابل تعامل باشد. بنابراین در رجیستری به طور اتوماتیک کنترل می شود که مستندات WSDL خوش فرم و ساده باشند و با پروفایل های WSI، مطابقت داشته باشند.
* قابلیت تعامل: چگونگی تعامل سرویس ها با استفاده از مجموعه ای از استاندارد ها
* قابلیت کشف: سرویس ها ممکن است به اطلاعات خاصی نظیر توصیفی از سرویس کسب و کار و یا اطلاعات مربوط به محل سرویس ها در کاتالوگ سرویس نیاز داشته باشند. این عناصر امکان کشف سرویس ها را فراهم کرده و از طریق سیاست تعریف می شوند.
* امنیت: تعیین پارامتر های امنیتی برای تامین امنیت در بین سرویس ها
* یگانگی68: سرویس ها نباید با سرویس های موجود در رجیستری هم نام باشند. این مورد به وسیله یک مکانیزم با عنوان فضای نام 69کنترل می شود.
* فرمت داده: سیاست های مربوط به تعیین فرمت داده مشترک، امکان استفاده مجدد از سرویس ها را فراهم می کند. سرویس ها دارای یک فرمت های داده ای مشترک تحت عنوان schema هستند.
* سیاست های مربوط به انتشار، استفاده و معلق شدن سرویس ها

این مطلب رو هم توصیه می کنم بخونین:   منابع و ماخذ پایان نامهدرمان بیماران، اقدامات درمانی، شاخص توده بدنی، تشخیص بیماری

3.8.4 نقاط کنترلی زمان اجرای سرویس
اجرای سیاست های زمان اجرای سرویس ها در چرخه عمر سرویس عمدتا مربوط به سیاست های انتقال و تبادل پیغام بین تامین کننده و مصرف کننده سرویس دهنده است.
اجرای سیاست های زمان اجرا وابسته به زیر ساخت معماری سرویس گرا است. یک محل مناسب برای قرار دادن نقاط اجرای سیاست زمان اجرا، لایه میانی سرویس از زیرساخت معماری سرویس گراست. با اجرای سیاست ها در لایه میانی دیگر نگران تفاوت پروتکل ها و فرمت های مختلف پیغام نخواهید بود. لایه میانی این تفاوت ها را در نظر گرفته و سیاست هایی را به صورت همگن برای همه تامین کنندگان و مصرف کنندگان استفاده می کند. این عملیات از طریق یک عامل یا واسطی که در بین تامین کننده و مشتری قرار می گیرد و یک رجیستری/ انباره که هم نیازهای زمان طراحی سرویس و هم زمان اجرا را پوشش می دهد، صورت می گیرد.

شکل 3.6 اجرای سیاست های زمان اجرا از طریق سیستم انتقال پیام

مطابق شکل بالا واسط انتقال پیغام با رجیستری/ انباره در تعامل است تا سرویس ها و سیاست های زمان اجرای آنها را پیدا کرده و آنها را در طی اجرای سرویس کنترل و اجرا نماید. با وجود این که واسط انتقال پیغام و رجیستری/ انباره از هم جدا شده اند، اما انتقال دهنده پیغام بایستی بتواند سیاست های تعریف شده در رجیستری/ انباره را تفسیر کند.
در یک معماری سرویس گرا، گذر گاه سرویس مسئول سیستم انتقال پیغام و لایه واسط است. واسط های انتقال پیغام تراکنشی را بین تامین کننده سرویس و مشتری سرویس به وجود می آورند و عملیات انتقال داده نظیر مرتب کردن پیغام، تضمین قابلیت اطمینان پیغام و دیگر توانایی های عملیاتی را انجام می دهند. بدون سرویس گرایی، توانایی کنترل کردن و مدیریت پیغام به این روش بدلیل محدودیت پلتفرم وجود ندارد.
بعد از این که مصرف کننده سرویس، سرویسی را پیدا می کند، با اتصال70 به انباره آن را دریافت می کند. این فرایند یک نقطه کنترلی ایده آل برای مذاکره بین تامین کننده سرویس است. قبل از استفاده سرویس، عموما یک توافق نامه سطح سرویس بین مصرف کننده و تامین کننده تنظیم می شود. این توافقنامه در خصوص سیاست های امنیتی، کارایی، دسترس پذیری و سایر نیازمندی های غیر عملکردی سرویس است. توافق نامه مورد نظر پس از تایید در انباره نگهداری می شود.
سیاست های زمان اجرا معمولا برای پیغام هایی به کار برده می شوند که از طریق سیستم انتقال پیغام جریان پیدا می کنند. مواردی که در نقاط کنترلی زمان اجرا مدنظر قرار می گیرد عبارتند از:
* شناسایی مشتری و امنیت: شناسایی برنامه های مشتری برای جلوگیری از دستیابی غیر مجاز به سرویس ها، ایجادامنیت سرویس ها در زمان اجرا و اجرای سیاست هایی برای رمزنگاری (برای پیغام های محرمانه)، استفاده از امضا های دیجیتالی و ثبت آرشیو برای پیگیری.
* قوانین مسیریابی: قوانین مسیریابی زمان اجرا برای کارایی آدرس ،مدیریت نسخه های مختلف سرویس ها و دیگر نیازمندی های عملیاتی است. این قوانین شامل مسیریابی بر اساس محتوا(بررسی محتوای یک پیغام برای پیدا کردن مسیر بر طبق قوانین تعیین شده، برای مثال پردازش انواع دستورات از طریق یک فرایند متفاوت). مسیریابی بر اساس ورژن(برای پشتیبانی از مدیریت نسخه های مختلف سرویس ها) و مسیریابی کیفیت سرویس(دادن اولویت های پردازش مختلف بر اساس اولویت های کسب و کاری و سطوح سرویس تعریف شده) است.
* قوانین انتقال: ترجمه بین پروتکل های مختلف پیغام برای آسان کردن اتصال برنامه یا تغییر داده بین مشتری و تامین کننده.
* سیاست های امنیتی شامل احراز هویت، رمزنگاری، تعیین اختیارات و ….
* اطلاع رسانی و هشداردهی: سیاست های مربوط به اطلاع رسانی و اعلام خطر و افرادی که به آنها اطلاع رسانی شود.
* سنجه ها: شاخص های ک
ارایی71 و معیارهای مورد استفاده برای ارزیابی.

3.9 چرخه حیات حاکمیت
چرخه حیات حاکمیت چارچوب پیشنهادی همانند چارچوب COBIT دارای چهار فاز می باشد.در هر مرحله از چرخه حیات،ما مولفه های اصلی حاکمیت SOAکه شامل فرایند،سیاست،تکنولوژی و اشخاص می باشد را مشخص کردیم.به اختصار مراحل چرخه حیات حاکمیت را بیان کرده و در ادامه به شرح هر یک می پردازیم.
1) برنامه ریزی و سازماندهی:در این فاز مفاهیم استراتژی مانند چشم انداز SOA،سرمایه گذاری استراتژی SOA تعیین می شود وبعد از ارزیابی بلوغ نقشه راه حک.مت SOAفراهم می شود.
2) اکتساب و اجرا : این فاز به تعیین افراد سازمان و تعیین منابع معماری ،استاندارد ها معیارها و قوانین لازمه برای مدیریت فرایند SOA تمرکز دارد،همچنین شکاف بین حاکمیت SOA فعلی و هدف آنالیز شده و مجموعه ای از برنامه گذار تهیه می شود.
3) تحویل و پشتیبانی : به امکان پذیر بودن و قابل تحقق بودن راه حل های تعیین شده در فاز قبل تمرکز دارد.
4) نظارت و ارزیابی : در این فاز فرایند پیروی از سیاست با استفاده از معیار های چک پوینت برای تعیین اینکه آیا چارچوب حاکمیت SOA مناسب بوده یا نیاز به تغییر دارد.

شکل 3.7 شماتیک چارچوب پیشنهادی کوبیت برای معماری سرویس گرا

3.9.1 برنامه ریزی و سازماندهی(PO)
فرآیندهای کنترلی این حوزه، مقولات مرتبط با استراتژیها و تاکتیکها را مورد بررسی قرار میدهد، شناسایی راهکارهایی که SOA از طریق آن راهکارها دارای بیشترین تأثیرگذاری ممکن به منظور دستیابی به اهداف فناوری اطلاعات و کسب وکار باشد، از موضوعات قابل بررسی این حوزه است.

فرایند های کنترلی در این فاز شامل:

3.9.1.1 تدوین یک طرح SOA (PO1)
برنامه ریزی استراتژیک SOA به منظور مدیریت و جهت گیری تمامی منابع SOA و همسو با استراتژی و اولویت های کسب وکار، از جمله نیازمندیهای ضروری سازمانی است.
اهداف کنترلی:
(1 مدیریت ارزش SOA :مدیریت برای تشخیص وجود تمایز بین سرمایه گذاری های اجباری،تداومی و اختیاری که وجه تمایز از طریق پیچیدگی و درجه آزادی تخصیص بودجه ها صورت می گیرد.SOA باید دارای ارائه موثر و کارامد از سرویس های معماری باشد که هر گونه انحراف از طرح ازجمله هزینه،زمان و کارکردی که می تواند بر نتایج مورد انتظار طرح تاثیر بگذارد را هشدار دهد..
2 ) همسوسازی SOAو فناوری اطلاعات و کسب وکار: فرآیندهای آموزش دوسویه و مشارکت متقابل در برنامه ریزی استراتژیک به منظور دستیابی به همسوسازی و یکپارچه سازیSOA و فناوری اطلاعات و کسب وکار را در سازمان خود ایجاد کنید. برای تعیین نیازمندیها، اولویت را بر الزامات و نیازمندیهای مشترکSOA و فناوری اطلاعات و کسب وکار بگذارید.
3)بررسی عملکرد و قابلیت کنونی:دراین فرایند به ارزیابی عملکرد و قابلیت کنونی راه حل ها و سرویس های SOA، ارایه یک سند پایه مقارن با نیازمندیهای آینده پرداخته وبا تعریف عملکردی که سهم سرویس گرایی را در اهداف کسب و کار،عملکرد،ثبات،پیچیدگی،هزینه ها و نقاط ضعف و قوت سازمان را تعیین می کند.
4)طرح استراتژیک SOA : ایجاد یک طرح راهبردی در همکاری با ذی نفعان مرتبط ، چگونگی نقش داشتن اهداف SOA در اهداف استراتژیک سازمان و هزینه ها وریسک های مرتبط را تعریف می کند.برنامه


دیدگاهتان را بنویسید