ترکيب سرويسهاي در معماری سرویس گرا

1. ترکيب سرويسهاي در معماری سرویس گرا رضا فیوضی علی کوثری استاد گرامی: جناب دکتر خیرخواه

2. رئوس مطالب • مقدمه • ترکيب سرويس مرکب • بررسي درخواست يك سرويس مركب از طرف کاربر • كشف سرويس • انتخاب • توليد توصيف براي سرويس هاي مركب • زبان هاي Choreography • زبانهاي هم آهنگي • BPEL4WS • OWL-S • Petri-net • اجرای سرويس مرکب • موتور اجرا • بخش مديريت تراکنش • بخش جايگزيني سرويس

3. رئوس مطالب(ادامه) • ديدگاههاي مختلف در زمينه تركيب سرويسهاي مبتني بروب • تركيب وب‌سرويس‌ها به شكل ايستا و پويا • تركيب سرويس‌ها به شكل اتوماتيك يا دستي • تركيب سرويس‌ها بر اساس توصيف و يا مدل‌ها • تركيب سرويس‌ها با استفاده از برنامه‌ريزي هوش‌مصنوعي • هم‌زماني اجرا و تركيب وب‌سرويس‌ها • ادامه‌ی کار • جزء هماهنگ‌کننده اجراي وب‌سرويس‌ها • جزء جايگزيني سرويس • جزء مديريت تراکنش ها • مراجع

4. مقدمه • وب‌سرويس: يک برنامه‌ی کاربردي دسترس‌پذير است که ديگر برنامه‌هاي کاربردي و انسان‌ها مي‌توانند به‌طور اتوماتيک آن را کشف، و از آن استفاده کنند. • سرويس مرکب: ترکيبي از چند سرويس ساده يا مرکب ديگر با هدف انجام يک کار مشترک • ترکيب اتوماتيک وب‌سرويس‌ها: • ترکيب سرويس‌ها • اجراي سرويس مرکب

5. ترکيب سرويس مرکب بررسي درخواست يك سرويس مركب از طرف کاربر كشف سرويس انتخاب توليد توصيف براي سرويس‌هاي مركب

7. مراحل ترکيب سرويس مرکب • بررسي درخواستيك سرويس‌مركب از طرف کاربر: دريافت يك توصيف سطح بالا از سرويس‌مركب موردنياز كاربر توسط موتور‌ترکيب و شکستن آن به زيردرخواست‌ها • كشف سرويس: پيداكردن سرويس‌هاي مناسب جهت اجراي زيردرخواست‌هاي مشخص‌شده • ثبت توصيف معنايی سرويسها در repository • کشف سرويس موردنياز با ارائه‌ی توصيف معنايي آن • توليد ليستی از سرويسهای کشف‌شده به‌ازای هر درخواست • انتخاب: انتخاب مناسب‌ترين سرويس از ليست سرويس‌هاي كشف‌شده در فاز قبل با توجه به معيارهاي: • Functional • Non-functional : كارايي، قابليت اطمينان، امنيت، قابليت گسترش، QoS • نيازمندي‌هاي كاربر • قابليت تركيبسرويسها (Composability): تشکيل مدل قابليت تركيب

8. مراحل ترکيب سرويس مرکب (ادامه) • توليد توصيف براي سرويس‌هاي مركب: شامل • ليست سرويس‌هاي شركت‌كننده در تركيب • ترتيب آن‌ها • روشِ ارتباط آن‌ها • پيغام‌هاي رد و بدل شونده بين آن‌ها • به وسيله‌ی يک زبان توصيف: • زبان‌هاي Choreography: مدلي از رفتار خارجي سرويس‌ها، در قالب پيغام‌هايي كه بين اجزا ردوبدل مي‌شوند • زبان‌هاي هم‌آهنگي (Orchestration):ارتباطات كلي بين وب‌سرويس‌ها در يك وب‌سرويس مركب و چگونگي استفاده‌ي وب‌سرويس مركب از سرويس‌هاي كمكي • هماهنگ کننده (Coordinator):مديريت و هم‌زماني تبادلات و هم‌چنين كنترل ارتباطات بين اجزا

9. زبان‌هاي Choreography • مفهومChoreography به ارتباطات دوطرفه­اي كه بين دو سرويس مختلف، از طريق پيغام، وجود دارد. • WS-CDL (Web Service Choreography Description Language)[1]: • جديدترين زباني است كهW3C جهت توصيف رفتارهاي مشترك و غيرمشترك سرويس ها از يك ديد كاملا كلي طراحي كرده است • بر مبناي XML • مدلي غير لايه اي • WSCI (Web Service Choreography Interface)[2]: • بر مبنايXML • براي توصيف پيغام هاي ورودي و خروجي سرويس ها • هيچ پشتيباني براي معنا نداشته • مدلي غير لايه اي است.

10. زبان‌هاي هم‌آهنگي (Orchestration) • BPEL4WS: • بر پايه زبان­هاي WSFL (متعلق به IBM) و XLANG (متعلق بهMicrosoft ) بناشده است و ترکيبي از امكانات اين دو زبان را در خود دارد. • مبتني بر XML • تعريف سرويس ها را به شكل فرآيند محور(work flow based) • وجود تعداد زيادي سرور براي اجراي سرويس هاي مركب BPEL4WS براي بسترهاي J2EE و .Net

11. زبان‌هاي Choreography (ادامه ) • Petri-net: • اختصاص دادن يك Petri-net به هر فرآِیند • در هرزمان سرويس در يكي از حالات not instantiated، ready، running، suspended، و يا completed قراردارد.

12. زبان‌هاي هم‌آهنگي (Orchestration) • OWL-S: • تعريف معنایی سرويس ها و به شكلي قابل فهم براي ماشين←با استفاده از Ontology: • كشف اتوماتيك سرويس، صدا کردن سرويس ها، تركيب، ارتباط بين آنها وكنترل اجراي آنها • بخش های OWL-S: • Profile: • معرفي سروِس: اين اطلاعات در مراحل كشف سرويس توسط ديگر سرويس ها، كاربران يا عامل ها و.. به كارمي رود. • مدل فرآيند (Process Model): • اطلاعات دقيق تري راجع به عمليات سرويس • طريقه ي استفاده ي سرويس • بيان جزئيات معنايي درخواست ها • شرايطي كه تحت آنها خروجي هاي خاص توليد مي شوند • نحوه درخواست براي يك سرويس، ورودي ها، خروجي ها، پيش شرط ها و اثرات سرويس • Grounding: • جزئيات چگونگيِ ارتباط با يك سرويس از طريق پيغام ها • پروتكل ارتباطي، فرمت پيغام ها و ديگر جزئيات مربوط به سرويس مثل شماره پورت هايي كه سرويس روي آنها قابل دسترسي است

13. زبان‌هاي هم‌آهنگي (Orchestration) • OWL-S

14. مقايسه زبان‌هاي هم‌آهنگي (Orchestration) • زبان انتخاب شده جهت توصيفسرويس مرکب در ارائه

15. اجراي سرويس مرکب موتور اجرا بخش مديريت تراکنش بخش جايگزيني سرويس

16. اجراي سرويس مرکب • فراخوانی سرويس‌هاي شركت‌كننده در وب‌سرويس مركب به ترتيبي كه درنهايت يك وظيفه‌مندي موردنظر را به انجام برسانند. • ورودی: توصيف وب‌سرويس مركب • وظيفه: • آغاز اجراي وب‌سرويس مركب • فراخوانی سرويس‌هاي شركت‌كننده در سرويس مركب به ترتيبي بر اساس توصيف وب‌سرويس مركب • نظارت بر اجراي سرويس مرکب • شناسايي و كنترلخطاهاي زمان اجرا • جايگزيني سرويس‌ها • مديريت تراكنش

17. اجزاي اصلي يک چهارچوب اجرا‌کننده‌ي سرويس مرکب • موتور اجرا(Execution Engine) • بخش جايگزيني سرويس(Replacement Component) • بخش مديريت تراکنش(Transaction Management Component)

18. موتور اجرا(Execution Engine) • نظارت بر اجراي وب‌سرويس‌ مركب(Monitoring) • برخورد مناسب با خطاهاي به وجودآمده در زمان اجراي سرويس مركب: • مشكلات مربوط به سرويس:مثل crash کردن سرور سرويس يا خطاي زمان اجراي سرويس (Exception) • مشكلات مربوط به شبكه • مشكلات مربوط به تركيب: • ناشی از طراحي بدِ تركيب مثل رسيدن به يك بن‌بست ارتباطي در تركيب • خطاي زمان اجراي مربوط به جريان‌كار تركيب (Composition Workflow) • تصميم فراخوانی بخش‌های جايگزيني سرويس و بخش مديريت تراکنشبر اساس خطا

19. بخش جايگزيني سرويس(Replacement Component) • وظيفه: جايگزيني سرويس‌ در زمان اجرا با سرويس‌ معادلِ ديگری كه به تنهايي و يا به‌شكل مركب بتواند وظايف سرويس تعويض‌شده را انجام دهند. • سرويس جايگزين‌شونده: • سرويسی که با خطا مواجه شده • سرويسی که كند شده • سرويسی که كارايي خود را ازدست‌داده است • هنگامي كه تعريف بخشي از سرويس مركب در زمان اجرا تغييرکند • ايده: انتخاب يك سرويس با قابليت‌هاي مشابه سرويس جايگزين شونده، از ليست سرويس‌های کشف‌شده در فاز كشف سرويس‌ها

20. بخش مديريت تراکنش(Transaction Management Component) • تعريف کلاسيک تراکنش (تراکنش‌هاي ACID): تغيير حالتي که چهار ويژگيِ زير را دارد: • Atomicity: «يا همه يا هيچ‌کدام» • سازگاري (Consistency): صحت در تغيير حالت • Isolation: عدم تأثير متقابل تراکنش‌هايي است که هم‌زمان باهم اجرا مي‌شوند • ماندگاري (Durability): عدم امکان لغوکردن تراکنشي که پايان‌يافته است نيز معروفند. • دو رويکرد متفاوت در قبال مديريت تراکنش‌ها: • رويکرد بدبينانه: قفل‌کردن منابع در دسترس تراکنش • رويکرد خوش‌بينانه: • مبنا: در برخي محيط‌ها، امکان بروز ناسازگاري بسيار پايين است ← هزينه‌ي قفل‌کردن منابع در چنين محيط‌هايي به‌صرفه نيست • رويکرد: به جاي قفل‌کردن منابع، تغييرات تراکنش را در محلي مياني نگهداري کرده و در پايان تراکنش تغييرات را يکباره ماندگار مي‌کنيم.

21. بخش مديريت تراکنش (ادامه)(Transaction Management Component) • ويژگي‌هاي محيط وب‌سرويس‌ها: • اتصال و پيوستگي بسيار کم(loosely coupled) • قابليت ‌اطمينان پايين • برخورداری از درجه‌ي بالايي از خودمختاري • مدت اجرای طولانی: با توجه به ماهيت سناريوها در اين محيط، معمولا تراکنش‌ها مدت زيادي به طول مي‌انجامند (مثالا تراکتشی شامل خريد، پرداخت و تحويل کالا که در مجموع چندين روز به طول مي انجامد). • تعلق منابع درگير در يک تراکنش به حوزه‌هاي متفاوت • تراکنش‌هاي ACID برای اين محيط به نظر سخت‌گيرانه مي‌آيند. • اجبارکردن چهار ويژگي تراکنش‌هاي ACID نتايج نامطلوبي به دنبال خواهدداشت. • براي برآوردن نياز تراکنش‌ها در چنين محيطي تراکنش‌هايي با سخت‌گيري کمتر و ضعيف‌تر مطرح شده است. «تراکنش‌هاي طولاني مدت» يا Long Running Transactions • «تراکنش‌هاي طولاني مدت» ويژگي Isolation در تراکنش‌ها را پياده‌سازي نمي‌کنند

22. بخش مديريت تراکنش (ادامه) (Transaction Management Component) • ايده‌ي «خنثاکردن» (Compensation) • تراکنش T↔ خنثاکننده‌يC • خنثاکننده‌يCسرويسي مستقل است که بعد از اتمام تراکنش و خارج از قلمرو آن اجرا مي‌شود • C بعد از اتمام T انجام می‌شود • T نه منابع مورد نيازش را قفل مي‌کند و نه تغييرات موقتي در سيستم ايجاد مي‌کند • تغييرات همگي واقعي بوده و بلافاصله درسيستم قابل مشاهده هستند. • درحالتي که به هردليل خارجي، تراکنش سطح بالاتر با مشکلي مواجه شود، سرويسC براي جبران‌کردن و برطرف‌کردن آثارT اجرا می‌شود • ميزان موفقيت C در ازبين‌بردن تمامي آثار تراکنش T بستگي به زمينه دارد

23. بخش مديريت تراکنش (ادامه)(Transaction Management Component) • چهارچوب‌هاي ارائه شده براي پشتيباني مديريت تراکنش‌ها • Web Service Transaction Management (WS-TXM)[3]: • (بخشي از چهارچوبWeb Service Composite Application Framework (WS-CAF) که توسط شرکت SUN ارائه‌شده است[4]) • معماري لايه‌اي دارد و بر روي دو لايه‌ي ديگرِ چهارچوبِ WS-CAF بنا شده است: • Web Service Context (WS-CTX) [5] • Web Service Coordination Framework (WS-CF) [6] • به طور خاص به اجراي رفتارهاي تراکنشي مي‌پردازد و سه نوع رفتار را براي تراکنش‌ها پشتيباني مي‌کند: • تراکنش‌هاي قديميِ ACID • تراکنش‌هاي طولاني‌مدت (Long Running Actions يا LRAs) • تراکنش‌هاي فرآيندتجاري: يک يا چند تراکنش از دو نوع ديگر را شامل مي‌شوند. • به مسئله‌ي تعريف و مشخص‌کردن تراکنش‌ها و سرويس‌هاي مرکب نپرداخته است.

24. بخش مديريت تراکنش (ادامه) (Transaction Management Component) • WS-Transaction: • مشابه WS-TXM توسط شرکت‌هاي BEA, IBM و Microsoft ارايه شده است. • که به رفتار تراکنش‌ها پرداخته‌است. • دو نوع رفتار براي تراکنش‌ها درنظرگرفته است • تراکنش‌هاي اتميک (Atomic Transactions) • فعاليت‌هاي تجاري (Business Activities) • اين چهارچوب بر روي چهارچوب ديگري که توسط همين گروه ارايه شده است بنا شده که به پشتيباني ارتباط تراکنش‌ها مي‌پردازد (WS-Coordination) • BPEL4WS را به عنوان زبانِ تعريف سرويس مرکب پشتيباني مي‌کند.

25. بخش مديريت تراکنش(Transaction Management Component) • WebTransact: • معماري چند لايه • يک مدل تراکنشي • Web Service Transaction Language: • مبتنی بر XML • گسترشی بر زبان WSDL • تعريف سرويس‌های مرکب • امکان تعريف و توصيف تراکنش‌ها در سطوح مختلف • تمرکز بر رفع مشکل انواع مختلف ناهمگونی موجود در فضای وب‌سرويس‌ها (نحوی، ساختاری و محتوايی) • ايده‌ي سرويس ميانجي (Mediator Service): سرويسي که با مجردکردن مفاهيم سرويس‌ها، به عنوان واسطي بين هماهنگ‌کننده‌ي سرويس‌ها و سرويس‌هاي اصلي قرارمي‌گيرد

26. بخش مديريت تراکنش(Transaction Management Component) • چهارچوب‌هاي ديگربا اهميت و حوزه‌ي پوشش ضعيف‌تر: • Transactional Web Service Orchestration (TWSO)[7] • Business Transaction Framework (BTF)[8] • پژوهش‌هايي که صرفا به تعريف و مشخص‌کردن رفتار تراکنشی پرداخته‌اند: • استفاده از زبان UML جهت تعريف و مشخص‌کردن رفتار تراکنشی و نگاشت به استانداردهاي ديگري مثل BPEL4WS: • کار آقاي شهرام دوستدار و همکارانش [9و 10]. • کارOrriens و همکارانش ]11و 12[.

27. ديدگاههاي مختلف در زمينه تركيب سرويسهاي مبتني بروب تركيب وب‌سرويس‌ها به شكل ايستا و پويا تركيب سرويس‌ها به شكل اتوماتيك يا دستي تركيب سرويس‌ها بر اساس توصيف و يا مدل‌ها تركيب سرويس‌ها با استفاده از برنامه‌ريزي هوش‌مصنوعي همزماني اجرا و تركيب وب‌سرويس‌ها

28. تركيب وب‌سرويس‌ها به شكل ايستا و پويا • تركيب ايستا در طول زمانِ طراحي، اجزاي تركيب انتخاب شده به يكديگر لينك مي‌شوند • مناسب برای محيط‌های بدون تغيير • ماژول‌هاي تشكيل‌دهنده‌ی پلتفرم اجرای سرويسهای مرکبStarWSCop[13] : • سيستم هوشمند براي تجزيه‌ي نيازهاي كاربر • انباري از وب‌سرويس‌هاي ثبت‌شده • موتور كشف‌سرويس • موتور تركيب • مانيتوركننده جهت ثبت وقايع و مطلع‌ساختن موتور تركيب. • سيستمe-flow • تعريف، اجرا و مانيتوركردن e-serviceهاي مركب • كشف پوياي سرويس • تراكنش‌هاي ACID • نمايش يك سرويس مركب به وسيله‌ي يك گراف كه ترتيب اجراي نودها را در پروسه نشان ميدهد

29. تركيب سرويس‌ها به شكل اتوماتيك يا دستي • تركيب دستی: انتخاب سرويس‌هاي شركت‌كننده در ترکیب توسط كاربر از بين سرويس‌هاي موجود • ترکيب اتوماتيک يا مبتنی‌بر آنتولوژی [14]: • چهار ماژول اصلی: specification, matchmaking, selection, generation • ارايه‌ی يك «مدل قابليت تركيب» • معرفی زبان سطح بالای CSSL در ماژول selection • WSDL+ معنا = CSSL • استفاده از محدوديتهای QoS در ماژول selection

30. گسترش WSDLبا استفاده از آنتولوژی

31. تركيب سرويس‌ها بر اساس توصيف و يا مدل‌ها • ترکيب با استفاده از مدل (Orriens): • بر اساس ترکيب پويای وب‌سرويس‌ها • مدل مبتنی‌بر UML با استفاده از دو مفهوم: • المان‌هاي تركيب سرويس • قوانين تركيب سرويس • ترکيب با استفاده از توصيف (enTish): • بيان درخواست‌هاي كاربر به شكل صوري • توصيف صوري سرويس‌هاي موجود • تركيب سرويس‌ها درزمان اجرا

32. تركيب سرويس‌ها با استفاده از برنامه‌ريزي هوش‌مصنوعي • مسئله‌ي برنامه‌ريزي: پنج‌تايي (S, S0, G, A, Г). در محيط وب‌سرويس‌ها: • SO و G حالت‌هاي اوليه و نهاييِ تعريف‌شده در نيازمندي‌هاي درخواست‌دهنده‌ • A مجموعه‌ي سرويس‌هاي موجود • Г نشان‌دهنده تابع تغيير حالت هر سرويس • DAML-S (و متعاقباً OWL-S) تنها زبان وب‌سرويسي است كه امكان برقراري ارتباط مستقيم با برنامه‌ريزي هوش‌مصنوعي را داراست.

33. SHOP2 • مبتني برDAML-S • سيستم برنامه‌ريزي HTN (Hierarchical Task Network) • يك وظيفه را به وظايف بسيار كوچك تجزيه‌مي‌كند • مفهوم تجزيه‌ي وظايف در HTN بسيار مشابه مفهوم تجزيه‌ي Process در DAML-S است اين سيستمِ برنامه‌ريزي كانديد بسيار خوبي براي استفاده در تركيب اتوماتيك وب‌سرويس‌ها به شمار مي‌رود. • پايگاه دانش SHOP2شامل: • عملگرها (operators): توصيفي از آنچه براي انجام يك زيروظيفه‌ مورد‌نياز است • متد: شيوه‌ي تجزيه‌ي يك وظيفه‌ي مركب به زير وظيفه‌ها • يك مسئله‌ي برنامه‌ريزي در SHOP2 يك سه تائي (S, T, D) است که به عنوان وروردي به SHOP2 داده شده و يك برنامه (p1p2…….pn)=P را برمي‌گرداند.pn…,p2,p1 عملگرهايي هستند كه درمجموع باعث رسيدن از S بهT درD مي‌شوند.

34. همزماني اجرا و تركيب وب‌سرويس‌ها • مشکل تركيب و اجراي وب‌سرويس‌هاي مركب به شكل پي‌درپي: محيط‌هاي پويا با تغييرات زياد زمان اجرا • راه حل: هم‌زماني اجرا و تركيب در وب‌سرويس‌ها • ايده: استفاده از عامل‌هاي نرم‌افزاري و تقسيم برنامه به بخش‌هاي كوچك‌تر. پس‌از برنامه‌ريزي هر بخش، بخش مذكور اجرا شده و بخش بعدی برنامه‌ريزي می‌شود. • دو نوع عامل: • کاربر: در نقش كاربر درخواست كننده‌ي سرويس مركب • تامين‌کننده: در نقش تامين‌كنندگان سرويس‌ها • معيارِهای انتخاب سرويس شرکت‌کننده در ترکيب توسط عامل‌كاربر: • هزينه‌ي اجرا • محل قرارگيري عامل‌هاي تامين‌كننده • عامل سوم: عامل‌كمكي

36. ادامه‌ی کار جزء هماهنگ‌کننده اجراي وب‌سرويس‌ها جزء جايگزيني سرويس جزء مديريت تراکنش ها

37. ادامه کار • در اينارائه چهارچوبيجهت اجرايسرويس‌هاي مرکبارايهمي‌شود • ورودی: توصيفيکسرويس مرکب با زبان OWL-S (البته نسخه‌ايگسترش‌يافته ازOWL-S). • جنبه‌هاي مختلف چهارچوب پيشنهادی: • جزء هماهنگ‌کنندهاجرايوب‌سرويس‌ها (Coordinator Component) • جزء جايگزينيسرويس (Replacement Component) • جزء مديريتتراکنش ها(Transaction Management Component)

38. جزء هماهنگ‌کننده اجراي وب‌سرويس‌ها(Coordinator Component) • جزء اجراکننده سرويس مرکب شامل بخشهای زير می‌باشد: • بخش هماهنگ‌کننده بين سرويسها (Coordinator Component): • ايجاد ارتباط بين سرويس‌هاي بدوی سرويس مرکب • انتقال اطلاعات بين سرويس‌ها • برقراري ارتباط با ساير اجزاء چهارچوب • بخش مديريت زمينه (Context Management): • ايجاد زمينه‌ی مشترک برای سرويسهاي جزء يک سرويس مرکب: • محلي جهت نگهداري اطلاعات زمينه‌اي مشترک بين سرويس‌ها • نگهداری حالت سرويس مرکب (State) • اين بخش مورداستفاده‌ی بخش هماهنگ‌کننده است. • مدلي از زمينه(Context Model) در اين بخش ارايه خواهد شد.

39. جزء جايگزيني سرويس(Replacement Component) • «مدل قابليت جايگزيني» (Replaceability Model) شامل همه‌ي معيارها جهت انتخاب سرويس جايگزين‌شونده: • معيارهاي Functional: • معيارهاي نحوي (Syntactic): • ميزان و نحوه سازگاری نحوی بايد به‌دقت در مدل مذکور مشخص شود • برخي ناسازگاري‌هاي نحوي به وسيله‌ی ميانجي‌گري‌هايي مثل تبديل و يا اجتماع نوع‌هاي داده‌اي قابل‌حل هستند. • معيارهاي معنايي (Semantic): • سرويس جايگزين‌شونده بايد از لحاظ معنايي معادل سرويس ازکارافتاده بوده و قابليت انجام تمامي کارهاي آن را داشته باشد. • سرويس جايگزين‌شونده و سرويس ازکارافتاده بايد متعلق به حوزه‌های (Domain) و دسته (Category) يکسانی باشند. • انجام اين مقايسه‌ي معنايي به قابليت مدل‌کردنِ معنايي دو سرويس بستگي دارد. • قابليت مدل‌کردن و توصيف معنايي سرويس و حوزه و دسته و ... ←OWL-S • معيارهايNon-Functional: • خصوصياتی مثل QoS، زمان‌بندي، امنيت، قابليت‌اطمينان و... • قابليت مدل‌کردن اين خصوصيات در زبان مدل‌کردن سرويسها ضروری است ←OWL-S

40. جزء جايگزيني سرويس(Replacement Component) • موارد ديگري که براي جايگزيني سرويس ازکارافتاده با سرويس يا سرويس‌هاي مشابه درنظرگرفته شوند: • نياز به ليستي از سرويس‌هاي کانديد جهت جايگزينی: • نگهداری ليست سرويس‌های يافت‌شده در مرحله کشف سرويس ← نياز به نگهداري ليست سرويس‌هاي مشابهِ هر سرويس، از فاز کشف سرويس تا انتهاي اجراي سرويس مرکب ← گسترش زبان OWL-S (مشخصا بخش پروفايل)، و اضافه کردن يک ليست از سرويس‌هاي کانديد به ازاي هر سرويس • دسترس‌پذيري اين سرويس‌ها بايد بررسي شود. • در صورت عدم دسترسي به سرويس‌کانديد مناسب دوباره فاز کشف سرويس تکرار می‌شود. • بررسی قابليت‌جايگزينيباتوجه به معيارهاي مدل‌قابليت‌جايگزيني • درک مشترکي از محيط اجراي وب سرويس مرکب به شکل (زمينه يا context) درهنگام جايگزيني به سرويس جديد منتقل شود ← با استفاده از بخش مديريت زمينه (Context Management) در جزء اجراکننده سرويس مرکب • برخي اصلاحات و يا تغييرات برای سرويس جديد براي جايگزين شدن توسط يک واسط، قبل از جايگزيني انجام مي شود، مثلا تبدِل برخي پارامترها (مثل ورودي و خروجي سرويس) • ترکيبي از سرويس هاي دردسترس جهت جايگزينی با سرويس از کار افتاده ← اجرای مراحل ترکيب سرويس

41. جزء مديريت تراکنش ها(Transaction Management Component) • بررسي احتمال استفاده از رويکرد بدبينانه در محيطِ خاص وب سرويس ها • در صورت استفاده از رويکرد خوش بينانه بخش هاي زير بايد مدنظر قرارگيرند: • امکان تعريف و مشخص کردن تراکنش ها در تعريف سرويس هاي مرکب ← گسترش زبان OWL-S • مدل کردن انواع رفتارهاي تراکنشي در محيط وب سرويس ها • حداقل انواع رفتارهاي تراکنشي • فعاليت هاي ACID • فعاليت هاي طولاني مدت (LRAs): در مدل LRAs بايد حتماً به ازاي هر فعاليت يک سرويس خنثاکننده نيز در هماهنگ کننده ی سرويس مرکب ثبت شده باشد. • فعاليت هاي غيرحفاظت شده (Unprotected) • فرآيندهاي تجاري

42. مراجع • Kavantzas, N., Burdett, D., Ritzinger, G., “Web Services Choreography Description Language Version 1.0”, http://www.w3.org/TR/2004/WD-ws-cdl-10-20040427/, April 2004. • Arkin, A., Askary, S., Fordin, S., Jekeli, W., Kawaguchi, K., Orchard, D., Pogliani, S., Riemer, K., Susan Struble S., Takacsi-Nagy, P., Trickovic, I. and Zimek, S. “Web Service Choreography Interface (WSCI)”, 2002, 1.0, http://www.w3.org/TR/wsci/ • Bunting, D., Hurley, M.C.O., Little, M., Mischkinsky, J., Newcomer, E., Webber, J. and Swenson, K. (2003c), “Web Services Transaction Management (WS-TXM) Ver1.0”, • B. Medjahed, A. Bouguettaya. "A Dynamic Foundational Architecture for Semantic Web Services", Distributed and Parallel Databases (DAPD), 17(2), March 2005. • Bunting, D., Hurley, M.C.O., Little, M., Mischkinsky, J., Newcomer, E., Webber, J. and Swenson, K. (2003d), “Web Services Context (WS-Context) Ver1.0", • B. Medjahed, A. Bouguettaya, and A. Elmagarmid. “Composing Web Services on the Semantic Web”. The VLDB Journal, 12(4):333--351, November 2003. • Hrastnik, P. Winiwarter, W. “TWSO — Transactional Web Service Orchestrations”, International Conference on Next Generation Web Services Practices. NWeSP. Aug. 2005: 45- 50. • Wang, T. “Towards a transaction framework for contract-driven service-oriented business processes”. In A. Hanemann (Ed.), Proceedings of the IBM PhD Student Symposium at ICSOC 2005 (pp. 43-48). • Benjamin A. Schmit, SchahramDustdar, “Systematic Design of Web Service Transactions”. TES, 2005, pp:23-33. • Schmit, B.A. Dustdar, S, “Towards transactional Web services”, Seventh IEEE International Conference on E-Commerce Technology Workshops, 2005. , July 2005, 12- 20. • Orriens, B., Yang, J. and Papazoglou, M.P. (2003b) Jeusfeld, M.A. and Pastor, Ó. (Eds.): “A Framework for Business Rule Driven Web Service Composition”, ER 2003 Workshops, LNCS 2814, Springer-Verlag Berlin Heidelberg 2003, pp.52–64 • Orriens, B., Yang, J. and Papazoglou, M.P. (2003c) Benatallah, B. and Shan, M-C. (Eds.): “A Framework for Business Rule Driven Service Composition”, TES, LNCS 2819, Springer-Verlag Berlin Heidelberg, pp.14–27.

43. مراجع(ادامه) • Sun, H., Wang, X., Zhou, B. and Zou, P. “Research and Implementation of Dynamic Web Services Composition”, APPT 2003, LNCS 2834, Springer-Verlag Berlin Heidelberg, pp.457–466. • Su, S.Y.W., Meng, J., Krithivasan, R., Degwekar, S. and Helal, S. “Dynamic inter-enterprise workflow management in a constraint-based e-service infrastructure”, Electronic Commerce Research, Kluwer Academic Publishers, 2003, Vol. 3, pp.9–24.