معماری سرویسگرا از جنبههای مختلفی قابل بررسی میباشد، هر ذینفعی بر اساس جایگاه خود برداشتی از این معماری دارد که در ادامه به بررسی آن‌ها میپردازیم:
متخصصان کسبوکار: معماری سرویسگرا مجموعهای از سرویسها است که سازمان مایل به ارائه آن‌ها به مشتریان یا شرکای کاری خود میباشد [6].
معماران: معماری سرویسگرا یک سبک از معماری است که حاوی قوانین، الگوها و ضوابطی است که باعث ایجاد خصوصیاتی مانند پیمانهای بودن، بستهبندی، اتصال سست، استفاده مجدد و ترکیب پذیری شده و از نظر ساختار از یک ارائهدهنده سرویس و یک درخواست‌کننده سرویس تشکیل شده است[16].
طراحان و پیادهسازان: معماری سرویسگرا یک سبک و مدل برنامهنویسی است که از استانداردهایی مانند (WSDL,UDDI,SOAP,…) و فناوریهایی نظیر سرویسهای وب استفاده میکند و قابلیت تعامل پذیری بین مؤلفه‌های نرمافزاری را بدون توجه به سکو و فناوری پیادهسازی آن‌ها پشتیبانی میکند[15].
2-2-1 تعاریف معماری سرویسگرا
برای معماری سرویسگرا تعاریف متنوع و متفاوتی ارائه شده است که به نحوی خصوصیات آن را بیان نموده است. برای درک بهتر این مفهوم در ادامه مروری بر تعدادی از این تعاریف خواهیم داشت.
یک سبک برای ساخت سیستمهای توزیع شده مطمئن است که امکاناتش را به صورت سرویس تحویل میدهد و بیشتر روی سست اتصالی بین تعاملات سرویسها تاکید دارد[17].
مدلی ارائه میدهد که در آن منطق خودکارسازی به واحدهای منطق کوچک‌تر و مجزا تفکیک شدهاست[15].
چارچوب وسیع و استانداردی که سرویسها در آن ساخته شده، استقرار مییابند و مدیریت میشوند. هدف این چارچوب افزایش چابکی زیرساختهای فناوری اطلاعات در جهت واکنش سریع به تغییرات نیازهای کسبوکار میباشد[9].
در جمعبندی از تعاریف معماری سرویسگرا میتوان به ویژگیهای زیر اشاره نمود[15]:
همراستا با کسبوکار سازمان است.
هم موضوعی فنی است و هم نوعی تفکر است.
مبتنی بر اتصال سست است و از پیامرسانی استفاده میکند.
قادر به ساخت سیستمهای ترکیبی است.
مهمترین دستاورد آن انعطافپذیری و چابکی فناوری اطلاعات در برابر تغییرات حرفه است.
منجر به تعامل پذیری سامانه‌ها و سازمانها میگردد.
امکان ارائه یک سرویس با واسطههای متنوع را محقق میسازد.
در مدل پایهای این معماری، تعدادی سرویس وجود دارد که قرار است مشتریان از آنها استفاده کنند. مشتریان ممکن است کاربران، سرویسهای دیگر یا برنامههای کاربردی باشند؛ ابتدا سرویس مورد نظر را بر اساس قراردادهای سرویس شناسایی، سپس درخواست خود را به آن سرویس ارسال میکنند. مکانیزم کلی عملکرد معماری سرویسگرا به وسیله سه مؤلفه اولیه درخواستدهنده سرویس6 یا مشتری، فراهمکننده سرویس7، انباره سرویس8 بیان میشود (شکل 2-1) [15].
شکل 2-1 مدل پایه سرویسگرایی[15]
هر فراهمکننده سرویس، برای معرفی خود توصیفکننده خود را در انباره سرویس قرار میدهد. درخواستکننده سرویس با جستجو در انباره سرویس، سرویس مورد نظر خود را انتخاب و بدون واسطه با فراهمکننده آن سرویس ارتباط برقرار میکند. همان‌طور که گفته شد انباره سرویس شامل توصیفکنندههای فراهمکنندههای سرویس است. در ضمن هر سرویس میتواند هر دو نقش فراهمکننده و درخواستدهنده را داشته باشد. در هنگام فراخوانی یک سرویس، پارامترهای معینی ممکن است برای انجام درخواست مورد نیاز باشد که به آن خصوصیات مدل دادهای مرتبط میگویند و یک سرویس ممکن است پارامترهایی را به کاربران سرویس بازگرداند. W39C , WSD10L یک نمونه از این پیادهسازی میباشد [18].
2-2-2 سرویس
سرویسها در واقع همان بخشهای منطقی، در معماری سرویسگرا میباشند. هر سرویس در برگیرنده وظیفه مشخص، موجودیت و یا مجموعهای از فعالیتهای مرتبط است که در ابعاد مختلف تعریف میشوند. هر سرویس شامل منطق جداگانهای است. طبق تعریفی دیگر سرویس مکانیزمی برای فعال کردن دسترسی به یک یا چند قابلیت است، دسترسی با استفاده از یک واسط مورد تأیید و سازگار با قیود و سیاست‌های تعیین شده در شرح سرویس فراهم می‌شود[19]. سرویس رفتار قراردادی تعریف شدهای است که میتواند به وسیله یک جزء برای استفاده جزء دیگر پیادهسازی شده، فراهم شود[20]. مفهوم سرویس بر تمایز بین قابلیتی که مجموعه عملیاتی برای رفع نیازها ارائه می‌دهد و نقطه دسترسی به سرویس را که در متن معماری سرویسگرا آورده می‌شود تاکید دارد. یک سرویس را میتوان تابعی خوشتعریف11 و جامع در نظر گرفت که به زمینه و حالت سرویسهای دیگر بستگی ندارد[21].
هر سرویس شامل پارامترهای فنی، قیود و سیاستهایی است که قالبهای لازم برای فراخوانی سرویس را تعریف میکند. هر سرویس، شرح سرویسی را در قالب استانداردی تعریف میکند. مزیت شرح سرویس برای کاربران و طراحان سرویس این است که به آن‌ها کمک میکند تا بدانند سرویس چه کاری انجام میدهد و ورودی و خروجی آن چیست [20]. از آنجایی که طبیعت سرویسها دائماً در حال تغییر است، باید واژههایی را به صورت قانونی و استاندارد برای برقراری ارتباط بین سرویسها تعریف نمود. که میتوان به عنوان نمونه زبان توصیفی وب سرویس را نام برد[9] .
شرح سرویس باید به شیوهای قابل دسترس در اختیار کاربران بالقوه قرار گیرد که به این امر اعلان سرویس میگویند. پایش سرویس زمانی صورت میگیرد که یک مشتری بالقوه اطلاعاتی در مورد وجود یک سرویس، پارامترهای قابل اعمال و واژگان آن بیابد[15]. اجزای اعلان و پایش در معماری سرویسگرا به شیوههای مختلفی پیادهسازی میشود که در ادامه به برخی از آن‌ها میپردازیم:
پیادهسازی به روش ثبات/مخزن: در این حالت کاربران امکان ذخیره و مدیریت سرویسهای لازم برای عملکرد سازمانشان را خواهند داشت. این موضوع شامل سرویسهایی است که تسهیم بین بیش از یک کاربر (مانند شرح وب سرویس‌ها) را فراهم میآورد و ثبات در مورد تمامی رویدادهای قابل ارزیابی به نسبت محصولات درون مخزن اطلاع دارد[15].
پیادهسازی به روش کتاب راهنما12 : کتاب راهنما یک واسط است که اطلاعات نسبت داده شده به محصولات را فراهم میآورد. افرادی که مالک هستند یا آن‌ها را کنترل میکنند، میتوانند یک راه به کتاب راهنما باز کنند و به محصولات ارجاع شده و اطلاعات نسبت داده شده توضیح دهند. همچنین ممکن است این اطلاعات توسط دیگران نیز بازیابی شود. مهم‌ترین مشکل کتاب راهنما این است که هیچ کنترلی یا اطلاع رسانی در صورت حذف، تغییر و جایگزینی یک محصول انجام نمیدهد و قادر به اعلام این رویدادها به کاربران نیست[18].
سرویسگرایی در تئوری جداسازی نگرانیها13 ریشه دارد. بر اساس این تئوری هر مسئله بزرگ را میتوان با شکستن به بخشهای کوچک‌تر و مستقل و مرتبط به هم حل کرد. سرویسگرایی برای تحقق این تئوری اصول زیر را برای سرویسها در نظر گرفته است[15]:
سرویسها قابل استفاده مجدد14 هستند: سرویسگرایی تمام سرویسها را به استفاده مجدد بدون در نظر گرفتن نیازهای فعلی تشویق میکند. با رعایت استانداردهای طراحی پتانسیل استفاده مجدد از سرویسها بیشتر میشود که سبب برطرف کردن سریع نیازهای آینده میشود. همچنین به صورت چشمگیری نیاز به سرویسهای پنهانساز15 برای قرار دادن واسطی بر روی سرویسها را کاهش میدهد. استفاده مجدد یکی از مهمترین اصول سرویسگرایی است.
سرویسها قرارداد رسمی16 را به اشتراک میگذارند: هر قرارداد شامل تعریفی رسمی از نقطه تماس17 سرویس، عملهای سرویس، پیغامهای ورودی و خروجی و قواعد و مشخصات عملهای سرویس است. به بیانی دیگر بخشهای مختلف در مدل پایه معماری سرویسگرا را تعریف میکند.
سرویسها به صورت ارتباط سست18 هستند: ارتباط سست شرایطی است که یک سرویس دانش مربوط به سرویس دیگر را بدست میآورد در حالی که به صورت مستقل از آن سرویس باقی میماند. ارتباط سست به وسیله استفاده از قرارداد رسمی میان سرویسها محقق میشود. در معماری سرویسگرا منظور از اتصال سست قابلیت تعامل بین سرویس‌ها به صورت مستقل از کد نویسی و مکان سرویس‌ها است، به گونه‌ای که سرویس‌ها در زمان اجرا می‌توانند تغییر مکان داده، روالهای داخلی خود را تغییر دهند یا حتی از یک فناوری جدیدتر استفاده کنند، بدون اینکه تأثیری منفی بر سرویسگیرندگان گذاشته شود. ارتباط سست یکی دیگر از مهمترین اصول سرویسگرایی است.
سرویسها منطق زیرین خود را به صورت تجرید19 محقق میسازند:به عبارتی سرویسها منطق محصور شده درون خود را از عالم خارج مخفی می‌کنند. نکته قابل ذکر در اینجا این است که تفاوت میان مجرد سازی و مخفی سازی در چیست؟ مجرد سازی به تعریف موجودیتهای رویه‌ای و یا اطلاعاتی که نرمافزار را می‌سازند کمک میکند، ولی پنهانسازی محدودیتهای دسترسی را برای جزئیات رویهای داخل پیمانه و هر ساختمان داده محلی استفاده شده در پیمانه را تعریف و اجباری مینماید.
سرویسها قابل ترکیب20 هستند: هر سرویس میتواند مقدار متفاوتی از منطق را از منابع متفاوت که شامل سرویسها نیز میشود تأمین کند. دلیل اصلی از این اصل برای اطمینان از طراحی سرویسها به صورتی که بتوانند به عنوان عضوی از یک سرویس ترکیبی باشند، است.
سرویسها خودمختار هستند: هر سرویس منطق خویش را به صورت محدوده مشخص بیان میکند. سرویس به تمام فرآیندهای خویش خودمختار است. این اصل تنها ضمانت میکند که در زمان اجرا سرویس نسبت به منطق خویش کنترل دارد.
سرویسها قابل کشف و شناسایی هستند: این خاصیت سرویسها سبب میشود تا سرویسهای تکراری ایجاد نشوند. خاصیت مهم دیگر آن امکان ارائه مکانیزم کشف و شناسایی است که معمولاً بر اساس انباره سرویس صورت میگیرد
.
2-2-3 مفاهیم مرتبط با معماری سرویسگرا
در این مبحث به تشریح برخی مفاهیم مرتبط با معماری سرویسگرا خواهیم پرداخت. بعضی از این مفاهیم در فصول بعدی، جایی که مفاهیم امنیتی مطرح میشود به کار میآید.
فراهمکننده سرویس: یک موجودیت نرمافزاری است که خصوصیات سرویس را پیادهسازی میکند[15].
درخواست کننده سرویس: یک موجودیت نرمافزاری است که یک فراهمکننده سرویس را فراخوانی میکند. به طور سنتی این مورد به عنوان سرویسگیرنده شناخته میشود. اما یک درخواست کننده سرویس میتواند به عنوان یک برنامه کاربردی و یا به عنوان یک سرویس دیگر قرار گیرد[15].
موقعیت یاب سرویس: یک نوع خاصی از فراهمکننده سرویس است که به عنوان یک ثبات عمل میکند و امکان جستجوی واسطههای فراهمکننده سرویس و همچنین موقعیت سرویس مورد نظر را میدهد[15].
واسط سرویس: یک نوع خاصی از فراهم کننده سرویس است که میتواند درخواست سرویس را به یک یا چند فراهمکننده سرویس منتقل کند[15].
محصورسازی سرویس: محصورسازی یکی از اصول شیگرایی است که در معماری سرویسگرا نمود پیدا کرده است. در شیگرایی شی را محصور میکنند تا از تأثیرات ناخواسته در امان باشد، همچنین از واسط جهت ارتباط با شی استفاده میکنند و طرق دسترسی به شی را به آن محدود میکنند. در معماری سرویسگرا هم این منطق است؛ و باز هم با همین اهداف محصورسازی میشود. اما باید توجه داشت که این منطق دارای اندازههای متفاوت است به طوری که این دانهبندی برای سرویس و منطق آن مانع از محصورسازی آن‌ها نمیشود و در این حالت نیز محصورسازی انجام میشود (شکل 2-3) [15].
شکل 2-2 دانهبندی سرویسها[15]
هر سرویس میتواند یک وظیفه که توسط یک گام مشخص اجرا میشود را بستهبندی کند. این کوچک‌ترین دانهبندی در محصورسازی منطق راهحل توسط سرویس به شمار میآید. همچنین میتواند یک زیر فرآیند که شامل مجموعهای از گامهاست یا تمامی منطق فرآیند را محصورسازی کند. در دو مورد اخیر محدوده بزرگ ارائه شده توسط سرویسها ممکن است شامل منطق ارائه شده توسط دیگر سرویسها نیز باشد. برای آنکه سرویسها از منطقی که محصور کردهاند استفاده نمایند، میتوانند در اجرای فعالیتهای کسبوکار سهیم شوند [15].
همنواسازی21 و همخوانی22 : دو واژه پر کاربرد در حوزه کسبوکار و معماری سرویسگرا که معمولاً به جای هم اشتباه گرفته میشوند. همنواسازی در خصوص ترتیب اجرای سرویسها در فرآیند بحث میکند، همنواساز اصلی مجموعهای از سرویسها را فراخوانی میکند تا نتیجه مورد نظر حاصل شود و فرآیند تکمیل گردد (ممکن است سرویسهای خارج سازمان نیز در این راستا فراخوانی و استفاده شوند که این کار با کمک موتور فرآیند تحقیق انجام میشود). در حالی که همخوانی به فرآیندهایی میگویند که بدون موتور فرآیندی (رهبر ارکستر) اقدام به تبادل پیام کرده و ترتیب و توالی پیامهای مبادلاتی را خود بازیگران ثبت و کنترل میکنند (شکل 2-3)[22] .
شکل 2-3 همنواسازی و همخوانی

بنابراین همنواسازی به معنای وجود یک موتور فرآیندی است که ترتیب و توالی را کنترل کرده و از شرکا داخلی یا خارجی برای انجام کارها استفاده میکند. نمونه این مدل، سیستم مدیریت فرآیندهای کسبوکار است که فرآیندها در موتور فرآیندی اجرا میشوند[22]. همخوانی به معنای پردازشهای توزیعشده بین چند فرآیند است که بدون یک رهبر مرکزی با هم تعامل دارند و یا چندین موتور فرآیندی که در کنار و همسطح هم اجرا میشوند و با همکاری هم هدفی را محقق میسازند. نمونه این حالت در پردازشهای توزیعشده و یا فعالیتهای بین سازمانی که هر دو طرف با مشارکت هم به دنبال یک هدف معین هستند دیده میشود[22]. بنابراین مهم‌ترین تفاوت همخوانی و همنواسازی در داشتن مالک و کنترلکننده مرکزی است.
2-2-4 فناوریهای سازنده سرویس وب
در سالهای اخیر سه فناوری اصلی به عنوان استانداردهای معماری سرویسگرا پدیدار شدند که هستهی سرویسهای وب امروزی را می‌سازند، این فناوریها عبارتند از UDDI، WSDL، SOAP که در ادامه به شرح دو مورد از آن‌ها خواهیم پرداخت و از شرح UDDI به دلیل منسوخ شدنش خودداری میکنیم.
WSDL : استاندارد WSDL جهت توصیف ویژگیهای عملیاتی سرویسهای وب استفاده میشود. دارای دو بخش تعریف واسط (منطقی) و پیادهسازی (فیزیکی) است. قسمت واسط برای استفاده متقاضیان سرویس بوده و ممکن است شامل چندین پیادهسازی باشد در حالی که قسمت پیادهسازی مشخص میکند که چگونه واسط به وسیله یک ارائهدهنده مشخص پیادهسازی شدهاست. این استاندارد در سال 2001 توسط W3C ارائه شد.
قسمت منطقی که مشخصات انتزاعی وب سرویس را توصیف میکند، شامل بخشهای زیر است.
Type: انواع دادهای برای دادههای قابل حمل به وسیله XSD تعریف میشوند.
Message: شامل یک یا بیشتر بخش منطقی است که نمایشدهنده تعریف پارامترهای ورودی و خروجی است که توسط Operationها استفاده میشوند.
Operation: عملیات واقعی که توسط سرویس انجام میشوند را توصیف میکند و شامل پیامهای ورودی و خروجی که به عنوان پارامتر آن است.
Port type: مجموعه انتزاعی از عملیات سرویس را شامل میشود.
قسمت فیزیکی از WSDL مشخصات واقعی وب سرویس را توصیف میکند، شامل بخشهای زیر است:
Binding: پروتکل واقعی و قالب پیام برای عملیات و پیامهای تعریف شده در port type در این قسمت مشخص میشود. به عنوان مثال پروتکل SOAP مشخص میشود.
Port: انقیاد آدرس شبکه واقعی برای نقطه تماس انجام میشود.
Service: شامل یک یا چندین عنصر که نمایشدهنده نقاط تماس مرتبط است.
ساختار یک سند WSDL را به عنوان نمونه در زیر آوردهایم شکل (2-4)[23].
<definitions name =”poService”…>
<message name=”getOrderStatusInput”>

</message>
<portType name=”poServicePortType”>
<operation name=”getOrderStatus”>
<input message=”tns:getOrderStatusInput”/>
<output… />

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

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

ولی برای دانلود فایل اصلی با فرمت ورد حاوی تمامی قسمت ها با منابع کامل

اینجا کلیک کنید

</operation>
</portType>
<binding name=”poServiceBinding” type=”tns:poServicePortType”>
<soap:binding… >…
</binding>
<service name=”poService”>
<port name=”poServicePort” binding=”tns:poServiceBinding”>

</port>
</service>
</definitions>
شکل 2-4 ساختار یک سند WSDL [23]
SOAP : یکی از عمومیترین استانداردهایی است که در وب سرویسها استفاده میشود. طبق شواهد اولین بار توسط Developer Mentor، شرکت User Land و مایکروسافت در سال ???? ساخته شده و نسخه اول آن در سال ???? ارایه شده است. آخرین نسخه SOAP، نسخه 1.2 بود که در دسامبر سال ???? در W3C ارایه شد. نسخه 1.2 نشان دهنده کار زیاد بر روی آن و نمایانگر اشتیاق زیاد صنعت IT برای استفاده از SOAP وب سرویس است. به صورت مختصر SOAP پروتکل پیام رسانی است که برای انتقال دادههای برنامههای مختلف در قالب XML و بر روی پروتکل لایه انتقال مانند HTTP, SMTP, FTP استفاده میشود. امروزه برنامههای وبسرویس از استاندارد SOAP برای مبادله اطلاعات در حالت توزیع شده سود میبرند. ساختار کلی یک پیام SOAP در قالب سند XML، به صورت زیر است شکل (2-5)[23].
<SOAP-ENV:Envelope…>
<SOAP_ENV:Header>


</SOAP_ENV:Header>
<SOAP_ENV:Body>


</SOAP_ENV:Body>
</SOAP-ENV:Envelope…>
شکل 2-5 ساختار کلی یک پیام SOAP [23]
همان‌طور که میبینید سند XML نمایشدهنده SOAP شامل عناصر زیر است:
عنصر Envelope در برگیرنده تمام پیام است.
عنصر Header که اختیاری است شامل توضیحات اضافه در رابطه با پیام (مشخصات امنیتی و انتقالی) است.
عنصر Body که شامل محتوی مفید پیام است.
2-2-5 یکپارچهسازی سیستمهای سازمان و تعامل پذیری بین سازمانی به کمک معماری سرویسگرا
سیستمهای اطلاعاتی در یک سازمان زمانی میتوانند موثر و کارآمد باشند که با هم تعامل و ارتباط مناسبی داشته باشند. امروزه این مورد یکی از اهداف مدیران اطلاعاتی سازمانهاست؛ البته نباید تصور کرد که ارتباط بین سیستمهای اطلاعاتی فقط مختص به انتقال بایتهای داده میشود. انجام فرآیندهای کسبوکار وابسته به نرمافزارها و سیستمهای اطلاعاتی متنوعی است که هر کدام در زمانی و با تکنولوژی خاصی تهیه شدهاند؛ لذا اتوماسیون چنین فرآیندهایی منوط به تعامل پذیری سیستمهای مختلف سازمانی است و در این راستا سه استراتژی ارائه شدهاست[24]:
یکپارچهسازی سیستمهای اطلاعاتی داخل سازمانی23 که یکی از اهداف معماری سرویسگرا میباشد و به سرعت در حال همهگیر شدن است. راهحل معماری سرویسگرا برای یکپارچهسازی سیستمهای اطلاعاتی، ارتباط بین سیستمهای اطلاعاتی به کمک وبسرویس است. در معماری سرویسگرا اصل بر این است که همه سیستمهای اطلاعاتی با یک واسط استاندارد و مورد توافق جهانی تعامل داشته باشند. این واسط وبسرویس نام دارد و پروتکلهای مورد استفاده آن نیز شامل SOAP,WSDL,UDDI میباشد. همه این پروتکلها بسطی از XML هستند که استانداردی جهانی و مورد توافق همه سکوها، فناوریها و سازندگان است.
یکپارچگی اتوماسیون فرآیندهای سازمان در قالب همنواسازی؛ اتوماسیون فرآیندهای سازمان تحت عنوان مدیریت فرآیند کسبوکار24 نیز شناخته میشود. معماری سرویسگرا برای مدیریت و اجرای فرآیندهای سازمان از مفهوم همنواسازی کمک گرفته است. در این رهیافت منطق و جریان کار فرآیند از فعالیتهای آن متمایز میشود، به گونهای که جریان گردش فرآیند در قالب زبان اجرایی فرآیند کسبوکار مدیریت میشود ولی هر کدام از فعالیتهای فرآیند میتوانند توسط سیستمهای اطلاعاتی مختلف پیادهسازی شوند. در صورت تغییر منطقی در روند گردش فرآیندها دیگر نیازی به تغییر سیستمهای پشتیبان نمیباشد و این امر کمک شایانی به انعطافپذیری فناوری در پاسخ به تغییرات کسبوکار میکند.


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