Подходящие рамки для ERP-приложений

Question

Я хочу создать систему управления производством, которая будет использоваться небольшой производственной фирмой. Система позволит документировать различные этапы изготовления оборудования. Требования следующие:
1.Не браузерный интерфейс. Нужно что-то вроде Swing или AWT. Хотя я понимаю удобство реализации браузерного решения, владелец бизнеса настаивает на не браузерном интерфейсе.
2. Доступ к нескольким системам. Эти системы позволяют выполнять операции CRUD в центральной системе (Тонкий клиент?)
3. Приложение не будет иметь более 3 одновременно работающих пользователей.
Мне нужно несколько советов относительно того, что было бы хорошим путем для такого рода приложений. В настоящее время я думаю об использовании Griffon с RMI. Тем не менее, у меня нет большого опыта разработки. Читайте немного об Apache River (Jini) тоже.Будет ли хорошей идеей использовать Griffon с RMI?

Пожалуйста, дайте несколько советов. Благодарю.
РЕДАКТИРОВАТЬ: после некоторого чтения, я решил использовать больше основных структур. Так, Griffon не вариант. Как насчет Джини (Apache River) или OSGI (Apache Felix)?

Answer 1

Учитывая то, что, по-видимому, является вашим текущим пониманием проблемы, я не рекомендовал бы OSGI, особенно для небольшой производственной фирмы (возможные проблемы с обслуживанием, в зависимости от "персонала").

Основная причина, по которой я не стал бы защищать JINI или OSGI в вашем случае, заключается в том, что вы сказали

However, i don't have much development experience.

JINI (Apache River) является жизнеспособным вариантом, если вы полностью понимаете концепции LookupService и регистрации служб и т. Д. Здесь происходит множество RMI с возможными последствиями брандмауэра...

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

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

Существуют простые варианты веб-служб, такие как Spring Remoting (например, через http/https), если только Spring не вводит слишком много концепций и проблем для вашего приложения.

Answer 2

Хм, как этот проект, который недавно вышел из фазы инкубации, считается основным по сравнению с проектом, который используется в производстве более 3 лет? В любом случае, Apache River дает вам доступ к технологии Jini и ничего более; Это означает, что вы не можете достичь пункта № 1 в своем списке с одной рекой. River может использовать RMI для доступа к удаленным ресурсам, однако вы можете использовать RMI напрямую или попробовать DRMI, Kryonet, Hessian/Burlap, HTTP Invoker Spring, буфер протоколов, Avro/Thrift, REST, SOAP, ZMQ и многие другие.

Даже если вы выберете один из этих вариантов и / или Ривер, вам все равно придется определить следующие вещи

• структура приложения (структура файла и поведение во время выполнения)
• настройка сборки
• управление зависимостями
• профили тестирования
• упаковка
• стратегии развертывания

Эти вещи и многое другое - то, что Гриффон приносит на стол. Как вы, возможно, заметили, инфраструктура позволяет создавать приложения путем добавления плагинов, сокращая время, которое вы должны выделить для поиска зависимостей, настройки механизма начальной загрузки и выполнения задач. В отношении технологий удаленного взаимодействия взгляните на различные варианты, которые предлагает Гриффон http://artifacts.griffon-framework.org/tags/plugin/remoting

Более того, вы также можете комбинировать OpenDolphin ( http://open-dolphin.org/dolphin_website/Home.html) с Griffon. Есть даже пример приложения, найденного в репозитории opendolhpin, показывающего полное клиент-серверное приложение (сборка с Griffon, Grails и OpenDolphin) https://github.com/canoo/open-dolphin/tree/master/dolphin-griffon-crud