Каковы преимущества JCA?

Question

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

Мы поняли, что существуют части кода, обозначающие значения, которые являются общими для всех этих конкретных реализаций соединителей, и мы решили упростить разработку будущих соединителей с помощью одного универсального соединителя.Этот соединитель будет способен форматировать сообщения в формат, ожидаемый серверной частью, и отправлять их с использованием доступного транспортного механизма.Например, формат сообщения фиксированной длины через MQ или через сокет.

Одна из дилемм, с которыми мы сталкиваемся, - это наиболее подходящая технология для такого рода соединителей.До сих пор наши соединители были базовыми классами Java, которые реализуют общий интерфейс Java.Поскольку мы обычно размещаем наши приложения на каком-нибудь сервере приложений Java EE, кажется, что архитектура Java Connector была бы наиболее подходящей технологией для этой части программного обеспечения.Однако реализация JCA-совместимого соединителя представляется относительно сложной.Каковы ощутимые преимущества перехода на стандарт – JCA и оправдывают ли преимущества дополнительные усилия?

Answer 1

Действительно , JCA кажется наиболее подходящая технология для вас.Уже были приведены отличные аргументы, а именно переносимость, стандартизированный интерфейс, объединение пулов соединений и поддержка транзакций.И не забывайте о безопасности.

С WebSphere Process server адаптеры могут быть представлены как служба SCA, которая может иметь много преимуществ, если это важно для вас.

Кроме того, некоторые инструменты разработки имеют обширную поддержку для разработки и тестирования JCA-коннекторов.

Другим преимуществом является то, что (опытные) администраторы Java EE и разработчики Java EE (должны) знать стандарт, поэтому администрирование и разработку должно быть легко упростить.

Но, в конце концов, вам придется найти причины для внедрения JCA, исходя из масштаба вашего проекта, ваших планов на будущее или, возможно, в рамках политики вашей компании.

Answer 2

Короткий ответ:Я не вижу никакой пользы в выборе JCA по сравнению с другими технологиями, я рассматриваю это как недостаток, поскольку вам нужен контейнер Java EE.

Длинный ответ:

Я уже некоторое время скептически отношусь к этим стандартам Java EE.Я не вижу убедительного технический причина больше использовать полнофункциональный Java EE-сервер, поскольку существуют лучшие реализации с открытым исходным кодом для каждый предлагаемая функция.Я несколько раз сталкивался с несовместимостью реализации при переходе в / из "корпоративных решений".

Идея для JCA всплывает здесь прямо сейчас, и я настаиваю на том, чтобы попробовать верблюд - апач или весенняя интеграция вместо этого.Я полностью за реализации с открытым исходным кодом, которые вы можете использовать везде.И там многое происходит.Проверить этот список компонентов.Конечно, maybe меньше, чем то, что уже разработано с помощью JCA, но каждый бит имеет открытый исходный код, и все это в одном месте.Кроме того, я считаю, что документация проще и полнее.Стремление к интеграции требует мощного SPI с большим количеством открытых исходных текстов, реальных примеров, разработанных тем же способом, и которые можно найти в том же месте.

Я ненавижу негатив, но мне не нравятся полнофункциональные серверы приложений.Например, я бы выбрал tomcat и terracota в любой день по сравнению с другими продуктами "enterprisey", точно так же, как я бы выбрал camel до JCA, пока не будет доказана необходимость JCA.Мне не нравится идея Комитета Java указывать, как я должен разрабатывать свои собственные приложения, потому что я им не доверяю.Я считаю, что в моих наилучших интересах, когда часть программного обеспечения может работать так же легко на Java SE / RCP, как и в средах Java EE или в чистом контейнере сервлетов.

Answer 3

Я только что разработал адаптер входящих ресурсов для устройства gps, обменивающегося данными по проприетарному протоколу.Это было не так уж много хлопот, хотя у меня сложилось впечатление, что разработка исходящего может потребовать дополнительной работы.Самое худшее, что связано с JCA, - это отсутствие документации.Кажется, во всех книгах и статьях есть один и тот же глупый пример.

Что меня больше всего радует, так это портативность.После написания адаптера вы можете подключить rar (архив адаптера ресурсов) к любому серверу приложений, чтобы предоставить развернутым приложениям возможность взаимодействовать с eis, поддерживаемыми вашим ra.Или вы можете подключить rar к war / ear.

Answer 4

Преимущества в первую очередь для поставщиков, которые хотят продавать соединители для собственных серверных систем для использования с любым сервером приложений, для клиентов, которые хотят иметь возможность подключать соединитель, не беспокоясь о том, работает ли он только на WebLogic, а не Websphere, и т.д.Действительно, это цель Java EE в целом.

Обратите внимание, что JBoss решила внедрить несколько функций в JCA, например, соединения JDBC проходят через JCA.

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

Answer 5

Звучит как хорошее применение для JBI контейнер со связующими компонентами. Обсуждение о JCA против JBI.