سرويسهای مبتنی بر رويداد در SOA
نويسنده:
Jeff Hanson
JavaWorld
مترجم: احسان اميريان
خلاصه:
پاسخدهي به تغييرات بلادرنگ و رويدادها به يك شيوه زماني، يكي از مهمترين نيازمنديهاي چهارچوب فراگير ميباشد. اين مقاله تكنولوژيها و مكانيسمهايي را كه يك چهارچوب سرويسگرا را قادر ميسازد تا به صورتي كارا به محركهاي بلادرنگ پاسخ دهد و از اين رو رويدادهاي همزمان و غيرهمزمان را در ميان لايههاي يك معماري ارسال و دريافت نمايد، بدون اينكه از جزئيات سيستم رويدادي تحت آن اطلاعي داشته باشد، شرح ميدهد.
تراكنشهاي اينترنتي، سيستمهاي (B2B) Business-to-Business، فرآيندهاي Peer-to-peer و جريانهاي كاري بلادرنگ بسيار پويا، براي مدلسازي با روشهاي سنتي پردازش ترتيبي و دنبالهاي، بسيار پيچيده هستند. از اين رو نياز به تكنيكهاي پردازش غيرهمزمان بهتر و كاراتر، به سرعت پديدار ميشود. براي آدرسدهي و كنار آمدن با چنين محيطهاي غيرقابل پيشبيني، راهكار فعلي در معماري سيستمها، طراحي سرويسگرا و برنامهنويسي مبتنيبر رويداد ميباشد.
یک معماری سرویسگرا اساسا یک مچموعه از سرویسها است که این سرویسها با هم ارتباط و تعامل دارند. این ارتباط میتواند به صورت ارتباط از طریق پیغام باشد یا اینکه دو یا چند سرویس با همکاری هم، کاری را انجام دهند. معماری سرویس گرا چیز جدیدی نمیباشد. اولین معماری سرویس گرا برای کاربران در گذشته استفاده از DCOM یا ORB (Object Request Broker) بر پایه مشخصههای CORBA بود.
يك معماري سرويسگرا (SOA) يك محيط اجراي ديناميك ارائه ميدهد كه همكاري و ارتباط سبك و كم (Loose Coupling)، بين مهياكنندگان سرويس و يا مصرفكنندگان و مشتريان سرويس، تعامل بين اجزاء قوي و انعطافپذيري را منجر ميشود. ساخت يك مدل ارتباطي براي در خدمت گرفتن اين قدرت و انعطافپذيري يك اولويت بالا براي توسعه دهندگان نرمافزاري كه رقيب يكديگر هستند، ميباشد.
يك مدل ارتباطي مبتنيبر رويداد، پاسخدهي بهتر به تغييرات و محركهاي بلادرنگ را نسبت به مكانيسمهاي درخواست-پاسخ قراردادي، ممكن ميسازد.
معماريهاي سرويسگرا و مبتنيبر رويداد به صورت طبيعي و ذاتي براي سيستمهاي توزيع شده، مناسب هستند، چرا؟ آنها ويژگيهاي يكسان زيادي نظير ماژولاريتي، سازگاري و Loose-Coupling را به اشتراك ميگذارند.
در اينجا طراحي موثر و كاراي يك پلتفرم سرويسگرا و مبتنيبر رويداد با استفاده از Mule كه يك چهارچوب سبك پيغام - رويداد (event-messaging) بوده و در محدوده الگوي(ESB) Enterprise Service Bus طراحي شده، ارائه كرده است.
اجزاء و برنامههاي كاربردي ميتوانند از Mule براي برقراري ارتباط از طريق يك فريمورك پيغام رساني مشترك كه به صورت واضح و شفاف و با استفاده از سرويس پيغام رساني جاوا (JMS) پيادهسازي شده يا ديگر تكنولوژيهاي پيغام رساني، استفاده كنند.
مروري بر معماري سرويسگرا
اصطلاح »سرويسگرا« براي تعريف معماري استفاده شده است كه در آن يك سرويس، يك جزء نرمافزاري است كه مشتمل بر يك بخش اصلي از يك منطق كاري جامع است و ويژگيهاي ريز را دارد:
* اتصال سبك (Loosely Coupled): سرويسها به طور اساسي با ديگر اجزاء تركيب نشدهاند.
* مستقل از پروتكل: چندين پروتكل ميتوانند بصورت آشكار و شفاف به يك سرويس ارائه شده دسترسي داشته باشند.
* يك سرويس ارائه شده اصولا يك شكل تركيبي از منطق كاري را اجرا ميكند و نتايج را در يك فراخواني ارسال مينمايد.
* سرويسها به يك شيوه يكسان قابل دستيابي هستند و مكان آنها مهم نميباشد.
* حالت هيچ كاربري را نگه نميدارد.
سرويسها اساسا بصورت انحصاري بر حل مشكلات دامنههاي تجاري تمركز دارند. عموما مشتريان سرويس بر پيكربندي داده، رجيستريها و فاكتورهاي نرمافزاري براي تعيين مكان، پروتكل و واسط كاربري عمومي براي هر سرويس تمركز دارند.
اصولا برنامههاي كاربردي اينگونه تشريح ميشوند كه آنها چه كار ميكنند و الزاما اينگونه نيست كه آنها چه هستند و يا شامل چه ميباشند. به اين منظور، سر راستتر است كه يك برنامه كاربردي را با استفاده از افعال (سرويسها) تشريح كنيم تا استفاده از نامها (اشياء). از آنجا كه اشياء چيزها را تعريف ميكنند نه اعمال را، در تلاش براي كپسولهسازي اينكه يك جزء چه كاري انجام ميدهد، در مقابل اينكه يك جزء چه هست، دچار ناسازگاري و عدم انطباق ميشويم.
در SOA يك برنامه كاربردي بصورت ماهيتي و طبيعي تشريح ميشود، از اين رو هر عمليات منطقي از برنامه كاربردي كه ميتواند با فعل بيان شود، كانديدي مناسب براي يك سرويس است، بنابراين SOA ناسازگاري موجود را با اجازه دسترسي دادن به برنامههاي كاربردي و اجزاء به عملكردهاي سرويس بر پايه اينكه سرويسها چه كاري انجام ميدهند (يعني چه عملي را اجرا ميكنند)، حل ميكند.
در عوض، توسعه دهندگان برنامههاي كاربردي ميتوانند سادهتر نيازهاي خود را با سرويسهاي مناسب وفق دهند، تا جايي كه واسطهاي كاربري سرويسها بصورت كاملتر مشكلاتي را كه حل ميكنند، تشريح مينمايند.
مروري بر معماري مبتني بر رويداد
يك معماري مبتنيبر رويداد (EDA)، يك متدولوژي براي طراحي و پيادهسازي برنامههاي كاربردي و سيستمها تعريف ميكند، در حالتي كه رويدادها بين اجزاء نرمافزاري با اتصال سبك و سرويسها منتقل ميشوند. يك سيستم مبتني بر رويداد، اصولا شامل مصرف كنندگان رويداد و توليدكنندگان رويداد ميباشد. مصرفكنندگان رويداد به يك مدير رويداد مياني متصل شده و توليدكنندگان رويداد ارسال كننده به اين مدير هستند. هنگامي كه مدير رويداد، رويدادي را از توليد كننده دريافت نمود، آن را به مصرف كننده ارسال ميكند. اگر مصرف كننده در دسترس نباشد، مدير ميتواند رويداد را ذخيره و بعدا دوباره آن را ارسال نمايد. به اين شيوه، انتقال رويداد در سيستمهاي مبتنيبر پيغام، ذخيره و ارسال اطلاق ميشود.
ساخت برنامههاي كاربردي و سيستمها در حيطه معماري مبتنيبر رويداد اين امكان را فراهم ميسازد كه برنامههاي كاربردي و سيستمها به شيوهاي ساخته شوند كه به پاسخگويي بهتر كمك نمايند، چرا كه سيستمهاي مبتنيبر رويداد، به دليل طراحيشان، براي محيطهاي غيرقابل پيشبيني و غيرهمزمان نرمالتر ميباشند.
مزاياي طراحي و توسعه مبتنيبر رويداد
* طراحي و توسعه مبتنيبر رويداد مزاياي زير را ارائه مينمايد:
* اجازه توسعه و نگهداري آسان برنامههاي كاربردي توزيع شده و در اندازههاي بزرگ و همچنين سرويسهايي كه شامل وقايع غيرقابل پيشبيني و يا غيرهمزمان ميشوند، را ميدهد.
* اجازه پيكربندي، اسمبل كردن ساده و كم هزينه برنامههاي كاربردي و سرويسهاي جديد و موجود را ميدهد.
* امكان استفاده مجدد از اجزاء و سرويس را فراهم ميآورد، بنابراين توسعه عاري از خطا و باگ و سريعتر سيستم را سبب ميشود.
* مزاياي كوتاه مدت: اجازه سفارشي نمودن سادهتر را ميدهد، چرا كه طراحي به فرآيندهاي پويا پاسخگوتر است.
* مزاياي بلند مدت: اجازه ميدهد كه صحت و سلامت سيستم و سازمان دقيقتر با همزماني بهتر، نزديكتر به تغييرات بلادرنگ باشد.
EDA وSOA با هم
برخلاف يك سيستم درخواست- پاسخ كه در آن فراخوانها بايد بطور آشكار و واضح اطلاعات را درخواست كنند، يك معماري مبتنيبر رويداد (EDA) مكانيسمي ارائه ميدهد كه سيستم هنگامي كه رويدادي واقع ميشود بصورت خودكار پاسخ دهد. در يك EDA، رويدادها توسط توليد كننده رويداد منتشر ميشوند و مصرف كنندگان رويداد هنگامي كه رويدادها روي ميدهند، آنها را دريافت ميكنند.
سيستمهاي تجاري و كاري از جنبههاي هر دوي SOA وEDA بهره ميبرند، چرا كه يك EDA ميتواند مصرف كنندگان رويداد را به محض اينكه رويدادها روي دادند، تريگر نمايد و سرويسهاي با اتصال نيز ميتوانند به سادگي مورد دستيابي قرار گرفته و از سوي مصرفكنندگان مورد جستجو واقع شوند.
سيستمهايي كه بايد قابليت پاسخگويي بالايي داشته باشند، بايد قادر باشند كه به سرعت اعمال لازم را در هنگام تريگر شدن رويدادها تعيين نمايند. بدين منظور، رويدادها بايد در تمام مرزهاي SOA كه شامل لايههاي معماري و لايههاي فيزيكي ميشود، منتشر و مصرف شوند.
شكل 1، رويدادهاي ممكن كه ميتوانند در ميان لايههاي معماري تريگر شوند، را نشان ميدهد.
جريان رويدادها در پشته معماري
در شكل 1، يك رويداد ميتواند به عنوان هر تغيير انتشار يافته در يك سيستم، پلاتفرم، جزء كاري يا فرآيند برنامه كاربردي باشد. رويدادها در ويژگيها ميتوانند سطح بالا و كسب و كارگرا باشند يا سطح پايين و تكنيكي. از آنجا كه رويدادها ميتوانند منتقل و دريافت شوند، برنامههاي كاربردي و سرويسهايي كه از رويدادها پشتيباني ميكنند نيز ميتوانند به تغييرات روي داده، در هنگام نياز پاسخ دهند.
طبقهبندي و علت رويداد
يك نكته حياتي كه بايد در مورد يك رويداد دانست اين است كه سبب و علت رويداد را در زماني كه رويداد واقع ميشود، بفهميم. اين دانش اغلب به عنوان عليت رويداد (Event Causality) خوانده ميشود. عليت رويداد، اصولا به دو دسته اصلي تقسيم ميشود.
* عليت افقي: هر دوي منبع رويداد و علت آن در يك لايه مفهومي در پشته معماري واقع شوند.
* عليت عمودي: منبع رويداد و علت آن در لايههاي مختلف مفهومي در پشته معماري قرار دارند.
* عليت عمودي بر اين دلالت دارد كه طبقهبندي رويداد، گاهي در ميان لايههاي مختلف يك سيستم ثابت بماند، چنانكه در ليست زير مشخص شده است:
* رويدادهاي چرخه حيات: تغييرات در چرخه حيات يك رويداد را تعيين ميكنند از قبيل آغاز يا توقف يك فرآيند.
* رويدادهاي اجرايي: وقايع زمان اجرا مثل فراخواني سرويس يا جزء را تعيين ميكنند.
* رويدادهاي مديريتي: تعيين ميكنند چه موقع مقادير آستانه (thresholds) از محدوديتها و بازههاي تعريف شده، تجاوز كنند.
* عليت افقي نيز سبب ميشود كه گاهي طبقه بندي رويداد در ميان يك لايه سيستم، ثابت بماند. چنانكه در ليست زير نشان داده شده است:
* رويدادهاي لايه سيستم: فعاليتهاي سطح سيستم را از قبيل ساخت يك فايل يا بستن يك پورت، تعيين ميكنند.
* رويدادهاي سطح پلتفرم: فعاليتهاي سطح پلتفرم، مثل تغييرات يك منبع داده يا افزودن يك سرويس جديد را مشخص ميكنند.
* رويدادهاي لايه اجزاء: فعاليتهاي سطح جزء مثل، دگرگوني يك شيء View يا يك گذر ماشين حالت را تعيين ميكنند.
* رويدادهاي سطح كسب و كار: رويدادهاي سطح كسب و كار از قبيل ساخت و ايجاد يك كاربر يا حذف يك اكانت را مشخص ميكنند.
* رويدادهاي سطح كاربردي: فعاليتهاي سطح برنامه كاربردي مثل، افزايش پاداش را مشخص ميكنند.
مزيتهاي ارتباطات مبتنيبر رويداد در داخل يك SOA، اكنون در حال واقعي شدن، توسط تعدادي از فريموركهاي پلاتفرمهاي ESB است. يكي از اميدوارانهترين آنها در داخل قلمرو توسعه جاوا، Mule است.
معرفي Mule
مول يك فريم ورك منبع باز پيغامرساني ESB است كه بصورت سبك بر پايه معماري مبتني بر رويداد مرحلهاي (SEDA) ميباشد. SEDA يك پلاتفرم فراگير و با همزماني بالا را با مراحلي (Stages: اجزاء خود شمول برنامه كاربردي) كه با صفها به هم متصل شدهاند، تعريف ميكند. مول از مفاهيم SEDA استفاده ميكند تا كارآيي رويدادهاي پردازشي را افزايش دهد.
مول پشتيباني از پردازش رويدادها بصورت غيرهمزمان، همزمان و درخواست- پاسخ را با استفاده از تكنولوژيهاي مختلف ارائه ميدهد و انتقال را با JMS، HTTP، نامه الكترونيكي و فراخواني از راه دور روال مبتنيبر XML انجام ميدهد. مول ميتواند به آساني در هر فريمورك برنامه كاربردي جاسازي شود و بهطور واضح و آشكار چهارچوب Spring را حمايت ميكند. مول همچنين مسيريابي پويا، توصيفي، مبتني بر محتوي و مبتني بر قاعده پيغامها را پشتيباني ميكند. مول پشتيباني از تراكنش توصيفي و قابل برنامهنويسي را ساده كرده كه شامل پشتيباني از تراكنش XA است.
مول به منظور دستيابي مبتنيبر وب به رويدادها،Representational State Transfer (REST) API را فراهم نموده است. مدل EBS مول تمام سرويسهاي سيستم را بر پايه يك بكبن تجزيه شده ارتباط از طريق پيغام دارد. هر سرويسي تنها با پردازش رويدادهايي كه دريافت ميكند، در ارتباط است.
براي تشريح مفاهيم و ايدههاي بحث شده در اين مقاله از فريمورك مول استفاده شده است.
معماري مول
معماري مول از عناصر زير تشكيل شده است:
UMOAPI: Universal Message Object (UMO) API سرويسها و تعاملات اشيايي كه بايد توسط مول مديريت شوند را تعريف ميكند.
اجزاء UMO:
اجزاء UMO ميتوانند هر جزئي در سيستم مول باشند كه داده را در قالب پيغامهاي رويداد دريافت، پردازش و ارسال ميكنند.
سرور مول:
سرور مول يك برنامه كاربردي سرور است كه در آغاز محيط مول شروع و بارگذاري ميشود.
توصيفگرها
اجزاء توصيفگر ويژگيهاي UMO مول را تشريح ميكنند. UMOهاي جديد مول ميتوانند هنگامي كه نياز شد، از توصيفگرهاي مرتبط با آنها، مقداردهي اوليه شوند. يك توصيفگر شامل اجزاء زير است:
* نام جزءUMO
* نسخه جزء UMO
* كلاس پيادهسازي جزء UMO
* يك استراتژي استثناء (exception)
* ارائه دهندگان Inbound وoutbound
* ريابهاي Inbound وoutbound
* كنندهها (Interceptors)
* نقاط پاياني دريافت و ارسال
* مبدلهاي Inbound وoutbound
* ويژگيهاي متفرقه
اتصال دهندگان
اتصال دهندگان اجزايي هستند كه پيادهسازي براي اتصال به يك سيستم يا پروتكل خارجي ارائه ميكنند و نشستهاي (Session) سيستم يا پروتكل را مديريت مينمايند. يك اتصال دهنده مسئول ارسال داده به يك دريافت كنندههاي پيغام، ميباشد.
فراهم كنندگان (Providers)
فراهم كنندگان اجزائي هستند كه ارسال، دريافت و انتقال داده رويداد را از سيستمهاي خارجي مديريت ميكنند. آنها اتصال به سيستمهاي خارجي يا ديگر اجزاء را در مول ممكن ميسازند. يك ارائه دهنده به عنوان يك پل از سيستم خارجي به مول و برعكس عمل ميكند. اين جزء تركيبي است از مجموعهاي از اشياء كه براي اتصال و ارتباط با سيستم مورد نظر استفاده ميشود.
عناصر فراهم كننده عبارتند از:
* اتصال دهنده: مسئول ارتباط و اتصال به سيستم مورد نظر است.
* دريافت كننده پيغام: براي دريافت رويدادها از سيستم استفاده ميشود.
* توزيع كننده اتصال دهنده: داده را به سيستم ميفرستد.
* مبدلها: دادهاي كه از سيستم ميآيد و دادهاي كه بايد به سيستم ارسال شود را تبديل ميكنند.
* نقاط انتهايي (Endpoints): به عنوان آدرس كانال هنگامي كه اتصالي ايجاد ميشود، استفاده ميشود.
* پيكربندي تراكنش: براي تعريف ويژگيهاي تراكنش اتصال استفاده ميشود.
* Endpoint Resolves:: تعيين ميكنند چه متدي بايد بر روي يك جزء UMO فراخواني شود، هنگامي كه جزء رويدادي را دريافت ميكند.
* Transformers (مبدلها):
اين اجزاء پيغامها يا رويدادها را از يا به فرمتهاي مختلف داده انتقال ميدهند. انتقال دهندهها ميتوانند براي انجام انتقالهاي دنبال هم بر روي يك رويداد قبل از دريافتش توسط شياي، به هم زنجيره شوند.
* Message adapters:
اين اجزاء يك روش مشتركي را براي خواندن دادههاي مختلف از سيستمهاي خارجي ارائه ميدهند.
* دريافت كنندگان پيغام:
دريافت كنندگان پيغام نخهايي (Threads) هستند كه داده را از يك سيستم خارجي دريافت ميكنند.
* توزيع كنندگان پيغام (Message dispatchers):
اين اجزاء رويدادها را به تكنولوژي مورد استفاده ارسال (همزمان) يا توزيع (غيرهمزمان) ميكنند.
* مسيريابهاي پيغام:
مسيريابهاي پيغام، اجزايي هستند كه ميتوانند براي جزء UMO پيكربندي گردند كه اين جزء بتواند پيغام را براي توليدكنندگان مختلف برمبناي پيغام يا ديگر پيكربنديها مسيريابي نمايد.
* عاملها (Agents):
عاملها اجزايي هستند كه به سرويسهاي خارجي نظيرJMES (Extension Servers Java Management)، مقيد ميشوند.
* مدل مول:
مدل مول رفتار زمان اجراي نمونه سرور مول را كپسوله و مديريت ميكند. يك مدل شامل اجزاء زير است.
- توصيفگرها
- اجزاء UMO
- يك Endpoint Resolver
- يك استراتژي exception
- يك Lifecycle- adapter factory
- يك Component resolver
- يك Pool factory
* مدير مول:
مدير مول سرويسهاي زير را ارائه و نگهداري ميكند:
- عاملها
- ارائه دهندگان
- اتصال دهندگان
- نقاط انتهايي
- مبدلها
- پشته جدا كننده (Interceptor Stack)
معماري سطح بالاي مول
-مدل مول
- سرور مول
- مدير تراكنش
- ويژگيهايي برنامه كاربردي
- پيكربندي مول
دياگرام شكل 2، نماي سطح بالايي از جريان پيغام را براي معماري مول نشان ميدهد.
رويدادهاي مول
رويدادهاي مول شامل ويژگيها و دادههاي رويداد ميباشند كه توسط اجزاء آگاه از رويداد دستكاري و آزموده ميشوند. اين ويژگيها اختياري هستند و ميتوانند هر زماني پس از ايجاد رويداد تنظيم شوند.
كلاس org.mule.umo.UMOEvent