Создание внешнего интерфейса браузера для приложения TigerLogic D3 DB
У меня есть интересная головоломка. Передо мной стояла задача определить наиболее подходящий процесс для создания "интерфейса браузера" для существующего многопользовательского приложения, созданного в среде TigerLogic/Pick D3. Мое исследование показывает, что есть много способов сделать это; но я изо всех сил пытаюсь решить, какой метод лучше и с чего начать. Я "поиграл" с несколькими технологиями, но для того, чтобы начать, нужно стремиться к одной технологии.
Эти методы включают в себя:
- Создание сложного веб-сервиса с использованием MVS Toolkit; и разработка клиента из WSDL либо с нуля, либо с использованием maven/wsimport. Тесты показывают, что в этом процессе намного больше, чем изначально для простого WSDL.
- Разработка веб-приложения на основе Java, использующего MVSPJavaAPI - я не являюсь разработчиком JAVA, поэтому это означает изучение нового языка. Разработка, скорее всего, будет происходить в Eclipse.
- Использование TigerLogics FlashCONNECT - что приводит к дополнительным расходам для клиентов, поэтому не является предпочтительным - и более или менее управляемым
из.
Существует также опция.NET, но я исключил это из-за необходимости переносимости.
Мой вопрос: кто-нибудь еще делал что-то подобное, и не могли бы вы поделиться своим опытом? Моя первая задача - создать веб-приложение, которое будет надежно отображать подсказку D3 TCL в браузере, который я могу настроить.
Я не уверен, что здесь есть однозначный ответ, но хотел бы услышать мысли людей и обозначить наиболее полезный ответ.
3 ответа
Я использовал все описанные технологии и многое другое для взаимодействия с D3. Я согласен с @Glenn и добавлю... Я понимаю, что вы уходите от.NET. Это нормально, тебе это не нужно. Но учтите, что большинство реализаций LAMP отделяют серверы СУБД от веб-серверов. Эта топология вводит короткие задержки между уровнями, но разъединяет их в случае, если вы хотите использовать несколько веб-серверов или несколько баз данных - обычная топология даже с D3 / MV.
У меня есть клиент, у которого есть интерфейс Java/Grails поверх Linux, со всеми запросами данных, отфильтрованными через один элегантный класс поставщика данных, который абстрагирован от логики приложения. Это использует вызов веб-службы, который я написал на Java, вызов веб-службы.NET. Сервис легко генерируется / модифицируется, как и клиент из WSDL. Оттуда IIS передает входящие запросы к D3 через mv.NET, и в этот момент не имеет значения, находится ли СУБД D3 в Linux или Windows. Мой веб-сервис мог бы так же легко работать в Linux с Java, но в этом случае отсутствовал бы механизм объединения - см. Ниже.
Если вам нужен весь Linux, вы можете использовать библиотеку Java MVSP. TigerLogic (сейчас приобретенный Rocket Software) несколько месяцев назад посвятил себя привязке PHP для MVSP. Вместо того чтобы ждать, один из моих клиентов создал оболочку PHP для mv.NET, хотя MVSP так же прост. Таким образом, полученное приложение по сути является LAMP, но с M = Multivalue. Я тоже написал такой код - мы можем написать обертку на любом языке, который предоставляет полезный API и абстрагирует как метод подключения, так и зависимости ОС. Другими словами, не имеет значения, какие языки мы хотим использовать или какие ОС задействованы. Эта часть довольно тривиальна и может быть изменена позже. Лучше сосредоточиться на приложении, чем на коммуникациях.
Вы также можете выйти из меню, если можно так выразиться, и создать свою собственную оболочку Java/PHP для команды d3tcl уровня ОС, которая представляет собой сценарий / оболочку для исполняемого файла d3. Это позволяет самостоятельно открывать соединение и передавать команды.
Какой бы вариант вы ни выбрали, вы должны учитывать, что открытие и закрытие соединения с СУБД - это медленный процесс. Вы не хотите, чтобы сценарий входа вокруг каждого запроса данных. Вы действительно хотите открыть соединение и сохранять его открытым постоянно, пока ваш клиентский код обращается к этому постоянному соединению и освобождает его по мере необходимости. Вот почему нам нравятся mv.NET и FlashCONNECT. С MVSP и другими механизмами вам нужно создать свою собственную модель персистентности. Вам также нужно будет управлять пулом ресурсов соединения - что произойдет, если вы получите 10 одновременных запросов или только 1 короткий один за другим длинный? Вы не хотите, чтобы запросы выполняли резервное копирование, вы не хотите отклонять или прерывать соединения, и вы не хотите запускать соединение для каждого клиента. Вам нужно правильное количество сеансов СУБД, ожидающих входящих подключений. mv.NET и FlashCONNECT делают это для вас, остальные - нет.
Лично я бы уклонился от FlashCONNECT. Я был там для его первоначальной разработки и тестирования и в течение многих лет реализации для конечного пользователя. Он не так широко используется, как другие опции, и больше подходит для тех, кто не знаком с другими вариантами. Если вы говорите о Java, то, вероятно, вы не склонны использовать FlashCONNECT. Тем не менее, если у вас есть разработчики, которые не знакомы ни с чем за пределами D3, то FlashCONNECT - достойный инструмент на стороне сервера для них, в то время как кто-то еще фокусируется на стороне клиента с другими технологиями. Каждый должен использовать свои лучшие навыки.
Наконец, (уже?), Если кто-то не знаком с внешними технологиями и более тесно связан с D3, тогда существуют другие варианты, такие как DesignBAIS и Viságe, в основном снимающие нагрузку на коммуникации и позволяющие разработчикам работать над функциями на стороне клиента и обратно. Правила конца в бейсике.
Я обсуждаю все эти темы, а также мобильную связь и телефонию в своем блоге.
НТН
Я бы предложил использовать API-интерфейсы Rocket D3 (ранее TigerLogic D3).NET и создать RESTful-сервис веб-API, который вы можете использовать с JavaScript в любой другой веб-технологии, и если вам нужно вызывать из подпрограммы D3 (в случае необходимости), используйте инструментарий MVS.
Требования хотя D3 9.0 или позже.
Какой путь вы выберете, зависит в некоторой степени от вашего существующего набора навыков и от того, соответствует ли он вашим потребностям в мобильности. Очень сложно дать вам конкретный ответ на ваш вопрос, потому что вы не знаете, в какой части цепочки вам нужна мобильность.
Тем не менее, возможно разработать интерфейс веб-браузера с использованием.NET, который будет работать в Linux или Windows, поэтому я не вижу здесь проблемы с переносимостью. Ваш веб-сервер должен быть основан на Windows, но не должно иметь значения, работает ли D3 в Linux или Windows на стороне сервера, или на клиентских рабочих столах работает Linux или Windows.
Вы можете попробовать TigerLogics MVSP .NET API, но я не знаю, обладает ли он возможностями для доставки в зависимости от ваших потребностей. Я полагаю, вы можете найти mv.NET от Bluefinity, который может удовлетворить ваши потребности. На мой взгляд, это ведущий продукт на рынке MultiValue для достижения поставленных целей. Это будет означать, конечно, тратить деньги. Для этого вы получите очень мощный набор инструментов. Кроме того, стоимость инвестиций в хороший инструмент может оказаться меньше, чем затраты времени, усилий и потенциальных сложностей, связанных с попыткой сделать это по частям без дополнительных затрат. Я уверен, что Flashconnect также сделает эту работу. Вам нужно будет взвесить стоимость различных вариантов, чтобы узнать, какой из них подходит вам технически и финансово.
Не зная, есть ли у вас.NET в вашем наборе навыков, я не знаю, будет ли вам проще вариант.NET. Однако это технически возможно.