Здравствуйте ВСЕМ!

Есть клиент (автоперевозчик), есть предварительный заказ на
создание системы продажи билетов примерно следующего вида:

У клиента есть несколько точек (3-5 шт.) по продаже билетов (кассы),
разнесенных на расстоянии от 10 до 1000км.

На точке есть оператор, ноутбук, GPRS связь

Есть центральный офис.

Заказчик (клиент) хочет распределенно продавать
билеты во всех кассах на рейсы всех направлений,
с учетом уже проданных, зарезервированных
билетов, естественно и т.п.

И видеть в реальном времени картину у себя в центральном офисе.
+несложные отчеты +печать билетов (чеков)

ВОПРОСЫ:
Как лучше построить такую систему?
С применением каких технологий?
Каков, примерный срок построения такой системы?
СТОИМОСТЬ?

Заказ, скорее теоретический, нежели повод обогатиться,
интересны возможные варианты в первую очередь.

Спасибо!

Здравствуйте, Alex A. Kuzmin, Вы писали:

AAK>ВОПРОСЫ:
AAK>Как лучше построить такую систему?
AAK>С применением каких технологий?
AAK>Каков, примерный срок построения такой системы?
AAK>СТОИМОСТЬ?

В данной задаче время критично поэтому
У тебя один выход: использование обмена данными клиент-сервер через tcp(так как это наиболее скоростной вариант)
вот только как разрулить ситуацию когда два пользователя одновремменно закажут один билет на один рейс?
можешь еще юзать веб-службу, но это будет медленнее, да и реальности не будет, так как веб-службы работают сеансово, а тебе нужен постоянная синхронизация данных по билетам.
Сроки: Забивай не менее 2х месяцев на разработку.
Явная проблема с ГПРС — Новый год))) сам попробуй дозвониться)))

Здравствуйте, Alex A. Kuzmin, Вы писали:

AAK>ВОПРОСЫ:
AAK>Как лучше построить такую систему?
AAK>С применением каких технологий?
Net или Java. Формат данных простой, поэтому можно взять любой из ORM. База — любая многопользовательская. Интерфейс — лучше Web сервис. Ну и построитель отчетов, канечно.
Единственное — бизнес-транзакция != системной транзакции. Бизнес-транзакция — путь билета от заказа до продажи. Системная транзакция — это, например, перевод билета из состояния зарезервирован/заказан в состояние продан. И в случае прерывания бизнес-транзакции по любым причинам, она должна переводить БД в исходное состояние.
AAK>Каков, примерный срок построения такой системы?
здесь Лучше рассчитай сам.

Я бы выбрал ASP .NET

Здравствуйте, Alex A. Kuzmin, Вы писали:

AAK>ВОПРОСЫ:
AAK>Как лучше построить такую систему?

Раз на точках основное средство связи GPRS — то, лучше сделать приложение по принципу SmartClient. т.к. сказать то, что GPRS отличается хорошей скоростью/надежностью нельзя.

AAK>С применением каких технологий?

Например у Microsoft есть Synchronization Services API которые предоставляют механизмы для создания "переодически" подключаемых приложений (т.е. приложение может время от времени плдключаться к серверу и синхронизировать с ним свои данные). Из плюсов — возможность работы в offline режиме и возможно более меньшие требования к передаче данных.

AAK>Каков, примерный срок построения такой системы?

Наверное зависит от того, насколько вы детализируете исходные требования. Плюс, если для разработки выбирать новые технологии это тоже может сказаться на времени разработки.

AAK>СТОИМОСТЬ?

Оценить время необходимое на разработку (Зарплата разработчика), прибавить к этому прочие затраты (Расходы на офис/основные средства и т.п) — будет базовая цена которую надо умножить на X для определения какую прибыль вы хотите получить с этого предприятия или не умножать — если отдавать все за "условно бесплатно"

Здравствуйте, TK, Вы писали:

TK>Раз на точках основное средство связи GPRS — то, лучше сделать приложение по принципу SmartClient. т.к. сказать то, что GPRS отличается хорошей скоростью/надежностью нельзя.
offline для данной задачи не подойдет. Один и тот же билет нельзя одновременно продать с двух станций. Транзакционность изменений обязательна.

TK>Например у Microsoft есть Synchronization Services API которые предоставляют механизмы для создания "переодически" подключаемых приложений (т.е. приложение

Процесс бронирования билета должен рассматриваться как атомарная операция и выполняться в транзакции.

Здравствуйте, GlebZ, Вы писали:

TK>>Раз на точках основное средство связи GPRS — то, лучше сделать приложение по принципу SmartClient. т.к. сказать то, что GPRS отличается хорошей скоростью/надежностью нельзя.
GZ>offline для данной задачи не подойдет. Один и тот же билет нельзя одновременно продать с двух станций. Транзакционность изменений обязательна.

Причем здесь offline и транзакционность? Делается все более чем просто — человек пришел к оператору, говорит хочу билет. они выбирают из списка доступных и формируют заявку на бронирование. нажимают кнопку CONNECT, отправляют заявку (фактически бронирование) и и ждут подтверждения о ее приеме. если все успешно — клиент расплачивается, забирает билет а оператор фиксирует данную операцию еще одним нажатием на CONNECT. (Плюс, в сам протокол можно внести еще улучшений которые позволят работать с подобной системой проще)

Или предлагается держать соединение с открытой транзакцией до SQL Server? Очень сомневаюсь что это будет устойчиво работать в случае GPRS и прочих ненадежных линий связи.

Здравствуйте, Dima_1st, Вы писали:

TK>>Например у Microsoft есть Synchronization Services API которые предоставляют механизмы для создания "переодически" подключаемых приложений (т.е. приложение

D_>Процесс бронирования билета должен рассматриваться как атомарная операция и выполняться в транзакции.

И?
Представьте себе, что вы бронируете билет по почте или телефону. В случае если направление популярное то диалог может быть такой (т.е. человека с человеком):
— какие у вас билеты есть?
— А и Б
— есть В?
— нет
— забронируйте мне А
— А уже выкупили. Берете Б?
— да/нет/придержите мне надо посоветоваться

Простой вопрос — сколько транзакций прошло в процессе данного разговора?

Здравствуйте, TK, Вы писали:

TK>Или предлагается держать соединение с открытой транзакцией до SQL Server? Очень сомневаюсь что это будет устойчиво работать в случае GPRS и прочих ненадежных линий связи.
Естественно нет. Тут системная транзакция != бизнес-транзакции. Но причем тут smart client? Как впрочем и Synchronization Server?

Здравствуйте, GlebZ, Вы писали:

TK>>Или предлагается держать соединение с открытой транзакцией до SQL Server? Очень сомневаюсь что это будет устойчиво работать в случае GPRS и прочих ненадежных линий связи.
GZ>Естественно нет. Тут системная транзакция != бизнес-транзакции. Но причем тут smart client? Как впрочем и Synchronization Server?

smart client при том, что данный подход расчитан на то, что постоянного соедиения с внешним сервером оно не требует. что, может быть полезно в случае использования мало-надежных линий связи (было в исходной задаче).

Что такое Synchronization Server я незнаю. Слова offline я тоже не писал (хотя, Почта России успешно проводит бизнес транзакции не смотря на то, что она offline) Думаю, что это все от того, что кто-то не внимательно читает сообщения.

Здравствуйте, TK, Вы писали:

TK>smart client при том, что данный подход расчитан на то, что постоянного соедиения с внешним сервером оно не требует. что, может быть полезно в случае использования мало-надежных линий связи (было в исходной задаче).
ocсasionally connected подразумевает разрыв связи. Это не мало-надежная связь. В случае ненадежной связи конечно можно воспользоваться гарантированной доставкой. Но можно и просто максимально уменьшить кол-во вызовов.

TK>Что такое Synchronization Server я незнаю.
Synchronization Service, ессно, очепятка.
TK>Слова offline я тоже не писал (хотя, Почта России успешно проводит бизнес транзакции не смотря на то, что она offline)
Перечитай первое сообщение. Слово offline — есть.

Здравствуйте, TK, Вы писали:

Это не наезд. Просто хочу понять что ты предлагаешь.

Здравствуйте, TK, Вы писали:
TK>Простой вопрос — сколько транзакций прошло в процессе данного разговора?
одна. "забронируйте мне А -> А уже выкупили".
Все остальные операции идут не в контексте транзакций, т.к. состояние сервера они не изменяют.
Чтобы уменьшить шансы на отказ в процессе "разговора", можно делать автоматическое бронирование.
Примерно так:
1. Идет запрос на поиск билетов по критериям
Первые пять позиций автоматически кратковременно бронируются на данного оператора (например, на 5 минут)
2. (возможная оптимизация) При покупке одного из вариантов кратковременная бронь на остальные снимается сразу.
3. (возможная оптимизация) Рейсы, на которые не хватает свободных билетов, но хватило бы билетов, временно забронированных другими операторами, учитываются при поиске. Очередность запросов операторов соблюдается:
— оператор А делает запрос; в результате видны
--- рейс 1, на котором есть пять билетов, один бронируется на 5 минут
--- рейс 2, на него есть только один билет, который уже забронирован 3:42 назад оператором Б
если клиенту интереснее рейс 2, то он может подождать 3:42. К этому моменту либо билет на рейс 2 окажется выкуплен, либо снята бронь (и автоматически выдана бронь оператору А). В итоге, у него будет полторы минуты чтобы решить, хочет ли он всё-таки рейс 1.

Здравствуйте, Sinclair, Вы писали:

TK>>Простой вопрос — сколько транзакций прошло в процессе данного разговора?
S>одна. "забронируйте мне А -> А уже выкупили".

т.е. кратковременное бронирование билета состояние сервера (вообще, причем тут сервера-то?) не меняет? как-то оно несколько странно получается. есть обычная ситуация (собственно, она и описана пред. сообщением): мне А -> забронировали -> деньги дома забыл, ничего выкупать не буду. Лично мне кажется, что есть большое различие между забронированным билетом и выкупленным. и это отличие так или иначе меняет состояние сервера. думаю, что если смотреть на транзакции со стороны бизнеса то, транзакция начинается в момент бронирования и заканчивается отказом, откатом по таймауту, либо выкупом билета. при этом сам процесс может длиться достаточно продолжительное время.

Здравствуйте, TK, Вы писали:

TK>Здравствуйте, Sinclair, Вы писали:

TK>>>Простой вопрос — сколько транзакций прошло в процессе данного разговора?
S>>одна. "забронируйте мне А -> А уже выкупили".

TK>т.е. кратковременное бронирование билета состояние сервера (вообще, причем тут сервера-то?) не меняет?
В описанном сценарии никакого кратковременного бронирования нет. Есть попытка забронировать, на нее приходит отказ в связи с отсутствием свободных мест. В конце разговора дается намек на то, что может быть еще одна транзакция ("придержите мне Б"), но я его проигнорировал в связи с отсутствием подтверждения. Скорее всего, связь оборвалась, и транзакция так никогда и не была стартована.

TK>Лично мне кажется, что есть большое различие между забронированным билетом и выкупленным.
Приведенный диалог никак это отличие не иллюстрирует. Всё, что он иллюстрирует — это отсутствие сериализуемости при разговоре по телефону. Тот факт, что попытка забронировать B была отклонена, означает, что не весь разговор идет в одной транзакции. Если бы это была одна транзакция, то во-первых бы требовался уровень изоляции не ниже repeatable read (т.к. после получения списка билетов покупатель обращается к нему повторно), а во-вторых, никто бы не смог вклиниться и выкупить билет А в промежутке между первым и вторым запросами.

TK>и это отличие так или иначе меняет состояние сервера. думаю, что если смотреть на транзакции со стороны бизнеса то, транзакция начинается в момент бронирования и заканчивается отказом, откатом по таймауту, либо выкупом билета. при этом сам процесс может длиться достаточно продолжительное время.
С точки зрения бизнеса может быть всё что угодно.