информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Где водятся OGRыАтака на InternetСтрашный баг в Windows
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
А попроще нельзя? 18.07.04 14:52  Число просмотров: 1335
Автор: Den <Denis> Статус: The Elderman
<"чистая" ссылка>
Если удаленные пользователям не нужно получать данные с сервера, а только отсылать данные за отчетный период, то можно написать клиента, который будет сохранять инфу из форм в форматированный txt файл или в dbf или еще в какой-нибудь формат, архивировать и отправлять по почте. А также написать робот, который будет переодически получать данные из почтового ящика, разархивировать их и вливать в базу.
<programming>
Архитекторы, подскажите, плз. 18.07.04 02:16  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
Есть корпоративная инф.система, где расположены различные сервера RDBMS. В перспективе (год-два) инфраструктура этой инф.система может поменяться. Скорее всего, так и будет.
Сейчас появилисьудалённыепользователи, которые должны сливать в эти базы небольшую инфу по-квартально – типа статотчётности. Частьудалённыхпользователей имеют инет. Для другой части – можно организовать только соединения точка-точка по меди.

Для удалённых контор всего будет сделано 10 форм (пять в этом году, остальное потом). Работа будет растянута на год – полтора. Делать клиентское ПО могут независимые, различные программеры (часть – может и я удалённо).

Думаю сделать так:
1) Под эти 10 подзадач взвести отдельную базу (а лучше отдельно стоящий сервак в DMZ или отдельной подсетке за МСЭ)
2) Клиентское ПО будет актуализировать только эту базу
3) Будет написано дополнительное ПО, которое будет зашедулено на этом серваке, и которое будет актуализировать базы основной инф. системы.

Система получается избыточной, т.к. появляется дополнительная «буферная» база (скорее всего на дополнительном сервере). Но, думаю, что так будет луше и с точки зрения безопасности данных основной инф. системы, и с точки зрения модернизации основной системы, и с точки зрения удобства сторонних разработчиков клиентского и серверного ПО.

Как лучше сделать? Спасибо.
Логично. Отдельный сервак - безопаснее. 18.07.04 15:27  
Автор: J'JF <Dmytro Volhushyn> Статус: Elderman
<"чистая" ссылка>
> 1) Под эти 10 подзадач взвести отдельную базу (а лучше
> отдельно стоящий сервак в DMZ или отдельной подсетке за
> МСЭ)

Логично. Отдельный сервак - безопаснее.
Правда, если включать клиентов в домен и использовать стойкий метод аутентификации вкупе с шифрованием трафика, то с отдельным серваком можно не заморачиваться - уровень безопасности данного решения, как мне кажется, будет вполне приемлемым.

> 2) Клиентское ПО будет актуализировать только эту базу
> 3) Будет написано дополнительное ПО, которое будет
> зашедулено на этом серваке, и которое будет актуализировать
> базы основной инф. системы.

Вот тут есть замечание.
Если это будет именно отельный сервак "в дмз за мсэ", то имхо безопаснее брать инфу изнутри, чем наоборот. То есть шедулить задачу актуализации на одном из серверов внутри инф. системы.
Согласен. Так лучше. Кстати, дельный совет. Спасибо. 19.07.04 03:07  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
А попроще нельзя? 18.07.04 14:52  
Автор: Den <Denis> Статус: The Elderman
<"чистая" ссылка>
Если удаленные пользователям не нужно получать данные с сервера, а только отсылать данные за отчетный период, то можно написать клиента, который будет сохранять инфу из форм в форматированный txt файл или в dbf или еще в какой-нибудь формат, архивировать и отправлять по почте. А также написать робот, который будет переодически получать данные из почтового ящика, разархивировать их и вливать в базу.
Парни, подскажите, ещё, пожалуйста по транспорту (https? ....) 19.07.04 03:43  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
> Если удаленные пользователям не нужно получать данные с
> сервера, а только отсылать данные за отчетный период, то
> можно написать клиента, который будет сохранять инфу из
> форм в форматированный txt файл или в dbf или еще в
> какой-нибудь формат, архивировать и отправлять по почте. А
> также написать робот, который будет переодически получать
> данные из почтового ящика, разархивировать их и вливать в
> базу.

Вряд ли это проще. Для меня, лично, может это и проще и универсальнее (в аски). Покрайней мере понятно, что и как надо делать в этом случае. Но надо, чтоб народ здесь без меня разрулил и потом, когда у меня закончится контракт (извините за не скромность). Хотя, то, что Вы говорите, отчасти будет использовано. Но думаю, что не самодельный формат, а XML. Мне кажется, что легче будет в XML сдёрнуть "статистику" с "буферного" сервака и из XML-ей же залить на основые сервера. Тоже, что и в самостийном txt-формате, но только есть готовые парсеры, и объекты ADO.NET для работы с ХМЛ и сиквелом. Хочу принудить публику здесь в основном писать на VB.NET. И при этом не использовать ОДБЦ или АДО - только АДО.НЕТ.

Вообщем идея такова:
1) Тундрянские пользователи районов, у которых есть инет - будут заливать статистику по https на "буферный сервак".
2) Ещё более тундрийцы, у которых только доступ по проводам (медная пара) будут передавать статистику в XML на сервер удалённого доступа. Как (www?, ftp?, samba? или написать вообще сервер для них на гольных сокетах) - пока не решил. Как защищать это соединение, тоже пока не решил. Думаю, надо пробовать.

Парни, подскажите, ещё, пожалуйста по транспорту (https? ....)
А стоит ли? 18.07.04 15:32  
Автор: J'JF <Dmytro Volhushyn> Статус: Elderman
<"чистая" ссылка>
Лично мне не кажется, что класть текстовые файлы и потом их импортировать в БД - проще. В принципе, это, наверное, из разряда имхо. Достаточно только вспомнить недавнюю ветку, касающуюся вопроса сравнения БД в виде текстовых файлов с бинарными БД "традиционных" СУБД. То есть многое зависит от конкретной задачи.
Ну и следует учесть, что разнородные методы хранения и передачи информации потребуют дополнительных административных и, возможно, материальных затрат (резервирование, предоставление соответствующих сервисов, их администрирование и т.д.).
Хотя, следует признать, что такой метод является более универсальным, т.к. позволяет отвязать удаленных клиентов от физической структуры БД.
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach