1) تکنولوژی توسعهی نرم‌افزار (Software Development Technology)تکنولوژی توسعهی نرم‌افزار انتخاب شده برای توسعهی نرم‌افزارهای شرکت، .NET می‌باشد. مرکز تحقیقاتی Forrester Research از 878 مدیر IT در شرکت‌های بزرگ آمریکایی در زمینه‌ی تکنولوژی توسعهی نرم‌افزار تحقیق کرده است. 48% این شرکت‌ها بین 1000 تا 4999 کارمند و 52% آن‌ها بیش از 5000 کارمند دارند. این تحقیقات نشان می‌دهد که تکنولوژی .NET به تنهایی، انتخاب 56% از این شرکت‌ها به عنوان پلت‌فرم توسعه بوده است.
در تحقیقات دیگری که در سال 2005 توسط موسسه‌ی معتبر IDC(Analyze the Future) در میان بیش از 1700 نفر از مدیران IT، توسعه‌دهندگان و معماران برنامه‌ها در آسیا، اروپا و آمریکا صورت گرفت، .NET به تنهایی 35.7% پلت‌فرم توسعهی نرم‌افزاری شرکت‌ها در این قاره‌ها را تشکیل می‌دهد.
سیستم‌عامل‌هایی که .NET از آن‌ها پشتیبانی می‌کند عبارت‌اند از:
· Linux.
· Mac OS X.
· Sun Solaris.
· BSD: OpenBSD, FreeBSD, NetBSD.
· Microsoft Windows.
پردازنده‌هایی که .NET از آن پشتیبانی می‌کند عبارت‌اند از:
|
معماری پردازنده
|
Runtime
|
سیستم عامل
|
|
s390, s390x (31 and 64 bits)
|
JIT
|
Linux
|
|
SPARC (32 and 64 bits)
|
JIT
|
Solaris, Linux
|
|
PowerPC
|
JIT
|
Linux, Mac OSX
|
|
x86
|
JIT
|
Linux, FreeBSD, OpenBSD, NetBSD,
Microsoft Windows, Solaris
|
|
x86-64: AMD64 and EM64T (64 bit)
|
JIT
|
Linux
|
|
IA64 Itanium2 (64 bit)
|
JIT
|
Linux
|
|
ARM: little and big endian
|
JIT
|
Linux
|
|
HP-PA
|
Interpreter
|
HP-UX
|
همان‌طور که در جدول فوق مشاهده میشود، می‌توان از .NET Runtime توسط پردازنده‌هایی با معماری‌های 64بیتی نیز بهره‌برداری کرد.
در برنامه به صورت کامل از تکنولوژی .NET Enterprise Services استفاده میشود. .NET Enterprise Services روشی برای استفاده از سرویس‌های COM+ می‌باشد و در سطح گسترده‌ای در دنیا استفاده میشود.
به منظور امکان استفاده‌ی مجدد از کامپوننت‌ها (reuse) و مقیاس‌پذیری (scalability)، عملکرد برنامه (functionality) مطابق لایه‌های نشان‌داده شده تفکیک میشود:
Presentation Services.
نقش لایه‌ی presentation ارائه‌ی واسط کاربر (UI) است. به‌وسیله‌ی تکنولوژی .NET می‌توانیم سرویس‌های presentation را ارائه کنیم که به صورت rich client (مانند برنامه‌های دسک‌تاپ) یا thin client (مانند برنامه‌های وب) باشند.
Business Services.
به‌جای آوردن business logic به همراه UI در برنامه، آن‌ها را در کلاس‌های جداگانه‌ای قرار می‌دهیم. قراردادن این کلاس‌ها در اسمبلی‌های جداگانه امکان استفاده مجدد از business logic توسط قسمت‌های دیگر برنامه و یا حتی توسط برنامه‌های دیگر را فراهم می‌کند.
Data Services.
کامپوننت‌های data service که توسط .NET نوشته می‌شوند را می‌توان مشابه کامپوننت‌های business service توسط قسمت‌های دیگر برنامه یا برنامه‌های دیگر مورد استفاده قرار داد. این کامپوننت‌ها همچنین بهره‌برداری مؤثری از enterprise serveices می‌کنند (برای مثال از automatic transaction).
با تفکیک لایه‌های برنامه به سه سرویس ذکر شده مزایای زیر فراهم میشود:
· با ایجاد کامپوننت‌های مجزا برای UI، business و data، برنامه می‌تواند در مقیاس صدهاهزار کاربر مورد بهره‌برداری قرار گیرد، چرا که با توجه به معماری distributed برنامه، می‌توان این کامپوننت‌ها را در کامپیوترهای جداگانه‌ای به صورت موازی مورد بهره‌برداری قرار داد.
· در صورت تغییر business logic، کافی‌است تا سرور (سرورهایی) که کامپوننت‌های مربوط به این سرویس بر روی آن نصب شده‌اند را به‌روز کرد.
· به آسانی می‌توان تحت شرایط مورد نیاز، UI دسک‌تاپ را جای‌گزین UI وب کرد و یا به‌طور هم‌زمان از هر دو interface بهره‌برداری کرد.
· نیازی به نصب و تنظیم راه‌انداز‌های مربوط به database در client ها نیست.
· می‌توان اتصالات به database را در میان چندین کاربر share کرد، چرا که این connection ها مستقیماً از client ها صورت نمی‌گیرد، بلکه از طریق middle-tier server انجام میشود.
· می‌توان برنامه را طوری تقسیم (partition) کرد که با توجه به سرعت پایین connection در برخی نقاط دنیا، آن‌ها هم بتوانند به راحتی از آن استفاده کنند.
· امکان این وجود دارد که در صورت نیاز کارفرما، از تکنولوژی‌های message queuing استفاده کرد تا بتوان از برنامه به صورت disconnected هم بهره‌برداری کرد.
2) مدل معماری نرم‌افزار (Application Architecture)
مدل معماری برنامه، برنامه‌نویسی توزیع‌شده (Component-based) و سرویس‌گرا (Service Oriented) است.
از نگاه کلی، برنامه‌نویسی توزیع شده به مجموعه ای از کامپوننت‌های فیزیکی مجزا اشاره دارد که مجموعاً به‌عنوان یک سیستم واحد عمل می‌کنند. در اینجا منظور از «کامپوننت‌های فیزیکی مجزا»، چندین پردازنده (CPU)، یا حتی چندین کامپیوتر در شبکه است. فرض برنامه‌نویسی توزیع شده بر این عبارت ساده استوار است که: اگر یک کامپیوتر می‌تواند عملیاتی را در 5 ثانیه انجام دهد، 5 کامپیوتر می‌توانند با عملکرد موازی آن عملیات را در یک ثانیه تمام کنند.
البته موضوع به این سادگی نیست. مشکل «عملکرد موازی» است. عملکرد موازی و مؤثر چندین کامپیوتر باهم در یک شبکه کار بسیار پیچیده‌ای است. در حقیقت نرم‌افزاری که می‌خواهد در این محیط کار کند، می‌بایست به‌طور خاص برای این منظور طراحی گردد. برای تقریب ذهن مثالی می‌زنیم. یک اسب حیوان قدرت‌مندی است، اما از منظر نسبت «وزن به قدرت»، یک مورچه بسیار قوی‌تر از یک اسب است (تقریباً 10 برابر). بنابراین اگر ما بتوانیم به تعداد زیادی مورچه که هم‌وزن یک اسب شوند افسار بزنیم، می‌توانیم باری معادل 10 برابر باری را که یک اسب تحمل می‌کند، حمل نماییم. یک مثال خوب از بار توزیع شده! گرچه محاسبات منطقی به‌نظر می‌رسند، اما تصور لشگری از مورچگان افساربسته حقیقتاً پیچیده است و نیاز به هماهنگی فوق‌العاده مشکلی دارد.
همان‌طور که در مثال مقایسه‌ی اسب و مورچه دیدیم، عملیات توزیع شده، نیاز به هماهنگی کامل چندین کامپیوتر دارد. همچنین مستلزم آن است که عملکرد برنامه نیز به واحدهای جزئی‌تری تقسیم شود که همان لایه‌بندی منطقی برنامه به سه‌بخش منطقی اصلی است:
· Presentation logic: بخشی از برنامه است که کاربران با آن سر و کار دارند و می‌توانند اطلاعاتی را وارد کنند، جستجو کنند و گزارش‌ها را دریافت نمایند.
· Business logic: قلب برنامه به حساب می‌آید و بیش‌تر وقت توسعه‌دهندگان نرم‌افزار را به خود اختصاص می‌دهد. این بخش شامل business rules است که مشخص می‌کند برنامه چگونه عمل می‌کند.
· Data source logic: در این بخش اطلاعات برنامه ذخیره میشود. نرم‌افزارهای مدیریت بانک‌های اطلاعاتی قدرت‌مندی چون DB2، Oracle و SQL-Server برای این‌منظور می‌توانند مورد استفاده قرار گیرند.
اولین ملاحظه‌ی طراحی یک برنامه کارا، می‌بایست تقسیم این اجزاء منطقی به لایه‌های مجزا باشد. به عبارت دیگر نباید کدهای Business logic با کدهای Presentation logic مخلوط شود. این موضوع لزوماً به معنی آن نیست که این لایه‌ها باید در ماشین های مجزا یا در پردازش‌های مستقل اجرا شود؛ بلکه باید ارتباط یک لایه با لایه‌ی دیگر منحصرا از طریق یک interface صورت پذیرد. عموما این لایه‌ها به صورت فیزیکی در قالب DLLهای مجزا قرار می‌گیرند.
لایه‌بندی به ما اجازه می‌دهد تا پیاده‌سازی (implementation) یک لایه را بدون تأثیر بر لایه‌ی دیگر تغییر دهیم. همچنین ممکن است این امکان را فراهم کند که بتوان در آینده لایه‌ها را به صورت فیزیکی جدا کرد و در کامپیوترهای مستقل قرار داد. با این‌وجود تصمیم برای جداسازی فیزیکی لایه‌ها در ماشین‌ها یا پردازش‌های مستقل و موازی ساده نیست. اگر بخواهیم این لایه‌ها را در ماشین‌ها یا پردازش‌های مجزا توزیع کنیم، باید آن را از ابتدا برای این منظور طراحی کنیم. به این معنی است که لایه‌بندی یک برنامه، ارتباطی با امکان توزیع‌کردن آن ندارد و یک برنامه‌ی 3 لایه را نمی‌توان توزیع‌شده دانست.
هدف معماری برنامه‌ی توزیع‌شده (distributed application architecture) افزایش کارایی (performance) و مقیاس‌پذیری (scalability) برنامه است.
دلایل دیگر انتخاب معماری توزیع شده عبارت‌اند از:
· مجتمع کردن کدهایی که در محیط‌های مختلف، سیستم‌های عامل مختلف و سکوهای مختلف (platforms) اجرا می‌شوند.
· فراهم کردن هم‌زمانی (synchronization) و ارتباط زنده (live communication) بین کلاینت‌های متعدد (برای مثال، با یک chat server).
· پشتیبانی از thin clients ، که قدرت پردازش ناکافی جهت دریافت اطلاعات مورد نیاز خود دارند.
با این همه، مزیت اساسی معماری توزیع‌شده، مقیاس‌پذیری (scalability) آن است. در این حالت زمانی که به قدرت پردازش بیش‌تری نیاز است، کامپیوترهای جدیدی را می‌توان به مجموعه افزود. پایداری مجموعه نیز در این حالت بهتر است، چرا که با ازدست رفتن یک کامپیوتر، اجرای کل برنامه مختل نمی‌شود.
3) معماری سرویس‌گرا Service Oriented Architecture (SOA)
در گذشته بخش‌های مختلف یک برنامه به صورت مجموعه‌ای از توابع (functions) نوشته می‌شد. استفاده از function ها این امکان را میسر می‌کرد که بتوان از آن‌ها در قسمت‌های دیگر برنامه و یا در برنامه‌های دیگر استفاده کرد، با این وجود برنامه‌ها به تدریج بزرگ‌تر و پیچیده‌تر می‌شدند، بنابراین دیگر نمی‌شد به سادگی فهمید که مثلاً چه تابعی چه سطحی از برنامه را تغییر می‌دهد. برای غلبه بر موانع این نوع توسعهی برنامه، برنامه‌نویسی شیءگرا (object-oriented programming) اختراع شد. در برنامه‌نویسی شیءگرا، object ها شامل توابع (متدها) به همراه data بودند. برنامه‌نویسی شیءگرا مبتنی بر مفاهیمی چون abstraction، encapsulation و inheritance است. با وجود برنامه‌نویسی شیءگرا، برنامه‌ها بازهم پیچیده‌تر می‌شدند، و استفاده‌ی مجدد (reuse) از بخش‌های مختلف یک برنامه هنوز هم به آن سادگی که انتظار می‌رفت میسر نبود. برنامه‌های جدید تنها یک سیستم را اجرا نمی‌کنند، بلکه به اطلاعاتی نیاز دارند که توسط برنامه‌های دیگری فراهم میشود که ممکن است در سازمان‌های مختلفی وجود داشته باشند. معماری SOA، مرحله‌ی تازه‌ای از برنامه‌نویسی بود که بر مبنای web service توسعه یافت.
قلب SOA، یک web service است. بر اساس SOA، یک لایه‌ی سرویس بین client و business objects افزوده میشود. این لایه‌ی service، درحقیقت مرزی است که client(consumer) را از business objects جدا می‌کند. این لایه قراردادی (contract) را مشخص می‌کند که بر اساس آن consumer از آن service، عملکردی را دریافت می‌کند. service نحوه‌ی انتقال اطلاعات را کنترل کرده و اجازه‌ی دسترسی مستقیم به آن اطلاعات را سلب می‌کند.
تنها راه بهره‌برداری از service، ارسال message است. Messageها با فرمت SOAP فرستاده می‌شوند. این موضوع باعث میشود که message ها به platform وابستگی نداشته باشند. اعتبار messageهایی که به service فرستاده می‌شوند، در برابر security policies و business rules مورد بررسی قرار می‌گیرد. استفاده از messageها به جای فراخوانی متدها سبب میشود که معماری برنامه مستقل از تکنولوژی و ملاحظات مربوط به versioning درخصوص business logic باشد.
consumer می‌تواند از یک agent برای دسترسی آسان‌تر به سرویس استفاده نماید. چرا که agent ، مجموعه‌ی business rule های service را می‌شناسد و می‌تواند مثلاً اطلاعات را cache کرده و وضعیت session را حفظ کند.
4) لایه‌بندی نرم‌افزار (Application Layers)
لایه‌بندی نرم‌افزار 3-tier است و در بخش 2-1، 2-2 و 2-4 مفصلاً به آن اشاره شده است. با توجه به معماری SOA برنامه، یک لایه‌ی منطقی جدید Web service نیز به لایه‌های منطقی Presentation، Business و Data اضافه میشود. این 4 لایه‌ی منطقی با توجه به معماری Distributed برنامه، به صورت فیزیکی در n لایه توزیع می‌شوند. تعداد لایه‌های فیزیکی محدودیت ندارد و با عنایت به قابلیت scaling out برنامه، توسعه‌پذیر است و با افزایش نرخ کاربران سایت افزایش می‌یابد.
2-6) طرح توسعهی کمّی نرم‌افزار (Application Scale Out)
با توجه به این که معماری نرم‌افزار طراحی شده در پروژه، توزیع‌شده (distributed) است، قابلیت مقیاس‌پذیری کمّی (scale out) را خواهد داشت.
گرچه در نگاه اول به نظر می‌رسد که مقیاس‌پذیری (scalability) به کارایی (performance) برنامه ارتباط دارد، این دو با یکدیگر تفاوت دارند. «کارایی» به میزان سرعت سیستم اشاره دارد و «مقیاس‌پذیری» مشخص می‌کند که «کارایی« سیستم هنگامی که منابع آن مانند پردازنده‌ها، حافظه، و کامپیوترهای دیگر اضافه میشود، چقدر بهبود می‌یابد.
دو نوع scaling وجود دارد:
· Vertical scaling (scaling up). وقتی اتفاق می‌افتد که سخت‌افزار کندتر را با سخت‌افزار جدیدتر و سریع‌تری تعویض می‌کنید. برای مثال ارتقای یک پنتیوم 1GHz به یک پنتیوم 2.8GHz. طبیعتاً این نوع scaling محدودیت دارد و علاوه بر هزینه‌ی زیاد، وابسته به فن‌آوری روز بازار است.
· Horizontal scaling (scaling out). وقتی اتفاق می‌افتد که به منظور load balancing یک سرور جدید به مجموعه‌ی کامپیوترها اضافه شود. در این صورت ضمن حفظ سرمایه‌ی سرورهای موجود، امکان fail شدن برنامه در صورت fail شدن یکی از سرورها منتفی میشود. آشکار است که این روش علاوه بر ارزان‌تر بودن، محدودیت روش scaling up را هم ندارد.
مزیت برنامه‌ی توزیع شده طرح ما این است که امکان مقیاس‌پذیری را از طریق scaling out فراهم می‌کند. اساساً برخی از تکنولوژی‌های توسعهی برنامه‌های تحت وب، امکان scaling out را ندارند.
جداسازی لایه‌های برنامه به چندین لایه‌ی منطقی، الزامی را برای تفکیک فیزیکی و استفاده از چندین سیستم سخت‌افزاری ایجاد نمی‌کند و لایه‌های منطقی کاملاً مستقل از توسعهی فیزیکی سیستم هستند. در محیط‌هایی که کاربران اندکی دارند، برنامه‌های .NET Enterprise Services را به همراه database می‌توان در یک کامپیوتر مورد بهره‌برداری قرار داد.
با افزایش تعداد کاربران برنامه، دیگر نمی‌توان از scale up بهره برد، اما در سیستم طراحی‌شده‌ی ما، می‌توان به سهولت از scale out با افزودن به کامپیوترها استفاده کرد. نه تنها این قابلیت وجود دارد که database را از سیستمی که .NET Enterprise Services بر روی آن اجرا میشود، جدا کرد، بلکه می‌توان .NET Enterprise Services را نیز بر روی چندین سرور تفکیک کرد:
NET Enterprise Services را می‌توان حقیقتاً برای توسعهی نامحدود پروژه scale out کرد. توسط برنامه‌های تحت وب ASP.NET، می‌توانیم چندین web server را برای network load balancing(NLB) مورد بهره‌برداری قرار دهیم. در عین حال برنامه‌های ASP.NET می‌تواند از business components که در طراحی ما بر روی چندین سیستم توزیع شده است، به عنوان component load balancing(CLB) استفاده نماید. از طریق این کامپوننت‌هاست که DB2 در دسترس قرار خواهد گرفت. با بهره‌برداری از DB2 این امکان فراهم می‌آید که از cluster services بهره‌برداری نمود. در این حالت در صورتی که یکی از data server ها fail شود، اجرای برنامه متوقف نخواهد شد.
5) امنیت نرم‌افزار (Application Security)
طرح امنیت برنامه شامل موارد زیر است:
· Evidence-based Security. این خصوصیت مجوزی را که به کد برنامه اعطا میشود، بر مبنای اطلاعاتی که از آن جمع‌آوری میشود، مشخص می‌کند. CLR اطلاعاتی را که درباره‌ی یک assembly دارد، بررسی کرده و مجوزهایی را که باید به کد برنامه اعطا شود برمبنای آن مشخص می‌کند.
· Code Access Security. CLR از این خصوصیت استفاده کرده و مشخص می‌کند که آیا برنامه‌های موجود در stack مجوز استفاده از یک منبع خاص یا انجام یک عمل خاص را دارند یا خیر.
· Defined Verification Process. قبل از آنکه کامپایلر فایل باینری MSIL را بپذیرد، این قسمت کد assembly را برای کنترل type safety و دیگر موارد خطا چک می‌کند. این پروسه‌ی کنترل تضمین می‌نماید که کد برنامه حاوی اشکالاتی نیست که مانع اجرای آن شوند. همچنین مشخص می‌کند که یک عامل خارجی کد برنامه را تغییر داده است یا نه. پس از این کنترل‌هاس که JIT کد MSIL را به زبان ماشین کامپایل می‌کند.
· Role-based Security. به‌جای تعیین سطوح امنیتی برای افراد یا گروه‌ها، سطوح امنیتی به عملکرد (task) منتسب می‌شوند.گرچه Role-based security هنوز هم فرد یا گروه را از روی logon آن‌ها شناسایی می‌کند. مزیت این روش آن است که شما می‌توانید role کاربر را از سیستم پرسیده و بر مبنای آن اختیارات کاربر را در اجرای عمل‌کرد‌های مختلف برنامه مشخص و محدود کنید.
· Cryptography. مزایای رمزنگاری (cryptography) متعدد است. گرچه مفهوم آن بسیار ساده و ملموس است: اطلاعات توسط یک الگوریتم و یک کلید رمزنگاری و غیرقابل خواندن می‌شوند. زمانی که مؤلف اطلاعات آن کلید را با الگوریتم مخصوص دیگری ترکیب کند، اطلاعات اصلی بازگردانده میشود. در طول سالیان گذشته با توجه به افزایش قدرت پردازش رایانه‌ها، برخی تکنیک‌های رمزنگاری از رده خارج شده است. با این وجود .NET از آخرین تکنیک‌های مطمئن رمزنگاری پشتیبانی می‌کند که امنیت اطلاعات را تضمین می‌کند.
· Separate Application Domains. می‌توان کدهای .NET را به نحوی نوشت که قسمت‌های مختلف آن در حوزه‌های جداگانه اجرا شوند. این یک مفهوم COM-type است که بخشی از کد برنامه را از بخش دیگر ایزوله کرد. این خصوصیت امکان این را فراهم می‌سازد که بخشی از کد برنامه را با سطح امنیتی متفاوت در یک حوزه (domain) متفاوت اجرا کرد.
6) Application and Data Reliability
با توجه به موارد ذکر شده در طرح امنیت نرم‌افزار در بند «2-7» و معماری نرم‌افزار «2-4» اعتماد‌پذیری نرم‌افزار تضمین‌شده خواهد بود.
درخصوص اعتماد‌پذیری بانک اطلاعاتی، تمامی فرآیندهای ثبت، تغییرات و حذف اطلاعات از جداول اطلاعاتی در بلوک‌های محافظت‌شده توسط Transaction های موتور بانک اطلاعاتی (MICROSOFT SQL SERVER 2005) انجام خواهد شد. بدین ترتیب تضمین خواهد شد که در بدترین شرایط کاری، اطلاعات موجود در جداول اطلاعاتی برنامه، آسیبی نخواهند دید. به علاوه تمامی عملیات بر روی data های جداول اطلاعاتی در database، log میشود.
برای غلبه بر disk errors از یک سیستم RAID بهره‌برداری میشود که از روش‌های کپی‌برداری اتوماتیک اطلاعات جهت مواقعی که disk failure رخ می‌دهد، استفاده می‌کند.
برنامه بر مبنای service-oriented architecture توسعه می‌یابد. قلب SOA، یک web service است. بر اساس SOA، یک لایه‌ی سرویس بین client و business objects افزوده میشود. این لایه‌ی service، درحقیقت مرزی است که client(consumer) را از business objects جدا می‌سازد. این لایه قراردادی (contract) را مشخص می‌سازد که بر اساس آن consumer از آن service، عملکردی را دریافت می‌کند. service نحوه‌ی انتقال این اطلاعات را کنترل می‌نماید و اجازه‌ی دسترسی مستقیم به اطلاعات را سلب می‌نماید.
تنها راه بهره‌برداری از service، ارسال message است. Messageها با فرمت SOAP فرستاده می‌شوند. این موضوع سبب میشود که message ها به platform وابستگی نداشته باشند. اعتبار messageهایی که به service فرستاده می‌شوند، در برابر security policies و business rules مورد بررسی قرار می‌گیرد. استفاده از messageها به جای فراخوانی متدها سبب میشود که معماری برنامه مستقل از تکنولوژی و ملاحظات مربوط به versioning درخصوص business logic باشد.
توسط پروسه ی Defined Verification Process، قبل از آنکه کامپایلر فایل باینری MSIL را بپذیرد، این قسمت کد assembly را برای کنترل type safety و دیگر موارد خطا چک می‌کند. این پروسه‌ی کنترل تضمین می‌نماید که کد برنامه حاوی اشکالاتی نیسست که مانع اجرای آن شوند. همچنین مشخص می‌سازد که یک عامل خارجی کد برنامه را تغییر داده است یا نه. پس از این کنترل‌هاس که JIT کد MSIL را به زبان ماشین کامپایل می‌کند.
درخصوص دسترسی کاربران به برنامه، سطوح دسترسی تمامی کاربران به بخش‌های مختلف برنامه توسط administrator برنامه مشخص میگردد و هرکاربر تنها اختیاراتی را خواهد داشت که برای وی تعیین شده است.
7) طرح سامانه‌ی گزارش‌گیری پویا (Reporting Service)
علاوه بر گزارش‌های طراحی شده‌ی مورد نیاز در برنامه، امکان طراحی گزارش با استفاده از طراحی و پیاده‌سازی یک برنامه‌ی مولد گزارش (report generator) برای کاربران میسر میگردد. با استفاده از این مولد گزارش، کاربرانی که مجوز طراحی گزارش برای آنان توسط administrator لحاظ گردیده است، می‌توانند گزارش‌های دلخواه خود را بر روی سایت طراحی و ذخیره نمایند. این گزارش‌ها تا زمانی که توسط کاربرانی که مجوز مربوطه را دارند، حذف نشده باشد قابل اجرا خواهد بود. سیستم مولد گزارش در حقیقت دارای یک هسته‌ی query builder بوده که با UI مناسب در دسترس کاربر قرار می‌گیرد و کاربر می‌تواند queryهای دلخواه خود را بر روی DB2 اجرا نموده و نتایج آن را دریافت نماید. به‌علاوه امکان چاپ این گزارش‌ها نیز برای کاربر مهیا میگردد.
8) تهیه‌ی نسخه‌های پشتیبان به صورت خودکار
با توجه به قابلیت scheduling انعطاف‌پذیر MICROSOFT SQL SERVER 2005، امکان ایجاد برنامه‌های زمان‌بندی تهیه‌ی نسخه‌های پشتیبان از جداول اطلاعاتی توسط administrator یا کاربرانی که مجوز تعیین این برنامه‌ی زمان‌بندی را داشته باشند، از طریق فضای خود سایت فراهم میگردد.
برای غلبه بر disk errors از یک سیستم RAID بهره‌برداری میشود که از روش‌های کپی‌برداری اتوماتیک اطلاعات جهت مواقعی که disk failure رخ می‌دهد، استفاده می‌نماید.
9) امکان ثبت کلیه‌ی عملیات بر روی اطلاعات (auditing data)
کلیه‌ی عملیاتی که برروی داده‌های بانک اطلاعاتی در طی تمامی فرآیندهای برنامه توسط همه‌ی کاربران انجام میگردد، توسط مجموعه‌ای از trigger ها در database، ثبت و log میگردد. این ثبت شامل همه‌ی اطلاعات لازم در خصوص افزودن، تغییر یا حذف اطلاعات جداول اطلاعاتی database به علاوه‌ی مشخصات کاربری که عملیات را انجام داده می‌باشد. علاوه بر این مشخصات client و ISP سرویس‌دهنده و کاربرانی که از طریق شبکه‌ی اینترنت از برنامه استفاده کرده‌اند و زمان و مکان اتصال به برنامه و صفحه‌ای که از آن به برنامه redirect شده‌اند و تعداد کاربران و ...، در جداول اطلاعاتی برنامه ذخیره میگردد. کاربرانی که مجوز مربوطه را دارند می‌توانند از تمامی این اطلاعات گزارش بگیرند؛ گزارش‌های مخصوصی که برای این منظور در برنامه طراحی میگردد.
10) امکان ارتباط و استخراج اطلاعات از نرم‌افزار طراحی شده توسط برنامه‌های دیگر
اساساً مزیت کلیدی برنامه که به صورت service oriented طراحی میشود، این است که می‌تواند بدون آن که اجازه‌ی مستقیم دسترسی به اطلاعات برنامه را به برنامه‌های دیگر بدهد، آن اطلاعات را در غالب مجموعه‌ای از serviceها در دسترس برنامه‌های دیگر قرار دهد. تنها راه بهره‌برداری از service، ارسال message است. Messageها با فرمت SOAP فرستاده می‌شوند. این موضوع سبب میشود که message ها به platform وابستگی نداشته باشند. اعتبار messageهایی که به service فرستاده می‌شوند، در برابر security policies و business rules مورد بررسی قرار می‌گیرد. بدین ترتیب سیستمی فراهم می‌آید که برنامه‌ها و سایت‌های دیگر بدون آنکه درگیر ساختارهای database و چگونگی دستیابی به آن را داشته باشند، از مجموعه‌ی اطلاعات آن سرویس بگیرند. این سرویس می‌تواند مثلاً آمار خاصی باشد که در سایت یکی از مناقصه‌گران نمایش داده میشود، در حالی که آن گزارش به صورت یک service از برنامه‌ی ما درخواست شده است. برای اطلاعات تکمیلی‌تر به بخش معماری سرویس‌گرا Service Oriented Architecture (SOA) مراجعه نمایید.