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)
مدل معماري برنامه، برنامهنويسي توزيعشده (Distributed Programming 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 Serveices را به همراه 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) مراجعه نماييد.