Интересен универсальный (и концептуально правильный) подход к решению вопроса интеграции разных приложений.

Вопрос хоть и абстрактный, но приведу пример. Допустим у вас есть приложения CMS, форум и веб-галерея от разных производителей. Каждое из них работает со своей базой пользователей, со своими наборами шаблонов.

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

Короче дано: 
1. пользователь должен авторизоваться единожды для всех трех приложений
2. В каком бы из приложений пользователь ни выбрал шаблон, остальные должны два должны об этом узнать и тоже обеспечить свой вывод в выбранном стиле
3. Классы, непосредственно заведующие выводом и авторизацией должны бы существовать в единственном числе (синглетоны)
4. RMI и cookie решения не интересуют. Хочется иметь именно единственный экземпляр класса, разделяемый между тремя приложениями в одном контейнере и дергающие друг друга за методы напрямую.
5. Приложения могут знать про существование других приложений всё что угодно - через файлы конфигурации.
6. Конфигурация контейнера недоступна (Tomcatовы server.xml, web.xml) - это потому, что решение должно быть применимо к разделяемому хостингу.
7. К 6-му - соотв. недоступны и каталоги общих библиотек, по этому ресурс, даже размещенный в своём контекстве, видимо работать не будет - ODBC-шный же пут у Томката не работает, если либы лежат в контексте приложения.


Всё, решается, если у приложения есть возможность расшарить интерфейс созданного им экземпляра класса где-нить в общей области.. Только вот как.. Может JNDI позволяет? 

можно сделать через вебсервисы, ИМХО... Ну, может, еще получится воспользоваться CORBA... Вобщем в любом случае это достаточно не тривиально. Может проще завести общую БД для хранения конфигов? А перед тем как показывать нужный гуй, просто залезать в эту БД и доставать нужную настройку

Это сообщение отредактировал(а) y3u - 1.10.2006, 14:44

Не, RMI, Corba, SOAP - это всё, конечно, красиво, но как-то попахивает оверхедом. Ну зачем нужно превращать каждый запрос в XML (или ещё во что-то), дёргать свой же сервер, на том конце декодировать запрос, и после обработки слать обратно - и это на каждый запрос вида "отрисуй мне эту строчку по шаблону", "оформи мне этот блочок по стилю", "проверь - разрешена ли эта опция клиенту" - их же тысячи на запрос могут быть.... 

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

Общая БД - это само собой, а бизнес-логика - д/б в приложении. Есть объект "пользователь", чьи методы реализованы классом, а данные хранятся в базе, и который как-то используется разными приложениями - пусть один экземпляр пользователя для всех приложений и будет, при интеграции нужно будет только прописать интерфейсы понятные каждому отдельно взятому приложению. А если в каждом аппликейшне свой инстанс "пользователя" будет жить, то мало того, что расходы на ресурсы возрастут втрое, но и на каждое обращение его всё равно нужно будет из базы вытаскивать - что бы узнать, не изменил ли его сосед, а тут опять же - на каждый чих не наздравкаешься - проще кешировать такие объекты в своём кеше, уже созданными и не обращаться к серверу базы данных каждый раз - тот же оверхед, пусть она и кеширует данные. 

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

JNDI позволяет, почему нет. Только не понятно чем обращение к некоторому узлу в JNDI и получение оттуда экземпляра класса будет отличаться от вызова вебсервиса. Хотя, возможно, и проще. Хотя здесь, конечно, никаких удаленных вызовов методов не будет. Главное чтобы класс реализовывал интерфейс Serializable.

Зачем Serializable?
Живёт в JVM некий инстанс "пользователь". Другой инстанс другого класса в этой же JVM испытывает настойчивое желание поговрить с этим "пользователем", не беда, что они из разных аппликейшенов. Второму инстансу просто надо как-то получить ссылку на интересующий его интерфейс первого. Совершенно не обязательно для этого его сериализовать, даже, наверное, вредно - потому что я чувствую, что тут попахивает тем, что в результате в сервере поселятся два клона исходного "пользователя" и станут друг с другом потенциально конфликтовать: один аппликейшн будет говорить своему клону "пользователя" одно, другой - своему другое, и постепенно у клонов "пользователя" сформируются совершенно разные взгляды на жизнь ;)

Это сообщение отредактировал(а) 3x3 - 1.10.2006, 18:25

Очень похожий вопрос обсуждался вот тут: http://forum.vingrad.ru/index.php?showtopic=83074&st=0.

Задача стояла практически такая же, разве что отсутствовали ограничения пп. 6 и 7. В общем, там можно кое-чего полезного поДчерпнуть.

Добавлено @ 18:51 


Тут, ИМХО, выходит практически неразрешимое противоречие с п. 7 (отсутствие доступа к общим библиотекам). Даже если привести классы из разных приложений к общему знаменателю (интерфейсу), то экземпляры, созданные одним ClassLoader'ом, будучи переданные в другое приложение, там не поймутся. Если только не продублировать jar'ы всех приложений во всех контекстах.

Добавлено @ 18:55 


Абсолютно согласен. Ремоутинг и сериализация - это очень хлюпкие абстракции (leaky abstractions, как говорит Джол Сполски), именно в отношении иллющии работы как с локальными объектами 

Хм, вот это было бы самое красивое и отлично масштабируемое решение, идеальное наверное:



Тут и безопасность на уровне конфигурации попробовать задать можно - ведь вообще всем приложениям давать потенциальную возможность подёргать инстансы за методы - тоже не хорошо, надо иметь возможность контролировать доступ.

Жаль что chief39 тему не продолжил.. Подниму-ка я ту веточку.

Иначе просто не понятно каким образом будет храниться объект в JNDI если этот самый сервис JNDI - удаленный. Для того, чтобы передать объект по сети нужно его сериализовать. Собственно, вот. В рамках одной JVM - там да, необходимости нет. Хотя, возможно, я просто чего-то недопонимаю.

Видимо JNDI не годится. Объект нужно не хранить, а расшарить интерфейс конкретного экземпляра конкретным аппликейшенам. С хранением разбирается тот апликейшен, который создал инстанс.




Или я недопонимаю. Ещё раз:
1. Есть независимое приложение "А". Оно содержит сервлет, бин или что угодно, что заведует созданием пользователей, сохранением их в какой-то там базе и извлечением оттуда, отправкой почты этим юзерам, другой приватной информацией. Оно само предоставляет интерфейс к своим функциям - по управлению юзерами, плюс может вернуть интерфейс конкретного инстанса класса юзера.
2. Есть другое независимое приложение "Б", которое знает про все эти интерфейсы и хотело бы пользоваться объектами, размещенными в приложении "А".

Спрашивается - как код из приложения "Б" может получить указатель на интерфейс объекта, живущего в коллекции одного из классов приложения "А". Как вообще разные приложения могут общаться между собой, минуя уровень контейнера, который может быть недоступен для конфигурации.