|
АБПо поводу неэкономности XML. В XML было принято радикальное проектное решение: не экономить байты. Некоторым по-видимому трудно принять такой подход, но он сегодня доминирует.
...
Поэтому пусть даже будут преобразовываться гигабайты. Ведь это не длина одного сообщения, а скорее годовой объем передаваемой информации. Если так, то я никакой проблемы с производительностью не вижу. Пусть железка молотит, главное -- разгрузить мозги, а не интеловский процессор.
Ну во-первых - мне байтов не жалко. :) Не в экономии дело, а в "лишнем" преобразовании. Давайте еще раз посмотрим на конкретном примере:
- с одной стороны, гигабайты - это никак не годовые объемы. Реальные размеры обработки, например, "голоса" у крупного оператора - ~400-700 МБ за сутки "сырых" данных (plain text), месячный сегмент служащий источником для тарификации (при загрузке а БД произведена уже некоторая "очистка" данных) тянет на 10-12 ГБ (привожу реальные цифры, с чем работал не так давно, и объемы растут);
- с другой стороны, эти-же данные нужны не только для тарификации, сейчас другие задачи с других серверов "ходят" к данным биллинга, когда им что-то из этих данных нужно, с соответствующей нагрузкой на этот сервер, что "не есть гут", потому как неизвестно, в общем случае, когда оно, другое приложение, за ними "попрется";
- с третьй стороны, и самому-то биллингу эти данные нужны только в момент тарификации, но будут жить там год, потому как "мало-ли чего" (и это "чего" реализуется, увы, регулярно);
Тут вообще возникает крамольная мысль - не оставить-ли все совместно используемые данные именно в общем хранилище, делегировав туда, на уровне интерфейсов, к примеру, и часть функций первичной обработки. Конечные приложения пусть хранят только то, что им нужно "больше одного раза", имея возможность перезапросить данные из хранилища, по мере надобности. Вот тут вполне сгодятся и вебинтерфейсы и XML. Примерно такая-же картина вырисовывается с данными технологическими и финансовыми - используются не в одном только приложении. Объемы, разве что, будут существенно меньшими.
АБЕсли я правильно понял, Вы предлагаете промежуточное хранилище, я же считаю что достаточно промежуточного формата, а хранит данные пусть каждая система у себя. Проблема взаимодействия каждого с каждым решается и у Вас, и у меня.
В том-то и дело, что мне не нравится как она сейчас решается.
Можно предположить, что существуют и другие области, где можно выделить значимые массивы разделяемых различными приложениями данных. IMHO, повод для размышлений есть...
АБЯ согласен, ради этого "городить огород" с BPMS смысла нет. Но я исхожу из того, что BPMS -- это просто полезная вещь . Ну типа как DBMS. Ведь если у вас есть СУБД, вы зачастую создаете БД там, где в принципе можно было бы обойтись чем-то попроще.
Не могу согласится. На мой взгляд, BPMS и DBMS инструменты принципиально разных уровней. Приведенные примеры, в частности, на уровне бизнес-процесса могут быть вообще не видны, т.к. на его логику не влияют. У Вас получается, что на определенном участке я должен вместо DBMS использовать BPMS.
АБТак вот, меня давно уже терзает вопрос: как в процессном управлении дать реализоваться российской ментальности?
Мне он тоже интересен, но как-то пока не видится путей, увы. В предыдущих дискуссиях по BPM, на мой взгляд, совершенно правильно давались отсылки на идеи Деминга. По-моему, без них (или чего-то близкого по смыслу) говорить о серьезном применении процессного управления в бизнесе - просто несерьезно. Ну так и что ? Я вот как-то с друдом себе представляю их массовое применение в нашей реальности. Предприятие с развитой системой штрафов для работников - это пожалуйста, этих "у нас есть". А вот, не то, что-бы с развитой системой поощрения, а просто с пониманием роли и места каждого подразделения (хотя-бы) в общем результате - много ли найдется ?
|
