۳٫۵٫۳معماری سخت‌افزار برای پشتیبانی همکاری در مکان‌های مختلف، یکسان/ زمان متفاوت

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

این اشکال حمایت از تصمیم‌گیری گروهی برای همکاری در مکان‌های مختلف مناسب است. آن‌ها همچنین در مدیریت داده‌ها و عملکردهای پشتیبانی تحلیلی محدود هستند. به این دلیل، پشتیبانی کامپیوتری به‌عنوان فناوری جدید در حال توسعه است که (با توجه به پهنای باند کافی) می‌تواند قابلیت‌های صوتی و تصویری به همراه مدیریت داده‌ها و پشتیبانی تحلیلی را ارائه دهد؛ در غیر این صورت، در کنفرانس‌های راه دور معمولی در دسترس نیست. اینترنت یک زیرساخت ارتباطی تبلیغ‌شده است که می‌توان روی آن، پشتیبانی رایانه‌ای برای کار مشترکی را توسعه داد. اگرچه در پهنای باند فعلی، زیرساخت اینترنت عمدتاً بلادرنگ قادر به پشتیبانی از ویدیو و صدا نیست، اما قابلیت‌های ارتباطی آن برای پشتیبانی از مدیریت داده و عملکردهای تحلیلی لازم برای فضای تصمیم‌گیری مشترک کافی است.

اگرچه می توان معماری مبتنی بر اینترنت را بدون سرور تصور کرد، اما یک کار عملی راه حل برای اکثر تصمیم های توزیع شده در فضا و زمان سیستم های پشتیبانی شامل معماری سرویس گیرنده-سرور می شوند (شکل ۳٫۱۱).

سرور می‌تواند هر رایانة شخصی پیشرفته یا ایستگاه کاری یونیکس با پشتیبانی سخت‌افزاری داخلی برای اتصال به شبکه باشد. مهم است که سرور از طریق اتصال پرسرعت با سرعت حداقل ۱ مگابیت بر ثانیه به زیرساخت اینترنت متصل شود. مشتریان می‌توانند از طریق خط اختصاصی، اتصال مودم پرسرعت (مانند مودم DSL یا کابلی) یا اتصال بی‌سیم به اینترنت متصل شوند.

۳٫۵٫۴   معماری نرم‌افزار برای پشتیبانی همکاری در مکان‌های مختلف، یکسان/ زمان متفاوت

سه رویکرد وجود دارد که می‌توان هنگام طراحی سیستم پشتیبانی تصمیم فضایی با ابزارهای اینترنتی (وب سرور و مرورگر وب) در نظر گرفت. اول، از دیدگاه نرم‌افزار مشتری (مرورگر وب)، برنامة کاربردی ممکن است به‌عنوان یک اپلت (برنامة کوچک) نوشته‌شده به زبان برنامه‌نویسی جاوا کار کند (جانکوسکی و استاسیک، ۱۹۹۷، استاسیک ،۱۹۹۹). اپلت‌های جاوا از پیش کامپایل شده‌اند، در داخل یک سند وب کار می‌کنند و پیشرفت‌هایی را برای محتوای صفحة وب ثابت ارائه می‌دهند. این رویکرد را می‌توان برای قابلیت‌های پشتیبانی تصمیم‌گیری مبتنی بر اینترنت که به برنامه‌های GIS محدود (در اندازة کوچک) نیاز دارند، در نظر گرفت. با این حال، بسیاری از برنامه‌های GIS بزرگ هستند و بنابراین، دانلود کردن زمان می‌برد. از آنجایی که هر بار که کاربران یک صفحة وب را دوباره بازدید می‌کنند، اپلت‌های جاوا باید دوباره بارگیری شوند، زمان مورد نیاز برای بارگیری اپلت‌ها مشکل‌ساز می‌شود. این محدودیت در حال حاضر، استفاده از اپلت‌های جاوا را به چند توابع تحلیل فضایی ساده که برای تصمیم‌گیری مفید هستند، محدود می‌کند.

شکل ۳٫۱۱ معماری سخت‌افزار برای تصمیم‌گیری مشترک فضا و زمان توزیع‌شدة سیستم پشتیبانی

پشتیبانی (به‌عنوان مثال پرس‌وجو مبتنی بر فاصله، جستجوی نقطه در چندضلعی، بافر و پوشش).

یکی از راه‌حل‌های جایگزین برای مشکل فوق، ایجاد نرم‌افزار GIS است که مانند یک جزء مرورگر وب عمل می‌کند. به‌عنوان مثال، می‌توان به افزونه‌های متعدد برای مرورگر وب Netscape Navigator اشاره کرد. پلاگین برنامة مستقلی است که در چارچوب یک مرورگر کار می‌کند و خود را بین مرورگر و داده‌های قابل دسترس قرار می‌دهد. تفاوت اساسی بین افزونه و اپلت جاوا در نحوة دسترسی کاربر به آن‌ها است. پلاگین باید ابتدا از یک سرور روی هارد دیسک ماشین کاربر دانلود شود تا بتوان از هارد دیسک به آن دسترسی پیدا کرد. این یک افزونه را قادر می‌سازد تا به فایل‌های دیگر روی هارد دیسک دسترسی داشته باشد. اپلت جاوا برخلاف افزونه، هربار از یک سرور بارگیری می‌شود و فقط در زمینة صفحة WWW خاص که از آن استفاده می‌کند، وجود دارد. مزیت راه‌حل پلاگین نسبت به اپلت جاوا، این است که کاربر مجبور نیست در مورد نرم‌افزارهای پیچیده مانند GIS، داده‌ها را به صورت دستی به یک برنامة خارجی ارسال کند. مرورگر وب این کار را به صورت خودکار انجام می‌دهد.

با اینکه به نظر می‌رسد طراحی سیستم پشتیبانی تصمیم‌گیری فضایی مشارکتی، مبتنی بر مرورگر وب و معماری پلاگین راه‌حل امیدوارکننده‌ای باشد، اما عاری از محدودیت نیست. شدیدترین آن، وابستگی به نرم‌افزار مرورگر وب است. ممکن است نیاز باشد که یک افزونه به‌طور خاص برای مرورگر وب خاصی پیاده‌سازی شود؛ این بدان معناست که باید یک افزونة جداگانه برای Netscape Navigator و MS Internet Explorer وجود داشته باشد. اگر نسخة جدیدی از نرم‌افزار مرورگر در دسترس قرار گیرد، باید افزونه به‌روز شود. علاوه بر این، ارسال حجم زیادی از داده‌ها از مرورگر وب، محدودیت دیگری ایجاد می‌کند. انتقال داده‌های بزرگ باعث کاهش عملکرد می‌شود و حس تعامل را در یک برنامه کاهش می‌دهد.

رویکرد سوم شامل توسعة مستقل است. نرم‌افزار تخصصی که به مشتری اجازه می‌دهد با استفاده از زیرساخت اینترنت با سرور ارتباط برقرار کند، نمونه‌ای از این‌گونه معماری‌ها می‌باشدـ نمونة اولیة نرم‌افزار برای درک فضایی و سیستم پشتیبانی تصمیم (SUDSS)  (جانکوسکی و استاسیک،۱۹۹۷،استاسیک،۱۹۹۹). SUDSS بر اساس معماری مشتری- سرور است (شکل ۳٫۱۲ را ببینید). جزء سرور که تحت سیستم‌عامل MS Windows NT 4.0 کار می‌کند، وظایف مدیریت پایگاه داده را انجام می‌دهد. مؤلفة کلاینت (کاربر) که تحت سیستم‌عامل MS Windows 95 کار می‌کند، یک برنامة کاربردی مستقل است که با پایگاه داده روی سرور ارتباط برقرار می‌کند. تبادل داده بین نرم‌افزار مشتری SUDSS و سرور SUDSS، تنها بر اساس پروتکل TCP/IP است. ارتباطات مبتنی بر TCP/IP با استفاده از انتقال داده با سوئیچ بسته، اتصال مشتری- سرور قابل اعتماد را فراهم می‌کند. یک ضعف بالقوة پروتکل از این واقعیت ناشی می‌شود که ممکن است در بالای پروتکل‌های سطح پایین‌تر و کمتر قابل اعتماد، عمل کند. این ممکن است در صورت انتقال چندرسانه‌ای (به‌خصوص زنده) مشکل ایجاد کند. با این حال،

شکل ۳٫۱۲ معماری نرم‌افزار نمونة اولیه SUDSS

مزیت رویکرد مورد استفاده در نمونة اولیة SUDSS (یک نرم‌افزار مستقل و آگاه به اینترنت)، استقلال آن از مرورگر وب و قابلیت‌های مدیریت داده بهتر است. علاوه بر این، از آنجایی که بسیاری از عملکردهای تحلیلی و مدیریت داده‌ها را می‌توان بر روی کلاینت انجام داد، این امر زمان ارتباط شبکه را کاهش داده و درنتیجه، سرعت عملیات نرم‌افزار را افزایش می‌دهد. نقطه‌ضعف این راه‌حل، هزینة توسعه و اغلب «ظاهر» و «احساس» جدید رابط کاربری است که با آنچه ممکن است بسیاری از کاربران در مرورگرهای وب محبوب به آن عادت داشته باشند، متفاوت است.