آشنایی با معماری بر  پایه سرویس

فهرست مطالب

لزوم استفاده از معماری بر پایه سرویس... 4

معرفی سرویس... 8

تاثیر SOA بر هزینه در بخش IT. 8

SOA بعنوان یک طرح استراتژیک... 10

مواردی که در پیاده سازی SOA در سازمان باید در نظر گرفته شود. 11

7 قدم برای پیاده سازی SOA.. 12

قدم اول: انتخاب برنامه. 13

قدم دوم:نگاشت سرویسها 14

قدم سوم:ایجاد ارتباط بین سرویس ها 15

قدم چهارم:پیاده سازی توالی رویداد بین سرویس ها 15

قدم پنجم: انتقال سرویسها به کاربران توسط یک رابط کاربری غنی.. 16

قدم ششم:ارائه داشبورد مدیریتی همزمان. 17

قدم هفتم:امن سازی بستر ارتباطی.. 18

برنامه پیشنهادی برای اجرای SOA در سازمان. 19

برنامه های کاربردی لازم جهت توسعه. 20

کلیات مفاهیم SOA.. 22

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

دلیل استفاده از SOAچیست؟. 22

معماری سرویس... 23

زیربنای SOA.. 23

SOAP, WSDL, UDDI 23

کیفیت سرویس‌ها 24

امنیت.. 24

قابلیت اطمینان. 24

خط‌مشی.. 24

هماهنگ‌سازی.. 25

مدیریت.. 25

SOA سرویس‌ وب نیست.. 25

مزایای SOA.. 25

لزوم استفاده از معماری بر پایه سرویس

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

همواره در مسیر رسیدن از مدل تجاری جدید سازمان که بر گرفته از اهداف استراژیک آن سازمان میباشد، به نرم افزار های مورد نظر جهت پیاده سازی و اجرایی نمودن آن مدل فاصله زمانی و هزینه فراوانی[1] وجود دارد جهت رفع این فاصله نیاز به راهکار نرم افزاری مناسبی میباشد که به کمک آن بتوان این فاصله زمانی را به حداقل رساند.

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

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

میتوان این معماری یکپارچه را با مثال زیر ملموس تر گرداند. شرکتی را در نظر بگیرید که فقط شامل یک واحد باشد مسلماً این بخش میبایست کارهای مالی، بازرگانی و منابع انسانی را همزمان انجام دهد مبرهم است که مدیریت این بخش بسیار پیچیده خواهد بود حال تصور کنید که این سازمان به سه بخش گوناگون تقسیم گردد یک بخش مالی یک بخش منابع انسانی و بخش آخر مسائل بازرگانی را انجام دهد اما امکان تعامل با یکدیگر را نداشته باشند مسلما در این مدل کارها راحت تر و منظم تر خواهد بود اما بدلیل عدم تعامل درست هزینه بیشتری را سازمان متحمل میگردد و بسیاری از روالها تکراری خواهد بود حال مدل نهایی را تصور نمایید که هر بخش دارای مدیریت مجزا باشد و بتواند با سایر بخش ها در صورت لزوم ارتباط و تعامل بر قرار نماید در این صورت بدلیل اینکه هر بخش مجزا مدیریت میگردد مدیزیت آن راحت تر بوده و از آنجا که امکان تعامل وجود دارد از پتانسیل 100% هر بخش استفاده میگردد این مدل های ارائه گردیده مثالی بود جهت نمود دادن به سیر تکاملی معماری نرم افزار از گذشته به امروز و مدل نهایی ارائه گردیده نیز مبین معماری سرویس گرا میباشد.

در معماری سرویس گرا[2] در حقیقت از معماری شبکه کامپیوتر تبعیت میکنند همانگونه که در محیط اینترنت[3] به کاربران سرویس های گوناگونی ارائه میگردد مانند سرویس چت، ایمیل،بلاگ،وب سایت و سایر خدمات دیگر این سرویس ها همگی از بستر مشترکی استفاده مینمایند و با یکدیگر به راحتی در تعامل و رد و بدل کردن اصلاعات میباشند و شما جهت استفاده از سرویس جدید نیازی به خریداری تجهیزات یا کامپیوتر جدید نخواهید داشت، فقط کافیست به بستر ازتباطی اینترنت متصل گردید. در معماری ارائه گردیده در معماری مبتنی بر سرویس نیز این ماهیت وجود دارد که شما از سرویس های گوناگون (برنامه های گوناگون) استفاده خواهید نمود فقط کافیست به بستر اطلاعاتی متصل گردید و سرویس های گوناگون نیز به راحتی با یکدیگر در تعامل خواهند بود زیرا بستر مشترکی بین آنها وجود دارد شایان ذکر است در محیط اینترنت برای ایجاد این بستر از پروتکل مشترک[4] استفاده میگردد و لایه های امنیتی داده بر روی این بستر اعمال میگردد در معماری مبتنی بر سرویس نیز پروتکل مشترکی[5] بین سرویس ها وجود دارد و لایه های امنیتی بر روی این پروتکل اعمال میگردد.

در ادامه اشاره کوتاهی به این موضوع خواهیم داشت که چگونه معماری سرویس گرا میتواند در توسعه سیستم و پیاده سازی استراتژی سازمان زمان توسعه را کاهش داده و برای برنامه نویسان محیط راحتی را فراهم نماید.حهت بسط این موضوع از امکان نرم افزاری Oracle Fusion Middleware استفاده گردیده است که معروف ترین زیر ساخت برنامه نویسی در جهان میباشد.منظور از زیر ساخت ایجاد امکانات لازم و سرویس های لازم میباشد نه اینکه یک محیط برنامه نویسی جهت توسعه سیستم، جهت بررسی امکانات این زیر ساخت[6] به مقاله معرفی شرکت اراکل مراجعه نمایید.

شرکت اراکل بعنوان پیشکسوت در ایجاد تکنولوژیهای نرم افزاری به کمک مجموعه ابزار خود تحت نام Oracle Fusion Middleware که بر پایه معماری سرویس گرا مبتنی میباشد این امکان را فراهم آورده تا فاصله بین برنامه های سرویس دهنده مانند محصولات شرکت SAP یا IFLEX یا Siebel و سایر سرویس دهنده های مطرح دنیا و یک برنامه چندگانه (برنامه ای که قرار است از سرویس های گوناگون استفاده نماید) را پوشش میدهد. به کمک این مجموعه محصول یک زیر ساخت قابل گسترش کامل و در عین حال ساده جهت استفاده برای برنامه نویس فراهم خواهد گردید تا بتواند برنامه ای بنویسد که از چندین سرویس استفاده مینماید.

از آنجا که فرد برنامه نویس در پیاده سازی خود منوط به استفاده از یک تکنولوژی یا سرویس دهنده خاص نیست بجای تمرکز بر روی تکنولوژی برنامه نویسی انژی خود را بر روی پیاده سازی نیاز تجاری سازمان مصرف مینماید.

معرفی سرویس

سرویس در حقیقت مجموعه خدماتی میباشد که در سازمان به آن نیاز میباشد هم از جهت استفاده و هم از جهت ارائه معماری بر پایه سرویس در حقیقت فرایند های سازمان را به سرویسهای گوناگون شکسته و ارتباط بین سرویس ها را فراهم مینماید سرویس های گوناگون در داخل انبار سرویس[7] قرار میگیرد نکته مهم در مورد سرویس این میباشد که سرویس هم برای افرادی که قرار است برنامه نویس انجام دهند و هم برای سایر افراد درگیر با تجارت سازمان قابل لمس میباشد این موضوع سبب میشود تا تعامل بین افرادی که قرار است IT سازمان را هدایت کنند با افرادی که تجارت سازمان را مدیریت مینمایند به بهترن نحو اجرا میگردد.

تاثیر SOA بر هزینه در بخش IT

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

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

SOA بعنوان یک طرح استراتژیک

با توجه به ارزیابی صورت گرفته توسط منابع معتبر[8] بصورت پله ای از سال 2005 میلادی تا کنون مشخص گردیده است که بسیاری از مدیران ارشد سازمانها به SOA به عنوان یک طرح استراتژیک نگاه خواهند کرد زیرا در آینده میتواند باعث برون رفت شرکت از مشکلات فعلی IT گردد و نه تنها باعث ایجاد همسویی IT با چشم انداز تجاری[9] سازمان گردد بلکه میتواند در کاهش هزینه ها نیز نقش مهمی ایفا نماید.

در آینده تحولات IT بسیار گسترده خواهد بود و مسلماً تغییرات در رویه بازرگانی و تجاری سازمان و مدل های فعلی نیز وجود خواهد داشت لذا نیاز به بستری در IT میباشد تا بتواند 2 نیاز زیر را پوشش دهد.

تغییر در مدل تجاری سازمان را بپذیرد

بتواند با نرم افزار ها و ماژولهای آینده یکپارچه گردد

در صورتیکه 2 تغییر بالا در یک معماری پیاده سازی گردد میتوان این معماری را استراتژیک دانست و مسلماً در آینده مزیت رقابتی محسوب میگردد.

در مدل های زیر ساختی مدیریت IT مانند ITIL[10] نیز لایه های گوناگون مدیریتی به صورت مبنی بر سرویس میباشد و پیاده سازی از چنین مدل های مدیریتی IT در صورتیکه زیر ساخت نرم افزاری سرویس گرا باشد بسیار راحت و اقتصادی میباشد.

مواردی که در پیاده سازی SOA در سازمان باید در نظر گرفته شود

در زمان پیاده سازی SOA در یک سازمان غیر از مسایل تکنیکی و فنی از آنجا که این پیاده سازی نصب و راه اندازی یک محصول نمیباشد بلکه پیاده سازی یک معماری میباشد باید به مسایل زیر دقت نمود

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

از آنجا که به منظور پیاده سازی سرویس های گوناگون در محیط SOA نیاز به شناخت از اهداف و نیاز های سازمان میباشد میبایست نگرش درستی از چشم انداز استراتژیک سازمان ایجاد و مورد بررسی قرار گیرد تا بتوان الگوهای متناظر و صحیحی برای آن اتخاذ نمود.

مسلماً پس از راه اندازی SOA در سازمان کلیه فرآیند های سازمان در قالب سرویس های گوناگون در اختیار کاربران قرار میگیرد به همین جهت میبایست فرآیند های تجاری سازمان مشخص گردد تا بتوان بر پایه آن الگوی لازم جهت پیاده سازی پروسس های سازمان را مبین نمود.

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

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

7 قدم برای پیاده سازی SOA

به منظور پیاده سازی معماری سرویس گرا در یک سازمان به ترتیب مراحل زیر صورت میپذیرد لازم به ذکر میباشد که بعضی از مجموعه ابزار ها مانند Oracle Fusion Middleware تمام 7 مرحله زیر را پوشش میدهد این در حالیست که بسیاری از ابزار ها هنوز چنین قابلیتی را در اختیار توسعه دهندگان قرار نمیدهند.

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

انتخاب برنامه

نگاشت سرویسها

ایجاد ارتباط بین سرویس ها

پیاده سازی توالی رویداد بین سرویس ها

انتقال سرویسها به کاربران توسط یک رابط کاربری غنی

ارائه داشبورد مدیریتی همزمان

امن سازی بستر ارتباطی

در ادامه در مورد هر مرحله توضیحات بیشتری ارائه میگردد.

قدم اول: انتخاب برنامه

در این مرحله نرم افزار مناسب جهت پیاده سازی روالهای مبتنی بر SOA و همچنین نرم افزار لازم برای پیاده سازی زیر ساخت SOA مورد برررسی قرار گرفته و در سازمان نصب میگردد از جمله مواردی که در این قدم میبایست به آن توجه گردد امکانات و ویژگیهایی میباشد که ابزار مورد نظر باید دارا باشد.

بعنوان مثال معیارهای زیر را باید در نظر داشت

عدم ایجاد پروسسهای گسسته

نرم افزار موجود نباید پروسس های منفک در سیستم ایجاد نماید پروسس منفک به پروسسی گفته میشود که امکان تعامل با سایر پروسسها را ندارد

عدم شفاف بودن مراحل

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

شاخص های معین

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

علاوه بر معیارهای ذکر گردیده در انتخاب برنامه زیر ساخت SOA باید دقت گردد تا این برنامه بتواند امکانات زیر را داشته باشد.

امکان کشیدن پروسسها بصورت گرافیکی و اتصال گرافیک به فایل و بروزرسانی همزمان این دو

امکان پیاده سازی پروسسهای انسانی و مبتنی بر افراد سازمان

دارا بودن مجموعه ای از عملیات های اتوماتیک مانند خواندن فایل و داده از پایگاه داده

دارا بودن مجموعه قوی از رخدادهای[11] پروسس، مانند رخداد زمان تکمیل یک پروسس

امکان تعریف و بهره گیری از قوانین در پروسسها

در راستای ابزار های موجود در حال حاضر کاملترین ابزاری که تمام معیارها و امکانات بالا را دارد میتوان به11g Oracle SOA Suite اشاره نمود.

قدم دوم:نگاشت سرویسها

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

پس از مشخص گردیدن سرویسها سپس برای هر سرویس اطلاعات لازم پر میگردد این اطلاعات در حالت ابتدایی شامل مواردی مانند ورودی و خروجی های سرویس،نحوه لغو عملیات سرویس ، نسخه مربوط به سرویس و مقاله عملیاتی مربوط به سرویس میباشد. تمامی این مجموعه مقالات در داخل سیستم ذخیره و بنا بر هر تغییر در داخل سیستم نسخه بندی خواهند گردید.

قدم سوم:ایجاد ارتباط بین سرویس ها

پس ازمشخص گردیدن سرویسها کلیه سرویسها به خط ارتباطی[12] سرویسهای سیستم متصل میگردند این خط ارتباطی باعث میشود تا برنامه هایی که میخواهند از سرویسها استفاده نمایند مستقل از جزییات مربوط به سرویسها باشند و بتوانند با یکدیگر ارتباط برقرار نمایند در حقیقت این خط ارتباطی مانند شبکه اینترنت عمل مینماید در مقابل برنامه هایی که سرویس اینترنتی ارائه میدهند.

در خط ارتباطی سرویسها کلیه سرویسها به این شاخه ارتباطی متصل میگردند و مشخصات خود را با این خط ارتباطی ثبت مینمایند در این لایه میتوان سیاست های امنیتی لازم جهت چگونگی ارتباط بین سرویسها را بر قرار نمود.

از آنجا که مسیر استفاده از سرویسها مسیر خط ارتباطی میباشد این موضوع سبب میشود تا در صورتیکه آدرس هر سرویس تغییر کند نیازی به هیچگونه تغیر در لایه برنامه نباشد.

قدم چهارم:پیاده سازی توالی [13] رویداد بین سرویس ها

پس از آماده سازی سرویسها در لایه SOA جهت پیاده سازی برنامه مورد نظر از آنجا که معمولا نیاز به صدا کردن یک یا چند سرویس با منطق و الگوی خاص میباشد نیاز به مکانیزمی میباشد که از طریق آن بتئان این توالی را پیاده سازی نمود ابزار ها و مکانیزمهای گوناگونی جهت اجرای این توالی وجود دارد که از مهمترین آن زبان BPEL میباشد که زبانی استاندارد و عاری از محیط اجرا میباشد به کمک این زبان میتوان توالی صدا کردن سرویسها را مشخص نمود.

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

در شکل موادی که در این قدم صورت میپذیرد نمایان گردیده است، همانگونه که در شکل مشخص میباشد سرویسها از لایه زیرین که خط ارتباطی میباشد گرفته شده و ارتباط و توالی اجرا مشخص میگردد از مهمترین اجزا در این بخش میتوان به BPEL , Human Workflow, Rule Mg. اشاره نمود.

قدم پنجم: انتقال سرویسها به کاربران توسط یک رابط کاربری غنی[14]

در مرحله پنجم پروسسهای طراحی شده مبتنی بر سرویس از لایه زیرین در اختیار لایه نهایی که رابط کاربری میباشد قرار میگیرد که چون نقل و ارتباط با استفاده از فایلهای XML میباشد در این لایه از هر تکنولوژی توسعه میتوان استفاده نمود

با توجه به محبوبیت جاوا در توسعه سیستم های تحت وب پیشنهاد شرکت اراکل استفاده از تکنولوژی JSF[15] در توسعه این لایه میباشد.

قدم ششم:ارائه داشبورد[16] مدیریتی همزمان

از آنجا که هدف نهایی از توسعه سیستم ها راحت سازی مدیریت مجموعه و نزدیک شدن به تجارت اصلی سازمان میباشد جهت حصول اطمینان از تحقق این مهم در زمان توسعه سرویس ها معیار هایی تحت عنوان نقاط ازریابی کارایی[17] در توسعه سیستم طراحی میگردد و در SOA میتوان این نقاط را در داشبورد های مدیریتی بطور همزمان رویت نمود بعنوان مثال در پروسس وام میتوان مشخص نمود که چه تعداد وام در حال حاضر در سیستم داده شده است یا میتوان طرحی ارائه داد که در صورتیکه میزان مبلغ وامهای واگذاری بیشتر از مبلغ خاصی باشد داشبورد مدیریتی پیغام و آلارم مربوطه نمایان گردد.

همانطور که در شکل مشخص میباشد از 4 نوع هشدار مختلف میتوان استفاده نمود تا در هر لحظه بتوان از صحت پروسسهای کلیدی سازمان مطلع گردید.

قدم هفتم:امن سازی بستر ارتباطی

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

از جمله نکات مهم در این قدم به این موضوع میبایست اشاره کرد که این امن سازی مجزا از نحوه ایجاد و پیاده سازی میباشد و هیچ تغییری در مراحل قبلی وجود نخواهد داشت.

برنامه پیشنهادی برای اجرای SOA در سازمان

اکنون که کلیه موارد لازم جهت پیاده سازی بستر SOA در سازمان را مشخص نموده ایم نوبت به آن میرسد که ابزار Oracle Fusion Middleware برای شرکت اراکل را با سایر نرم افزار های مشابه مقایسه نماییم.

همانگونه که در گزارش شرکت فراستار مشخص گردیده است شرکت اراکل در تمام معیارها از سایر رقبا پیشی داشته و از جمله مهمترین حسن این محیط توسعه SOA باید به این موضوع اشاره نمود که مجموعه ابزار Oracle Fusion Middleware 11g تمام مراحل لازم برای توسعه سیستم با SOA را پوشش میدهد.

شرکت اراکل مجموعه برنامه های متنوع و در عین حال همپوشانی را جهت ارائه سرویس SOA در سازمان دارا میباشد در شکل زیر یک شمای کلی از این مجموعه ابزارها ارائه گردیده است.

برنامه های کاربردی لازم جهت توسعه

جهت پیاده سازی کامل SOA در یک سازمان مجموعه ابزار های زیر توسط شرکت اراکل پیشنهاد میگردد

پایگاه داده اراکل 10g

برنامه Oracle SOA Suite 11g

برنامه Oracle Identity Management 11g

برنامه Oracle Jdeveloper 11gو چهارچوب ADF[18]

سرور WebLogic Server 11g

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

امکان توسعه برنامه تحت وب به کمک ابزار Jdeveloper و چهارچوب ADF لازم به ذکر میباشد که برنامه های قدیمی توسعه یافته با Form Builder 6i,10g به ADF قابل تبدیل میباشند البته با صرف هزینه و زمان مناسب

امکان ایجاد لایه امنیتی و سطوح دسترسی برای بیش از 5 میلیون کاربر سیستم با استفاده از ابزار Identity Mg.

امکان ایجاد چهارچوب SOA با تمام امکانات ذکر شده در این مقاله به کمک ابزار SOA Suite 11g

امکان راه اندازی سیستم و کلاسترینگ و جوابگویی به حجم زیاد درخواستها به کمک سرور WebLogic

ابزار های گفته شده مهمترین ابزار ها جهت راه اندازی و عملیتی کردن معماری سرویس گرا در سازمان میباشد.

کلیات مفاهیم SOA

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

معماری سرویس‌گرا (SOA[19]) شکل تکامل یافته محاسبه‌گری توزیع شده مبتنی بر فرضیه طراحی تقاضا/پاسخ برای برنامه‌های کاربردی همگام و ناهمگام است. منطق تجاری یا توابع اختصاصی یک برنامه کاربردی به صورت ماژولار در آمده‌اند و به عنوان سرویس‌هایی برای برنامه‌های کاربردی مصرف‌کننده/کلاینت ارایه گردیده‌اند. مهم‌ترین نکته‌ در مورد این سرویس‌ها طبیعت اتصال آزادانه آنهاست؛ بدین معنی که رابط سرویس، مستقل از پیاده‌سازی است. توسعه‌دهندگان برنامه‌های کاربردی یا گردآورندگان سیستم‌ها می‌توانند با ساختن یک یا چند سرویس بدون آگاهی از پیاده‌سازی‌های زیرین سرویس‌ها اقدام به ایجاد برنامه‌های کاربردی نمایند. برای مثال، یک سرویس می‌تواند در .Net یا J2EE پیاده‌سازی گردد، و برنامه کاربردی استفاده کننده از سرویس می‌تواند بر روی یک پلات‌فرم یا زبان متفاوت قرار داشته باشد.

معماری‌های سرویس‌گرا دارای خصوصیات اصلی زیر هستند:

سرویس‌های SOA دارای رابط‌های خود-توصیف‌گر در اسناد XML مستقل از پلاتفرم هستند. زبان توصیف سرویس‌های وب (WSDL) استاندارد به کار برده شده برای توصیف این سرویس‌ها می‌باشد.

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

سرویس‌های SOA توسط یک رجیستری که به عنوان یک فهرست دایرکتوری عمل می‌کند نگهداری می‌گردند. برنامه‌های کاربردی می‌توانند سرویس‌ها را درون رجیستری جستجو نمایند و سرویس را فراخوانی کنند. توصیف، تعریف، و یکپارچگی جهانی (UDDI) استانداردی است که برای رجیستری سرویس مورد استفاده قرار گرفته است.

هر سرویس SOA دارای یک کیفیت سرویس (QoS[20]) مرتبط با خود است. برخی از عناصر اساسی QoS شامل نیازمندی‌های امنیتی، از قبیل احراز هویت و صدور مجوز، پیام‌رسانی قابل اطمینان، و خط‌مشی‌هایی در این زمینه که چه افرادی می‌توانند سرویس‌ها را فراخوانی نمایند، می‌باشد.

دلیل استفاده از SOAچیست؟

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

یک سازمان استفاده کننده از SOA می‌تواند یک برنامه کاربردی مرکب زنجیره تامین را با استفاده از مجموعه‌ای از برنامه‌های کاربردی موجود که کارکرد خود را از طریق رابط‌های استاندارد ارایه می‌دهند، ایجاد نماید.

معماری سرویس

چندین مصرف‌کننده سرویس می‌توانند با ارسال پیام اقدام به فراخوانی سرویس‌ها نمایند. این پیام‌ها معمولا توسط یک گذرگاه سرویس تغییر شکل داده شده و به سوی یک پیاده‌سازی سرویس مناسب هدایت می‌گردند. این معماری سرویس می‌تواند یک موتور قواعد تجاری را فراهم سازد که امکان تلفیق قواعد تجاری در یک سرویس یا چندین سرویس را عملی سازد. معماری سرویس مزبور همچنین یک زیربنای مدیریت سرویس فراهم می‌آورد که سرویس‌ها و اعمالی از قبیل بازرسی، پرداخت صورتحساب، و واقعه‌نگاری[21] را مدیریت می‌نماید. به علاوه، این معماری انعطاف‌پذیری ناشی از دارا بودن فرایندهای تجاری تغییر پذیر را به سازمان‌ها ارزانی می‌دارد، فرایندهایی که نیازمندی‌های تنظیمی را مد نظر قرار می‌دهند، و سرویس‌های اختصاصی را بدون تحت تاثیر قرار دادن سایر سرویس‌ها تغییر می‌دهند.

زیربنای SOA

برای اجرا و مدیریت برنامه‌های کاربردی SOA، سازمان‌ها نیازمند یک زیربنای SOA هستند که بخشی از پلات‌فرم SOA محسوب می‌گردد. یک زیربنای SOA باید تمامی استانداردهای مرتبط و ظرف‌های (container) مورد نیاز زمان اجرا را پشتیبانی کند. یک زیربنای SOA معمولی چیزی شبیه شکل ۳ است. بخش‌هایی که در ادامه این مقاله مشاهده می‌نمایید قطعات اختصاصی این زیربنا را مورد بحث قرار می‌دهند.

SOAP, WSDL, UDDI

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

WS-I Basic Profile، که از سوی Web services Interoperability Organization فراهم شده است، یکی دیگر از قطعات اساسی مورد نیاز برای تست و interoperability (قابلیت کار با سایر اجزای سیستم) سرویس است. فراهم‌کنندگان سرویس می‌توانند از مجموعه‌های تست Basic Profile برای تست نمودن interoperability سرویس در میان پلات‌فرم‌ها و تکنولوژی‌های متفاوت استفاده کنند.

اگر چه پلات‌فرم‌هایJ2EE و .Net برای برنامه‌های کاربردی SOA پلاتفرم‌های توسعه غالب به شمار می‌روند، اما SOA به هیچ عنوان به این پلات‌فرم‌ها محدود نیست. پلات‌فرم‌هایی از قبیل J2EE نه تنها یک framework را برای توسعه‌دهندگان جهت سهیم شدن در SOA فراهم می‌آورند، بلکه با طبیعت ذاتی خود، یک زیربنای کامل و مورد تایید از لحاظ بسط‌پذیری، قابلیت اطمینان، دسترس‌پذیری، و کارآیی را برای دنیای SOA به ارمغان می‌آورند. مشخصه‌های جدیدی از قبیل JAXB (Java API for XML Binding)، که کاربرد آن در نگاشت اسناد XML به کلاس‌های جاوا است،JAXR[22] ، که کاربرد آن در تعامل با رجیستری‌های UDDI به یک شیوه استاندارد است، و XML-RPC[23] ، که کاربرد آن در فراخوانی سرویس‌های راه دور در J2EE است توسعه و گسترش سرویس‌های وبی که در میان ظرف‌های استاندارد J2EE قابل انتقال هستند را تسهیل می‌نمایند، ضمن این که به شکل همزمان به کار با سرویس‌های موجود در پلات‌فرم‌های دیگری از قبیل .Net می‌پردازند.

کیفیت سرویس‌ها

سیستم‌های حیاتی موجود در سازمان‌ها نیازمندی‌های پیشرفته‌ای از قبیل امنیت، قابلیت اطمینان، و تراکنش‌ها را مد نظر قرار می‌دهند. همچنان که سازمان‌ها شروع به پذیرش معماری سرویس به عنوان ابزاری برای توسعه و گسترش برنامه‌های کاربردی می‌نمایند، مشخصه‌های بنیادین وب از قبیل WSDL، SOAP، و UDDI قادر به برآورده ساختن این نیازمندی‌های پیشرفته نیستند. همچنان که قبلا گفته شد، این نیازمندی‌ها، همچنین تحت عنوان کیفیت سرویس‌ها شناخته می‌شوند. تعداد بیشماری از مشخصه‌های مرتبط با QoS[24] در هییت‌های برخی استانداردها همچون[25] W3Cو OASIS[26] مطرح گردیده‌اند. بخش‌هایی که در ادامه آمده است برخی از اثرات QoS و استانداردهای مرتبط را مورد بحث قرار داده‌اند.

امنیت

مشخصه Web Services Security امنیت پیام را مد نظر دارد. این مشخصه بر روی تبادل اعتبارنامه، یکپارچگی پیام، و محرمانگی پیام متمرکز گردیده است. نکته جذاب در مورد این مشخصه این است که آن از استانداردهای امنیتی موجود، از قبیل SAML[27] ، بهره می‌گیرد و امکان استفاده از این استانداردها را به منظور ایمن‌سازی پیام‌های سرویس‌های وب فراهم می‌سازد. Web Services Security یک تلاش مداوم و در حال رشد از سوی OASIS است.

قابلیت اطمینان

در یک محیط SOA معمولی، اسناد متعددی میان استفاده‌کنندگان از سرویس و فراهم‌کنندگان سرویس مبادله می‌گردد. تحویل پیام‌ها با خصوصیاتی همچون تحویل یکباره و فقط یکباره، تحویل حداکثر یکباره، حذف دوباره‌ای پیام، تحویل تضمین شده پیام، و تصدیق در سیستم‌های حیاتی که از معماری سرویس استفاده می‌کنند از اهمیت بالایی برخوردار می‌گردد

WS-Reliability و WS-Reliable Messaging دو استانداردی هستند که مسایل مربوط به پیام‌رسانی قابل اطمینان را مد نظر قرار می‌دهند. هر دوی این استانداردها اکنون بخشی از OASIS می‌باشند.

خط‌مشی

فراهم‌کنندگان سرویس در برخی موارد استفاده‌کنندگان از سرویس را ملزم به مراوده با خط‌مشی‌های معین می‌نمایند. به عنوان یک مثال، یک فراهم‌کننده سرویس ممکن است یک نشانه امنیتی Kerberos را برای دستیابی به سرویس الزامی نماید. این استلزام‌ها به عنوان اظهارنامه‌های خط‌مشی تعریف گردیده‌اند. یک خط‌مشی ممکن است شامل چندین اظهارنامه باشد. WS-Policy نحوه مورد مراوده قرار گرفتن خط‌مشی‌ها میان استفاده‌کنندگان از سرویس و فراهم‌کنندگان سرویس را به شکل استاندارد در می‌آورند.

هماهنگ‌سازی

همچنان که سازمان‌ها به معماری سرویس روی می‌آورند، سرویس‌ها می‌توانند برای یکپارچه‌سازی مخازن داده، برنامه‌های کاربردی، و کامپوننت‌ها مورد استفاده قرار گیرند. یکپارچه‌سازی برنامه‌های کاربردی بدان معنی است که نیازمندی‌های پردازش، از قبیل ارتباط ناهمگام، پردازش موازی، تبدیل داده‌ها، و تصحیح، باید استانداردسازی گردند. BPEL[28]۴WS یا WSBPEL (Web Services Business Process Execution Language) یک مشخصه OASIS است که هماهنگ‌سازی سرویس را مد نظر دارد، جایی که فرایندهای تجاری با استفاده از مجموعه‌ای از سرویس‌های گسسته ایجاد گردیده‌ باشند. WSBPEL اکنون بخشی از OASIS می‌باشد.

مدیریت

همچنان که تعداد سرویس‌ها و فرایندهای تجاری ارایه شده به عنوان سرویس در سازمان افزایش می‌یابد، یک زیربنای مدیریت که امکان مدیریت سرویس‌های در حال اجرا در یک محیط ناهمگن را به مدیران سیستم می‌دهد از اهمیت بالایی برخوردار می‌گردد. WSDM[29] بیانگر آن خواهد بود که هر سرویس پیاده‌سازی شده بر اساس WSDM توسط یک راهکار مدیریت سازگار با WSDM قابل مدیریت خواهد بود.

سایر صفت‌های QoS از قبیل هماهنگی میان شرکا و تراکنش‌ها که در بر دارنده چندین سرویس هستند به ترتیب مد نظر قرار گرفته‌اند.

SOA سرویس‌ وب نیست

آن گونه که به نظر می‌رسد در مورد ارتباط میان SOA و سرویس‌های وب نوعی سردرگمی عمومی وجود دارد. در یکی از گزارش‌های Gartner مورخ آوریل ۲۰۰۳، Yefim V. Natis این گونه تقاوت میان آنها را شرح می‌دهد: ”سرویس‌های وب راجع به مشخصه‌های تکنولوژی هستند، در حالی که SOA یک قاعده‌ی طراحی نرم‌افزار است. شایان ذکر است که WSDL سرویس‌های وب یک استاندارد تعریف رابط مناسب SOA است: این نقطه‌ای است که سرویس‌های وب و SOA اساسا به یکدیگر پیوند می‌خورند.“ اساسا، SOA یک الگوی معماری است، در حالی که سرویس‌های وب سرویس‌های پیاده‌سازی شده توسط مجموعه‌ای از استانداردها می‌باشند؛ سرویس‌های وب یکی از روش‌هایی است که شما با استفاده از آن می‌توانید SOA را پیاده‌سازی نمایید. مزیت پیاده‌سازی SOA با سرویس‌های وب این است که شما به یک رویکرد بی‌طرفانه نسبت به پلات‌فرم به منظور دستیابی به سرویس‌ها و interoperability بهتر دست می‌یابید همچنان که فروشندگان بیشتر و بیشتری مشخصه‌های بیشتر و بیشتری از سرویس‌های وب را پشتیبانی می‌نمایند.

مزایای SOA

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