Каковы преимущества JCA?
Вы можете использовать перед этим GO:
IF EXISTS(SELECT * FROM SYS.VIEWS WHERE NAME = 'TP_LEAVEDATA') BEGIN
EXEC SP_RENAME 'TP_LEAVEDATA', 'TP_LEAVEDATA_BKP_EXPORT_TEST1' ;
END;
GO
CREATE VIEW TP_LEAVEDATA AS
SELECT USERNAME, Dept, LeaveType, LeaveFrom, LeaveUpto
FROM LeaveRequest_DATA;
Другой вариант - использовать динамический SQL для создания представления.
5 ответов
Действительно, JCA кажется наиболее подходящей для вас технологией. Уже были приведены отличные аргументы: переносимость, стандартизированный интерфейс, пул соединений и поддержка транзакций. И не забывайте о безопасности.
С помощью сервера WebSphere Process адаптеры могут быть представлены как сервис SCA, который может иметь много преимуществ, если это важно для вас.
Также некоторые инструменты разработки имеют обширную поддержку для разработки и тестирования. JCA-коннекторы.
Еще одним преимуществом являются (опытные) администраторы Java EE и разработчики Java EE (должны) знать стандарт, поэтому администрирование и разработку должно быть легко упорядочено.
Но, в конце концов, вам нужно найти причины для реализации JCA в зависимости от объема вашего проекта,
Краткий ответ: я не вижу преимущества в выборе JCA по сравнению с другими технологиями, я считаю это недостатком, поскольку вам нужна Java Контейнер EE.
Длинный ответ:
Я уже некоторое время скептически отношусь к этим стандартам Java EE. Я не вижу убедительной технической причины использовать полнофункциональный сервер Java EE, поскольку существуют лучшие реализации с открытым исходным кодом для каждой предлагаемой функции . Меня несколько раз укусили несовместимости реализации при переходе к / от «корпоративных решений».
Идея для JCA сейчас появляется здесь, и я пытаюсь попробовать apache camel или весенняя интеграция вместо. Я полностью за реализацию с открытым исходным кодом, которую вы можете использовать везде. И там много чего происходит. Проверьте этот список компонентов . Конечно, может быть меньше, чем то, что уже разработано с JCA, но каждый бит с открытым исходным кодом, и все это в одном месте. Кроме того, я считаю, что документация проще и полнее. Стремление к интеграции требует мощного SPI с множеством открытых исходных кодов, реальных живых примеров, разработанных таким же образом, и их можно найти в одном месте.
Я ненавижу негатив, но мне не нравится полнофункциональные серверы приложений. Например, я бы пошел на tomcat и terracota каждый день поверх других «корпоративных» продуктов, точно так же, как я бы пошел с верблюдом до JCA, пока не будет доказана необходимость JCA. Мне не нравится идея Комитета по Java рассказывать, как я должен разрабатывать свои собственные приложения, потому что я им не доверяю.
Я только что разработал входящий адаптер ресурса для устройства gps, связывающегося по собственному протоколу. Это не было так много стычки, хотя у меня есть впечатление, что разработка исходящей могла бы потребовать большего количества работы. Худшей вещью с JCA является отсутствие документации. Все книги и статьи, кажется, имеют тот же немой пример.
Вещью, которой я больше всего доволен, является мобильность. После того как Вы записали адаптер, можно включить rar (архив адаптера ресурса) в любой сервер приложений, чтобы предоставить развертываемым приложениям способность общаться с eis, поддерживаемым Ра. Или можно связать rar в войну/ухо.
Преимущества, прежде всего, для поставщиков, которые хотят продать коннекторы собственным системам бэкэнда для использования с любым сервером приложений для клиентов, которые хотят смочь заглядывать коннектору, не волнуясь о том, работает ли это только над WebLogic не Websphere и т.д. Действительно это - цель Java EE в целом.
Обратите внимание, что JBoss решил поместить несколько вещей в JCA, например, соединения JDBC идут через JCA.
Ваш будущий клиентский код будет иметь стандартизированный интерфейс, некоторая поддержка объединения и транзакции и т.д., но важно сохранить вид большего изображения; а именно, то, что преимущества не предназначены для Вас и Вашего одного проекта а именно, но для экосистемы программного обеспечения, состоящей из многих серверов приложений, многих систем бэкэнда, много коннекторов и так далее.
Походит на хорошее использование для контейнера JBI со связующими компонентами. Обсуждение JCA по сравнению с JBI.