Здравствуйте, Нахлобуч, Вы писали:
Н>Здравствуйте, Aviator, Вы писали:
A>>Я на русском вообще не люблю читать документацию по многим причинам, основная из которых — предпочитаю читать chm на кпк
Н>Чем читаешь?
MicroOlap chm reader, жаль версии для смарта у них нет.
Re[6]: Интеграция нескольких приложений - Оффтопик
Здравствуйте, Нахлобуч, Вы писали:
Н>Здравствуйте, Aviator, Вы писали:
A>>MicroOlap chm reader, жаль версии для смарта у них нет.
Н>Спасибо! А то я умаялся уже их декомпилировать и в россыпи файлов копаться.
на ентот случай есть неплохая тулза chm2web
Не знаю куда это лучше поместить, мож скорее в философию, так как тема достаточно философская. Итак берём достаточно типичную задачу — есть несколько приложений, которые должныобмениваться между собой информацией. В качестве механизма передачи информации выбираем обмен сообщениями. Вводим понятие канала, который реализовать можно например посредством message queue от билли. Однако в таком подходе каждое приложение, подключённое к этому каналу, получает все сообщения, в то время как далеко не все его интересуют. мало того — каждое приложение имеет возможность читать и получать то, что возможно оно не имеет право читать. Другое решение — ввести несколько каналов, соединяющих приложения со шлюзом, и уже шлюз будет определять какое сообщение как посылать и кому. Однако плодить кучу каналов не всегда удобно и оправдано... Итак возникает вопрос — какие существуют нормальные подходы для передачи сообщений между различными приложениями через количество каналов, не зависящее от количества интегрируемых приложений?
Здравствуйте, Aviator, Вы писали:
A>... Итак возникает вопрос — какие существуют нормальные подходы для передачи сообщений между различными приложениями через количество каналов, не зависящее от количества интегрируемых приложений?
Хоп Г., Вульф Б. "Шаблоны интеграции корпоративных приложений"
здесь есть многие ответы на ваши вопросы
UMA>Читать переводы на русском — упаси господи!!
Я на русском вообще не люблю читать документацию по многим причинам, основная из которых — предпочитаю читать chm на кпк
Здравствуйте, Aviator, Вы писали:
A>Я на русском вообще не люблю читать документацию по многим причинам, основная из которых — предпочитаю читать chm на кпк
Чем читаешь?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, UrryMcA, Вы писали:
UMA>Здравствуйте, Aviator, Вы писали:
UMA>>>Fowler Enterprise integration patterns A>>Енто ещё что такое?
UMA>http://martinfowler.com/books.html
а теперь читаем внимательно авторов
Здравствуйте, Aviator, Вы писали:
A>А если допустить, что я, как неразумный и малоопытный, изобретаю его в силу некоторых причин?
Допустить? Да, пожалуйста. Причины сложно представить, но... хозяин — барин или, как говорят мои коллеги, каждый сам себе злобный Буратино.
Здравствуйте, Aviator, Вы писали:
A>Например тем, тем что маршрут вычисляется обычно динамически, а тут статически задаётся.
Что вы имеете в виду под динамическим и статическим маршрутом? Если можно — на примере.
Здравствуйте, rsn81, Вы писали:
R>Здравствуйте, Aviator, Вы писали:
A>>Например тем, тем что маршрут вычисляется обычно динамически, а тут статически задаётся. R>Что вы имеете в виду под динамическим и статическим маршрутом? Если можно — на примере.
Когда на этапе компиляции неизвестно, сколько и какие маршрутизаторы надо пройти пакету что бы достигнуть цели. Как в udp.
Здравствуйте, Aviator, Вы писали:
A>Когда на этапе компиляции неизвестно, сколько и какие маршрутизаторы надо пройти пакету что бы достигнуть цели. Как в udp.
Все равно не очень доходчиво. В ESB пакеты могут трансформироваться, разветвляться, собираться, храниться, перенаправляться и т.д. и т.п. — вроде бы полет фантазии ничем не ограничены. Какую конкретно динамику вы хотите? Все ж таки приведите конкретный пример в отношении интеграции приложений.
Здравствуйте, Aviator, Вы писали:
A>Например тем, тем что маршрут вычисляется обычно динамически, а тут статически задаётся.
Позволю себе предположить, что в очереди ( шине ) динамическими являются только списки подключенных издателей (publishers) и потребителей (consumers), а сама структура (точки подключения , маршруты внутри шины ) и алгоритм обработки сообщений внутри шины неизменны, т.е. статичны и определяются настройками в момент запуска. Шина доставляет сообщение в точку, определенную настройками, а потребители данного типа сообщения могут в этой точке зарегистрироваться.
Может не стоит изобретать велосипед? Re: Как собрать процесс воедино?
