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

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

Upload: saburo

Post on 10-Jan-2016

116 views

Category:

Documents


3 download

DESCRIPTION

ترکيب سرويسهاي در معماری سرویس گرا. رضا فیوضی علی کوثری استاد گرامی: جناب دکتر خیرخواه. رئوس مطالب. مقدمه ترکيب سرويس مرکب بررسي درخواست يك سرويس مركب از طرف کاربر كشف سرويس انتخاب توليد توصيف براي سرويس هاي مركب زبان هاي Choreography زبانهاي هم آهنگي BPEL4WS OWL-S Petri-net - PowerPoint PPT Presentation

TRANSCRIPT

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

1

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

رضا فیوضی

علی کوثری

استاد گرامی: جناب دکتر خیرخواه

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

2

رئوس مطالب

مقدمه1.

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

زبان هايChoreography زبانهاي هم آهنگي

•BPEL4WS•OWL-S•Petri-net

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

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

3

رئوس مطالب)ادامه(

ديدگاههاي مختلف در زمينه تركيب سرويسهاي 4.مبتني بروب

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

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

مراجع6.

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

4

مقدمه

پذير ی کاربردي دسترس يک برنامهسرويس: وبها هاي کاربردي و انسان است که ديگر برنامه

طور اتوماتيک آن را کشف، و از آن توانند به مي استفاده کنند.

:ترکيبي از چند سرويس ساده يا سرويس مرکب مرکب ديگر با هدف انجام يک کار مشترک

ها : سرويس ترکيب اتوماتيک وبها ترکيب سرويساجراي سرويس مرکب

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

5

ترکيب سرويس مرکببررسي درخواست يك سرويس مركب از طرف کاربر

كشف سرويسانتخاب

توليد توصيف براي سرويس هاي مركب

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

6

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

7

مراحل ترکيب سرويس مرکب

يك سرويس مركب از طرف کاربر: بررسي درخواستدريافت يك توصيف سطح باال از سرويس مركب موردنياز ها كاربر توسط موتور ترکيب و شکستن آن به زيردرخواست

:هاي مناسب جهت پيداكردن سرويسكشف سرويسشده هاي مشخص اجراي زيردرخواست

ثبت توصيف معنايی سرويسها درrepositoryی توصيف معنايي آن کشف سرويس موردنياز با ارائهازای هر درخواست شده به توليد ليستی از سرويسهای کشف

:هاي ترين سرويس از ليست سرويس انتخاب مناسبانتخابشده در فاز قبل با توجه به معيارهاي: كشف

FunctionalNon-functional ،كارايي، قابليت اطمينان، امنيت، قابليت گسترش :

QoSهاي كاربر نيازمندي( قابليت تركيب سرويسهاComposability تشکيل :) مدل قابليت

تركيب

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

8

مراحل ترکيب سرويس مرکب )ادامه(

هاي مركب توليد توصيف براي سرويس: شامل

كننده در تركيب هاي شركت ليست سرويسها ترتيب آنها روش[ ارتباط آنها هاي رد و بدل شونده بين آن پيغامزبان توصيفی يک به وسيله:

هاي زبانChoreography:ها، مدلي از رفتار خارجي سرويسشوند هايي كه بين اجزا ردوبدل مي در قالب پيغام

هاي هم زبان ( آهنگيOrchestration:) ارتباطات كلي بيني سرويس مركب و چگونگي استفاده ها در يك وب سرويس وبهاي كمكي سرويس مركب از سرويس وب

زماني تبادالت و مديريت و هم (:Coordinatorهماهنگ کننده )•چنين كنترل ارتباطات بين اجزا هم

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

9

Choreographyهاي زبان

مفهومChoreography ،به ارتباطات دوطرفه اي كه بين دو سرويس مختلف از طريق پيغام، وجود دارد.

WS-CDL (Web Service Choreography Description Language) [1]:جديدترين زباني است كهW3C جهت توصيف رفتارهاي مشترك و غيرمشترك

سرويس ها از يك ديد كامال كلي طراحي كرده است بر مبنايXML اليه ايمدلي غير

WSCI (Web Service Choreography Interface) [2]:بر مبنايXML براي توصيف پيغام هاي ورودي و خروجي سرويس هاهيچ پشتيباني براي معنا نداشته است.اليه ايمدلي غير

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

10

آهنگي هاي هم زبان(Orchestration)

BPEL4WS: بر پايه زبان هايWSFL متعلق به( IBM و )XLANG متعلق(

( بناشده است و ترکيبي از امكانات اين دو زبان را در Microsoftبهخود دارد.

مبتني بر XML ( تعريف سرويس ها را به شكل فرآيند محورwork flow based) وجود تعداد زيادي سرور براي اجراي سرويس هاي مركب

BPEL4WS براي بسترهاي J2EE. و Net

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

11

)ادامه (Choreographyهاي زبان

Petri-net : اختصاص دادن يكPetri-net یند به هر] فرآ در هرزمان سرويس در يكي از حاالتnot instantiated، ready،

running، suspended و يا ،completed.قراردارد

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

12

آهنگي هاي هم زبان(Orchestration)

OWL-S: با استفاده از ←تعريف معنایی سرويس ها و به شكلي قابل فهم براي ماشين

Ontology: كشف اتوماتيك سرويس، صدا کردن سرويس ها، تركيب، ارتباط بين آنها وكنترل

اجراي آنها بخش هایOWL-S:

.1Profile: ،معرفي سرو[س: اين اطالعات در مراحل كشف سرويس توسط ديگر سرويس ها

كاربران يا عامل ها و.. به كارمي رود. (:Process Modelمدل فرآيند )2.

اطالعات دقيق تري راجع به عمليات سرويسطريقه ي استفاده ي سرويسبيان جزئيات معنايي درخواست هاشرايطي كه تحت آنها خروجي هاي خاص توليد مي شوند نحوه درخواست براي يك سرويس، ورودي ها، خروجي ها، پيش شرط ها و اثرات

سرويس.3Grounding:

جزئيات چگونگي[ ارتباط با يك سرويس از طريق پيغام ها پروتكل ارتباطي، فرمت پيغام ها و ديگر جزئيات مربوط به سرويس مثل شماره

پورت هايي كه سرويس روي آنها قابل دسترسي است

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

13

آهنگي هاي هم زبان(Orchestration)

OWL-S

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

14

آهنگي هاي هم مقايسه زبان(Orchestration)

زبان انتخاب شده جهت توصيف سرويسمرکب در ارائه

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

15

اجراي سرويس مرکبموتور اجرا

بخش مديريت تراکنش

بخش جايگزيني سرويس

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

16

اجراي سرويس مرکب

سرويس ‌ سرويس هاي شركت كننده در وبفراخوانیمركب به ترتيبي كه درنهايت يك وظيفه مندي موردنظر را

به انجام برسانند.

سرويس مركب ‌ورودی: توصيف وب :وظيفه

سرويس مركب‌آغاز اجراي وب فراخوانی سرويس هاي شركت كننده در سرويس مركب به ترتيبي

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

جايگزيني سرويس هامديريت تراكنش

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

17

اجزاي اصلي يک چهارچوب اجرا کننده ي سرويس مرکب

موتور اجرا( Execution Engine)( بخش جايگزيني سرويسReplacement

Component)( بخش مديريت تراکنشTransaction

Management Component)

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

18

(Execution Engine )موتور اجرا

مركب‌سرويس‌نظارت بر اجراي وب ( Monitoring) برخورد مناسب با خطاهاي به وجودآمده در زمان

اجراي سرويس مركب: :مثل مشكالت مربوط به سرويسcrash کردن سرور

( Exceptionسرويس يا خطاي زمان اجراي سرويس )مشكالت مربوط به شبكه:مشكالت مربوط به تركيب

ناشی از طراحي بد[ تركيب مثل رسيدن به يك بن بست ارتباطي در تركيب

( خطاي زمان اجراي مربوط به جريان كار تركيبComposition Workflow)

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

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

19

بخش جايگزيني سرويس(Replacement Component)

:در زمان اجرا با سرويس‌ جايگزيني سرويسوظيفه ‌ شكل مركب بتواند ‌معادل[ ديگری كه به تنهايي و يا به

شده را انجام دهند.‌وظايف سرويس تعويضشونده:‌سرويس جايگزين

سرويسی که با خطا مواجه شدهسرويسی که كند شدهداده است ‌سرويسی که كارايي خود را ازدست هنگامي كه تعريف بخشي از سرويس مركب در زمان اجرا

تغييرکند

هاي مشابه سرويس جايگزين ‌ايده: انتخاب يك سرويس با قابليتشده در فاز كشف ‌های کشف‌شونده، از ليست سرويس

ها‌سرويس

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

20

بخش مديريت تراکنش(Transaction Management Component)

تراکنشتراکنشتعريف کالسيک( ‌ هايACID تغيير :)حالتي که چهار ويژگي[ زير را دارد:

Atomicity »يا همه يا هيچ کدام« :( سازگاريConsistency صحت در تغيير حالت :)Isolationزمان باهم ‌هايي است که هم‌: عدم تأثير متقابل تراکنش

شوند‌اجرا مي( ماندگاريDurability عدم امکان لغوکردن تراکنشي که :)

يافته است نيز معروفند. ‌پايان

ها:‌دو رويکرد متفاوت در قبال مديريت تراکنش:کردن منابع در دسترس تراکنش‌ قفلرويکرد بدبينانهبينانه‌رويکرد خوش :

ها، امکان بروز ناسازگاري بسيار پايين است ‌مبنا: در برخي محيط← صرفه نيست‌هايي به‌کردن منابع در چنين محيط‌ي قفل‌هزينه

کردن منابع، تغييرات تراکنش را در محلي مياني ‌رويکرد: به جاي قفلکنيم. ‌نگهداري کرده و در پايان تراکنش تغييرات را يکباره ماندگار مي

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

21

بخش مديريت تراکنش )ادامه((Transaction Management Component)

ويژگي هاي محيط وب سرويس ها:(اتصال و پيوستگي بسيار کمloosely coupled)قابليت اطمينان پايينبرخورداری از درجه ي بااليي از خودمختاري مدت اجرای طوالنی: با توجه به ماهيت سناريوها در اين محيط، معموال تراکنش ها مدت

زيادي به طول مي انجامند )مثاال تراکتشی شامل خريد، پرداخت و تحويل کاال که در مجموع چندين روز به طول مي انجامد(.

تعلق منابع درگير در يک تراکنش به حوزه هاي متفاوت

تراکنش هايACID مي آيند. سخت گيرانه برای اين محيط به نظر اجبارکردن چهار ويژگي تراکنش هايACID .نتايج نامطلوبي به دنبال خواهدداشت

براي برآوردن نياز تراکنش ها در چنين محيطي تراکنش هايي با سخت گيري کمتر و Long Running»تراکنش هاي طوالني مدت« يا ضعيف تر مطرح شده است.

Transactions »ويژگي »تراکنش هاي طوالني مدتIsolation در تراکنش ها را پياده سازي

نمي کنند

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

22

بخش مديريت تراکنش )ادامه(( Transaction Management Component)

ايده‌( »ي »خنثاکردنCompensation) تراکنشT ↔ي ‌ خنثاکنندهC

خنثاکننده يC سرويسي مستقل است که بعد از اتمام تراکنش و خارجاز قلمرو آن اجرا مي شود

C بعد از اتمام Tشود‌ انجام میTکند و نه تغييرات موقتي در سيستم ‌ نه منابع مورد نيازش را قفل مي

کند‌ايجاد مي تغييرات همگي واقعي بوده و بالفاصله درسيستم قابل مشاهده

هستند. درحالتي که به هردليل خارجي، تراکنش سطح باالتر با مشکلي مواجه

اجرا Tکردن آثار ‌کردن و برطرف‌ براي جبرانCشود، سرويس شود‌می

ميزان موفقيتC در ازبين بردن تمامي آثار تراکنش T بستگي به زمينه دارد

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

23

بخش مديريت تراکنش )ادامه((Transaction Management Component)

ها‌هاي ارائه شده براي پشتيباني مديريت تراکنش‌چهارچوب .1Web 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تراکنش هاي قديمي[ •( LRAs يا Long Running Actionsتراکنش هاي طوالني مدت )•تراکنش هاي فرآيندتجاري: يک يا چند تراکنش از دو نوع ديگر را شامل •

مي شوند.به مسئله ي تعريف و مشخص کردن تراکنش ها و سرويس هاي مرکب •

نپرداخته است.

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

24

بخش مديريت تراکنش )ادامه( (Transaction Management Component)

.2WS-Transaction : مشابهWS-TXM توسط شرکت هاي BEA, IBM و

Microsoft.ارايه شده است .که به رفتار تراکنش ها پرداخته استدو نوع رفتار براي تراکنش ها درنظرگرفته است

( تراکنش هاي اتميکAtomic Transactions)( فعاليت هاي تجاريBusiness Activities)

اين چهارچوب بر روي چهارچوب ديگري که توسطهمين گروه ارايه شده است بنا شده که به پشتيباني

(WS-Coordinationارتباط تراکنش ها مي پردازد )BPEL4WS را به عنوان زبان[ تعريف سرويس مرکب

پشتيباني مي کند.

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

25

بخش مديريت تراکنش( Transaction Management Component)

WebTransact : معماري چند اليهيک مدل تراکنشيWeb Service Transaction Language :

مبتنی برXML گسترشی بر زبانWSDLتعريف سرويس های مرکبها در سطوح مختلف‌امکان تعريف و توصيف تراکنش

تمرکز بر رفع مشکل انواع مختلف ناهمگونی موجود درها )نحوی، ساختاری و محتوايی(‌سرويس‌فضای وب

( ايده ي سرويس ميانجيMediator Service سرويسي که با :)مجردکردن مفاهيم سرويس ها، به عنوان واسطي بين

هماهنگ کننده ي سرويس ها و سرويس هاي اصلي قرارمي گيرد

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

26

بخش مديريت تراکنش( Transaction Management

Component)

چهارچوب هاي ديگربا اهميت و حوزه ي پوششضعيف تر:

Transactional Web Service Orchestration (TWSO) [7] Business Transaction Framework (BTF)[8]

کردن ‌هايي که صرفا به تعريف و مشخص‌پژوهشاند:‌رفتار تراکنشی پرداخته

استفاده از زبانUMLکردن رفتار ‌ جهت تعريف و مشخصتراکنشی و نگاشت به استانداردهاي ديگري مثل

BPEL4WS:[ 10و 9 کار آقاي شهرام دوستدار و همکارانش .]کارOrriens] 12و 11 و همکارانش.[

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

27

ديدگاههاي مختلف در زمينه تركيب سرويسهاي مبتني بروب

تركيب وب سرويس ها به شكل ايستا و پوياتركيب سرويس ها به شكل اتوماتيك يا دستي

تركيب سرويس ها بر اساس توصيف و يا مدل هاتركيب سرويس ها با استفاده از برنامه ريزي هوش مصنوعي

همزماني اجرا و تركيب وب سرويس ها

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

28

تركيب وب سرويس ها به شكل ايستا و پويا

در طول زمان[ طراحي، اجزاي تركيب انتخاب تركيب ايستاشوند شده به يكديگر لينك مي

مناسب برای محيط های بدون تغيير ماژول هاي تشكيل دهنده ی پلتفرم اجرای سرويسهای

: ]StarWSCop ]13مرکبسيستم هوشمند براي تجزيه ي نيازهاي كاربرانباري از وب سرويس هاي ثبت شدهموتور كشف سرويسموتور تركيب.مانيتوركننده جهت ثبت وقايع و مطلع ساختن موتور تركيب

سيستمe-flow تعريف، اجرا و مانيتوركردنe-serviceهاي مركبكشف پوياي سرويسهاي تراكنشACIDي يك گراف كه ترتيب اجراي نمايش يك سرويس مركب به وسيله

نودها را در پروسه نشان ميدهد

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

29

تركيب سرويس ها به شكل اتوماتيك يا دستي

:هاي انتخاب سرويستركيب دستیاز بين كاربر كننده در ترکیب توسط شركت

هاي موجود سرويس [:14بر آنتولوژی ] يا مبتنیترکيب اتوماتيک

:چهار ماژول اصلیspecification, matchmaking, selection, generation

»ارايه ی يك »مدل قابليت تركيب معرفی زبان سطح باالیCSSL در ماژول

selectionWSDL = معنا + CSSL

استفاده از محدوديتهایQoS در ماژول selection

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

30

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

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

31

تركيب سرويس ها بر اساس توصيف و يا مدل ها

مدل ترکيب با استفاده از(Orriens:)ها سرويس بر اساس ترکيب پويای وببر مدل مبتنیUML:با استفاده از دو مفهوم

هاي تركيب سرويس المان قوانين تركيب سرويس

توصيف ترکيب با استفاده از(enTish:)هاي كاربر به شكل صوري بيان درخواستهاي موجود توصيف صوري سرويسها درزمان اجرا تركيب سرويس

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

32

تركيب سرويس ها با استفاده از برنامه ريزي هوش مصنوعي

:پنج تايي مسئله ي برنامه ريزي (S, S0, G, A, Г در .)محيط وب سرويس ها:

SO و G حالت هاي اوليه و نهايي[ تعريف شده در نيازمندي هاي درخواست دهنده

Aمجموعه ي سرويس هاي موجود Гنشان دهنده تابع تغيير حالت هر سرويس

DAML-S � ( تنها زبان وب سرويسي OWL-S )و متعاقبااست كه امكان برقراري ارتباط مستقيم با

برنامه ريزي هوش مصنوعي را داراست.

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

33

SHOP2

مبتني برDAML-S ريزي سيستم برنامهHTN (Hierarchical Task Network)كند مي يك وظيفه را به وظايف بسيار كوچك تجزيهي وظايف در مفهوم تجزيهHTNي بسيار مشابه مفهوم تجزيهProcess در

DAML-Sبرنامه ] ريزي كانديد بسيار خوبي براي استفاده است اين سيستمدر تركيب اتوماتيك وب سرويس ها به شمار مي رود.

پايگاه دانشSHOP2:شامل ( عملگرهاoperators توصيفي از آنچه براي انجام يك زيروظيفه مورد نياز :)

است متد: شيوه ي تجزيه ي يك وظيفه ي مركب به زير وظيفه ها يك مسئله ي برنامه ريزي درSHOP2( يك سه تائي S, T, D است که به )

را P(=p1p2…….pn داده شده و يك برنامه )SHOP2عنوان وروردي به عملگرهايي هستند كه درمجموع باعث رسيدن از pn…,p2,p1برمي گرداند.

Sبه Tدر D.مي شوند

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

34

همزماني اجرا و تركيب وب سرويس ها

هاي مركب به شكل سرويس مشکل تركيب و اجراي وبهاي پويا با تغييرات زياد زمان اجرا : محيطدرپي پي

ها سرويس زماني اجرا و تركيب در وب راه حل: همافزاري و تقسيم برنامه به هاي نرم ايده: استفاده از عامل

ريزي هر بخش، بخش مذكور از برنامه تر. پس هاي كوچك بخششود. ريزي می اجرا شده و بخش بعدی برنامه

:دو نوع عاملي سرويس مركب کاربر: در نقش كاربر درخواست كنندهها كنندگان سرويس کننده: در نقش تامين تامين

کننده در ترکيب توسط معيار[های انتخاب سرويس شرکتكاربر: عامل

ي اجرا هزينهكننده هاي تامين محل قرارگيري عامل

:عامل كمكي عامل سوم

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

35

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

36

ادامه ی کارها جزء هماهنگ کننده اجراي وب سرويس

جزء جايگزيني سرويس جزء مديريت تراکنش ها

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

37

ادامه کار

چهارچوبي جهت اجراي در اين ارائهشود ارايه ميهاي مرکب سرويس

ورودی: توصيف يک سرويس مرکب با زبان OWL-Sالبته نسخه( يافته از اي گسترشOWL-S.)

هاي مختلف چهارچوب پيشنهادی: جنبهها ) جزء هماهنگ کننده اجراي وب سرويسCoordinator

Component)( جزء جايگزيني سرويسReplacement Component)( جزء مديريت تراکنش هاTransaction Management

Component)

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

38

جزء هماهنگ کننده اجراي ها وب سرويس

(Coordinator Component)

جزء اجراکننده سرويس مرکب شامل بخشهای زيرمی باشد:

( بخش هماهنگ کننده بين سرويسهاCoordinator Component):

ايجاد ارتباط بين سرويس هاي بدوی سرويس مرکب انتقال اطالعات بين سرويس هابرقراري ارتباط با ساير اجزاء چهارچوب

( بخش مديريت زمينهContext Management)::ايجاد زمينه ی مشترک برای سرويسهاي جزء يک سرويس مرکب

محلي جهت نگهداري اطالعات زمينه اي مشترک بين سرويس ها•(Stateنگهداری حالت سرويس مرکب )•

.اين بخش مورداستفاده ی بخش هماهنگ کننده است مدلي از زمينه (Context Model).در اين بخش ارايه خواهد شد

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

39

جزء جايگزيني سرويس(Replacement Component)

( »مدل قابليت جايگزيني«Replaceability Model) شامل شونده: ي معيارها جهت انتخاب سرويس جايگزين همه

معيارهايFunctional:( معيارهاي نحويSyntactic) :

دقت در مدل مذکور مشخص شود ميزان و نحوه سازگاری نحوی بايد به•هايي مثل تبديل و يا گري ميانجيی هاي نحوي به وسيله برخي ناسازگاري•

حل هستند. قابلاي هاي داده اجتماع نوع( معيارهاي معناييSemantic):

شونده بايد از لحاظ معنايي معادل سرويس ازکارافتاده بوده سرويس جايگزين•و قابليت انجام تمامي کارهاي آن را داشته باشد.

های شونده و سرويس ازکارافتاده بايد متعلق به حوزه سرويس جايگزين•(Domain( و دسته )Category.يکسانی باشند )

کردن[ معنايي دو سرويس بستگي ي معنايي به قابليت مدل انجام اين مقايسه•دارد.

OWL-S ←کردن و توصيف معنايي سرويس و حوزه و دسته و ... قابليت مدل•

معيارهايNon-Functional: خصوصياتی مثلQoSاطمينان و... بندي، امنيت، قابليت ، زمانکردن سرويسها ضروری کردن اين خصوصيات در زبان مدل قابليت مدل

OWL-S ←است

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

40

جزء جايگزيني سرويس(Replacement Component)

موارد ديگري که براي جايگزيني سرويس ازکارافتاده با سرويس يا هاي مشابه درنظرگرفته شوند: سرويس

هاي کانديد جهت جايگزينی: نياز به ليستي از سرويسنياز به ←شده در مرحله کشف سرويس های يافت نگهداری ليست سرويس

هاي مشابه[ هر سرويس، از فاز کشف سرويس تا نگهداري ليست سرويس )مشخصا بخش OWL-S گسترش زبان ←انتهاي اجراي سرويس مرکب

هاي کانديد به ازاي هر پروفايل(، و اضافه کردن يک ليست از سرويسسرويس

.دسترس پذيري اين سرويس ها بايد بررسي شود در صورت عدم دسترسي به سرويس کانديد مناسب دوباره فاز کشف

سرويس تکرار می شود.جايگزيني قابليت باتوجه به معيارهاي مدلجايگزيني بررسی قابليت درک مشترکي از محيط اجراي وب سرويس مرکب به شکل )زمينه يا

context با استفاده از ←( درهنگام جايگزيني به سرويس جديد منتقل شود ( در جزء اجراکننده سرويس Context Managementبخش مديريت زمينه )

مرکب برخي اصالحات و يا تغييرات برای سرويس جديد براي جايگزين شدن

توسط يک واسط، قبل از جايگزيني انجام مي شود، مثال تبد[ل برخي پارامترها )مثل ورودي و خروجي سرويس(

ترکيبي از سرويس هاي دردسترس جهت جايگزينی با سرويس از کار اجرای مراحل ترکيب سرويس←افتاده

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

41

جزء مديريت تراکنش ها(Transaction Management Component)

در محيط[ خاص بدبينانه بررسي احتمال استفاده از رويکردوب سرويس ها

در صورت استفاده از رويکرد خوش بينانه بخش هاي زير بايد:مدنظر قرارگيرند

امکان تعريف و مشخص کردن تراکنش ها در تعريف سرويس هايOWL-S گسترش زبان ←مرکب

مدل کردن انواع رفتارهاي تراکنشي در محيط وب سرويسها حداقل انواع رفتارهاي تراکنشي

فعاليت هايACID( فعاليت هاي طوالني مدتLRAs در مدل :)LRAs به ازاي هر � بايد حتما

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

( فعاليت هاي غيرحفاظت شدهUnprotected)فرآيندهاي تجاري

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

42

مراجع1. 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.2. 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/

3. 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”,

4. B. Medjahed, A. Bouguettaya. "A Dynamic Foundational Architecture for Semantic Web Services", Distributed and Parallel Databases (DAPD), 17(2), March 2005.

5. 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",

6. B. Medjahed, A. Bouguettaya, and A. Elmagarmid. “Composing Web Services on the Semantic Web”. The VLDB Journal, 12(4):333--351, November 2003.

7. Hrastnik, P. Winiwarter, W. “TWSO — Transactional Web Service Orchestrations”, International Conference on Next Generation Web Services Practices. NWeSP. Aug. 2005: 45- 50.

8. 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).

9. Benjamin A. Schmit, Schahram Dustdar, “Systematic Design of Web Service Transactions”. TES, 2005, pp:23-33.

10. Schmit, B.A. Dustdar, S, “Towards transactional Web services”, Seventh IEEE International Conference on E-Commerce Technology Workshops, 2005. , July 2005, 12- 20.

11. 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

12. 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.

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

43

مراجع)ادامه(

13. 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.

14. 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.