нужен совет (конвейер задач и сохранение состояний)

jakal222

Добрый день!
Есть такая легкая задача для опытных программистов.
Итак, имеем:
Некий сервис, который выполняет задачи над некоторым объемом типичных данных (допустим, что мы манипулируем сборкой автомобиля).
Этот сервис управляет полной сборкой автомобиля, т.е. от получения заказов до изготовления и отправки на пункт доставки.
Получается некоторый конвейер, который выполняет задачи: "получение заказа, заказ деталей, сборка деталей, покраска, сообщение о готовом автомобиле"
Теперь вопрос:
каким образом данный сервис будет узнавать, на каком он этапе находится к конкретному заказу автомобиля (получение необходимых деталей - завершено, сборка - завершена, заказ - ожидает ответа о пункте доставки)?
Предполагается, что нужно вести некоторый этап выполнения, который нужно записывать в некоторую бд, чтоб данный сервис при падении смог-таки в дальнейшем собрать заказы.
Простите за столь простой вопрос, никогда раньше не работал с похожими задачами. Выполнил все этапы по отдельности, но не могу понять как их связать вместе.

durka82

Например это делается через Stateful bean.

jakal222

Например это делается через Stateful bean.

а можешь раскрыть этот термин на примере?
описания на сайте оракла туманны: oracle: designing beans

bansek

язык какой? задачу нужно решать distributed?
гугли в сторону pipeline framework [язык]
например для java
http://programmers.stackexchange.com/questions/180212/good-i...
http://code.google.com/p/appengine-pipeline/wiki/GettingSta...
http://www.theregister.co.uk/2014/06/25/google_cloud_platfor...
http://code.google.com/p/pipelinepattern/

Varvara2002

Что, битовая маска не подойдёт для хранения текущего состояния?

jakal222

язык какой? задачу нужно решать distributed?

ruby
да, distributed.
хочу, чтоб при падениях серверок вставал и продолжал работу с "текущего" момента

kill-still

- описываешь процесс сборки автомобиля на BPMN
- запихиваешь его в jBPM
- в конфиге ему прописываешь SQL-базу куда ты хочешь его сохрянять (persistence.xml)
...
- profit
И никак иначе, опытные программисты только так делают. Иначе чек за работу меньше 100 тысяч нефти получится.

jakal222

- описываешь процесс сборки автомобиля на BPMN
- запихиваешь его в jBPM
- в конфиге ему прописываешь SQL-базу куда ты хочешь его сохрянять (persistence.xml)
...
- profit
И никак иначе, опытные программисты только так делают. Иначе чек за работу меньше 100 тысяч нефти получится.

ок, но сколько времени это займет для написания в две руки?
какие показатели и в каких условиях данное решение действительно вытягивает на поднебесные высоты?
да, еще раз упомяну, что решение на Ruby
P.S: странный этот раздел, постоянно минусуют, видимо, нужно на всякие SO ходить и спрашивать вопросы

bansek

мне кажется это был сарказм ...
а по теме, lmgtfy: http://github.com/arschles/ripeline

kill-still

ок, но сколько времени это займет для написания в две руки?

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

P.S: странный этот раздел, постоянно минусуют

Тут так принято, you are welcome!
И да, это был сарказм конечно.

khachin

Если последовательность состояний строгая, то в качестве примера:
Заводишь в базе две таблицы:
 — таблицу этапов: <id - PK>, <название_этапа>, <последовательность> (опциональные столбцы в духе "описание этапа", etc.)
 — таблицу ассоциаций состояния заказа: <id - PK>, <id_заказа - FK>, <id_этапа - FK> (опциональные столбцы в духе "по состоянию на дату", etc.)
В последовательности хранишь числа (100, 200, 300). Иногда так бывает, что необходимо добавить промежуточный этап (вставляешь с последовательностью 150, 175).
Разбор твоего примера:

ЭТАПЫ

id  название_этапа                   последовательность  завершен                   в_процессе

-------------------------------------------------------------------------------------------------------------

1   получение заказа                 100                 заказ принят и согласован  согласование заказа

2   заказ деталей                    200                 детали поступили           ожидание поставки деталей

3   сборка деталей                   300                 сборка завершена           детали в процессе сборки

4   сообщение о готовом автомобиле   400                 Ваш автомобиль ожидает     

5   покраска                         350                 автомобиль покрашен        идет покраска автомобиля



СОСТОЯНИЯ_ЗАКАЗОВ

id  id_заказа  id_этапа  на

-----------------------------------

1   1          5         2014-09-11

2   2          3         2014-09-12

Для первого заказа покраска имеет состояние "в процессе", этапы с меньшей последовательностью, логично — "завершен", с большей — "не начат".
Это в качестве простого примера. Конечно, не идеально (не соблюдена атомарность), но как я понял, тебе нужно что-то быстрое для небольшой задачи. У нас, например, на предприятии больше этапов, некоторые могут выполняться параллельно, некоторые могут быть не задействованы, для каждого описаны свои группы дискретных и количественных состояний, иногда есть определенные требования к состояниям с меньшей последовательностью... там уже не так всё просто.

странный этот раздел, постоянно минусуют

Не обращай внимания на ЦРОТисхку. Он должен всем доказать, что у него са-а-амая большая писька.