Архитектура мобильного решения
От: ivb22  
Дата: 29.10.07 10:53
Оценка:
Есть программулина под Palm OS, обеспечивающая работу торгового агента на маршруте.
В ней забита простенькая база данных (Sybase Ultralite) с маршрутами, клиентами, взиморасчетами с ними, товарами и остатками, прайсами.
Программа позволяет оформить продажу с борта и распечатать комплект документов, либо отправить заказ (по GPRS) на центральный склад. В начале следующего рабочего дня БД наладонника синхронизируется с базой центрального склада — это обеспечивает технология Ultralite и набор серверных скриптов.
Проблема состоит в том, что Palm OS потихоньку помирает, и все сложнее и сложнее ремонтировать старые наладонники и покупать новые.
Есть желание перевести все это мобильное хозяйство на другую платформу.
Вопрос — на какую?
— Вариант решения "в лоб" — закупить TabletPC, поставить на него эмулятор Palm'а. Плюсы: ничего переписывать не надо. Минус: очень дорогое решение по затратам на "железо"
— переписать приложение на .NET для Windows mobile — здесь вроде бы прямая колея и камней быть не должно.
— переписать на Java MIDP — совсем нет знаний про это, например непонятно, можно ли работать с базами данных и с внешними устройствами, также непонятны перспективы платформы, но с другой стороны, технических характеристик устройства типа смартфона-телефона для данной задачи, с натяжкой, но достаточно.
— мне почему-то нравится больше всего концепция веб-интерфейса: на мобильном устройстве работает веб-браузер, и на нем же запущен веб-сервер, реализующий приложение, и база данных. Оптимально наверное чтобы там был Linux, Java-сервлет контейнер, какой-нибудь MySQL-HSQLDB, Opera или Firefox. Но не на всякий КПК можно линукс поставить, и не слишком ли маргинально такое решение выглядит?
Re: Архитектура мобильного решения
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 29.10.07 11:17
Оценка:
Здравствуйте, ivb22, Вы писали:

I>- переписать приложение на .NET для Windows mobile — здесь вроде бы прямая колея и камней быть не должно.

много, но, на мой взгляд, наилучший вариант из перечисленных.

I>- мне почему-то нравится больше всего концепция веб-интерфейса: на мобильном устройстве работает веб-браузер, и на нем же запущен веб-сервер, реализующий приложение, и база данных. Оптимально наверное чтобы там был Linux, Java-сервлет контейнер, какой-нибудь MySQL-HSQLDB, Opera или Firefox. Но не на всякий КПК можно линукс поставить, и не слишком ли маргинально такое решение выглядит?

GPRS слишком нестабильная штука, для того чтоб на него завязываться. Плохая погода, высокая нагрузка на сеть, плохой прием в конкретной точке.. и все, и не заказать товар.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: Архитектура мобильного решения
От: ivb22  
Дата: 29.10.07 11:32
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>GPRS слишком нестабильная штука, для того чтоб на него завязываться. Плохая погода, высокая нагрузка на сеть, плохой прием в конкретной точке.. и все, и не заказать товар.


не, тут нормально все. Заказ принимается и записывается в память мобильного устройства (в базу данных). Затем в любое время в течение дня агент жмет кнопочку "отправить" и именно тогда устанавливается GPRS-соединение и непереданные заказы передаются. Частенько да, не с первой попытки.
Re: Архитектура мобильного решения
От: Аноним  
Дата: 29.10.07 14:43
Оценка:
Здравствуйте, ivb22, Вы писали:

I>- мне почему-то нравится больше всего концепция веб-интерфейса: на мобильном устройстве работает веб-браузер, и на нем же запущен веб-сервер, реализующий приложение, и база данных. Оптимально наверное чтобы там был Linux, Java-сервлет контейнер, какой-нибудь MySQL-HSQLDB, Opera или Firefox. Но не на всякий КПК можно линукс поставить, и не слишком ли маргинально такое решение выглядит?


А зачем на этом же устройстве запускать само приложение? Если мы уже приходим к web-интерфйесу, то очевидным решением являеится единый Application server (на котором ворочается само приложение) и единая БД. Достоинства: доступно любому клиенту (palm, win-mobile, обычный браузер и т.д. — только разные html'ки надо генерить в зависимости от типа клиента), не надо синхронизировать данные из разных БД, на клиентские компы ничего не надо ставить, включая update'ы, патчи и проч.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.