بررسی دی‌ان‌ان و ملاحظات استفاده از آن در سازمان‌ها
بازبینی دات‌نت‌نیوک: اشکالات قبلی و اصلاحات انجام‌شده در نسخه‌های جدید
یادداشت
{ این مطلب در مورد مقایسه بسترهای نرم‌افزاری یا توصیه به استفاده/عدم استفاده از آنها نیست؛ بلکه در این مورد بحث می‌شود که اگر تصمیم گرفتیم از این محصول نرم‌افزاری خاص استفاده شود چه ملاحظاتی را باید در نظر داشت تا استفاده بهینه‌تری از آن داشته باشیم. }
مقدمه
تعریف: محصول DotNetNuke یا به اختصار DNN یک پورتال نیست بلکه یک قالب توسعه برنامه‌های کاربردی مبتنی برر وب (Web Application Framework) است که می‌توان از سرویس‌ها و امکانات آن برای ساخت پورتال و دیگر برنامه‌های کاربردی مثل برنامه‌های کاربردی استاندارد ASP.NET تحت وب، سایت‌های اجتماعی، اینترانت و اکسترانت استفاده کرد. در حقیقت DNN یک لایه سرویس روی ASP.NET است که استفاده از آن حجم بسیار زیادی از کدنویسی برای ایجاد یک برنامه کاربردی از سطح صفر را حذف می‌کند. این بررسی اولین بار سال 1387 انجام شد و طی این مدت با بهبود این بستر بسیاری از اشکالات آن برطرف شده است؛ مواردی که مورد بازبینی قرار گرفته، بین دو علامت { } مشخص شده‌اند.
از مهمترین ویژگی‌های آن برای یک کاربر ایرانی و فارسی زبان می‌توان موارد زیر را ذکر کرد:
- سادگی نصب و راه‌اندازی: به سادگی کپی کردن فایل‌ها در مدت چند دقیقه تا چند ساعت (بسته به سرعت آپلود اینترنت)
- سادگی و راحتی ترجمه عناصر موجود در واسط کاربر (ولی نه محتوای آن) به زبان فارسی
اشکالات و نارسایی‌ها
باید توجه داشت که DNN هم مانند هر امکان دیگری دارای مزایا و معایبی هست، هدف ما در اینجا بیان مزایا و معایب آن و مقایسه با محصولات دیگر نیست، بلکه فقط دلایل نامناسب بودن {ملاحظات مربوط به} استفاده از این محصول در سازمان‌های بزرگ دولتی و غیر دولتی را ذکر می‌کنم:
- متن باز (Open Source) رایگان ولی غیر باز: در عمل امکان دسترسی و ایجاد تغییر در هسته‌ی اصلی محصول (به صورت فایل‌های dll) وجود ندارد.
- نوع لیسانس Berkeley Software Distribution (BSD): کاربر می‌تواند بدون هیچ محدودیتی هر نوع تغییری را در متن برنامه‌ها ایجاد کند اما با رعایت شرایط زیر:
- مالکیت معنوی شرکت DotNetNuke و
- مجوز تغییر به شرح فوق در تمامی کپی‌های محصول و یا اجزاء آن ذکر شود.
- محصول به صورت " همین طور که هست (AS IS)" ارائه می‌شود و هیچ‌گونه مسئولیتی در قبال هیچ‌گونه مشکل و یا خسارتی مستقیم یا غیرمستقیم وجود نخواهد داشت.
- عدم پشتیبانی استاندارد و رسمی از تقویم و تاریخ فارسی
- عدم امکان ترجمه پویای محتوا
برای پشتیبانی از چند زبان مجبور به ایجاد چند سایت مستقل هستید، هماهنگی بین این سایت‌ها به صورت سیستمی و خودکار انجام نمی‌شود بلکه باید به صورت دستی توسط کاربر انجام شود. {در نسخه‌های جدید و ماژول‌های استاندارد آن این مشکل برطرف شده، برای ماژول‌های افزودنی نیز توسعه‌دهندگان آنها به تدریج راهکار توسعه زبان را در آنها برقرار می‌کنند}
- عدم پشتیبانی از استانداردهای برنامه‌نویسی محیط تولید (مثل ObjectDataSource و استفاده از آنها در ویزاردها) هزینه‌های (زمان و حجم برنامه‌نویسی و اشکال‌یابی) را افزایش می‌دهد. {علت اصلی این اشکال، استفاده از عبارت پیشوند در نام‌گذاری اشیاء پایگاه داده مثل جداول، توابع، و... با استفاده از پارامتر objectQualifier در فایل وب‌کانفیگ سایت بود. از اهداف اصلی استفاده از این پارامتر یکی حفظ امنیت و تغییر نام جداول و... بود؛ یکی هم کاهش هزینه‌های ایجاد یک پایگاه داده برای هر سایت. مورد امنیتی امروز چندان مطرح نیست چرا که اگر فردی موفق به ورود غیرمجاز به سایت شود امکان شناسایی این پیشوند و نام جداول را هم دارد؛ بنابراین باید راهکارهای دیگری برای حفظ امنیت سایت اتخاذ شود. هدف صرفه‌جویی نیز امروزه با کاهش هزینه‌های خدمات میزبانی و ایجاد پایگاه داده دیگر مطرح نیست و به راحتی و هزینه کم می‌توان برای هر سایت یک دیتابیس خاص آن ایجاد کرد. همچنین حتی در صورت اصرار بر استفاده از این پیشوند، می‌توان از برنامه‌های پشتیبان که به صورت لفافه یا ورپر (wrapper) برای آن توسعه داده شده استفاده کرد.}
- زمانبر بودن و پیچیدگی برنامه‌نویسی {در قبال چارچوب استانداردی که به دست می‌دهد قابل پذیرش وبا استفاده از ابزارهای کمکی، قابل کاهش دادن است}
- عدم الزام به پشتیبانی: تأخیر زیاد در توسعه‌ی ماژول‌ها و رفع اشکالات آن.
- بروزرسانی‌های پی در پی پلاتفرم اصلی که بعضاً با نسخه‌ها و ماژول‌های قبلی سازگار نیستند. {گام‌های توسعه و ارتقاء پیش‌بینی شده که سازنده و کاربران بر اساس آن اقدام کنند: https://docs.dnncommunity.org/content/getting-started/setup/upgrades/suggested-upgrade-path/index.html بعلاوه اکنون و به‌ویژه پس از بازنویسی بستر و ماژول‌ها از ویژوال بیسیک به زبان سی شارپ تا حدود زیادی به حالت پایدار رسیده است}
- توسعه، رفع اشکال و ارتقاء ماژول‌ها: توسط افراد داوطلب از سراسر جهان و در زمان آزادی که می‌توانند به آن اختصاص دهند انجام می‌شود بنابراین این رویه خیلی کند است و اغلب اوقات به دلیل خروج افراد از تیم طراحی متوقف می‌شود.
- امنیتی
سایت‌های ایجاد شده با DNN به راحتی قابل شناسایی هستند (چه از نظر نوع لیسانس، و چه از نظر نوع آدرس‌دهی و اسامی کنترل‌ها و متغیرها)، در حالی که از نظر امنیتی سعی می‌شود تا جایی که ممکن است از انتشار کمترین اطلاعات در مورد محیط و شیوه پیاده‌سازی آن جلوگیری کرد. {این مورد همواره قابل ملاحظه است، اما همچنین در کنار پشتیبانی و اعتبار سازنده و جامعه پشتیبان می‌توان آن را یک نقطه قوت نیز در نظر گرفت}
- خطاهای امنیتی: بعضاً دیده می‌شود اطلاعات محرمانه مثل اسامی و کلمات عبور بدون هیچ رمزگذاری در یک جدول درج شده‌اند (مثل تنظیمات ایمیل در جدول HostSettings) {این مورد را در نسخه‌های جدید دیگر مشاهده نکردم، کلمات عبور رمزگذاری شده‌اند}.
- پشتیبانی محلی: با وجود گستردگی انجمن‌های مرتبط، اولاً به دلیل غیر حرفه‌ای و غیرتخصصی بودن آنان، و دوم به خاطر مسائل اختصاصی که ممکن است برای کاربران فارسی زبان و داخل ایران اتفاق بیافتد که در نتیجه محدوده‌ی افراد پاسخگو را تنگ‌تر می‌کند نمی‌توان از در دسترس‌پذیری پشتیبانی‌ها اطمینان خاطر داشت.
- ماژول‌های خریداری شده/تهیه شده از دیگران
در مقایسه با دیگر سیستم‌های مدیریت محتوا مثل SharePoint از شرکت‌های پشتیبانی حرفه‌ای بسیار کمتری برخوردار است در حالی که در شمارش، افراد و شرکت‌های بیشتری خدمات DNN را ارائه می‌دهند؛ اکثر ماژول‌های DNN از طریق سایت واسط SnowCovered آن هم ناکامل، بدون بروزرسانی، بدون مستندات و پشتیبانی کافی ارائه می‌شوند. {اکنون سایت فروشگاهی توسعه‌دهنده آن به نشانی https://store.dnnsoftware.com در کنار تعداد بسیار بیشتری توسعه‌دهنده ماژول و تم و اسکین وجود دارد. همچنین نسخه تجاری این محصول با نام ایووک Evoque وجود دارد که سازنده را ملزم و متعهد به پشتیبانی فعال از محصول می‌کند. بعلاوه انتقال DNN به محیط جیت‌هاب و ایجاد انجمن جهانی توسعه محصول این نقص را تا حدود زیادی جبران و در مواردی به نقطه قوت آن تبدیل کرده است. آدرس پلتفرم: https://github.com/dnnsoftware/Dnn.Platform و ماژول‌های توسعه‌ای آن: https://github.com/DNNCommunity }
- افزایش سریع حجم پایگاه داده، کاهش کارایی برنامه
در هر ماژول ممکن است از چند کنترل و چندین زیرکنترل استفاده کرد؛ هر ماژولی هم نیاز به اتصال به پایگاه داده برای واکشی اطلاعات یا ثبت پارامترهایش دارد. در یک سازمان بزرگ و در یک پروژه پیچیده ممکن است از ده‌ها ماژول پیچیده هر کدام شامل چندین کنترل کاربر استفاده کرد که هر کدام از این کنترل‌ها به نوبه خود نیازمند تعامل با پایگاه داده هستند. {این اشکال با کمینه‌سازی ماژول‌ها و اشیای سایت به فقط موارد مورد نیاز و استاندارد و معتبر، همچنین تنظیمات کارایی سایت قابل جبران است}
در یک مورد تجربه شخصی، در حالی که کل اطلاعات ثبت شده توسط من به زحمت به یک مگابایت هم نمی‌رسید، حجم پایگاه داده، اطلاعات کنترلی و لاگ فایل‌های آن تا نزدیک 100MB هم رسید!
- عدم یکپارچگی با سایر محصولات کاربردی مثل: Office {ماژول‌های توسعه‌ای برای این کار وجود دارد یا قابل توسعه است}
- ساختار یا معماری: مناسب برای وب‌سایت‌های غیر پیچیده مثل سایت‌های شخصی و شرکت‌های کوچک و همچنین آموزشی و یا حداکثر برای اینترانت یک سازمان؛ اما نه برای شرکت‌ها و سازمان‌های بزرگ با صدها کارمند
- قابلیت توسعه (Scalability): بدون توجه به تغییرات و پیشرفت‌های سخت‌افزاری، DNN روی فقط یک وب سرور و فقط یک SQL Server نصب می‌شود و نمی‌توان مثلاً Job Server، Index Server، Web frontend و Search Server را روی دستگاه‌های مختلف نصب کرد و از امکان Load Balancing استفاده کرد. {اکنون از استانداردهای جدید و خدمات ابری مثل میکروسافت آزور پشتیبانی می‌کند}
- عدم پشتیبانی از جستجوی سطح سازمانی (Enterprise Search) یا جستجوی همزمان در چند پورتال سازمان. همچنین در یک سازمان بزرگ نیاز است اطلاعات در فرمت‌های مختلف (مثل pdf، doc، excel و ...) در دسترس باشد، dnn به جز امکان جستجو در اطلاعات تنها پایگاه داده تعریف شده برای آن، در این موارد هیچ امکان قابل استفاده‌ای ندارد. این نقص به خصوص در بحث استفاده از فنآوری‌‌های نوین اطلاعاتی مثل مخازن داده و هوش سازمانی و سازمان هوشمند قابل توجه است. {با متن باز امکان توسعه قابلیت جستجوی استاندارد سایت و جایگزینی آن وجود دارد}
- عدم پشتیبانی از Single Sign-on
تعریف: امکان ورود به پورتال‌های مختلف و سایر برنامه‌های کاربردی فقط با یک بار ورود اطلاعات و login کردن.
توضیح: DNN امکان استفاده از سرویس‌های اکتیودایرکتوری را دارد ولی فقط امکان Single User-name (و نه Single Sign-on) را با نواقص و محدودیت‌هایی (به لحاظ تفاوت عملکرد در محیط‌های متفاوت) پشتیبانی می‌کند؛ یعنی برای ورود به هر پورتال، باید اطلاعات شناسایی را مجدداً وارد کرد.
یادداشت: امکان ورود خودکار به پورتال تحت Windows Vista و IIS 7.0 به بعد وجود دارد شاید بتوان از این امکان برای ورود به پورتال‌های مختلف DNN نصب شده در یک دستگاه یکه با مشخصات فوق استفاده کرد.
- تیم‌های کاری و همکاری تیمی، گردش کار: هیچ کدام را به صورت یکپارچه پشتیبانی نمی‌کند و مجبورید ماژول‌های متفاوت را از منابع مختلف تهیه کنید. {پشتیبانی از گردش کار در هسته‌ی بستر و ماژول‌های استاندارد آن تعبیه شده است؛ ماژوهای افزودنی نیز این قابلیت را به تدریج و حسب نیاز در نظر می‌گیرند.}
- امکانات مفید ولی نامناسب: امتیازات و ویژگی‌های مفیدی که در صورت عدم توجه در استفاده از آن می‌تواند مشکل‌آفرین باشد و با توجه به نیازمندی‌های سازمان‌های بزرگ باید از آنها صرف نظر کرد {اغلب اشکالات به علت کاهش هزینه‌های میزبانی و ارتقای این بستردیگر موضوعیت ندارند}:
- چند پورتالی – منشاء بیشتر مشکلات: از مشخصات برجسته‌ی DNN توانایی آن در میزبانی چندین وب‌سایت تحت یک فایل‌سیستم با یک پایگاه داده و در یک نسخه نصب شده‌ی واحد می‌باشد (Single installation – Multiple Portals). این ویژگی برای وب‌سایت‌های شخصی با کیفیت و خدمات معمولی امتیاز بزرگی محسوب می‌شود (برای کاهش هزینه‌های میزبانی، خرید ماژول و ایجاد سایت)، اما به ادارات و سازمان‌های رسمی/تجاری ارائه‌کننده‌ی خدمات اداری/تجاری به ارباب رجوع/مشتریان تجاری، توصیه می‌شود از این قابلیت آن استفاده نکنند. با وجود کاهش هزینه‌ها در چند پورتالی، محصول نهایی بدون قابلیت اعتماد، کارایی بد و غیر قابل توسعه خواهد بود و از همه مهمتر این که امکان ارائه‌ی خدمات مناسب و کامل به مشتریان [به لحاظ امنیتی، کارایی و ...] را از دست می‌دهید. {با کاهش هزینه‌های میزبانی استفاده از این قابلیت مطرح نیست و هر سازمانی می‌تواند منابع خاص خودش را داشته باشد}
- قابلیت اطمینان(Reliability) : پیکربندی نامناسب، ماژول‌های نامناسب و خطاهای کاربری باعث خطاهای مهلک می‌شوند. دو خطا:
- Portal Crashes: این مشکل ناشی از خطای کاربر، داده و یا پیکربندی است و باعث بروز وقفه در فقط یک پورتال از چند پورتال می‌گردد؛ مشکل در اینجاست که نمی‌توان فقط یک پورتال را از نسخ پشتیبان مجموعه چند پورتال بازیابی کرد – تنها راه حل مطمئن بازیابی تمام پورتال‌هاست، در این صورت تمام تغییرات محتوا در سایر پورتال‌ها هم از دست می‌رود. اگر نتوان مشکل را به صورت دستی حل کرد، تنها راه حل ممکن حذف پورتال و ایجاد مجدد آن است. با حذف پورتال یک سری از اطلاعات مربوط به آن به صورت داده‌های رها شده (Orphaned data) در پایگاه داده باقی می‌مانند که خود باعث کاهش بیشتر کارایی آن می‌گردد؛ در نتیجه همچنین حس کار با یک پورتال ناقص شده و ناکارا در کاربران آن القاء می‌گردد.
- Install Crashes: زمانی اتفاق می‌افتد که عملکرد تمامی پورتال‌ها در یک نصب DNN متوقف شوند. این مسئله در صورت بروز مشکل در نصب یک ماژول، اشکال در ارتقاء سایت و یا پیکربندی نامناسب میزبان اتفاق می‌افتد.
مهمترین اثر این مشکل عدم امکان ارائه‌ی خدمات به هیچ یک از مشتریان کل سایت است، اگر سایت ما شامل 100 پورتال باشد باید به 100 مشتری ناراضی پاسخگو باشیم. در صورت بازیابی سایت از نسخه پشتیبان، باید تمامی پورتال‌ها را بازیافت کنیم که باعث از دست رفتن کار کاربران همه‌ی این پورتال‌ها و در نتیجه از دست رفتن اعتبار ما نزد مشتریان می‌گردد. همچنین ناچاریم توضیح دهیم که چگونه اختلال در سایت یکی از مشتریان ما به سایت سایر مشریان سرایت کرده است.
- کارآیی: ایجاد هر پورتال باعث درج تعداد بیشتری رکورد در پایگاه داده می‌گردد. هر پورتال دارای مجموعه‌ای از صفحات، ماژول‌ها، کاربران، نقش‌ها، مجوزها و سایر موارد مخصوص به خودش است. با افزایش تعداد پورتال‌ها، کارایی کوئری‌های ارسالی به پایگاه داده کاهش می‌یابد. به عنوان مثال اگر سایت ما دارای 50 پورتال، هر کدام دارای 50 صفحه باشند، اطلاعات 2500 صفحه در پایگاه داده نگهداری می‌شود. صرف نظر از این که در هر لحظه با کدام پورتال کار می‌کنیم، پایگاه داده باید برای یافتن 50 صفحه مربوط به آن، تمامی 2500 صفحه را مورد بررسی قرار دهد.
- قابلیت توسعه: دو عامل مهم در هر نصب DNN عبارت است از CPU و RAM. در اغلب این سایت‌ها، درخواست برای افزایش فضای میزبانی و پهنای باند وجود دارد و به همین ترتیب زیرساخت سایت نیز باید توانایی ارتقاء این دو عامل را داشته باشد. اگر یک نصب DNN میزبان چندین پورتال باشد و یکی از این پورتال‌ها (مثل بانک اطلاعات سری‌های زمانی اقتصادی) حجم وسیعی از ترافیک سایت را به خود اختصاص دهد، راه حل مناسبی برای جداسازی آن از سایرین وجود ندارد.
- محرمانگی و امنیت (Security and Privacy)
با وجود قابل قبول بودن امنیت DNN، امکان بروز خطا در نمایش قسمت‌های مختلف سایت و یا دسترسی ماژول‌های ایجادی به اطلاعات سایر ماژول‌ها و تمامی پورتال‌ها وجود دارد. در یک نسخه‌ی چند پورتالی سایت، در صورتی که یک مشتری یک نسخه‌ی کپی از اطلاعات اختصاصی خودش را خواسته باشد، قادر نیستید فقط اطلاعات خودش را در اختیارش بگذارید؛ ناچارید اطلاعات تمام سایت شامل داده‌های سایر مشتریان را نیز در اختیارش قرار دهید.
خلاصه و نتیجه‌گیری
استفاده از DNN در ادارات و سازمان‌های بزرگ (مثل بانک‌ها که ارائه‌دهنده‌ی خدمات مختلف آماری به طیف وسیعی از مراجعین هستند و همچنین مسئول اصلی ارائه‌ی خدمات بانکداری الکترونیک در راستای دولت الکترونیک می‌باشند) با توجه به گستردگی نیازمندی‌های آن و محدودیت‌های این محیط اصلاً توصیه نمی‌شود. {در بخش‌های حساس سایت می‌توانند توسعه‌های خاص خود را در نظر بگیرند؛ یا دست‌کم در غیر این موارد، مثل اینترانت سازمانی و سایت اطلاع‌رسانی و... استفاده از این بستر را در نظر بگیرند}.
در حالی که با داشتن مهارت‌ها و دانش‌های ابتدایی، جزئی و پراکنده نزد معدودی از همکاران سازمانی، فاقد برنامه‌های ساختیافته و نیروهای صاحب نظر و خبره در این زمینه‌ها هستیم، قابل پیش‌بینی است که در صورت درخواست مراجع بالاتر به ارائه‌ی این خدمات از بخش‌های مرتبط با فنآوری اطلاعات به عنوان مرجع اصلی ارائه‌ی خدمات فنآوری اطلاعات نخواهند توانست در زمان مناسب، پاسخ مناسبی ارائه کنند (سازمان غیر هوشمند یا بیهوش).
متأسفانه در تولید نرم‌افزار آنقدر از استانداردهای جهانی فاصله گرفته‌ایم که حالا مجبوریم چند درجه نزول را بپذیریم و تولیدات درجه دوم خارجی را ملاک تولیدات جدید خود قرار دهیم و کار مهندسین نرم‌افزار ما مساوی باشد با کدنویسی و ماژول نویسی تحت ابزارهائی مثل DotNetNuke و Joomla و غیره. ای کاش حداقل این کار را خوب انجام دهیم[منبع]؛ از این رو توصیه می‌شود صرفاً به عنوان یک هدف واسط و کوتاه مدت به منظور یکپارچه کردن سیستم‌های مختلف و متفاوت، آموزش همکاران در برنامه‌نویسی استاندارد و ماژولار و آشنایی با این محیط‌ها و همچنین پرورش نیروهای ماهر و تعدد ایشان، با اعمال برخی اصلاحات در شیوه برنامه‌نویسی {و ساختار و مدیریت سازمان و ملاحظات مربوط به مدیریت ریسک} از آن استفاده شود.
یادداشت: این نوشته اولین بار تحت عنوان (بررسی دات نت نیوک و دلایل عدم مناسب بودن آن برای استفاده در سازمان‌های بزرگ) منتشر شد.
سعید، علی‌حسینی
چهارشنبه 17 مهر 1387
بازبینی 10 بهمن 1400
- انباره داده یا Data Warehouse: انباره‌سازی داده فرآیندی است که طی آن داده‌های جدا از هم موجود در منابع متعدد داده‌ای در سازمان که با ابزار و فرمت‌های مختلف ذخیره‌سازی شده‌اند، به صورت یکپارچه و در یک قالب گرد هم جمع‌آوری می‌گردند.
- هوش سازمانی یا Business Intelligence یا هوشمندی کسب و کار: یعنی ارائه‌ی اطلاعات مناسب در زمان مناسب در قالبی مناسب به کاربر مورد نظر برای پشتیبانی از فرآیند تصمیم‌گیری. هوش سازمانی ابزاری جهت تولید دانش در میان انبوهی از داده‌ها و اطلاعات است.