به نام خدا

1. به نام خدا مروری بر معماری سرویس گرا (SOA) سیستم جامع دریایی ارائه دهنده : شهرداد عزت دوست E-mail : Sh.Ezzatdoust@GmAil.com

2. فهرست مطالب تاریخچه SOA ضرورتهای مطرح شدن SOA تعریف SOA تکنیکهای اصلی بکار رفته در SOA برداشتهای اشتباه از SOA ویژگیهای SOA مزایای SOA عناصر تشکیل دهنده SOA متد توصیف برنامه های كاربردی و سرویس

3. تاریخچه SOA عبارت SOA در سال 1996 توسط آنالیست شرکت گارتنر بنام Yefim V. Natis در یک مقاله تحقیقی سکه خورد. عین عبارت نامبرده به این صورت بود: “SOA is a software architecture that starts with an interface definitionand builds the entire application topology as a topology of interfaces, interface implementations and interface calls… • …SOA would be better-named ‘interface-orientedarchitecture.’” تفکر SOA تفکری است که مبدع خاصی ندارد و نیازش از مدتها قبل کاملاً مشهود بوده است و مفاهیم کلی آن در مقالات مختلف مورد بحث قرار کرفته بود. SOA نیز مانند OO مسیر برنامه نویسی تا تفکر را پیموده است.

4. ضرورتهای مطرح شدن SOA • پیچیدگی معماری در توسعه سیستمهای مرتبط با هم در سازمانهای بزرگ و سیستمهای جامع • نیاز سازمانهای بزرگ به تغییر در فرآیندها و قواعد تجاری و نیاز IT به انطباق مناسب با این تغییرات • نیاز سازمانهای بزرگ به توسعه سیستمهای Reusable و کاهش هزینه های نگهداری سیستمها • توسعه تعاملات بین سازمانی و نیاز IT به همراهی در این راستا

5. تعریف معماری سرویس گرا سرویس گرایی راهی است برای ساختن سیستمهای توزیع شده - در انتزاعی ترین حالتش ، سرویس گرایی همه چیز را به عنوان ارائه كننده سرویس می بیند – از برنامه های كاربردیmainframe تا یک چاپگر. ارائه كنندگان سرویس قابلیت های خودرا از طریق رابطها به نمایش می گذارند. معماری سرویس گرا این قابلیتها را با رابطها منطبق می كند تا این قابلیتها در فرآیندهاهماهنگ شوند. فرآیند جدید تشكیل شده خود نیزیك سرویس است كه مجموعه ای از قابلیتهای جدید را به نمایش میگذارد. اصل مهم مدل سرویس، جداسازی بین رابط ها و پیاده سازی است. فراخوان این سرویس فقط و فقط نیاز دارد كهرابطها را درك كند ، بدون اینكه كار سرویس گیرنده مختل شود. پیاده سازی میتواند درطی زمان كامل شود.جالب است بدانیم كه همان رابطها میتوانند بوسیله چندین پیاده سازی ارائه شود.

6. SOA درعمل سرویس هویت شناسی و اعتبار سنجی سرویسارتباطبامشتریها خرید E-commerce portal سرویسفروش سرویسپرداختنی سرویسرضایتمندیمشتری

7. Bus Service Service Service Service Service Service حل مشکل ارتباط بین زیر سیستمها با استفاده از ESB

8. تكنیكهای اصلی بكار رفته در SOA • Component-based Development • Object Orientation • Business Process Engineering

9. برداشتهای اشتباه، ایده آل و واقعی از SOA • اشتباه: SOA متناظر با web services است و SOAمعادل سرویسهای توزیع شده است. • ایده آل: SOA تقسیم بندی بسیار مناسبی ازسرویسهای تجاری بدست میدهد و آنها را به شکلی سازگار بازنمایی می کند. • واقعیت : SOA تغییری زیربنایی در روش انجام حرفه است.

10. ویژگیهای SOA • Loosely coupled: ارتباطات بین سرویسها را به حداقل میرساند. • Contractual: التزام به توافقی که در توصیف سرویسها آمده است. • Autonomous: کنترل منطق تجاری که در بطن سرویس پوشانده شده است. • Abstract: منطق تجاری را از مصرف کنندگان سرویس مخفی می کند.

11. ویژگیهایSOA (ادامه) • مولفه های نرم افزار در SOA ، سرویسهایی هستند که بر اساس قراردادهای استاندارد بنا شده اند. • زیر ساختار ارتباطی که در SOA استفاده میشود باید بصورتی طراحی شود که از لایه پروتکل زیرین مستقل باشد. • سرویسهای تجاری دانه درشت را ارائه میدهد ، در صورتی که فراخوانی توابع در نرم افزار ها دانه ریز هستند. • SOA بیشتر برای پروژه های Enterprise و بزرگ قابل کاربرد است. • پیاده سازی یک راه حل SOA ابتدای یک مسیر پر فراز و نشیب است و باید در سازمان فرهنگ سازی و روش های نگهداری و ارتقاء به درستی دیده شود. • Distribution یکی از ارمغان های اصلی SOA در معماری سیستم های نرم افزاری است.

12. مزایای SOA • چابکی و انعطاف پذیری سازمان را در برابر تغییرات به ارمغان می آورد. • وابستگی به تکنولوژی را کم می کند. • وابستگی به نحوه استقرار (متمرکز/غیر متمرکز) ندارد. • یکپارچه سازی سازمان را آسان می سازد. • امکان آنالیز فرایندها و بهینه سازی فرایندها را میسر می سازد. • مشکلات موجود در انطباق IT و Business در سازمانها را تقلیل می دهد. • هزینه های نگهداری سیستم ها را کاهش می دهد.

13. عناصر SOA • Service • Message • Interface • Contract • Policy • Conversation • State • Transactions • Process

14. سرویس Message Service Logic State Policy

15. سرویسها • واحد های نرم افزاری که قادرند در پیاده سازی منطق ، با یکدیگر از طریق رد و بدل نمودن پیغامها ارتباط برقرار کنند. • یک سرویس همانند مولفه و یا شئی است. • هر سرویس داده مربوط به خود را مدیریت میکنند.

16. پیامها • واحد های اطلاعاتی که از یک سرویس به سرویس بعدی منتقل میشوند. • باید بسیار ساختاریافته باشند. - با استفاده از اسکیما این ساختار بین برنامه نویسان و سرویسها رد و بدل میشوند. • باید شامل تمامی اطلاعات مورد نیاز برای فهم یک پیام باشد. • اجازه ارتباط بین تکنولوژی های مختلف را فراهم سازد.

17. Service زیرساخت پردازش پیامها Log Sign Message processing infrastructure Serialize Monitoring Service Reliable messaging Encrypt Authorize Eventing Audit Message processing infrastructure Deserialize Routing Authenticate

18. Service Interface Service interface Service Service Business Document Business document رابطهایسرویس

19. Service قرارداد Service interface Process Service DocumentA DocumentC-1 DocumentC-2 Contract Service interface Contract EitherC-1 or C-2 Service interface Process DocumentB Service interface

20. قرارداد • یک قرار داد تعریف کننده کامل یک داد و ستد است. • یک قرار داد یک آداب تجاری است. • کلیه پیامها و غالب آنها را تعریف مینماید. • کلیه ترتیب های ممکن پیامها را تعریف مینماید. • تمامی پروتوکلها و روش هویت شناسی را تعریف میکند.

21. مشکلاتسرویسهایچندگانه مالی مدیریت سفارشات تولید CRM انبار

22. سرویسفرآیندی سرویس فرآیندی سرویسهایفرآیندی سرویس تجاری سرویس تجاری سرویس تجاری سرویس تجاری

23. مزایایسرویسهایفرآیندی • هزینه تغییرات فرآیندی را کاهش می دهد. • میزان وابستگی را کم می کند. • توزیع وظایف را ساده می سازد. • با استفاده از تراکنشهای طولانی مدت ، رفع استثنائات را ساده تر میسازد

24. Process Service فرآیندهایتجاری Business Service Business Service Process Service فرآیندهای تجاری مولفه های تجاری مولفه های تجاری Business Service Business Service مولفه های تجاری مولفه های تجاری سرویسهایتجاری

25. Service Service façade Processservice Business entity layer Data representation layer Data accessors Business entities Data accessors Business entities نمونهایازلایهبندیسرویسهایتجاری

26. متد توصیف برنامه های كاربردی و سرویس

28. متد توصیف برنامه های كاربردی و سرویس گام 1: چشم انداز اولیه و دورنمای دامنه گام 2: فرآیند های تجاری و سناریو ها گام 3: تحلیل كار كردی ، موارد كاربری و تجزیه كاركردی گام 4: تحلیل داده ای ، مدل سازی داده ها و داده های موضوعی گام 5: تحلیل وابستگی گام 6 : تعریف مولفه های تجاری گام 7: تعریف سرویسها گام 8: مولفه های رابط سرویس و مولفه های فرآیندهای تجاری گام 9: تعریف برنامه های كاربردی و چشم انداز به توافق رسیده

29. گام 1: چشم انداز اولیه و دورنمای دامنه در فاز چشم انداز سئوالات زیادی پرسیده خواهد شد - چه چیزی را میخواهیم بدست بیاوریم؟ - اهداف و مقاصد سازمان چیست؟ - چه مشكلات تجاری را مورد خطاب قرار می دهیم؟ - چه نیاز مندی های مدونی موجود است؟ - كرانه و وسعت تجاری به معنی فرایند تجاری و ساختار تشكیلاتی چیست؟ - چه چیزی در محدوده وجود دارد و چه چیزی خارج از آن است؟

30. گام 2: فرایند های تجاری و سناریو ها • آیا می توانیم چشم انداز اولیه را به صورت تعدادی سناریوبیان كرده و آنها را به فرآیند های جاری و آینده مرتبط سازیم؟ • این سناریو ها را مستند سازی می كنیم. • شروع تعریف فرایند تجاری كه منجر به فهم روالهای كاری و كاربردی و داده ای مورد نیاز می شود.

31. گام 3: تحلیل كار كردی ، موارد كاربری و تجزیه كاركردی • با استفاده از موارد كاربردی ، ‌وظایف مورد نیاز را تجزیه و تحلیل میکنیم. بزودی متوجه می شویم كه تعداد زیادی از كارها و عملیات تكراری هستند چون در تعدادی از موارد كاربری دوباره مورد استفاده قرار گرفته اند. • برای شناسایی عملیات مشابه و نواحی تجاری مورد خطاب ، آنها را بوسیله گروه بندی و خلاصه سازی در یك سلسله مراتب یا دریك تجزیه وظیفه ای مرتب میکنیم. • اكنون وظیفه های تجزیه شده را تركیب میکنیم. هر فعالیت در فرآیند تجاری باید به عنوان یك اتفاق واحد در تجزیه وظیفه ای موجود باشد.

32. فرایندهایتجاریوكاركردتجاری • یك كاركرد تجاری کاری است كه یك سازمان انجام می دهد...... • یك فرایند تجاری راهی است برای انجام آن. • كار كرد تجاری یك ساختار سلسله مراتبی را تشكیل می دهد. • فرایند تجاری ایجاد یك ساختار شبكه ای می نماید

33. سه فرآیند تجاری Process 1 Process 2 Process 3 Process Steps

34. All Processes Process 1 Process 2 Process 3 A X Y E M C N B Process Steps (Elementary Processes) ساختارشبکهپردازشی D

35. فرآیند حرفه به ساختار سلسله مراتبی توابع Process 1 Process 2 Process 3 Process Steps (Primitive Functions)

36. تجزیهکارکرد Manage & Operate Healthcare Systems Maintain Professional Manage Patient Manage Maintain Care Access GP & Manage Access Patient Consents Care Records Pathways Hospital Systems Register Patient Logon Define General Consents Maintain Care Pathways View Patient Health Records Access System Index Maintain Professional Register (Authentication) Manage Own Consents Apply Clinical Override Access Event Detail Patient Logoff Review Clinical Overrides Manage Care Relationships Maintain Clinical Processes Maintain Specific Permissions Professional Logon Generate Patient Events (Authentication) Manage Own Patient Events Professional Logoff View Own Medical History Maintain Health Manage Maintain Professional Manage Patient Manage Manage Organizational Permissions Information Patient Journeys Appointments Classifications Structure Maintain Health Subject Book Appointment Maintain Role Definitions Apply Patient Search View Patient Journey Define General Permissions Change Appointment Manage Own Patient’s Details View Own Patient Journey Capture Clinical Codes Maintain Group/Team Structure View Own Prof Permissions Define Role-based Access Manage Referrals View Own Personalized Area Model Clinical Codes Maintain Group/Team Membership Construct Patient Journey Perform Clinical Code Maintain Permission Delegations View Own GP’s Details Manage Own General Health data Translation Manage Donor Details Manage Patient Details (by Prof) Manage Family Members View Immunizations/Vaccinations Manage Personal Preferences View Personalized Area (by Prof)

37. گام 4: تحلیل داده ای ، مدل سازی داده ها و داده های موضوعی • این گام به موازات تحلیل كاربردی پیش می رود و چند چك نیز صورت می گیرد. هدف توسعه مدل داده ها است كه با دقت و عمق قابل قبولی كه ردیفی از نیاز های وظیفه ای را در بر گیرد، صورت بپذیرد. • بخصوص باید مطمن شویم كه تمامی موارد كاربردی موجودیت داده های صحیح دارند و تمامی داده های به طور درستی وارد و بروز نگه داشته شده اند. • مدل داده ای با تمامی موجودیت های تعریف شده در سطح منطقی بیان میشوند و كلیدهای اصلی تعین شده و تمامی روابط چند به چند نیز معین میشوند. • روال نرمال كردن داده ها به طور ضمنی در نظر گرفته شده است. موجودیتها ی كه ارتباط تنگاتنگی دارند به صورت ”بلوك داده ها“ گروه بندی می شوند. این گروه ها گاهی به نام ”موضوع داده ای نامیده می شوند“ و تشكیلمولفه های تجاری را می دهند.

38. گام 5: تحلیل وابستگی • روابط بین داده ها و كاربردهای وظیفه ای را تحلیل مینماییم.و به چند گروه خود كفاكه دارای ارزش تجاری و داده های كافیمی باشند میرسیم. اینها مولفه های تجاری هستند كه به صورت بلوكهایازپیش ساخته در ساخت نهایی برنامه كاربردیشركت نموده و فرایند های تجاری را سرویس می دهند. • این مولفه ها اشیاء دانه درشتی هستند كه خصوصیات كپسول سازی در مفهوم شیئ گرایی را دارا میباشند. همینطور كه توسعه ادامه می یابد، این مولفه ها به صورت گردهمایی اشیاء دانه ریزتربروز می كنندكه خصوصیت OO را به نمایش می گذارند. • تكنیك هاییكه كه برای تعریف مولفه های دانه درشت به كار می روند آنهای هستند كه به clustering and affinity analysis. موسوم هستند. • در مجموع، ماتریسی (معمولا به صورت صفحه كسترده) را میسازند كه تشكیل شده از وظایف بر حسب موجودیتهای داده ای كه روابط بین آنها را نشان می دهد و به عملیات معروف CRUD(Create, Read, Update , Delete) موسوم است. • خوشه بندی (clustering) روی C و Uگروه های كاندید یا مولفه های تجاری را تعریف مینماید. این بدین معنی است كه در هر گروه، وظیفه ها فقط داده ها را به وجود می آورند و بروز می رسانند.

40. گام 6 : تعریف مولفه های تجاری • اكنون ما در پایان مرحله اول ، صاحب یك لیست مولفه های تجاری كاندید هستیم. • اینها در حد وظیفه های موقتی تجاری تكمیل شده اند، ‌دارای داده و یك لیستی هستند كه دلالت بر سرویسهای عرضه شده دارند. • مولفه های تجاری كاندید ممكن است موقتا به قسمتهایی به نام مولفه های منطقی تجاری و مولفه های موجودیت داده تقسیم شوند. • ما همچنین تعاریف دقیقتری از داده و كاربرد وظیفه ای كه در تحلیل وظیفه ای وداده ای بدست آمدند نیز در نظر میگیریم.

41. گام 7: تعریف سرویسها • سرویسهای عرضه و مصرف شده توسط مولفه ها را با ذكراسكیمهای درخواست و پاسخ ، رسمی تر تعریف میکنیم. • با مراجعه به سناریوها و فرایند تجاری كه در گام 2 توضیح داده شد: بررسی میشود که آیا تمامی سناریوها و فرایندهای تجاری با سرویسهای تعریف شده چه از نظر وظیفه ای و چه از نظر داده ای حمایت می شوند.

42. گام 8: مولفه های رابط سرویس و مولفه های فرایند تجاری • مؤلفه های برنامه كاربردی انتخاب شده به درستی قابلیتهای مورد نظر را تامین می نمایند. • بررسی می كنیم كه تمامی پیامها به درستی ایجاد شده و پاسخ دریافت كرده اند.

43. گام 9: تعریف برنامه های كاربردی و چشم انداز به توافق رسیده • تعریف برنامه كاربردی نهایی را به این صورت كه این برنامه چه كاری را باید انجام دهد فرمولهمیكنیم و بازبینی مینماییم كه آیا نیاز ها برآورده می شوند. • مولفه های تجاری را مستند سازی میكنیم - توصیفات - رابط سرویس- چگونگی تعامل - مولفه منطقی تجاری – وظیفه هایی كه حمایت می شوند - مولفه موجودیتهای تجاری – مدیریت داده ها - مولفه های دسترسی به داده ها – پایگاه های داده ای به چه داده هایی دسترسی باید داشته باشند - عوامل سرویس (service agents) – كه به سرویسهای دیگر(خارجی) دسترسی دارند.

44. با تشکر از توجه شما پرسش ؟