Есть задача — сделать проект, состоящий из нескольких подсистем. Суть в том, что должна отработать одна подсистема, передать данные в следующую, затем отрабатывает следующая и передает данные дальше. Все подсистемы отрабатывают по порядку. Вопрос в следующем — как лучше такое организовать, учитывая что подсистемы должны быть легко заменяемы при необходимости(например описывается некий алгоритм обработки данных, и каждая подсистема является отдельным алгоритмом, и иногда нужно будет либо добавлять новые алгоритмы, либо менять старые).
Здравствуйте, artyo, Вы писали:
A>Есть задача — сделать проект, состоящий из нескольких подсистем. Суть в том, что должна отработать одна подсистема, передать данные в следующую, затем отрабатывает следующая и передает данные дальше. Все подсистемы отрабатывают по порядку. Вопрос в следующем — как лучше такое организовать, учитывая что подсистемы должны быть легко заменяемы при необходимости(например описывается некий алгоритм обработки данных, и каждая подсистема является отдельным алгоритмом, и иногда нужно будет либо добавлять новые алгоритмы, либо менять старые).
Здравствуйте, artyo, Вы писали:
A>Есть задача — сделать проект, состоящий из нескольких подсистем. Суть в том, что должна отработать одна подсистема, передать данные в следующую, затем отрабатывает следующая и передает данные дальше. Все подсистемы отрабатывают по порядку. Вопрос в следующем — как лучше такое организовать, учитывая что подсистемы должны быть легко заменяемы при необходимости(например описывается некий алгоритм обработки данных, и каждая подсистема является отдельным алгоритмом, и иногда нужно будет либо добавлять новые алгоритмы, либо менять старые).
Без конкретизации постановка задачи слишком размыта. Тут и OSGi с модульной архитектурой можно прикрутить. И JMS для асинхронной обработки данных. Вопрос только в том а нужно ли? Каждый модуль сделать отдельным классом и пусть себе обмениваются данными. 8) Тоже вариант ведь.
Здравствуйте, artyo, Вы писали:
A>p.s. JavaEE....делать через EJB? Как?
Читать про EJB, JMS, MDB. Но замечу, нет никаких объективных причин утверждать, что это лучшее для вас решение.
Здравствуйте, artyo, Вы писали:
A>Есть задача — сделать проект, состоящий из нескольких подсистем. A>организовать, учитывая что подсистемы должны быть легко заменяемы
ну если новичку то по моему можно обойтись простыми интерфейсами без всяких страшных мего технологий
Расширяем данные и реализуем подсистемы, потом их соединяем в строителе/конфиге меняя его руками. если хочется волшебства, то делаем как jdbc через глобальный регистратор или делаем сканер classpath на предмет реализаций интерфейса. ну тут фантазировать можно до бесконечности.
package com.пример;
import java.util.ArrayList;
public class Пример {
// Очень абстрактные данныеpublic interface АбстрактныеДанные {
public int getЧисло();
public void setЧисло(int число);
}
// Что умеем то и делаемpublic interface Подсистема {
public void рассчитать(АбстрактныеДанные данные);
}
// Менеджер высшего звенаpublic static class Цепочка implements Подсистема {
private ArrayList<Подсистема> подсистемы = new ArrayList<Подсистема>();
public boolean добавить(Подсистема подсистема) {
return подсистемы.add(подсистема);
}
@Override
public void рассчитать(АбстрактныеДанные данные) {
for (Подсистема подсистема : подсистемы) {
подсистема.рассчитать(данные);
}
}
}
public static void main(String[] args) {
Цепочка цепочка = new Цепочка();
// Добавлятор
цепочка.добавить(new Подсистема() {
@Override
public void рассчитать(АбстрактныеДанные данные) {
данные.setЧисло(данные.getЧисло() + 1);
}
});
// Убавлятор
цепочка.добавить(new Подсистема() {
@Override
public void рассчитать(АбстрактныеДанные данные) {
данные.setЧисло(данные.getЧисло() - 1);
}
});
АбстрактныеДанные статистика = new АбстрактныеДанные() {
int число;
int N;
@Override
public int getЧисло() {
return число;
}
@Override
public void setЧисло(int число) {
this.число = число;
N++;
}
@Override
public String toString() {
return String.format("статистика{число=%d, N=%d}", число, N);
}
};
цепочка.рассчитать(статистика);
// Ура оно работает. И подсистемы есть :)
System.out.println(статистика);
}
}
Здравствуйте, artyo, Вы писали:
A>p.s. JavaEE....делать через EJB? Как?
также как и всегда, с наименьшим boilerplate. ejb и так предполагаются как подсистемы. делаем interface с нужным функционалом, и его реализации — подсистемы. в конечный артифакт кладем только те реализации которые нужны в сборке. если нужно в рантайме менять то делает реализацию интерфейса которая по установленному алгоритму будет дергать нужную подсистему проксируя туда вызовы.
ну можно и OSGI(для кидания понтов на лету) и BPEL(для рисования) и вебсервисы(для того чтобы были) добавить. но это уже явно не уровень новичок. Это скорее уже уровень adept enterprise
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, artyo, Вы писали:
A>>Есть задача — сделать проект, состоящий из нескольких подсистем. Суть в том, что должна отработать одна подсистема, передать данные в следующую, затем отрабатывает следующая и передает данные дальше. Все подсистемы отрабатывают по порядку. Вопрос в следующем — как лучше такое организовать, учитывая что подсистемы должны быть легко заменяемы при необходимости(например описывается некий алгоритм обработки данных, и каждая подсистема является отдельным алгоритмом, и иногда нужно будет либо добавлять новые алгоритмы, либо менять старые). B>Без конкретизации постановка задачи слишком размыта. Тут и OSGi с модульной архитектурой можно прикрутить. И JMS для асинхронной обработки данных. Вопрос только в том а нужно ли? Каждый модуль сделать отдельным классом и пусть себе обмениваются данными. 8) Тоже вариант ведь.
Конкретная постановка...щас попробую описать то что нужно.
Первая подсистема — прием и обработка данных. (уже написана). Прослушивает порт, получает данные, обрабатывает их как нужно.
Вторая подсистема — необходимо взять обработанные данные из первой подсистемы и прогнать их через несколько алгоритмов(алгоритмы могут меняться, добавляться и т.д. — не суть важно. это я разрулю уже внутри подсистемы)
Третья — берет из второй результат анализа и делает по нему некий отчет.
Четвертая — берет отчет из третьей и делает с ним все что нужно)))
я думал о том чтобы сделать подсистемы в виде ejb с набором классов. и некий общий ejb?...который будет управлять остальными подсистемами...
почитал про ejb немного. не совсем понимаю, как можно из общего ejb иметь доступ к классам/методам остальных ejb-подсистем. Через remote интерфейс? В общем чувствую курить тут маны не один день))
Мб подскажете что-то по этому поводу?
просто в каждой подсистеме куча своих классов, и не хотелось бы пихать это все в один проект...была изначально идея тупо создать проект и по пакетам все распихать) но хочется сделать чтобы все это было легко заменяемо...
Здравствуйте, artyo, Вы писали:
A>я думал о том чтобы сделать подсистемы в виде ejb с набором классов. и некий общий ejb?...который будет управлять остальными подсистемами... A>почитал про ejb немного. не совсем понимаю, как можно из общего ejb иметь доступ к классам/методам остальных ejb-подсистем. Через remote интерфейс? В общем чувствую курить тут маны не один день)) A>Мб подскажете что-то по этому поводу? A>просто в каждой подсистеме куча своих классов, и не хотелось бы пихать это все в один проект...была изначально идея тупо создать проект и по пакетам все распихать) но хочется сделать чтобы все это было легко заменяемо...
В мавене ваши классы разбейте на модули. Будет вам модульность.
Развязывать классы как можно дальше через какую-либо технологию, я бы не стал. Вам потом долго и нудно бороться с интеграцией модулей, чтобы они вместе работали. Т.е. будете бороться с тем что создали.
Если решили взять технологию, то подумайте какие ваши проблемы она должна решить. Многопоточный доступ? Транзакционность? Асинхронность?
Из новой постановки задачи всё равно не ясно для чего нужна модульность и какую проблему она решает. Сделайте классы и интерфейсы. Нужна замена логики — добавили другую реализацию интерфейса и готово.
Может вам просто GoF почитать, а не технологии искать?
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, artyo, Вы писали:
A>>я думал о том чтобы сделать подсистемы в виде ejb с набором классов. и некий общий ejb?...который будет управлять остальными подсистемами... A>>почитал про ejb немного. не совсем понимаю, как можно из общего ejb иметь доступ к классам/методам остальных ejb-подсистем. Через remote интерфейс? В общем чувствую курить тут маны не один день)) A>>Мб подскажете что-то по этому поводу? A>>просто в каждой подсистеме куча своих классов, и не хотелось бы пихать это все в один проект...была изначально идея тупо создать проект и по пакетам все распихать) но хочется сделать чтобы все это было легко заменяемо...
B>В мавене ваши классы разбейте на модули. Будет вам модульность. B>Развязывать классы как можно дальше через какую-либо технологию, я бы не стал. Вам потом долго и нудно бороться с интеграцией модулей, чтобы они вместе работали. Т.е. будете бороться с тем что создали. B>Если решили взять технологию, то подумайте какие ваши проблемы она должна решить. Многопоточный доступ? Транзакционность? Асинхронность? B>Из новой постановки задачи всё равно не ясно для чего нужна модульность и какую проблему она решает. Сделайте классы и интерфейсы. Нужна замена логики — добавили другую реализацию интерфейса и готово. B>Может вам просто GoF почитать, а не технологии искать?
Может) ладно. завтра буду об этом думать, рабочий день кончился, моск уже умер) Спасибо за советы.
Здравствуйте, artyo, Вы писали:
A>Есть задача — сделать проект, состоящий из нескольких подсистем. Суть в том, что должна отработать одна подсистема, передать данные в следующую, затем отрабатывает следующая и передает данные дальше. Все подсистемы отрабатывают по порядку. Вопрос в следующем — как лучше такое организовать, учитывая что подсистемы должны быть легко заменяемы при необходимости(например описывается некий алгоритм обработки данных, и каждая подсистема является отдельным алгоритмом, и иногда нужно будет либо добавлять новые алгоритмы, либо менять старые).
Совсем простой подход — обмен данными через файлы + монитор, который следит за появлением файлов и вызывает для них нужный компонент.
