</element>
….
….
</schema>
<definitions>
<types>
..…
</types>
<message>
<part />
…..
</message>
<portType>
…..
</portType>
…..
</definitions>
بخش هایی از فایل WSDL که تحت تاثیر استاندارد سازی قرار می گیرند

شکل ۲-۲ : قالب فایل WSDL

اتصال سست بین سرویس‌ها^[۱۹] : همان‌طور که در بخش قبلی اشاره شد در این معماری هر سیستمی از همکاری و ارتباط چند سرویس به وجود می‌آید. نقطه­ای که در زمینه ارتباط سرویس‌ها باید رعایت شود این است که سرویس‌ها باید کمترین وابستگی را نسبت به همدیگر داشته باشند.
تجرد سرویس^[۲۰] : این اصل به طراح سرویس اجازه می‌دهد که سرویس را به صورت جعبه سیاه پیاده­سازی کند و جزئیات پیاده­سازی را از دید دیگران مخفی نگه دارد. هر اندازه این اصل بهتر رعایت شود به همان اندازه وابستگی بین سرویس‌ها کم می‌شود که این عمل به فراهم آوردن اصل «اتصال سست بین سرویس‌ها» کمک می‌کند.
خود مختاری سرویس‌ها^[۲۱] : برای اینکه سرویس‌ها قادر به انجام عملیات خود بدون نقص و با قابلیت اطمینان بالا باشند، باید تا حدودی کنترل محیط و منابع اطراف خود را در اختیار داشته باشند که این شرایط با اصل خود مختاری سرویس‌ها تأمین می‌شود.
(( اینجا فقط تکه ای از متن درج شده است. برای خرید متن کامل فایل پایان نامه با فرمت ورد می توانید به سایت feko.ir مراجعه نمایید و کلمه کلیدی مورد نظرتان را جستجو نمایید. ))

قابلیت استفاده مجدد سرویس^[۲۲] : یکی از دغدغه های اصلی طراحان سیستم‌های نرم­افزاری این بوده است که چگونه یک کامپوننتی ایجاد کنند تا بتوانند علاوه بر استفاده در سیستم خود، آن را برای استفاده در سیستم‌هایی که به این کامپونت نیاز دارند، در اختیار دیگران قرار دهند. امروزه می‌توان گفت که با بهره گرفتن از معماری سرویس­گرا پیشرفت زیادی در این زمینه حاصل شده است که طراحان با این روش به راحتی می‌توانند کامپوننت­های خود را به صورت سرویس پیاده­سازی کنند و آن را از طریق اینترنت در اختیار دیگران قرار دهند و این سادگی به خاطر زیر ساخت‌هایی است که معماری سرویس­گرا فراهم آورده است.
دانه­بندی سرویس^[۲۳] : سرویس‌ها را می‌توان بر حسب لایه­ های مختلف معماری دسته­بندی نمود. انواع مختلفی از دسته بندی سرویس‌ها در متون مختلف آورده شده است. یکی از این دسته­بندی‌ها دارای دانه­بندی با سه نوع سرویس بوده که در ادامه تشریح می­ شود:
سرویس‌های فرآیندی: فرآیندهای اصلی هستند که به صورت سرویس فرآیندی مبدل گشته‌اند. در واقع جزئیات و روال کار مخفی شده و ورودی و خروجی فرایند به عنوان پیام‌های سرویس در نظر گرفته شده‌اند. بدین ترتیب می‌توان جزئیات و روال انجام مراحل فرایند را تغییر داد بدون آنکه تغییری در واسط‌ها و ورودی و خروجی‌ها حاصل شود.
سرویس‌های پایه: این سرویس‌ها نهادهای نسبتاً مستقلی هستند که وابستگی اندکی با قوانین حرفه دارند و به صورت یک موجودیت نسبتاً مستقل تعریف شده‌اند و توسط سرویس‌های فرآیندی قابل فراخوانی هستند.
سرویس‌های کاربردی: نوعی از سرویس‌های ریز هستند که توسط سرویس‌های فرآیندی و پایه فراخوانی می‌شوند ولی وابسته به سرویس دیگری نیستند، یعنی برای ارائه سرویس نیاز به فراخوانی سرویس دیگری ندارند.
توانایی کشف سرویس^[۲۴] : یکی از اصولی که پژوهشگران امروزه خیلی روی آن کار می‌کنند این است که روشی ارائه دهند تا طراحان سیستم‌ها به راحتی بتوانند سرویس‌های مورد نیاز خود را پیدا کنند. امروزه سرویس‌های پیاده­سازی شده‌ی بسیار زیادی در زمینه های مختلف وجود دارند ولی با وجود ارائه‌ روش‌های مختلف هنوز طراحان به آسانی نمی‌توانند سرویس‌های مورد نظر خود را پیدا کنند.
توانایی ترکیب سرویس‌ها^[۲۵] : در بعضی از موارد ممکن است به سرویسی نیاز داشته باشیم که از ترکیب سرویس‌های دیگر بدست می‌آید. به همین دلیل سرویس‌ها باید توانایی ترکیب با هم دیگر داشته باشند.

۲-۳ وب­سرویس‌ها

وب سرویس‌ها^[۲۶] امروزه با فراهم ساختن پروتکل‌های استاندارد (یکی از اصول اولیه معماری سرویس گرا) در رابطه با توصیف، نحوه‌ی ارتباط و نحوه‌ی کشف سرویس‌ها به یکی از ابزار کارآمد در رابطه با پیاده­سازی سرویس‌ها در معماری سرویس­گرا تبدیل شده است به طوری که طراحان امروزه همه سرویس‌های مورد نیاز در سیستم‌ها را با وب­سرویس‌ها پیاده­سازی می‌کنند و به همین دلیل در بیشتر مواقع به جای سرویس از وب سرویس استفاده می­ شود. در ادامه این تحقیق از واژه‌ی وب­سرویس به جای سرویس استفاده می­ شود­. تعاریف مختلفی برای وب­سرویس‌ها ارائه شده است که در ادامه به بعضی از آن‌ ها اشاره می­ شود:
یک سیستم نرم افزاری است که تعامل ماشین با ماشین را در کل یک شبکه پشتیبانی می‌کند و دارای یک واسط تعریف شده به صورت یک فایل توصیفی wsdl می­باشد که توسط ماشین قابل پردازش است. برای تعامل با ماشین‌های دیگر از پیام‌هایی که از پروتکل soap تبعیت می‌کنند، استفاده می‌کند و توسط ماشین‌های دیگر از طریق آدرس اینترنتی قابل شناسایی هستند[۱۷] .
برنامه های کاربردی اینترنتی هستند که از طریق پروتکل انتقال ابرمتن^[۲۷] قابل دسترسی و بر روی یک کامپیوتر دور قابل اجرا هستند [۱۸] .
روش کلیدی برای پیاده­سازی سرویس‌ها در معماری سرویس­گرا هستند [۱۵] .
وب سرویس‌ها کامپوننت­های نرم افزاری هستند که توانایی همکاری با هر نوع شبکه­ ای را دارند و یک نتیجه‌ی مشخصی را به کاربر پایانی تحویل می­دهد[۱۹] .
علاوه بر بعضی ویژگی‌هایی که در تعاریف بالا به آن‌ ها اشاره شد، وب­سرویس‌ها ویژگی‌های دیگری نیز دارند که در زیر به آن‌ ها اشاره خواهد شد. در واقع با دارا بودن این ویژگی‌ها اصولی که در بخش قبلی برای معماری سرویس گرا آورده شده بود، در وب سرویس‌ها هم در نظر گرفته شده است.
مستقل از سکو^[۲۸] و زبان هستند.
خود شمول هستند.
خود توصیف هستند.
با سرویس‌های تحت وب تعامل دارند نه کاربران.
قابل شناسایی هستند.
در سطح اینترنت قابل دسترس باشند.

۲-۳-۱ پروتکل WSDL

توسعه دهندگان وب­سرویس‌ها برای اینکه بتوانند وب سرویس‌های خود را در مخازن ثبت سرویس منتشر کنند، به یک فایل توصیفی نیاز دارند که از یک طرف بتوانند از طریق آن اهداف و قابلیت‌های وب سرویس‌های خود را برای دیگران نمایش دهند و از طرف دیگر هم جزئیات پیاده­سازی وب سرویس‌های خود را از دید دیگران مخفی کنند (تجرید وب سرویس). در واقع هدف اصلی پروتکل WSDL ^[۲۹] ایجاد یک فایل توصیفی برای وب سرویس‌ها با در نظر گرفتن شرایط فوق می­باشد. تعریفی که سازمان استاندارد بین‌المللی W3C ^[۳۰] در رابطه با پروتکل WSDL و وب سرویس‌ها ارائه کرده است به این صورت است که WSDL وب سرویس‌ها را به صورت مجموعه ­ای از نقاط پایانی تعریف می‌کند. هر نقطه‌ی پایانی یک آدرس اینترنتی است که کاربران با بهره گرفتن از آن‌ ها می‌توانند به مجموعه ­ای از عملیات وب سرویس‌ها دستیابی پیدا کنند. شکل ۲-۳ قالب کلی بخش‌هایی را نشان می­دهد که باید در فایل توصیفی WSDL آورده شود.

شکل ۲-۳ : واسط‌ها و نقاط پایانی که در فایل توصیفی باید مشخص شوند [۲۰]

فایل‌های توصیفی وب سرویس‌ها از شش عنصر اصلی تشکیل شده است که در ادامه به طور مختصر شرح داده خواهند شد.
بخش‌های اصلی یک فایل WSDL :
Type: عنصر Type انواع داده‌ی ساده و پیچیده­ای که در تبادل پیام‌ها نقش دارند به فایل توصیفی اضافه می‌کند. برای این عمل از الگوی^[۳۱]XSD که مخصوص تعاریف داده­ای در XM^[32] می­باشد، استفاده می‌کند تا حداکثر همکاری و مستقل از پلت فرم بودن رعایت شود.
Message: پیام‌ها در واقع مجموعه پارامترهای ورودی و خروجی عملیات^[۳۳] وب­سرویس‌ها هستند. هر پیامی به وسیله نام آن تعریف می‌شود و ممکن است چندین بخش^[۳۴] داشته باشد که هر بخش آن نشان دهنده‌ی یک پارامتر ورودی یا خروجی است. برای مثال اگر یک عملیاتی دارای دو پارامتر ورودی داشته باشد، پیام ورودی مربوط به این عملیات دارای دو بخش خواهد بود.