دانلود پایان نامه *67- فایل

معماری سرویس گرا الگویی برای سازمان‌ها و استفاده از قابلیت‌های توزیع شده آن‌ها تحت نظارت افراد گوناگونی می‌باشد.
با توجه به تعریفی که در بالا آمده است معماری سرویس گرا یک الگو می‌باشد. به عبارت دیگر SOA یک رویکرد و یا یک روش تفکری است، بنابراین نمی‌توان گفت که یک ابزار می‌باشد، که بتوان آن را خرید ADDIN EN.CITE <EndNote><Cite><Author>Josuttis</Author><Year>2007</Year><RecNum>10</RecNum><DisplayText>[12]</DisplayText><record><rec-number>10</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">10</key></foreign-keys><ref-type name="Generic">13</ref-type><contributors><authors><author>Josuttis, N.</author></authors></contributors><titles><title>SOA in practice-Art of Distributed Sys-- Design. 2007</title></titles><dates><year>2007</year></dates><publisher>O&apos;Reilly &amp; Assoc</publisher><urls></urls><language>en</language></record></Cite></EndNote>[12].
معماری سرویس گرا شامل سیاست‌ها، تجارب و چارچوب‌هایی است که کارکردهای سیستم را قادر می‌سازد به صورت مجموعه ای از سرویس‌های توزیع شده در اندازه های مورد نظر سازمان تعریف شوند. این سرویس‌ها با کمک تعریف یک واسط استاندارد از پیاده سازی مجزا شده‌اند ADDIN EN.CITE <EndNote><Cite><Author>مهجوریان</Author><Year>زمستان 88</Year><RecNum>12</RecNum><DisplayText>[1]</DisplayText><record><rec-number>12</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">12</key></foreign-keys><ref-type name="Conference Proceedings">10</ref-type><contributors><authors><author><style face="normal" font="default" charset="178" size="100%">امیر مهجوریان</style></author><author><style face="normal" font="default" charset="178" size="100%">فریدون شمس</style></author></authors></contributors><titles><title><style face="normal" font="default" charset="178" size="100%">طراحی سازمان سرویس گرا بر اساس اصول معماری سرویس گرا</style></title><secondary-title><style face="normal" font="default" charset="178" size="100%">طراحی سازمان سرویس گرا بر اساس اصول معماری سرویس گرا</style></secondary-title></titles><dates><year><style face="normal" font="default" charset="178" size="100%">زمستان 88</style></year></dates><urls></urls><language>a</language></record></Cite></EndNote>[1].
افراد مختلف با توجه به جایگاه خود دیدگاه های متفاوتی نسبت به معماری سرویس گرا دارند و در ادامه سه دیدگاه کارشناسان حرفه، معماران و طراحان از معماری سرویس گرا توضیح داده شده است:
کارشناسان حرفه: مجموعه ای از سرویس‌ها که سازمان آن‌ها را به مشتریان یا شرکا خود ارائه می‌دهد.
معماران: سبکی از معماری که شامل قوانین و الگوهایی می‌باشد که منجر به ایجاد خصایصی نظیر پیمانه ای بودن، بسته بندی، اتصال سست، استفاده مجدد و ترکیب پذیری شده و از نظر ساختار از یک ارائه دهنده و یک درخواست کننده سرویس تشکیل شده است.
طراحان و پیاده سازان: مدل برنامه نویسی که از استانداردهایی مانند WSDL، UDDI، SOAP و فناوری‌هایی نظیر وب سرویس‌ها استفاده می‌کند و امکان برقراری ارتباط بین مؤلفه های نرم افزاری را مستقل از سکو و فناوری پیاده سازی فراهم می‌آورد ADDIN EN.CITE <EndNote><Cite><Author>مهجوریان</Author><Year>زمستان 88</Year><RecNum>12</RecNum><DisplayText>[1]</DisplayText><record><rec-number>12</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">12</key></foreign-keys><ref-type name="Conference Proceedings">10</ref-type><contributors><authors><author><style face="normal" font="default" charset="178" size="100%">امیر مهجوریان</style></author><author><style face="normal" font="default" charset="178" size="100%">فریدون شمس</style></author></authors></contributors><titles><title><style face="normal" font="default" charset="178" size="100%">طراحی سازمان سرویس گرا بر اساس اصول معماری سرویس گرا</style></title><secondary-title><style face="normal" font="default" charset="178" size="100%">طراحی سازمان سرویس گرا بر اساس اصول معماری سرویس گرا</style></secondary-title></titles><dates><year><style face="normal" font="default" charset="178" size="100%">زمستان 88</style></year></dates><urls></urls><language>a</language></record></Cite></EndNote>[1].
معماری سرویس گرا را می‌توان در روابط بین مشتریان سرویس، فراهم آورندگان سرویس و دلالان سرویس تعریف کرد و این 3 حوزه در کنار یکدیگر، یک محیط کسب و کار سرویس گرا را به وجود می‌آورند ADDIN EN.CITE <EndNote><Cite><Author>Kanchanavipu</Author><Year>2008</Year><RecNum>8</RecNum><DisplayText>[10]</DisplayText><record><rec-number>8</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">8</key></foreign-keys><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Kanchanavipu, K.</author></authors></contributors><titles><title>An Integrated Model for SOA Governance</title><secondary-title>rapport nr.: Report/IT University of Göteborg 2008: 002</secondary-title></titles><periodical><full-title>rapport nr.: Report/IT University of Göteborg 2008: 002</full-title></periodical><dates><year>2008</year></dates><urls><related-urls><url>http://hdl.handle.net/2077/10495</url></related-urls></urls><language>en</language></record></Cite></EndNote>[10].

شکل 2-1 : محیط کسب و کار سرویس گرا ADDIN EN.CITE <EndNote><Cite><Author>Kanchanavipu</Author><Year>2008</Year><RecNum>8</RecNum><DisplayText>[10]</DisplayText><record><rec-number>8</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">8</key></foreign-keys><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Kanchanavipu, K.</author></authors></contributors><titles><title>An Integrated Model for SOA Governance</title><secondary-title>rapport nr.: Report/IT University of Göteborg 2008: 002</secondary-title></titles><periodical><full-title>rapport nr.: Report/IT University of Göteborg 2008: 002</full-title></periodical><dates><year>2008</year></dates><urls><related-urls><url>http://hdl.handle.net/2077/10495</url></related-urls></urls><language>en</language></record></Cite></EndNote>[10]
2-2-4 مزایای استفاده از معماری سرویس گرا
مزایای عمده استفاده از SOA شامل قابلیت استفاده مجدد از سرویس‌ها و خدمات، توانایی آن در کاهش هزینه‌ها، بهبود فرایند های کسب و کار و چابک سازی سازمان‌ها می‌باشد ADDIN EN.CITE <EndNote><Cite><Author>Svensson</Author><Year>2006</Year><RecNum>13</RecNum><DisplayText>[14]</DisplayText><record><rec-number>13</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">13</key></foreign-keys><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Svensson, C.</author><author>Wallen, L.</author></authors></contributors><titles><title>SOA and M &amp; A-Relationships between Service Oriented Architectures (SOA) and Mergers and Acquisitions (M &amp; A)</title><secondary-title>Department of Informatics, Lund University, Lund, Sweden</secondary-title></titles><periodical><full-title>Department of Informatics, Lund University, Lund, Sweden</full-title></periodical><dates><year>2006</year></dates><urls></urls><language>en</language></record></Cite></EndNote>[14].
2-2-4-1 استفاده مجدد
معماری سرویس گرا این امکان را برای سازمان‌ها و توسعه دهندگان سیستم‌های اطلاعاتی فراهم می‌آورد تا از یک سرویس و یا خدمت چندین بار استفاده نمایند و دیگر نیاز نمی‌باشد تا سازمان‌ها سرویس‌های مورد نیاز خود را از نو پیاده سازی نمایند بلکه سرویس‌های موجود را می‌توانند چندین بار فراخوانی و مورد استفاده قرار دهند و این امر سبب کاهش هزینه‌ها در سازمان می‌شود.

شکل 2-2 : استفاده مجدد از وب سرویس‌ها در معماری سرویس گرا
در این معماری یک مخزنی از سرویس‌ها وجود دارد که وب سرویس‌ها در آن قرار می‌گیرند و کاربران و توسعه دهندگان تنها سرویس‌های مورد نیاز خود را فراخوانی می‌کنند بدون آنکه نیاز باشد از جزئیات آن سرویس‌ها و نحوه پیاده سازی آن‌ها آگاه باشند. از دیگر مزایای استفاده مجدد سرویس‌ها، فراخوانی یک سرویس در سرویس دیگر برای برآورده سازی نیازهای کاربران می‌باشد. معماری سرویس گرا می‌تواند انواع مختلف سیستم‌های اطلاعاتی را بدون هیچ گونه دردسر و به آسانی در سطح سازمانی و فرا سازمانی یکپارچه سازد همچنین دیگر نیاز نمی‌باشد توسعه دهندگان سیستم‌های اطلاعاتی برای افزودن قابلیت‌های جدیدی به نرم افزار کار زیادی انجام دهند. آن‌ها برای این کار از پروتکل‌های استاندارد و وب سرویس‌ها استفاده می‌کنند که در ادامه توضیح داده می‌شود.
2-2-4-2 کاهش هزینه در یکپارچه سازیطراحی خوب معماری سرویس گرا، به سازمان‌ها این امکان را می‌دهد تا برخلاف معماری‌های سنتی که نیاز به سرمایه گزاری های بسیار زیادی داشته، چندین سازمان کوچک با سرمایه و منابع مالی کم یکپارچه و همراه شده و با یکدیگر همکاری نمایند. در معماری سرویس گرا به جای آن که هر سازمان برای خود یک مجموعه کامل از سیستم اطلاعاتی را ایجاد و پیاده سازی نماید می‌تواند سرویس‌های مورد نیاز را برای توسعه سیستم‌های اطلاعاتی از فراهم آورندگان مختلف جمع آوری نماید و آن‌ها را در نرم افزار خود فراخوانی کند و در بدترین حالات سازمان نیاز پیدا می‌کند تا سرویس جدیدی را ایجاد نماید. با توجه با توانایی بالا معماری سرویس گرا در استفاده مجدد از سرویس‌ها و فرایند های سازمان، معماری سرویس گرا نه تنها هزینه های مستقیم سازمان را کاهش می‌دهد تأثیر بسیار زیادی را در کاهش هزینه‌های نگهداری و پشتیبانی می‌گزارد.
2-2-4-3 چابکی کسب و کارمعماری سرویس گرا برای یکپارچه سازی سیستم‌های اطلاعاتی در سازمان‌ها بسیار مناسب می‌باشد. سازمان‌هایی که از این معماری استفاده می‌نمایند می‌توانند سرعت بیشتری را در یکپارچه سازی بخش‌های مختلف به وجود آورند. امکان اضافه و یا تغییر ماژول‌ها در معماری سرویس گرا که فرایند های کسب و کار را شکل می‌دهند و تعامل بین آن‌ها را به وجود می‌آورند به سازمان‌ها این امکان را می‌دهد تا بیشتر تلاش و تمرکزشان به سمت ارزش‌های اصلی و سرعت بخشیدن به معرفی محصولات و خدمات جدید سوق یابد.

شکل 2-3 : چابکی کسب و کار در معماری سرویس گرا2-2-5 وب سرویس
همان طور که از نام معماری سرویس گرا پیداست، SOA تا حد زیادی مبتنی بر سرویس‌ها می‌باشد. یک سرویس می‌تواند نمایش قابلیت‌های کسب و کار یک سازمان باشد و افراد و یا سرویس‌های دیگر که از آن سرویس استفاده می‌کنند نیاز ندارند که از جزئیات تکنیکی سرویس و نحوه پیاده سازی آن اطلاعی داشته باشند همچنین واسط کاربری سرویس باید به گونه ای باشد که افراد در کسب و کار های مختلف بتوانند به آسانی آن سرویس را مورد استفاده قرار دهند ADDIN EN.CITE <EndNote><Cite><Author>Josuttis</Author><Year>2007</Year><RecNum>10</RecNum><DisplayText>[12]</DisplayText><record><rec-number>10</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">10</key></foreign-keys><ref-type name="Generic">13</ref-type><contributors><authors><author>Josuttis, N.</author></authors></contributors><titles><title>SOA in practice-Art of Distributed Sys-- Design. 2007</title></titles><dates><year>2007</year></dates><publisher>O&apos;Reilly &amp; Assoc</publisher><urls></urls><language>en</language></record></Cite></EndNote>[12] و این یک مزیت بسیار مهم برای معماری سرویس گرا در تعامل با ذی‌نفعان می‌باشد.
همان طور که قبلاً اشاره شده یکی از نقاط قوت معماری سرویس گرا قابلیت آن‌ها در همگون سازی عملیات بین سیستم‌های اطلاعاتی ناهمگون و استفاده مجدد از توابع و سرویس‌ها در سیستم‌های نرم افزاری جدید می‌باشد. معماری سرویس گرا برای یکپارچه‌سازی و ارتباط بین سیستم‌های اطلاعاتی از وب سرویس‌ها استفاده می‌کند.
در هر سرویس تنها خروجی آن سرویس برای کاربران مهم است و اینکه از چه پلتفرمی استفاده می‌شود و یا چه زبان برنامه نویسی مطرح نمی‌باشد، بنابراین سیستم‌های ناهمگون به آسانی می‌توانند با یکدیگر در تعامل و ارتباط قرار گیرند.
وب سرویس‌ها با یکپارچه سازی نرم افزار های تجاری موجود در اینترنت امکان اجرای کارآمد تبادلات بین دو بنگاه (B2B) و ایجاد بستری برای تجارت الکترونیک (B2C) را تسهیل می‌بخشند. وب سرویس‌ها می‌توانند به تنهایی در یک نرم افزار یا در وب سرویس‌های دیگر برای مبادلات پیچیده تجاری مورد استفاده قرار گیرند ADDIN EN.CITE <EndNote><Cite><Author>D&apos;Mello</Author><Year>2010</Year><RecNum>14</RecNum><DisplayText>[15]</DisplayText><record><rec-number>14</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">14</key></foreign-keys><ref-type name="Conference Paper">47</ref-type><contributors><authors><author>D&apos;Mello, D. A.</author><author>Ananthanarayana, V. S.</author></authors></contributors><titles><title>Review of Quality of Service (QoS) Driven Dynamic Web Service Selection Techniques</title><secondary-title>Industrial and Information Sys--s (ICIIS)</secondary-title></titles><pages>201 - 206 </pages><dates><year>2010</year></dates><urls></urls><language>en</language></record></Cite></EndNote>[15].
تکنولوژی وب سرویس‌ها بر مبنای استانداردهای XML نظیر SOAP، WSDL و UDDI می‌باشد. معماری سرویس گرا به دلیل پتانسیل بسیار بالای آن برای استفاده مجدد، کارایی و مقیاس پذیری بالا و قابلیت یکپارچه سازی سیستم‌های اطلاعاتی محبوبیت بالایی را نزد توسعه دهندگان سیستم‌های اطلاعاتی بدست آورده است ADDIN EN.CITE <EndNote><Cite><Author>Street</Author><Year>2008</Year><RecNum>15</RecNum><DisplayText>[16]</DisplayText><record><rec-number>15</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">15</key></foreign-keys><ref-type name="Conference Proceedings">10</ref-type><contributors><authors><author>Street, J.</author><author>Gomaa, H.</author></authors></contributors><titles><title>Software Architectural Reuse Issues in Service-Oriented Architectures</title><secondary-title>Hawaii International Conference on Sys-- Sciences, Proceedings of the 41st Annual</secondary-title></titles><pages>316-316</pages><dates><year>2008</year></dates><publisher>IEEE</publisher><isbn>0769530753</isbn><urls></urls><language>en</language></record></Cite></EndNote>[16].
2-2-5-1 انتخاب و کشف وب سرویسیکی از مهم‌ترین مسائلی که در معماری سرویس گرا وجود دارد حل مسائلی نظیر کشف، انتخاب و ترکیب سرویس‌ها می‌باشد. کشف سرویس فرایندی است که در آن کاربر سرویس‌های مورد نیاز خود را از مخزن سرویس می‌یابد و می‌تواند آن را در بین سرویس‌های موجود انتخاب نماید بنابراین بدیهی می‌باشد که کاربران قبل از هرگونه انتخاب سرویس، ابتدا باید سرویس‌های مورد نیاز خود را جستجو نمایند. در ADDIN EN.CITE <EndNote><Cite><Author>Sathya</Author><Year>2011</Year><RecNum>16</RecNum><DisplayText>[17]</DisplayText><record><rec-number>16</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">16</key></foreign-keys><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Sathya, M.</author><author>Swarnamugi, M.</author><author>Dhavachelvan, P.</author><author>Sureshkumar, G.</author></authors></contributors><titles><title>Evaluation of qos based web-service selection techniques for service composition</title><secondary-title>International Journal of Software Engineering (IJSE)</secondary-title></titles><periodical><full-title>International Journal of Software Engineering (IJSE)</full-title></periodical><pages>73</pages><volume>1</volume><number>5</number><dates><year>2011</year></dates><urls></urls><language>en</language></record></Cite></EndNote>[17] نیازمندی‌های پایه برای هر کدام از رویکردهای انتخاب سرویس به صورت زیر بیان شده است:
نیازهای مورد انتظار مشتریان از سرویس‌ها، سرویس‌های ارائه شده توسط فراهم آورنده سرویس و فرایند انتخاب سرویس
نیازهای مورد انتظار مشتریان از سرویس‌ها:
نیازهای مشتریان ممکن است ساده و یا پیچیده باشد. نیازهای ساده مشتریان می‌تواند توسط یک سرویس به تنهایی پاسخ داده شود و دیگر نیازی به ترکیبی از سرویس‌ها نباشد. اما برای برآورده سازی نیازهای پیچیده کاربران که شامل نیازهای عملیاتی و غیرعملیاتی می‌باشد باید سرویس‌های مختلف را با یک دیگر ترکیب نمود. یک سرویس مرکب سرویسی می‌باشد که با اجرای چندین سرویس در دسترس یک فرایند را انجام می‌دهد. مشتریان سرویس‌ها انتظار دارند علاوه بر برآورده سازی نیازمندی‌های عملیاتی، نیازهای غیرعملیاتی آن‌ها نیز که شامل یکسری معیارهای کیفیت سرویس نظیر درجه اطمینان به سرویس، زمان پاسخگویی و... می‌باشد توسط سرویس‌های انتخاب شده برآورده شود بنابراین امروزه انتخاب سرویس‌ها مبتنی بر معیارهای کیفیت سرویس برای کاربران اهمیت بسیاری پیدا کرده است.
سرویس‌های ارائه شده توسط فراهم آورنده سرویس:
سرویس‌های ارائه شده توسط فراهم آورنده سرویس علاوه بر برآورده سازی نیازهای عملیاتی کاربران، باید پاسخگو نیازهای کیفی آن‌ها نیز باشد. نیاز‌های عملیاتی به نیاز‌هایی گفته می‌شود که بیانگر عملکرد یک سرویس است و نیازهای غیرعملیاتی بیانگر کیفیت عملکردی سرویس می‌باشد.
فرایند انتخاب سرویس:
در مرحله انتخاب سرویس باید نیازهای کاربران را با سرویس‌های ارائه شده توسط فراهم آورنده تطبیق دهیم. انتخاب پویای سرویس‌ها شامل دریافت نیازهای کاربر، انتشار و ثبت سرویس توسط فراهم آورنده آن با استفاده از زبان توصیف سرویس‌ها و در نهایت تطبیق نیازهای کاربران با سرویس‌هایی انتشار داده شده و انتخاب یک سرویس برای برآورده سازی نیاز کاربران می‌باشد.
سرویس‌هایی که کشف شده‌اند به عنوان ورودی به فرایند انتخاب سرویس داده می‌شوند تا بهترین سرویس که نیازهای عملیاتی و کیفی کاربران را برآورده می‌سازد از بین چندین سرویس کشف شده انتخاب شود. تکنیک‌ها و رویکرد‌های مختلفی برای انتخاب بهینه سرویس‌ها در دهه اخیر توسط پژوهشگران ارائه شده است.
2-2-6 ترکیب وب سرویس‌هادر ایجاد و اجرای فرایندهای کسب و کار زمانی که یک سرویس به تنهایی نتواند نیازهای کاربران را برآورده سازد می‌توانیم چندین سرویس را در کنار یک دیگر قرار دهیم و آن‌ها را با هم ترکیب نموده و این‌گونه ارزش افزوده برای وب سرویس‌ها ایجاد نماییم.
برای مثال فرض کنید کنفرانس بین‌المللی در کشور دیگر در حال برگزاری است و شرکت کنندگان قبل از حضور در کنفرانس باید اقدام به رزرو هتل، رزرو بلیط هواپیما یا دیگر وسایل نقلیه، پرداخت هزینه ثبت نام در کنفرانس و غیره کنند. مسئولین برگزار کننده کنفرانس برای راحتی شرکت کنندگان که می‌خواهند در کنفرانس حاضر شوند برنامه ریزی سفر و ثبت نام در کنفرانس را توسط ارائه سرویس‌هایی به صورت خودکار در آورده‌اند.
در این سناریو شخص شرکت کننده وارد وب سایت کنفرانسی که قرار است در آن شرکت کند می‌شود اگر بخواهد تنها در کنفرانس ثبت نام کند با پر کردن فرم و پرداخت مبلغ ثبت نام این کار را انجام می‌دهد و اگر نیز بخواهد می‌تواند هتل و وسیله نقلیه را برای شرکت در کنفرانس از طریق وب سایت کنفرانس رزرو نماید و هزینه آن را پرداخت کند در این سناریو سرویس‌های مجزا و تک کاره با یکدیگر ترکیب شده و سرویس یکپارچه ای را برای حضور نویسندگان مقالات در کنفرانس فراهم آورده و در نهایت یک سرویس ترکیبی ایجاد شده است. زمانی که سرویس دهنده‌ای ترکیبی از سرویس‌ها را ارائه می‌دهد در ابتدا باید یک جریان کاری از فعالیت‌ها را طراحی نماید که هر کدام از این فعالیت‌ها توسط یک وب سرویس قابل انجام می‌باشد. شکل 2-4 جریان‌های کاری از فعالیت‌های سازمان را نشان می‌دهد که شامل 7 وب سرویس WS1، WS2، WS3، ...، WS7 می‌باشد. هر کدام از این وب سرویس‌ها می‌توانند پیاده‌سازی‌های متفاوت اما عملکرد‌های مشابهی داشته باشند بنابراین در ادامه باید اطلاعاتی راجع به پیاده‌سازی‌های تمامی وب سرویس‌های موجود بدست آوریم که این اطلاعات شامل ویژگی‌های کیفی، آدرس اینترنتی، وابستگی‌ها و تضاد‌های سرویس‌ها نسبت به یکدیگر می‌باشند.
شکل 2-4 : ترکیب وب سرویس‌ها در جریان کاریسپس باید از ابزاری برای ترکیب کارای وب سرویس‌ها با در نظر داشتن معیار‌های کیفی کاربران استفاده کنیم که در ادامه راجع به آن صحبت خواهیم کرد.
2-2-6-1 سرویس مرکبسرویس مرکب سرویسی است که از ترکیب چندین سرویس به وجود آمده و این سرویس‌ها با یکدیگر در تعامل می‌باشند. در ترکیبی از وب سرویس‌ها هرکدام از آن‌ها ممکن است در پلتفرم‌ها و محیط‌های مختلفی پیاده سازی شده و در سیستم اطلاعاتی جداگانه ای به کار گرفته شده باشند. در یک سرویس مرکب، برای دست یابی به هدف که همان اجرای فرایند کسب و کار می‌باشد تمامی سرویس‌ها باید با یکدیگر در تعامل باشند ADDIN EN.CITE <EndNote><Cite><Author>Zeng</Author><Year>2008</Year><RecNum>17</RecNum><DisplayText>[18]</DisplayText><record><rec-number>17</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">17</key></foreign-keys><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Zeng, L.</author><author>Ngu, A.H.H.</author><author>Benatallah, B.</author><author>Podorozhny, R.</author><author>Lei, H.</author></authors></contributors><titles><title>Dynamic composition and optimization of Web services</title><secondary-title>Distributed and Parallel Databases</secondary-title></titles><periodical><full-title>Distributed and Parallel Databases</full-title></periodical><pages>45-72</pages><volume>24</volume><number>1</number><dates><year>2008</year></dates><isbn>0926-8782</isbn><urls></urls><language>en</language></record></Cite></EndNote>[18].
یک سرویس مرکب خود ترکیبی از چند سرویس تک کاره و یا سرویس مرکب می‌باشد که بر اساس یک الگو از پیش تعریف شده فراخوانی می‌شوند و یک سرویس پیچیده برای اجرای فرایند کسب و کار را ایجاد می‌کنند ADDIN EN.CITE <EndNote><Cite><Author>Sivasubramanian</Author><Year>2009</Year><RecNum>18</RecNum><DisplayText>[19]</DisplayText><record><rec-number>18</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">18</key></foreign-keys><ref-type name="Conference Proceedings">10</ref-type><contributors><authors><author>Sivasubramanian, SP</author><author>Ilavarasan, E.</author><author>Vadivelou, G.</author></authors></contributors><titles><title>Dynamic web service composition: Challenges and techniques</title><secondary-title>Intelligent Agent &amp; Multi-Agent Sys--s, IAMA 2009</secondary-title></titles><pages>1-8</pages><dates><year>2009</year></dates><publisher>IEEE</publisher><isbn>1424447100</isbn><urls></urls><language>en</language></record></Cite></EndNote>[19].
BPEL2-2-6-2
BPEL یک زبان مبتنی بر XML برای تعریف و اجرای فرایندهای کسب و کار با بهره گیری از جریان‌های کاری مبتنی بر وب سرویس می‌باشد. یک فرایند شامل مجموعه ای از متغیرها و جریان‌های کاری می‌باشد که به عنوان ترکیبی از فعالیت‌ها بیان می‌شود ADDIN EN.CITE <EndNote><Cite><Author>Baresi</Author><Year>2007</Year><RecNum>19</RecNum><DisplayText>[20]</DisplayText><record><rec-number>19</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">19</key></foreign-keys><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Baresi, L.</author><author>Bianculli, D.</author><author>Ghezzi, C.</author><author>Guinea, S.</author><author>Spoletini, P.</author></authors></contributors><titles><title>Validation of web service compositions</title><secondary-title>Software, IET</secondary-title></titles><periodical><full-title>Software, IET</full-title></periodical><pages>219-232</pages><volume>1</volume><number>6</number><dates><year>2007</year></dates><isbn>1751-8806</isbn><urls></urls><language>en</language></record></Cite></EndNote>[20] به عبارت دیگر BPEL زبانی برای ترکیب وب سرویس‌ها می‌باشد که توسط شرکت‌هایی نظیر IBM، Microsoft، SAP و غیره توسعه یافته است.
BPEL دارای چندین گروه از عناصر سازنده می‌باشد که مهم‌ترین آن‌ها عبارتند از :
<Process> : شروع یک فرایند
<PartnerLink> : تعریف سرویس‌های شرکت کننده در یک ترکیب
<invoke>,<invoke>…<receivey> : فراخوانی همگام و غیر همگام
<variable>,<assign>,<copy> : دست‌کاری متغیرهای میانی و نتایج
<Scop>,<FaultHandlers> : اداره کردن خطا
<Sequence>,<flow> : اجرای موازی و ترتیبی
<Switch> :کنترل منطق ADDIN EN.CITE <EndNote><Cite><Author>Milanovic</Author><Year>2004</Year><RecNum>20</RecNum><DisplayText>[21]</DisplayText><record><rec-number>20</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">20</key></foreign-keys><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Milanovic, N.</author><author>Malek, M.</author></authors></contributors><titles><title>Current solutions for web service composition</title><secondary-title>Internet Computing, IEEE</secondary-title></titles><periodical><full-title>Internet Computing, IEEE</full-title></periodical><pages>51-59</pages><volume>8</volume><number>6</number><dates><year>2004</year></dates><isbn>1089-7801</isbn><urls></urls><language>en</language></record></Cite></EndNote>[21]
2-2-6-3 چرخه حیات سرویس مرکبیک سرویس مرکب شامل ترکیبی از سرویس‌های موجود برای دستیابی به قابلیت‌هایی می‌باشد که یک سرویس به تنهایی نمی‌تواند آن را فراهم آورد. چرخه حیات سرویس مرکب یک دید و نگاه یکپارچه ای از مراحل توسعه و اجرای ترکیب سرویس‌ها با یکدیگر را فراهم می‌آورد.
با توجه به حق انتخاب کاربران در توصیف فعالیت‌های گوناگون در فرایند ترکیب سرویس‌ها، مراحل چرخه حیات می‌توانند متفاوت باشند. شکل ۲-5 مراحل چرخه حیات که در ADDIN EN.CITE <EndNote><Cite><Author>Pessoa</Author><Year>2008</Year><RecNum>21</RecNum><DisplayText>[22]</DisplayText><record><rec-number>21</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">21</key></foreign-keys><ref-type name="Conference Proceedings">10</ref-type><contributors><authors><author>Pessoa, R.M.</author><author>Silva, E.</author><author>van Sinderen, M.</author><author>Quartel, D.A.C.</author><author>Pires, L.F.</author></authors></contributors><titles><title>Enterprise interoperability with SOA: a survey of service composition approaches</title><secondary-title>Enterprise Distributed Object Computing Conference Workshops, 2008 12th</secondary-title></titles><pages>238-251</pages><dates><year>2008</year></dates><publisher>IEEE</publisher><isbn>0769537200</isbn><urls></urls><language>en</language></record></Cite></EndNote>[22] برای توسعه و اجرای ترکیب سرویس‌ها ارائه شده است را نشان می‌دهد.

شکل 2-5 : چرخه حیات سرویس مرکب ADDIN EN.CITE <EndNote><Cite><Author>Pessoa</Author><Year>2008</Year><RecNum>21</RecNum><DisplayText>[22]</DisplayText><record><rec-number>21</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">21</key></foreign-keys><ref-type name="Conference Proceedings">10</ref-type><contributors><authors><author>Pessoa, R.M.</author><author>Silva, E.</author><author>van Sinderen, M.</author><author>Quartel, D.A.C.</author><author>Pires, L.F.</author></authors></contributors><titles><title>Enterprise interoperability with SOA: a survey of service composition approaches</title><secondary-title>Enterprise Distributed Object Computing Conference Workshops, 2008 12th</secondary-title></titles><pages>238-251</pages><dates><year>2008</year></dates><publisher>IEEE</publisher><isbn>0769537200</isbn><urls></urls><language>en</language></record></Cite></EndNote>[22]
تحلیل نیازمندی : اولین مرحله از چرخه حیات سرویس‌های مرکب شناسایی و اولویت بندی کسب و کار و نیازمندی‌های مشتریان می‌باشد. در این مرحله حوزه کار مشخص شده، منابع برنامه ریزی می‌شوند و محیط‌های کسب و کار که سرویس‌های جدید در آن قرار است عمل کنند تعیین می‌شوند. امکان نیاز به سرویس جدید بر مبنای نیازهای مشتریان و تحلیل آن مشخص می‌شود و خروجی این مرحله مستندی از نیازمندی‌های عملکردی و غیر عملکردی سیستم می‌باشد.
طراحی و توصیف : در این مرحله سرویس مرکب، برای برآورده سازی نیازهای کسب و کار مشتریان، که در مرحله قبل شناسایی شدند، طراحی و در ادامه سرویس‌هایی که برای ترکیب نیاز می‌باشند انتخاب و یک مدل فرایندی برای هماهنگی و تعامل وب سرویس‌ها با یکدیگر توصیف می‌شود که شامل گام‌های زیر می‌باشد :
انتخاب سرویس : در ترکیب سرویس‌ها ابتدا باید آنان را انتخاب و رتبه بندی کرد. خروجی الگوریتم انتخاب و رتبه بندی لیستی از سرویس‌ها می‌باشد که این سرویس‌ها نیازهای عملکردی و غیر عملکردی کاربران را بر اساس معیارهای کاربر برآورده می‌سازد.
ایجاد مدل فرآیندی : در ایجاد ترکیبی از سرویس‌ها باید بتوانیم تعیین کنیم که چه سرویس‌هایی، در چه زمانی و توسط چه کسانی اجرا شوند و اجزای آن چه وابستگی با هم داشته باشند. در نتیجه خروجی این مرحله این است که چگونه بین سرویس‌هایی که برای برآورده سازی نیازهای کاربران کشف و انتخاب شده‌اند هماهنگی ایجاد کنیم و این امر می‌تواند توسط روش‌های دستی، نیمه خودکار و خودکار صورت گیرد.
تایید و ارزیابی مدل فرایندی : ممکن است که سرویس‌ها قابلیت و کارکردهای مشابه ای داشته باشند و این احتمال وجود دارد که حالت‌های مختلفی از ترکیب سرویس‌ها برای برآورده سازی نیازهای کاربر به وجود آید بنابراین سرویس مرکب باید مورد ارزیابی قرار گرفته و سرویسی انتخاب شود که هم نیازهای عملیاتی و هم نیازهای غیرعملیاتی کاربران را برآورده سازد. یکی از راه های رایج برای ارزیابی استفاده از یک تابع ارزیابی و رتبه بندی می‌باشد که در آن کاربران برای هر کدام از معیارهای کیفی وزنی را در نظر می‌گیرند و این‌گونه ترکیب‌های مختلف رتبه بندی می‌شوند. همچنین باید اعتبارسنجی از صحت عملکرد سرویس مرکب و تعامل وب سرویس‌ها با یکدیگر در یک ترکیب صورت پذیرد تا در زمان اجرای سرویس مرکب ایجاد شده بن بستی رخ ندهد.
تحقق یافتن : در این مرحله تمرکز بر جزئیات فنی پیاده سازی سرویس می‌باشد. در این مرحله سرویس‌هایی که در مراحل قبل شناسایی و طراحی شده‌اند تولید و تست می‌شوند و پیاده سازی‌های مختلف از سرویس‌ها با زبان‌های برنامه نویسی مختلفی نوشته می‌شوند.
استقرار یافتن : در این مرحله مشکلات نصب، پیکربندی و مدیریت سرویس‌ها مورد بررسی قرار گرفته و نمونه سرویس در محیط اجرای سرویس نشان داده می‌شود.
انتشار یافتن : در این مرحله اطلاعات توصیفی سرویس‌ها انتشار می‌یابد. معمولاً این اطلاعات در یک سند توصیف سرویس ارائه می‌شود و سرویس‌ها می‌توانند توسط کاربران بالقوه شناسایی شوند. مستند توصیف سرویس شامل موارد زیر می‌باشد: سرویس چه کاری را انجام می‌دهد، کجا می‌توان آن را یافت و چگونه می‌توان آن را فراخوانی کرد.
کشف کردن : در این مرحله مشتریان در مستندات توصیف سرویس که در مرحله قبل مشخص شده و در رجیستری سرویس انتشار یافته‌اند جستجو کرده و سرویس‌های مورد نیاز خود را می‌یابند.
انقیاد سرویس : یک سرویس ممکن است پیاده سازی‌های متنوعی داشته باشد و هر پیاده سازی هم استقرارهای متفاوتی داشته باشد در این مرحله نشان داده می‌شود که سرویس نهایی چگونه می‌تواند کشف و نمونه گزاری شود. مرحله انقیاد هم در زمان طراحی و هم در زمان اجرا می‌تواند انجام شود همچنین می‌تواند به صورت پویا و یا ایستا باشد.
اجرا : مرحله اجرا شامل فراخوانی تمامی سرویس‌هایی است که توسط فراهم آورندگان مختلف توسعه داده شده‌اند. اجرای یک سرویس مرکب باید سازگار با مدل فرایندی باشد و برای آن نیاز به یک مکانیزم هماهنگ کننده دارد.
نظارت : در این مرحله فراهم آورنده سرویس باید به طور مداوم بر ترکیب سرویس نظارت کند و کارایی آن را مورد ارزیابی قرار دهد. هدف اصلی از این مرحله برطرف سازی مشکلات احتمالی و خطاهایی است که در حین ترکیب وب سرویس‌ها و اجرای آن‌ها رخ می‌دهد همچنین نظارت بر ترکیب سرویس‌ها تضمین می‌کند توافق نامه سطح سرویس بین فراهم آورنده و گیرنده سرویس برآورده می‌شود.
2-2-6-4 ساختارهای ترکیب وب سرویسیک سرویس ساده می‌تواند با ساختارهای متفاوتی با سرویس‌های دیگر ترکیب شود در شکل ۲-6 چهار نوع از ساختارهای مختلف ترکیب وب سرویس‌ها در فرایندهای کسب و کار شامل ترتیبی، انشعابی، شرطی، و حلقه نشان داده شده است ADDIN EN.CITE <EndNote><Cite><Author>Yu</Author><Year>2007</Year><RecNum>22</RecNum><DisplayText>[23]</DisplayText><record><rec-number>22</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">22</key></foreign-keys><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Yu, T.</author><author>Zhang, Y.</author><author>Lin, K.J.</author></authors></contributors><titles><title>Efficient algorithms for Web services selection with end-to-end QoS constraints</title><secondary-title>ACM Transactions on the Web (TWEB)</secondary-title></titles><periodical><full-title>ACM Transactions on the Web (TWEB)</full-title></periodical><pages>6</pages><volume>1</volume><number>1</number><dates><year>2007</year></dates><isbn>1559-1131</isbn><urls></urls><language>en</language></record></Cite></EndNote>[23].
در (a) وب سرویس 2 زمانی که وب سرویس 1 به اتمام برسد آغاز به کار می‌کند، در (b) هر دو وب سرویس در یک زمان و به طور موازی شروع به کار می‌کنند، در (c) نقطه تصمیمی وجود دارد که تعیین می‌کند کدام سرویس اجرا شود و در (d) سرویس 1 به تعداد K بار اجرا می‌شود.

شکل 2-6 : ساختارهای ترکیب وب سرویس‌ها در جریان‌های کاریپیچیدگی ترکیب وب سرویس‌ها بستگی به تعداد و پیچیدگی فرایندهای کسب و کار و ورودی و خروجی وب سرویس‌ها دارد.
ساختار ترتیبی: در ساختار ترتیبی هر یک از وب سرویس‌ها بعد از دیگری اجرا می‌شوند و تا زمانی که اجرای یکی از سرویس‌ها به اتمام نرسد وب سرویس دیگر اجرا نمی‌شود. شکل2-6 (a)
ساختار انشعابی: در این ساختار بعد از اتمام یک سرویس تمامی سرویس‌های بعد از آن به صورت موازی با یکدیگر اجرا می‌شوند. شکل 2-6 (b)
ساختار شرطی: در این ساختار بعد از اتمام یک سرویس تنها یکی از سرویس‌های بعد از آن اجرا می‌شود و چون یک ساختار احتمالی و غیرقطعی می‌باشد در آن باید بدترین حالت را برای محاسبه مجموع معیارهای کیفی در نظر گرفت، بنابراین از عملگرهای مینیمم و ماکسیمم استفاده می‌کنیم ( شکل 2-6 (c) ). برای مثال برای یک جریان کاری که ساختار شرطی دارد برای محاسبه مجموع ارزش معیار کیفی هزینه C1 و C2 می‌توان از رابطه Max(C1,C2) استفاده نمود ADDIN EN.CITE <EndNote><Cite><Author>Ko</Author><Year>2008</Year><RecNum>23</RecNum><DisplayText>[24]</DisplayText><record><rec-number>23</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">23</key></foreign-keys><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Ko, J.M.</author><author>Kim, C.O.</author><author>Kwon, I.H.</author></authors></contributors><titles><title>Quality-of-service oriented web service composition algorithm and planning architecture</title><secondary-title>Journal of Sys--s and Software</secondary-title></titles><periodical><full-title>Journal of Sys--s and Software</full-title></periodical><pages>2079-2090</pages><volume>81</volume><number>11</number><dates><year>2008</year></dates><isbn>0164-1212</isbn><urls></urls><language>en</language></record></Cite></EndNote>[24].
ساختار حلقه: در این ساختار اجرای یک سرویس چندین بار تکرار می‌شود و تعداد کل تکرار توسط یک متغیر مانند K مشخص می‌شود ( شکل 2-6 (d) ). برای مثال برای یک جریان کاری که ساختار حلقه دارد برای محاسبه مجموع ارزش معیار کیفی هزینه Ci هزینه کل آن سرویس از رابطه K*Ci بدست می‌آید ADDIN EN.CITE <EndNote><Cite><Author>Canfora</Author><Year>2005</Year><RecNum>24</RecNum><DisplayText>[25]</DisplayText><record><rec-number>24</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">24</key></foreign-keys><ref-type name="Conference Proceedings">10</ref-type><contributors><authors><author>Canfora, G.</author><author>Di Penta, M.</author><author>Esposito, R.</author><author>Villani, M.L.</author></authors></contributors><titles><title>An approach for QoS-aware service composition based on genetic algorithms</title><secondary-title>GECCO &apos;05 Proceedings of the 2005 conference on Genetic and evolutionary computation </secondary-title></titles><pages>1069-1075</pages><dates><year>2005</year></dates><publisher>ACM</publisher><isbn>1595930108</isbn><urls></urls><language>en</language></record></Cite></EndNote>[25].
شکل ۲-7 مثالی از ترکیب سرویس‌های وب به همراه ساختار آن‌ها را نشان می‌دهد که در آن بعد از WS2 یکی از دو وب سرویس WS5 یا WS6 با یک احتمال مشخصی اجرا می‌شود. وب سرویس WS2 نیز حداکثر به اندازه K بار اجرا می‌شود.

شکل 2-7 : ترکیب وب سرویس‌ها به همراه ساختارشان2-2-6-5 محدودیت‌ها در ترکیب وب سرویس‌هادر ترکیب وب سرویس‌ها می‌توان دو محدودیت را در نظر گرفت 1) محدودیت وابستگی 2) محدودیت تضاد.
محدودیت وابستگی:
در انتخاب سرویس‌های وب این احتمال وجود دارد که پیاده سازی متفاوت از چندین وب سرویس به یکدیگر وابسته باشند. بنابراین زمانی که ما یک پیاده‌سازی از یک وب سرویس را انتخاب می‌کنیم در انتخاب وب‌ سرویس دوم نیز باید پیاده‌سازی خاص سرویس اول را انتخاب کنیم، برای مثال زمانی که از یک سرویس دهنده تور مسافرتی استفاده می‌کنیم چنانچه از وب‌سرویس خاصی برای رزرو بلیط هتل استفاده کردیم ممکن است پرداخت هزینه آن تنها با مستر کارت امکان پذیر باشد بنابراین باید وب سرویسی انتخاب شود که پرداخت با مستر کارت را پشتیبانی می‌کند این امر منجر به محدودیت وابستگی بین سرویس‌ها می‌شود.
محدودیت تضاد:
به علاوه در انتخاب وب سرویس‌ها این احتمال وجود دارد که پیاده سازی متفاوت از چندین وب سرویس با یکدیگر در تضاد باشند بنابراین زمانی که ما یک پیاده‌سازی از یک وب سرویس را انتخاب می‌کنیم در انتخاب وب ‌سرویس دوم نباید پیاده‌سازی که با سرویس اول در تضاد است را انتخاب کنیم، برای مثال زمانی که از یک سرویس دهنده تور مسافرتی استفاده می‌کنیم چنانچه از سرویس خاصی برای رزرو بلیط هتل استفاده کردیم که پرداخت هزینه با مستر کارت را پشتیبانی نمی‌کند بنابراین نمی‌توانیم یک وب سرویس برای پرداخت را انتخاب کنیم که فقط مستر کارت را پشتیبانی می‌کند. این امر منجر به محدودیت تضاد بین سرویس‌ها می‌شود. در نتیجه باید این دو محدودیت را در انتخاب سرویس‌ها در نظر داشت ADDIN EN.CITE <EndNote><Cite><Author>Tang</Author><Year>2010</Year><RecNum>25</RecNum><DisplayText>[26]</DisplayText><record><rec-number>25</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">25</key></foreign-keys><ref-type name="Conference Proceedings">10</ref-type><contributors><authors><author>Tang, M.</author><author>Ai, L.</author></authors></contributors><titles><title>A hybrid genetic algorithm for the optimal constrained web service selection problem in web service composition</title><secondary-title>Evolutionary Computation (CEC), 2010 IEEE Congress on</secondary-title></titles><pages>1-8</pages><dates><year>2010</year></dates><publisher>IEEE</publisher><isbn>1424469090</isbn><urls></urls><language>en</language></record></Cite></EndNote>[26].
2-2-7 معیارهای کیفیت سرویسیکی از مهم‌ترین چالش‌های پیش روی ترکیب وب سرویس‌ها، ترکیب نمودن سرویس‌ها با توجه به معیارهای کیفیت سرویس می‌باشد. این امر به کاربران کمک می‌کند تا به بهینه‌ترین ترکیب از بین ترکیبات موجود برای برآورده سازی نیازهای عملیاتی و غیر عملیاتی خود دست یابند ADDIN EN.CITE <EndNote><Cite><Author>Canfora</Author><Year>2005</Year><RecNum>24</RecNum><DisplayText>[25]</DisplayText><record><rec-number>24</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">24</key></foreign-keys><ref-type name="Conference Proceedings">10</ref-type><contributors><authors><author>Canfora, G.</author><author>Di Penta, M.</author><author>Esposito, R.</author><author>Villani, M.L.</author></authors></contributors><titles><title>An approach for QoS-aware service composition based on genetic algorithms</title><secondary-title>GECCO &apos;05 Proceedings of the 2005 conference on Genetic and evolutionary computation </secondary-title></titles><pages>1069-1075</pages><dates><year>2005</year></dates><publisher>ACM</publisher><isbn>1595930108</isbn><urls></urls><language>en</language></record></Cite></EndNote>[25].
نیازمندی‌های کاربران را می‌توان به دو دسته نیاز‌های عملیاتی و غیرعملیاتی تقسیم نمود. در وب سرویس‌ها نیاز‌های عملیاتی به نیاز‌هایی گفته می‌شوند که بیانگر عملکرد یک وب‌سرویس است و اینکه وب‌سرویس مورد نظر چه کاری را انجام می‌دهد و نیاز غیرعملیاتی بیان می‌دارد که سرویس کار مورد نظر را با چه کیفیتی انجام می‌دهد. سفارش دهندگان سرویس‌های وب معمولاً نیازمندی‌های غیرعملیاتی خود را با استفاده از یکسری معیار‌های کیفی بیان می‌دارند.
تعداد مختلفی از سرویس‌ها با قابلیت و کارکردهای مشابه توسط فراهم آورندگان مختلف ارائه شده‌اند هرچند این سرویس‌ها دارای معیارهای کیفی متفاوتی می‌باشند. معیارهای کیفی بر مبنای ویژگی‌هایی نظیر قیمت، زمان پاسخگویی، در دسترس بودن و... تعریف شده‌اند. کاربران می‌توانند بین سرویس‌های مشابه، سرویس که نیاز آن‌ها را برآورده می‌سازد را انتخاب نمایند. ممکن است کاربری ارزان‌ترین سرویس را انتخاب کند و کاربر دیگر سرویس قابل اعتماد تر و گران‌تری را انتخاب نماید همچنین ممکن است کاربری محدودیتی را برای بعضی از ویژگی‌های کیفی در نظر بگیرد (برای مثال قیمت از یک مقداری بیشتر نشود) که می‌تواند انتخاب‌ها را تحت تأثیر قرار دهد همچنین فراهم آورنده سرویس می‌تواند رتبه ای را برای هر یک از مقادیر معیارهای کیفی با توجه به نظرات کاربران آن سرویس در نظر بگیرد و این چنین می‌توان با توجه به نظر کاربران میزان اعتبار هر یک از معیارهای کیفیت سرویس را برای سرویس‌های مشابه تضمین نمود بنابراین زمانی که کاربر برای خرید سرویسی هزینه ای را می‌پردازد و انتظار دارد در زمان مشخصی پاسخ را دریافت کند آن سرویس باید تضمین کند که در زمان مشخص پاسخگوی درخواست کاربر می‌باشد.

شکل 2-8 : معیارهای کیفیت سرویسمقدار و ارزش معیارهای کیفی یک سرویس ساده برای استفاده در ترکیبی از سرویس‌ها، یا توسط فراهم آورنده سرویس مشخص می‌شود یا از طریق محاسبه کردن نتایج آماری اجراهای قبلی آن سرویس بدست می‌آید. ممکن است در زمان اجرا مقدار کیفیت سرویس اندازه گیری شده از آن حدی که اندازه گیری شده و یا تخمین زده شده است منحرف شود و یا سرویس در دسترس نباشد. در این صورت سرویس مرکب برای برآورده سازی حداکثری محدودیت‌ها و معیارهای کیفیت سرویس باید دوباره برنامه ریزی شوند و این برنامه ریزی مجدد برای ترکیب سرویس‌ها باید در سریع‌ترین زمان ممکن صورت پذیرد مخصوصاً برای سیستم‌های تعاملی که این تأخیر ممکن است غیرقابل قبول باشد برای مثال کاربرانی که برای رزرو بلیط از این سرویس‌ها استفاده می‌کنند ممکن است نخواهند مدت زمان طولانی را منتظر بمانند تا سیستم برای یافتن سرویس مناسب در بین سرویس‌های موجود به جستجو بپردازد و ممکن است پس از چند دقیقه انتظار کاربر نا امید شود ADDIN EN.CITE <EndNote><Cite><Author>Canfora</Author><Year>2004</Year><RecNum>26</RecNum><DisplayText>[27]</DisplayText><record><rec-number>26</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">26</key></foreign-keys><ref-type name="Conference Proceedings">10</ref-type><contributors><authors><author>Canfora, G.</author><author>Di Penta, M.</author><author>Esposito, R.</author><author>Villani, M.L.</author></authors></contributors><titles><title>A lightweight approach for QoS-aware service composition</title><secondary-title>ICSOC 2004–short papers. IBM Technical Report</secondary-title></titles><dates><year>2004</year></dates><pub-location>New York, USA,</pub-location><urls></urls><language>en</language></record></Cite></EndNote>[27].

Related posts: