Методы проектирования Java-демонов

Question

Я пишу демон на Java, который принимает запросы от нескольких провайдеров , в которых провайдер возвращает объект service для запуска демона как нить.

Архитектура приложения:

• Основной класс
• Поставщики
• Услуга
• Библиотеки / Модели
• Элемент списка

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

Поставщики Провайдер - это в основном адаптер для сторонней службы. Это может быть электронная почта, факс, очередь заданий, база данных и т. Д. Когда поставщик инициализируется, он подключается к сторонней службе. Всякий раз, когда приложение выбирает новый объект service от поставщика, оно проверяет стороннюю службу, если оно находит новый запрос, оно анализирует его и затем возвращает новый объект service применение.

Услуга Сервис в основном специализированная работа. Когда провайдер получает новый запрос, он возвращает определенный тип сервиса, связанный с запросом. Когда приложение запускает новый поток службы, оно обрабатывает запрос и затем закрывается.

Вот пример, хотя он, вероятно, никогда не будет использоваться таким образом. Создается новый провайдер , который прослушивает порт HTTP. Новый HTTP-запрос приходит с просьбой обработать строку (перевернуть ее) и сохранить в обратном порядке в базе данных. Приходит новый запрос, поставщик возвращает сервис приложению, приложение запускает новый сервис , в котором происходит обратное изменение строки и обновляется база данных. После обновления приложение видит, что задание выполнено, и может получить новое от другого поставщика .

Вопрос: Существуют ли какие-либо шаблоны проектирования, такие как MVC, которые бы обрабатывали такую ​​архитектуру? Я понимаю, что MVC - очень плохой термин для использования, так как он содержит несколько шаблонов. Я думаю, что я спрашиваю, подход, который я иду, хорошо? Было бы хорошей идеей взять концепции MVC и перенести их в это приложение? Поставщики - это контроллеры, а услуги - действия, привязанные к моделям? Хотя в этом типе приложений никогда не бывает просмотров.

Edit:

• Демон обрабатывает запросы асинхронно с запросчиком. Запрашивающий никогда не получает прямой ответ.
• Приложение распространяется, поэтому вы можете запускать этот демон на любом количестве серверов. Всякий раз, когда поставщик получает новый запрос, он блокирует запрос, чтобы другие демоны не дублировали запрос. Джефф Стори упомянул JMS, который может быть полезен для этого. Я также думал об интеграции Memcache для обработки блокировки поверх того, как провайдеры ее обрабатывают.

Спасибо

Answer 1

В зависимости от масштаба, который вы хотите масштабировать, вы можете рассмотреть возможность использования службы обмена сообщениями, такой как JMS. Ваши производители и потребители (т.е. поставщики и респонденты) могут публиковать и слушать соответствующие темы JMS.

Answer 2

То, что вы описываете, очень похоже на то, что шаблоны интеграции предприятия решают.

• Чтобы распространяться, вы должны использовать какую-то систему обмена сообщениями , такую ​​как JMS.
• Чтобы прослушивать события из других протоколов, вы должны использовать Channel Adapter .
• Ваши "службы" могут быть связаны вместе с помощью Трубы и фильтры и Маршрутизаторы сообщений , или вы можете использовать Диспетчер процессов (часто некоторые BPM или рабочий процесс). двигатель).

Легкие библиотеки Java, поддерживающие эти шаблоны, - это, например, Apache Camel или Spring Integration , или вы можете использовать полную Enterprise Service Bus, такую ​​как ServiceMix или Mule.

Вот примерный перевод ваших терминов:

Основной класс - В полном ESB это будет сам ESB, то есть сервер приложений. Вы можете написать это самостоятельно или использовать существующий ESB или сервер приложений общего назначения, например OSGI.

Провайдеры - Канальные адаптеры.

Услуги - Это будут различные компоненты. Некоторые из них могут быть компонентами EIP, такими как преобразователи сообщений, а также сервисные активаторы или другие канальные адаптеры.

Answer 3

Веб-серверы (и не только HTTP) используют шаблон Запрос / Ответ. Приемник сокетов ожидает входящие соединения, использует фабрику запросов для создания объекта запроса и затем передает его обработчику, который возвращает объект ответа (или фабрика также создает объект ответа, а обработчик просто изменяет его).

В мире HTTP обработчик идентифицируется по URL, а параметры URL или данные POST становятся данными запроса. Ответ (обычно некоторая HTML-страница) кодируется из объекта ответа и отправляется обратно в браузер.

Answer 4

Не-специфичным для Java (под которым я подразумеваю общий подход, а не тот, который не применяется при использовании Java) является использование простого подхода «запрос / ответ», как отметил Аарон Дигулла. Это очень распространенный сценарий, но его легко перепроектировать (как на самом деле, его довольно просто и просто написать - особенно при использовании соответствующих вспомогательных библиотек).

Если ваше приложение для веб-службы для добавления / удаления записей из базы данных содержит более 200-300 строк кода, то оно, вероятно, перегружено (даже при разумной обработке ошибок и динамической конфигурации).

Если ваша база данных поддерживает блокировку и обеспечение уникальности (и транзакций, если вам требуется такая функциональность), я бы посоветовал вам не переусердствовать, написав демон блокировки - просто позвольте базе данных позаботиться об этом и обработать исключения.

Если вам действительно нужна блокировка (например, потому что вы пишете в какую-то внешнюю службу, например, немного аппаратного обеспечения), тогда вы можете использовать типичный подход UNIX для блокировки ресурсов и написать демон с одним экземпляром, который работает на локальном компьютере. сокет, с которым могут общаться все ваши веб-сервисы - в зависимости от того, указывает ли ресурс на занятость, они могут либо отклонить запросы, либо поставить их в очередь (например, в памяти в системе очередей, в таблице в базе данных SQL и т. д.) с демоном, который обрабатывать запросы в очереди (которые также общаются со службой блокировки).

Чтобы все было действительно просто, вы всегда можете просто всегда отправлять запросы в систему обслуживания очередей из веб-службы, я бы рекомендовал, если только вам не нужно различать «это действие выполняется» и « это действие ставится в очередь "в ваших ответах клиенту, отправившему запрос.

Что касается самого интерфейса, лично я предпочитаю что-то, что широко признано в качестве открытого стандарта, легко реализуемо и легко интерпретируемо, например, сервис Document / Literal SOAP, а не что-то вроде RPC / encoded (устарело и зло) или JMS (которая является собственностью, хотя на практике поддерживается в различной степени).

Если вы пишете исключительно внутреннюю службу, а вы - исключительно магазин Java, JMS очень подходит, но если это не внутреннее приложение, лучше играть хорошо и не предполагать, что все остальные захотят использовать JMS-клиент просто поговорить с вашим сервисом (я евангелизирую Doc / Lit SOAP, потому что он может быть проанализирован любым, что может обработать даже базовый XML и одобрен WS-I).

Answer 5

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

Отказ от ответственности: Я не знаю, каковы ваши требования к масштабированию или ваши ограничения ресурсов, и если вы работаетедемон это может быть важно.Как всегда, возьмите грядущие предложения с крошкой соли.

Моя первоначальная реакция заключается в том, что, вероятно, не существует единого шаблона проектирования, который решит всю вашу проблему, но есть некоторые шаблоны проектирования, которые могут помочь вам с подразделамиэто.

1) Похоже, ваш основной класс будет опрашивать поставщиков.Вы можете сделать что-то более управляемое сообщениями.Посмотрите на шаблон Observer и соответствующий шаблон публикация / подписка , если / когда вам нужно увеличить масштаб.

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

3) Исходя из вашего описания, вы можете отправиться в архитектуру астронавта территорию (т.е. обобщать все перед ваминужно).Если вы не собираетесь распространять API или у вас есть много людей, работающих над / повторно использующих этот код, я бы предостерег от такого поведения: это большое времяпрепровождение, и расстраивать стремление к такой высокой цели и только потомреализовать крошечную долю первоначальных амбиций.

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