- شناسایی منابع
- بکارگیری منابع از طریق نمایش آنها (منابع وب)
- پیامهای خودتوصیفی
- ابررسانه بعنوان قلب تپنده موقعیت برنامه
- درگیر نکردن برنامه “
- توزیع (HTTP , Feeds)
- ترکیب (Hypermedia , Mashups)
- امنیت (Open ID, SSL)
- قابلیت انتقال داده (XML,RDF)
- قابلیت نمایش داده (ATOM, JSON)
- متدهای انتقال (REST, HTTP, Bit Torrent)
- هر چیزی یک منبع است.
- هر منبعی یک تمثیل دارد.
- هر منبعی یک نام بخصوص دارد.
- انتقال موقعیت نیازمند کشف و شهود (Discovery) است.
- پروتکل شبکه پایه WOA میباشد
- اطلاعات در قالب منابع (Resources) نمایش مییابند.
- منابع توسط URIها شناخته میشوند.
- منابع از طریق HTTP اداره میشوند.
- معاهدات به صورت ضمنی در نمایش منابع میباشند.
- رابطها بطور کلی عام هستند.
- ساده سازی توسعه پذیری، مقیاس پذیری
- کاهش زمان توسعه ویژگیهای جدید
- کاهش زمان مهندسی مورد نیاز برای یکپارچه سازی
- سازنده فرصتهایی جدید برای mash-ups و دیگر داستانهای غیرقابل پیش بینی کاربری
- اما وضعیت ارتباطی کلاینتها و سرورها در WOA چگونه است ؟
- سرویسها وابسته به دیگر سرویسها هستند.
- ارتباطات از طریق HTTP صورت میگیرد.
- کلاینتها حکم منبع و سرویس دهی به دیگر کلاینتها را دارند.
- مقیاس پذیری ، توسعه پذیری == اتصالات داخی
بعنوان مثال میتوان با ترکیب تصاویر و آدرسهای مختلف دانشگاههای تهران، یک 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 دارای 2 سبک است : الف) مبتنی بر وب – ب) مبتنی بر سرور
در ادامه با هم نمونه ای از استقرار معماری وب گرا 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 است.
Unit Test Generator v1.3 منتشر شد
الگوی استراتژی - Strategy Pattern
NOSQL قسمت اول
با فراگیر شدن اینترنت در سالهای اخیر و افزایش کاربران ، سیستمهای RDBMS جوابگوی نیازهای برنامهنویسان در حوزهی وب نبودند زیرا نیاز به نگهداری دادهها با حجم بالا و سرعت خواندن و نوشتن بالا از جمله نقط ضعف سیستمهای RDBMS میباشد ، چرا که با افزایش شدید کاربران دادهها اصولا به صورت منطقی ساختار یکدست خود را جهت نگهداری از دست میدهند و به این ترتیب عملیات نرمال سازی منجر به ساخت جداول زیادی میشود که نتیجه آن برای هر کوئری عملیات Joinهای متعدد میباشد که سرعت خواندن و نوشتن را به خصوص برای برنامههای با گسترهی وب پایین میآورد و مشکلات دیگری در سیستمهای RDBMS که ویژگیهای سیستمهای NoSql مشخص کننده آن مشکلات است که در ادامه به آن میپردازیم.
طبق تعریف کلی پایگاه داده NOSql عبارت است از:
نسل بعدی پایگاه داده (نسل از بعد RDBMS ) که اصولا دارای چند ویژگی زیر باشد:
۱- دادهها در این سیستم به صورت رابطهای (جدولی) نمیباشند
۲-دادهها به صورت توزیع شده نگهداری میشوند.
۳-سیستم نرمافزاری متن باز میباشد.
۴-پایگاه داده مقیاس پذیر به صورت افقی میباشد(در مطالب بعدی توضیح داده خواهد شد.)
همانگونه که گفته شد این نوع پایگاه داده به منظور رفع نیازهای برنامههای با حجم ورود و خروج داده بسیار بالا (برنامههای مدرن وب فعلی) ایجاد شدند.
شروع کار پیادهسازی این سیستمها در اوایل سال ۲۰۰۹ شکل گرفت و با سرعت زیادی رشد کرد و همچنین ویژگیهای کلی دیگری نیز به این نوع سیستم اضافه شد.
که این ویژگیها عبارتند از:
- Schema-free
: بدون شَما ! ، با توجه به برنامههای وبی فعلی ممکن است شمای نگهداری
دادهها ( ساختار کلی ) مرتبا و یا گهگاهی تغییر کند. لذا در این سیستمها
اصولا دادهها بدون شمای اولیه طراحی و ذخیره میشوند. ( به عنوان مثال
میتوان در یک سیستم که مشخصات کاربران وارد سیستم میشود برای یک کاربر یک
سری اطلاعات اضافی و برای کاربری دیگر از ورود اطلاعات اضافی صرفنظر کرد ،
و در مقایسه با RDBMS به این ترتیب از ورود مقادیر Null و یا پیوندهای
بیمورد جلوگیری کرد.
کنترل اطلاعات الزامی توسط لایه سرویس برنامه انجام میشود. ( در زبان جاوا توسط jsr-303 و یاBean Validation ها) - easy replication support : در این سیستم ، نحوهی گرفتن نسخههای پشتیبان و sync بودن نسخههای مختلف بسیار ساده و سر راست میباشد و سرور پایگاه داده به محض عدم توانایی خواندن و یا نوشتن از روی دیسک سراغ نسخهی پشتیبان میرود و آن نسخه را به عنوان نسخهی اصلی در نظر میگیرد.
- Simple API : به دلیل متنباز بودن و فعال بودن Community این سیستمها APIهای ساده و بهینهای برای اکثر زبانهای برنامهنویس محبوب ایجاد شده است که در پستهای بعدی با ارائه مثال آنها را بررسی خواهیم کرد.
- eventually consistent : در سیستمهای RDBMS که دادهها خاصیت ACID را ( در قالب Transaction) پیاده میکنند ، در این سیستمهای دادهها در وضعیت BASE قرار دارند که سرنام کلمات Basically Available ، Soft State ، Eventual Consistency میباشد.
- huge amount of data: این سیستمها به منظور کار با دادههای با حجم بالا ایجاد شدهاند ، یک تعریف کلی میگوید اگر مقدار دادههای نگهداری شده در پایگاههای داده برنامه شما ظرفیتی کمتر از یک ترابایت داده دارد از پایگاه داده RDBMS استفاده کنید واگر ظرفیت آن از واحد ترابایت فراتر میرود از سیستمهای NOSql استفاده کنید.
جهت پیاده سازی پایگاه داده با این سیستمها تا حدودی نگرش کلی به دادهها و نحوهی چیدمان آنها تغییر میکند ، به صورت کلی مباحث مربوط به normalization و de-normalization و تصور دادهها به صورت جدولی کنار میرود.
سیستم NoSql به جهت دستهبندی نحوهی ذخیرهسازی دادهها و ارتباط بین آنها به ۴ دسته کلی تقسیم میشود که معرفی کلی آن دستهبندیها موضوع مطلب بعدی میباشد.
خیر نیازی به استفاده از SPA frameworks در آینده نمیبینم
Razor Components به نظر امکان خوبی نیست و نمیتواند جایگزین مناسبی برای SPA frameworks باشد