چارچوب توگف – TOGAF

توگف در واقع روشی برای طراحی و رسیدن به حالت مطلوب سازمان هست و شامل مجموعه ای از استانداردها هست که با همراهی مجموعه ای از ابزارها و سازه بلوک ها با تکیه بر واژگانی مشترک سعی در این مهم دارد. در توگف راهبردهای کسب و کار به عنوان ورودی فاز دیدگاه معماری در نظر گرفته شده است و دارای معماری بنیادین در قالب مدل مرجع فناوری (Technical Reference Model) هست و دارای یک متدولوژی عملی پیاده سازی به نام ADM هست که در واقع قلب تپنده این چارچوب هست.

نسخه جدید توگف در ۲۰۰۹ با پشتیبانی کامل از Service Orientation ارائه شد و این تحولی بزرگ و مزیتی رقابتی برای این چارچوب شمرده می شود. از جمله مفاهیم اصلی در توگف پیوستار سازمان، مخزن معماری و قابلیت معماری هست که بعدا مفصل باید بحث بشن.

توگف شامل ۴ دیدگاه هست :

  • معماری کسب و کار : راهبردی های کسب وکار، حاکمیت، سازماندهی، فرآیندهای مهم کسب و کار
  • معماری برنامه های کاربردی :
  • معماری دیتا : ساختار منطقی وفیزیکی دارایی های دیتا، مدیریت دیتا
  • معماری تکنولوژی : قابلیت های سخت افزاری و نرم افزاری (شبکه و …)

ارکستریشن یا هم نواسازی در تقابل با کاریگرافی یا رقصندگی

در هم نواسازی ما دو تا عنصر اصلی داریم :

  • رهبر ارکستر
  • نوازندگان ابزارها (شما فرض کن سنتور که من عاشقشم)

بعدش این نوازندها طبق دستورات رهبر ارکستر سازهاشون رو می زنن، حالا اگه رهبر ارکستر خسته بشه یا بخواد یه Break بگیره چی میشه ؟ خوب مشخصه اون عبارات هارمونیک هم به تبع تغییر می کنن. اینجا خیلی باید دقت کرد چرا ؟ چونکه همون سرویس قبلی داره اجرا میشه ولی خروجی تفاوت داره.

اما تو رقصندگی ما چی داریم ؟

  • یه رقصنده داریم
  •  یه گروه از رقّاصان صحنه

حالا رقصندگی چه کار میکنه ؟ Direction ، در واقع میاد جهت میده چطور سرویس رقص صورت بگیره ولی اینجا خود رقاص ها استقلال رفتاری دارن و مختارن (Autonomous) که چطور اون جهت دهی رو تحقق ببخشن. (realization)

هم نواساز سرویس (Service Orchestration) یک فرآیند کسب و کار قابل اجرای متمرکز منفرد (به مانند رهبر ارکستر) را ارئه می کند که نقش هماهنگی تعاملات فی ما بین سرویس های مختلف را بر عهده دارد.

در واقع Orchestrator یا هم نواساز دو تا وظیفه داره :

  • فراخوانی سرویس ها Service Invoke
  • ترکیب سرویس ها Service Combine

در واقع در Service Orchestration سرویس های چندگانه رو توسط یک Fixed Logic کنار هم قرار میدیم. این  Fixed Logic تو یه جای منفرد تشریح میشه. مثالش هم BPEL process هست. BPEL process شامل یه Logic هستش که می تونه چندین سرویس رو فراخونی کنه و Response هاشون رو یه عنوان یه Single Response Service ارائه کنه.

Orchestration زمانی مفید مواقع میشه که روی تمامی Actor های فرآیندمون کنترل داشته باشیم زمانی که همه اون Actor ها داخل یه Domain Control حاضر باشن و ما بتونیم جریان جریان کار رو دیکته کنیم. (dictate the flow of activities).

مساله دیگه اینکه هم نواسازی نسبت به رقصندگی دو تا مزیت داره :

  • قابلیت اطمینان Reliability
  • قابلیت تغییر Modifiability : ساخت و تغییر  process workflows و ترکیب سرویس های پیچیده (complex service compositions) در visual BPM tools که داخل پلت فرم های هم نواسازی هست آسون تره.

از سوی دیگه دیگه اینکه هم رقصندگی نسبت به هم نواسازی دو تا مزیت داره :

  • عملکرد Performance : هم نواساز هنگام تفسیر اسکریپت های جریان کار دچار یه سربار عملکرد (performance overhead) میشه
  • هزینه Cost : رقصندگی بر خلاف هم نواساز نیاز به زبان میانی یا زبان خاصی نداره

 

مدل مرجع فنی Technical Reference Model

از آنجایی که کتابخانه مرجع معماری سازمانی باید شامل مدل های مرجع هم باشد و TRM هم یک مدل مرجع است، TRM را با هم در TOGAF بصورت شماتیک بررسی می کنیم :

TOGAF دو تا مدل مرجع داره :

  • مدل مرجع فنی TRM
  • مدل زیرساخت اطلاعاتی جامع و یکپارچه IIIR

در واقع TRM دو تا بخش داره :

  • مدل
  • طبقه بندی

مدل و طبقه بندی برای چه ؟ برای سرویس های سکوهای عمومی

هر دو تا مدل بالا می تونن داخل پیوستار معماری سازمانی Enterprise Architecture Continuum مطرح بشن (مفصل درباره این Enterprise Architecture Continuum باید صحبت کنیم).

TOGAF_TRM
مدل مرجع فنی توگف

یک سری نکات را در رابطه با مدل مرجع فنی بررسی می کنیم :

  • بنیان مستحکم چارچوب TOGAF هستش.
  • نقش ADM اینجا چی هست ؟ ADM میاد میگه چطور میشه از این معماری بنیادین واسه یه مرکز خاص استفاده کرد و توسعه اش داد (Development)
  • TRM نیازهای محاسباتی که حالت General دارن رو نمایش میده
  • TRM بخش های Constructor که حالت General دارن رو نمایش میده
  • تعریف استانداردهای فناورانه که واسه Implement بخش های Constructor نیاز هست رو بر عهده داره
  • Product Direction رو انجام میده
  • Strategies رو نمایش میده
  • Open Sys Standards رو نمایش میده

TRM دو بخش اصلی داره :

  1.  Terms Description +  Information Systems Structure Segments Define
  2. A model with a Big Picture of Number 1 Class
TRM با دید سطح بالا
TRM با دید سطح بالا

شکل زیر مدل مرجع فنی رو که با نرم افزار Rational System Architect طراحی شده رو نشون میده :

مدل مرجع فنی طراحی شده توسط Rational System Architect
مدل مرجع فنی طراحی شده توسط Rational System Architect

این شکل هم رو نشون میده که سطوح چهارگانه سرویس در اون مشخص شده

  • محیط سرویس
  • موضوع سرویس
  • استاندارد سرویس
  • مشخصات سرویس

 

برای کسب اطلاعات بیشتر به این وب سایت خوب از آقای امیر درجه مراجعه کنید.

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

DevOps and Microservices

بررسی DevOps و Microservices

DevOps مجموعه ای از فعالیت ها هستش که یه همچین کاربردی داره : میاد و زمان بین تغییرات سیستم و انتقال اون تغییرات رو به یه محیط تولیدی نو کاهش میده . همینطور اصرار داره به اینکه بیاد و به مبحث تامین کیفیت نرم افزار بپردازه هم در رابطه با کد و هم مکانیزم تحویل محصول . هر نوع تکنیکی که باعث بشه این اهدافی که ذکر کردم محقق بشه رو بهش میگن DevOps .

یه فعالیت دیگه که به نوعی DevOps محسوب میشه هم “تحویل مداوم” هست. همین تحویل مداوم از بخش های متصل و جدایی ناپذیر میکروسرویس ها هستش . از دیگر فعالیت های ضروری DevOps هم “مانیتورینگ مداوم” هست که باعث میشه یه سری بازخوردهای مرتبط با عملکرد سیستم رو به توسعه دهندگان برسونه ؛ علاوه بر این تشخیص آنومالی های عملیاتی رو تسریع می بخشه.

در واقع DevOps با بهره گیری از فاکتور سرعت باعث میشه که بهتر بتونه به مشتری هاش سرویس بده و اونا رو حفظ کنه. وقتی ما تحت مدل DevOps هستیم دیگه تیم توسعه و تیم عملیاتی به صورتی سیلویی (Siloed)  نیستتند. گاهی اوقات دو تا  تیم توسعه و تیم عملیاتی در قالب یک تیم ظاهر میشن و مهندس ها در سراسر چرخه خیات برنامه کار میکنن ؛ از توسعه و آزمایش برنامه گرفته تا استقرار و بحث عملیاتی.

این تیم ها میان و یه سری فعالیت هایی رو انجام میدن تا پردازش هایی که قبلا بصورت دستی و کند صورت میگرفت حالا بصورت خودکار انجام بشه.

افزایش استفاده از DevOps و Microservices بر مبنای Google

شکل بالا هم افزایش استفاده از DevOps و Microservices بر مبنای موتور جست و جوی گوگل رو نشون میده که از سال ۲۰۰۹ شروع به رشد داشته و در سال ۲۰۱۶ به اوج رشد خودشون رسیدن . رنگ آبی مربوط به DevOps هست و رنگ قرمز مربوط به Ms

اما DevOps چه مزایای داره ؟

سرعت

تحویل سریع و مداوم

قابلیت اطمینان

مقیاس پذیری

بهبود همکاری و ارتباطات تیمی

تامین امنیت

اینجا رو هم ببینید که محشره.

نمونه یک Proposal (پاسخ به درخواست) برای سیستم انبارداری

نوشتاری که با هم می بینیم نمونه یک Proposal (پاسخ به درخواست) برای سیستم انبارداری به صورت مختصر است و باید مطلع باشیم نمونه Proposal کامل چیزی فراتر است و تنها هدف از درج نمونه ذیل آشنایی با ساختار یک  Proposal است.


پاسخ به درخواست

Proposal

  خرداد ۹۶

مقدمه

این Proposal برای پاسخ به RFP  سیستم انبار کالای  موردنظر تهیه شده است و سعی بر این بوده است که موارد مهم به روشنی بیان شود.

پیشنهاد ما اینست که طراحی سیستم به صورت آنلاین باشد تا مراجعه کنندگان بتوانند کالای موردنیاز خود را بصورت اینترنتی تهیه کنند و البته در این صورت این ساختار بطور کل با سیستم محلی Local تفاوت دارد. اين سامانه تحت وب ، کليه فرايند انبارداري را طبق گردش کاري در بستر اينترنت يا اينترانت ، مکانيزه مي کند. تمام فرآيند هاي انبارداري و اموال تحت يک سامانه اتوماسيون مي شود و هر بخش از فرآيند انبار و اموال تحت کارتابل کاري يک متصدي قرار مي گيرد  ، تا فرآيند انبارداري بصورت لحظه اي انجام شود  .

در اين فرآيند  لحظه اي ، در حين ورود کالا به انبار متصدي انبار اقدام به ثبت  اقلام ورودي به انبار مورد نظر کرده و بصورت لحظه اي اقلام وارد شده در کارتابل کاري واحد حسابداري انبار ظاهر شده تا واحد حسابداري انبار اقدام به درج داده هاي مالي انبار نمايد آنلاین بودن اين فرآيند ، به يک سازمان کمک مي کند که بصورت لحظه اي از تمام تراکنش هاي انبار با خبر شود و تصميم گيري هاي دقيق بر اساس اطلاعات لحظه اي داشته باشد. این طرح مزیت هایی هم دارد

مثلا :

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

البته این فقط یک پیشنهاد است و تعریف سیستم به صورت محلی Local قابل انجام است.

 

نگه داری و پشتیبانی :

سیستم به شکلی طراحی میشود که بتوان در مواقع مورد نیاز از آن نسخه پشتیبان تهیه کرد (Backup) تا در صورت نیاز به آن مراجعه شود و به جهت رعایت داده ها (Data) می توان این نسخه را بصورت امن (Safe) در محیط ابری (Cloud) بارگذاری کرد. ما به شما پیشنهاد پیاده سازی ربات برای حمل و نقل کالا را می دهیم و خودمان توانایی پیاده سازی آن را برعهده خواهیم گرفت.

 

ضمانت کیفیت :

تیم ما کیفیت را به شکل تمام و کمال تضمین میکند که در صورت مراجعه به سوابق کاری قبلی ما این مهم را مشاهده خواهید کرد ولی در صورتی که سیستم ما دارای نقص یا مشکلی بود این مساله حتما به جهت سوء تفاهم رخ داده است و از سمت افراد خبره و چیره دست ما نبوده است.

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

 

تجربه و سابقه کاری ما :

اگر بخواهید به نوعی پروژه ای نزدیک به سیستم مربوطه را ملاحظه کنید می توانید سیستم مدیریت اینترنتی سمساری را ملاحظه کنید که به شکلی کاملا رضایت بخش صورت گرفته و مشتریان از آن نهایت رضایت را دارند و به شکلی مناسب در حال ارایه خدمات است.

 

قیمت گذاری سیستم و موعد پیاده سازی و تحویل :

معیار و متریک ما برای قیمت گذاری میزان ساعت کاری است که تیم ما بر روی آن صرف خواهد کرد.

شخص تایم نرخ قیمت کلی (ریال)
Project Manager ۲۴۰ ساعت ۴۵۰۰۰ ۱۰۸۰۰۰۰۰۰
Analyzer ۱۸۰ ساعت ۴۲۰۰۰ ۷۵۶۰۰۰۰۰
Programmer ۱۴۰ ساعت ۳۸۰۰۰ ۵۳۲۰۰۰۰۰
Coordinator ۱۰۰ ساعت ۲۶۰۰۰ ۲۶۰۰۰۰۰۰
       

 

سطح دسترسی : (Permission Level)

  • مدیر سیستم :
    • می تواند سطوح دسترسی کاربران را تعیین کند.
  • مسئول امانت کالا :
    • با تطابق سطح دسترسی که برایش توسط مدیر تعریف شده فعالیت کند.

 نکات فنی سیستم : (Technical Point)

  • تهیه نسخه Backup در تاریخ های از پیش تعیین شده ممکن باشد.
  • زبان برنامه نویسی و پایگاه داده از بین موارد ذیل است :
  • زبان برنامه نویسی :
    • PHP
    • Java
    • C#
    • .Net
  • پایگاه داده :
    • SQL SERVER
    • MySQL

 


بخش های مختلف سیستم دارای Reporting مربوط به خودشان هستند.

  • سیستم دارای User Interface چشم نواز است
  • تجربه کاربری User Experience بخوبی در سیستم لحاظ شده است.
  • تدابیر امنیتی برای سیستم تدارک دیده شده است.
  • تمامی I/O ها در سیستم ثبت Log میشوند.

 


 

WSO2 چیست ؟

WSO2  یک  فناوری متن باز برای کسب و کارهای دیجیتال است که راه حل های مبتنی بر معماری سرویس گرا – Service-Oriented Architecture را برای توسعه دهندگان نرم افزار فراهم می آورد و تحت پشتیبانی شرکتی با همین نام WSO2 اداره می شود . WSO2 توسط Dr. Sanjiva Weerawarana  در آگوست ۲۰۰۵ راه اندازی شد و یکی از همکاران کلیدی پروژه عظیم وب سرویس آپاچی که شامل پروژه های Apache Axis2, Apache Rampart, Apache Synapse, Apache Axiom می شود می باشد . این فناوری تحت مجوز Apache License Version 2 بصورت رایگان منتشر می شود. این شرکت کنفرانسی را هم تحت عنوان WSO2Con در Colombo برگزار می کند که در رابطه با  SOA, Cloud Computing, IT strategies بحث می کنند.

فناوری این شرکت هم بصورت عمومی و هم خصوصی در فضای ابری ارائه می شود. به عنوان یک محصول یکپارچه  برخی  ویژگی های آن را با معمار سازمان بررسی می کنیم :

  • مسیر یابی پیام – Message routing
  • Message transformation
  • سوییچ بین پروتکل ها – Protocol switching
  • نگاشت داده – Data mapping.
  • تحلیل و ردیابی پیام ها – Message tracing and analytics.
  • امکان یکپارچه شدن با رابط های کاربردی نرم افزاری فضای ابری (سرویس ایمیل گوگل ، توییتر و …)  – Integration with cloud APIs (e.g. Salesforce, Gmail, and Twitter) using 160+ cloud connectors.
  • امکان یکپارچه شدن با پایگاه های داده و سرویس های ارایه دهنده داده – Integration with databases and offer data services.
  • Integration with proprietary systems (e.g. SAP, FIX, and HL7)

WSO 2 Identity Server  ؟

یک سرویس مدیریت متن باز اعتبارسنجی است که از استانداردهای زیر تبعیت می کند :

  • OpenID
  • OAuth 1.0a/2.0
  • XACML 2.0/3.0
  • SAML2
  • WS-Trust/STS
  • SCIM
  • XKMS
  • User Management
  • Connectors to AD/LDAP

WSO 2 Identity Server به منظور رفع اشکالات اعتبارسنجی ایجاد شده است و به مدیریت اعتبارسنجی نرم افزارهای تحت وب و API’s می پردازد.


پروتکل های سرویس گرایی – SOAP

SOAP که سر واژه کلمات Simple Object Access Protocol هست ، فرمت تبادل پیام در قالب XML می باشد که در تعاملات وب سرویس ها استفاده می شود. غالب پیام های SOAP بر بستر HTTP یا JMS انتقال می یابند با این وجود دیگر پروتکل های انتقال هم می توانند استفاده شوند. استفاده از SOAP خاصه در وب سرویس ها توسط WSDL – (Web Service Definition Language) تعریف می شود.

SOAP
SOAP

SOAP در مستندات زیر توسط کنسرسیوم وب جهانی W3C به خوبی تشریح شده است :

برای کسب اطلاعات بیشتر اینجا را ببینید.

پیام های SOAP همچون نامه های پستی در قالب یک Envelope (پاکت) در بستر اینترنت ارسال می شوند. همانطور که بالاتر هم اشاره شد SOAP یک استاندارد از سوی W3C می باشد. در واقع SOAP به عنوان جایگزینی برای REST , JSON می باشد. (پیش تر در مقاله معماری وب گرا در رابطه با تفاوت های SOAP , REST توضیحاتی نوشتم که می توانید در اینجا آنها را بخوانید)

ساختار SOAP بدین شکل هست :

ساختار پیام SOAP
ساختار پیام SOAP

پاکت نامه SOAP حاوی دو بخش است :

  • سرآیند اختیاری (Optional Header) که اطلاعاتی رو به منظور احراز هویت ، کدینگ داده ها ، یا چگونگی پردازش این پیام توسط گیرنده اشاره دارد.
  • بدنه محتوی که حاوی پیام هست. این پیام توسط WSDL تعریف می شود.

تو شکل بالا هم که کشیدم اشاره کردم که SOAP غالبا از HTTP بهره می بره ولی می تونه از پروتکل های دیگه مثل SMTP (Simple Mail Transfer Protoco)l هم استفاده کنه.

نکته : زمانی که SOAP شروع به کار کرد حروفش مخفف Simple Object Access Protocol بودند ولی از زمانی که ورژن ۱٫۰۲ استارت خورد این حروف دیگر معنای خاصی را القاء نمی کنند.

پس SOAP شامل سه بخش است :

  • Envelope
    • Packet Local Name
    • zero or more Quality Attribute
    • Body (Not Optional)1
  • Header
    • استایل رمزنگاری
    • نقش (Role)
  • Body
    • A Local name
    • A Namespace name
    • zero or more Attribute
    • zero or more Elements

توجه شود که Envelope اجباری است بر خلاف سرآیند که اختیاری است ،

ارتباط پروتکل SOAP و وب سرویس ها هم اینطوره :

پروتکل SOAP و وب سرویس ها
پروتکل SOAP و وب سرویس ها

اینجا رو هم ببینید که بخشی از مطالب از اینجا به قلم Douglas K Barry برگرفته شده است.

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

در رابطه با معماری سرویس گرا و میکروسرویس ها باید گفت هر دو زیر مجموعه از تفکر سرویس گرایی هستند و نقطه مشترکی که دارند بحث Distribution (توزیع پذیری) هست. در معماری سرویس گرایی بخش هایی از نرم افزار تو شِمای سرویس encapsulate (کپسوله) میشوند. حالا این کپسوله سازی رو همونطور که قبلا هم حتما شنیدید به این مساله اشاره داره که سرویس ها بصورت مجزی از هم طراحی می شوند.

سرویس ها هم در معماری به دو صورت طبقه بندی میشن :

  • Service Type (سطح الگوی معماری)
  • Business Type (سطح پیاده سازی)

تو میکروسرویس ها هم Service Type به دو صورت هست :

  • Functional
  • Infrastructure

به این صورت که کلاینت میاد یه درخواستی رو به سمت لایه API ارسال میکنه ، لایه API هم میاد منتقلش میکنه به سطح عملیات سرویس و اینجا هم تقاضای سرویس به سطح زیربنایی سرویس فرستاد میشه ، حالا شکلش رو میکشم بهتر متوجه بشیم :

 

تو SOA هم سرویس ها دو دسته هستند :

  • Business Service مثل XML , WSDL , BPEL ( سطح تجرید اینجا بالا هست)
  • Enterprise Service که مثلا تحت چارچوب دات نت با زبان سی شارپ پیاده سازی صورت بگیره یا …
  • Application Service
  • Infrastructure Service

اما  چطوره ؟

مدل مالکیت میکروسرویس هم بدین شکله :

مدل مالکیت میکروسرویس
مدل مالکیت میکروسرویس

تو SOA هر سرویسی صاحب خودشو داره ولی تو میکروسرویس این یه تیم هستش که درگیر میشه بر خلاف SOA که چند تا تیم میان درگیر چند تا سرویس میشن و این یه نقطه منفی واسه SOA محسوب میشه و همین ویژگی منفی باعث شده میکروسرویس ها بالاتر از SOA باشن. از منظر Granularity (دانه بندی) هم سرویس ها هستش که چون اندازه کوچکتری دارن :

  • سریع تر تولید میشن
  • سریع تر تو پروژه استقرار پیدا میکنن
  • سریع تر هم تست میشن

پس در این صورت میشه مزایای میکروسرویس ها رو اینا بر شمرد :

  • هزینه میاد پایین
  • زمان کمتری واسه توسعه نیاز هست
  • مشتری های رضایت بیشتری دارن
  • Stakeholder ها هم راضی ترن

الآن چلش اصلی SOA همین بحث  Granularity (دانه بندی) هستش که متاسفانه برخی معماران درک درستی ازش ندارن ؛ بعضی سرویس ها خیلی ریز طراحی میشن ، بعضی سرویس ها هم خیلی درشت . اگه یادتون باشه تو پایگاه داده یه قانون داشتیم به نام ACID که طبق اون اگه دانه بندی خیلی ریز باشه ما نمی تونیم سرویس ها رو با هم Synchronize کنیم.

دانه بندی هم رو دو تا فاکتور تاثیر میذاره :

  • Functionality
  • Transaction Management

میکرو سرویس ها :

  • Small Size
  • Small Structure

بحث دیگه ای هم که مطرح هست موضوع Component Share هست که SOA و Micro services با هم تفاوت دارند که سرویس گرایی بیشترین اشتراک رو داره بر خلاف میکروسرویس ها که کمترین اشتراک رو داره و همین شده واسش مزیت ! اما چرا ؟

  • چون که Modules Dependency پایین هستش پس نگهداری آسون تره چون که تکامل سرویس ها مستقل از سرویس های دیگه ست.
  • دوم اینکه فاز استقرار راحت تره ممکن هست ، چون که حجم کدهایی که تغییر میکنه زیاد نیست
  • سوم اینکه ریسک تاثیر تغییر یه سرویس به باقی سرویس ها میادش پایین

 

معماری وب گرا (سبکی از سرویس گرایی)

در ابتدای مقاله پیش از آن که وارد بحث معماری وب گرا بشوم یک سوال مطرح میکنم که شاید برای شما هم جالب باشد. آن سوال اینست : آیا SOA پاسخی برای همه چیز در حوزه معماری است ؟ شاید اینطور نباشد. به ترکیب زیر دقت کنید :

WOA  / SOA + WWW + REST

ترکیب فوق ما را چند قدم جلوتر برده و کاستی های سرویس گرایی را پر می کند و مارا یاری می کند تا اپلیکیشن های کامل end-to-end بسازیم ، اگر چه مفهوم WOA شاید چندان فراگیر نباشد ولی بسیاری از آنچه تاکنون در سطح اینترنت می بینیم شالوده همین تفکر وب گرایی است.

معماری وب گرا یا Web-Oriented Architecture در ۲۰۰۶ توسط  Nick Gall از گروه Gartner ابداع شده است. معماری وب گرا یک سبک معماری نرم افزاری است که معماری سرویس گرا (Service-Oriented Architecture) را در راستای اپلیکیشن های تحت وب گسترش می دهد. معماری وب گرا در اصل توسط بسیاری از شبکه های اجتماعی و وب سایت های شخصی ساخته شده است.

 

تعریف رسمی Gartner از معماری وب گرا چنین است : معماری وب گرا یا Web-Oriented Architecture سبکی معمارگونه از معماری سرویس گرا یا همان Service-Oriented Architecture می باشد که به یکپارچگی سیستم ها و کاربران از طریق ابررسانه های مرتبط با هم در سطح جهانی بر اساس معماری وب می پردازد. این نوع معماری بر تمامی اینترفیس ها (رابط کاربری و  رابط کاربردی برنامه نویسی) به منظور دستیابی به تاثیرات شبکه ی جهانی از طریق پنج عنصر رابط اساسی ذیل تاکید دارد :

  • شناسایی منابع
  • بکارگیری منابع از طریق نمایش آنها (منابع وب)
  • پیام های خودتوصیفی
  • ابررسانه بعنوان قلب تپنده موقعیت برنامه
  • درگیر نکردن برنامه

Nick Gall همچنین فرمولی برای تعریف معماری وب گرا (WOA) ارائه داده است که بدین شکل است:

WOA = SOA + WWW + REST

Dion Hinchcliffe مدعی است که معماری وب گرا چنین است: مجموعه ای از هسته پروتکل های وب مانند HTTP, XML است و اینکه تنها تفاوت معماری سرویس گرای سنتی و مفاهیم معماری وب گرا اینست که WOA از REST حمایت می کند. REST متدی به طور فزاینده محبوب ، قدرتمند و ساده به منظور اعمال نفوذ پروتکل انتقال ابر متن HTTP بعنوان یک وب سرویس در چارچوب حقوق خودش است.

پشته ی معماری وب گرا WOA شامل چنین مواردی است :

  • توزیع (HTTP , Feeds)
  • ترکیب (Hypermedia , Mashups)
  • امنیت (Open ID, SSL)
  • قابلیت انتقال داده (XML,RDF)
  • قابلیت نمایش داده (ATOM, JSON)
  • متدهای انتقال (REST, HTTP, Bit Torrent)

بطور کل باید گفت WOA هر چیزی است که در اینترنت وجود دارد و هر چیزی که بر مبنای REST می باشد والبته سرویس گراست. در کلامی گویا باید گفت امروزه معماری وب گرا پراستفاده ترین نوع معماری در جهان تا به امروز بوده است. طبق پیش بینی Gartner در ۲۰۱۴ سبک معماری وب گرای (مبتنی بر REST) در ۸۰% سازمان هایی که سرویس گرایی را دنبال می کنند فراگیر خواهد شد. واقعا صحت یا عدم صحت تحقق این پیش بینی Gartner شاید مهم نباشد ؛ چرا که هر کسی می بایست WOA را بشناسد.

اما REST چیست ؟ Representational State Transfer سبکی از معماری نرم افزار برای سیستم های ابررسانه توزیع شده مانند شبکه جهانی وب است. (منبع : ویکی پدیا) با هم اصول REST رو مرور کنیم :

  • هر چیزی یک منبع است.
  • هر منبعی یک تمثیل دارد.
  • هر منبعی یک نام بخصوص دارد.
  • انتقال موقعیت نیازمند کشف و شهود (Discovery) است.
  • پروتکل شبکه پایه WOA می باشد

بطور خلاصه WOA را بررسی می کنیم :

  • اطلاعات در قالب منابع (Resources) نمایش می یابند.
  • منابع توسط URI ها شناخته می شوند.
  • منابع از طریق HTTP اداره می شوند.
  • معاهدات به صورت ضمنی در نمایش منابع می باشند
  • رابط ها بطور کلی عام هستند.

معماری وب گرای سازمانی

معماری وب گرای سازمانی یا Enterprise Web Oriented Architecture (EWOA) یکی از زیر سبک های SOA می باشد. EWOA مجموعه ای از عناصر ، اصول و فرآیندهای معماری مبتنی بر وب می باشد. وب سایت ها و برنامه های کاربردی جدید مانند Google AdSense, Wikipedia و دیگر سرویس های RESTful از WOA استفاده می کنند.

مثال حال حاضر WOA را می توان Google’s Open Social  یا MindTouch دانست. در حال حاضر Mobile API بنایی اساسی بر تمرکز در استفاده از تکنولوژی WOA دارند. ساخت چنین سرویس هایی با استفاده از پروتکل های ساده شده وب نظیر Rest , JSON بیش از پیش آسان شده است. این پروتکل ها برای توسعه دهندگان وب بسیار راحت تر است چرا که CPU و پهنای باند کمتری را طلب می کنند. این پروتکل ها بیشتر بخاطر شبکه های اجتماعی بزرگ نظیر فیس بوک ، آمازون ، توییتر و … شناخته شده اند.

MindTouch هم یک شرکت اوپن سورس و یک سکوی مستندسازی استراتژیک و نوعی جدید از ECM می باشد. از جمله پروژه هایی که ارایه کرده است می توان به موارد ذیل اشاره کرد :

  • DReAM
  • SGML Reader
  • MindTouch Core/2010

در ادامه بکارگیری REST را در قالب شبکه جهانی وب (W3) در قالب جدول زیر با دیدگاه مقایسه ای با تلفیق در وب بررسی می کنیم :

{بنده می گویم} REST بدون WWW بی معناست. REST با Web است که تکمیل می شود و معنا پیدا می کند.

REST(www)Table
REST(www)Table

بررسی مزایای WOA

  • ساده سازی توسعه پذیری ، مقیاس پذیری
  • کاهش زمان توسعه ویژگی های جدید
  • کاهش زمان مهندسی مورد نیاز برای یکپارچه سازی
  • سازنده فرصت هایی جدید برای mash-ups و دیگر داستان های غیرقابل پیش بینی کاربری

اما وضعیت ارتباطی کلاینت ها و سرورها در WOA چگونه است ؟

  • سرویس ها وابسته به دیگر سرویس ها هستند.
  • ارتباطات از طریق HTTP صورت می گیرد.
  • کلاینت ها حکم منبع و سرویس دهی به دیگر کلاینت ها را دارند.
  • مقیاس پذیری ، توسعه پذیری == اتصالات داخی
شماتیکی از معماری وب گرا رو براتون طراحی کردم تا بهتر متوجه بشیم
شماتیکی از معماری وب گرا رو براتون طراحی کردم تا بهتر متوجه بشیم

بیضی های سمت راست در واقع لینک های وب هستند که با هم بصورت تنگانگ در ارتباط هستند و به هم گره خورده اند. لینک ها هم همان منابع تحت وب هستند که متشکل از صوت و تصویر و متن می باشند. (تارهای وب)

 

سوالی که بسیار مطرح می شود و در بالای مقاله هم به گونه ای دیگر به آن پاسخ داده شد اینست که آیا معماری وب گرا همان معماری سرویس گرا است ؟ در پاسخ باید گفت بله ، چرا که معماری وب گرا از تمامی اصول معماری سرویس گرا که شامل ۸ اصل است پیروی می کند. با هم این ۸ اصل را مرور می کنیم :

  • قابلیت استفاده مجدد سرویس
  • توافق سرویس
  • اتصال سست سرویس
  • تجرید سرویس
  • ترکیب پذیری سرویس
  • استقلال سرویس
  • عدم وابستگی سرویس (بی طرفی)
  • قابلیت کشف (شدن) سرویس

نکته مهم در تفاوت بین WOA , SOA اینست که معماری سرویس گرا به منظور  ابزار دوستانه بودن از بالا به پایین طراحی شده است (Top-Down) اما معماری وب گرا بصورت پایین به بالا طراحی شده است (Bottom-Up) . مساله دیگر اینکه SOA از WS-Security و دیگر استانداردهای پیچیده به منظور تامین امنیت استفاده می کند در حالی که WOA همانطور که در ابتدای مقاله و در شکل پشته های وب بدان اشاره شد از HTTPS ، OAuth و HMAC-SHA-1 بهره می برد.

 

مفهومی به نام Mashup

Mashup در واقع وب سایت ها و برنامه های کاربردی هستند که از ترکیب چند سرویس و مزایای چند سرویس دهنده ایجاد شده اند. بدین صورت که داده ها و سرویس های چند منبع بصورت یکپارچه حاصل می شود. اما اینکه چرا Mashup از نظر استفاده رو به افزایش است دو دلیل اصلی دارد :

  • مقادیر داده های بسیار زیاد از منابع متنوع در دسترس قرار می گیرد.
  • توسعه ابزارهای رابطی که با کمک آنها می توان به سادگی از Mashup استفاده کرد.

برخی از نمونه های Mashup می توان به موارد ذیل اشاره کرد :

  • Photo Mashup
  • Messaging Mashup
  • Search Mashup
  • Video Mashup
  • Travel Mashup

 

بعنوان مثال می توان با ترکیب تصاویر و آدرس های مختلف دانشگاه های تهران یک map Mashup درست کرد.

برای Photo Mashup ابزار Color Picker هم هست که امکان جست و جوی تصاویر را بر اساس رنگ فراهم می کند و از سرویس اشتراک گذاری عکس Flickr استفاده می کند که در این آدرس قابل استفاده است.

معماری Mashup هم مثل معماری MVC (البته با تفاوت های فاحش) سه لایه ای است :

  • لایه نمایش / تعامل کاربر (همان رابط کاربری است)
    • تکنولوژی ها : HTML/XHTML, CSS, Javascript, Asynchronous JS and Xml (Ajax).
  • وب سرویس ها : عملکرد محصول از طریق سرویس های API هم قابل دسترسی است
    • تکنولوژی ها : XMLHTTPRequest, XML-RPC, JSON-RPC, SOAP, REST
  • داده : فراهم آوردن امکان ارسال ، مرتب سازی و دریافت داده
    • تکنولوژی ها : XML , JSON , KML

از نظر معماری  Mashup  دارای ۲ سبک است : الف) مبتنی بر وب ب) مبتنی بر سرور

 در ادامه با هم نمونه ای از استقرار معماری وب گرا WOA در سازمان بصورت شماتیک می بینیم. با هم مشاهده می کنیم با این پیاده سازی موانع سر راه ما کاهش پیدا می کند ، سرعت یکپارچگی افزایش پیدا می کند. بدین صورت که می توان از قدرت شبکه جهانی وب در جهت انتقال محتوی مورد نیازمان به هر جا و در هر زمان بهره جست.

شاید برای شما سوال پیش بیاید که ما در معماری وب گرا بحث می کردیم اصلا چرا وارد مفهوم Mashup شدیم؟

بعبارت فنی تر چرا معماری وب گرا (WOA) برای Mashups اهمیت دارد ؟ پاسخ یک کلمه است : REST . همانطور که بالاتر مقاله هم اشاره کردم Mashup از REST بهره می برد. به منظور افزایش اطلاعات در رابطه با REST باید گفت Roy Fielding آنرا بنیان نهاده است. میخواهید او را بهتر معرفی کنم ؟ وی یکی از خالقان HTTP است و مگر می توان وب را بدون HTTP فرض کرد که مهمترین پروتکل انتقال ابر متن در جهان و پروتکل زیربنایی وب است؟! REST به خوبی با معماری اینترنت عجین شده است! بپرسید چرا ؟ چون پروتکل اصلی اینترنت HTTP است و هر دوی این ها از یک ذهن نشات گرفته و او کسی نیست جز Roy Fielding. اما باید بگویم REST یک استاندارد نیست ، با وجود سادگی بسیار زیاد تنها یک سبک استفاده از HTTP است.

REST همچنین از متدهای اختصاصی HTTP نظیر GET, PUT , POST , DELETE در بالای یک URL استفاده می کند تا نشان دهد چه رویدادی رخ می دهد.

در پایان گفته ها در رابطه با REST باید بگویم ATOM همان REST است. منظورم از ATOM ویرایشگر معروف متنی نیست که برای نوشتن کدهای برنامه نویسی استفاده قرار می گیرد؛ آنرا غالبا به شکل Atom می نویسند چرا که مخفف چند کلمه نیست و یک کلمه خاص است  اما ATOM یک استاندارد وب به زبان XML است که برای خوراک وب بعنوان جایگزینی برای RSS استفاده می شود. ATOM را با AtomPub یا APP اشتباه نگیرید ؛ چرا که APP پروتکل انتشاری است مبتنی بر پروتکل انتقال ابرمتن (HTTP) و برای به روزرسانی محتوی وب مورد استفاده قرار می گیرد.

در ادامه مباحث دررابطه با معماری وب گرا باید گفت WOA امروزه بعنوان مدل حاکم برنامه های تحت شبکه مطرح است اما متاسفانه فروشندگان بزرگی در پشت آن حضور ندارند به همین دلیل آنچنان که باید عمومیت نیافته است. WOA همچنان می تواند بیشترین سود حاصل را از طریق شبکه فراهم کند. شاید بتوان گفت کوتاه ترین مسیر برای رسیدن به چنین نتیجه ای همین معماری وب گرا است.

شماتیک وب گرایی در قالب سرویس گرایی
شماتیک وب گرایی در قالب سرویس گرایی

فرمول جالبی هم برای تعریف وب ارایه شد است که با هم می بینیم :

HTTP + URIs = Web

ظرافت فرمول بالا به اهمیت پروتکل زیربنایی وب یعنی HTTP اشاره دارد.  URI هم مجموعه ای از رشته هاست که برای شناسایی یک منبع خاص تحت وب به کار می روند.در شکل زیر رابطه بین URI , URN , URL را بررسی می کنیم. URI تشکیل شده است از URL و URN . URL متد دسترسی به منبع را مشخص می کند در حالی که URN تنها مشخص کننده نام منبع می باشد و هیچ گونه روشی برای دسترسی به ما ارایه نمی دهد. بعنوان مثال یک شماره ISBN کتاب یک نوع URN است.

شماتیک URI , URL
شماتیک URI , URL

منابعی که ازشون واسه مقاله استفاده کردم رو اینجا ذکر میکنم :

Web-oriented Architectures: On the Impact of Web 2.0 on Service-oriented

Architectures , Gunnar Thies, Gottfried Vossen

Nick Gall,WOA: Putting the Web Back in Web Services

Nick Gall Web-oriented architecture and the rise of pragmatic SOA

Dion Hinchcliffe, The SOA with reach: Web-Oriented Architecture

Web Oriented Architecture. Presented at Gluecon 2010 by Aaron Fulkerson

Dion Hinchcliffe. http:// Hinchcliffe.org. some rights reserved , 2008 [Shape]

org [Shape]

https://en.wikipedia.org/wiki/Mashup_(web_application_hybrid)

https://javabyab.com