Краткий ответ: я не вижу преимущества в выборе JCA по сравнению с другими технологиями, я считаю это недостатком, поскольку вам нужен контейнер Java EE.
Длинный ответ:
Я уже некоторое время скептически отношусь к этим стандартам Java EE. Я больше не вижу веской технической причины использовать полнофункциональный сервер Java EE, поскольку существуют лучшие реализации с открытым исходным кодом для каждой предлагаемой функции. Меня несколько раз укусили несовместимости реализации при переходе к / от «корпоративных решений».
Идея для JCA появляется здесь прямо сейчас, и я пытаюсь попробовать apache camel или весеннюю интеграцию . Я полностью за реализацию с открытым исходным кодом, которую вы можете использовать везде. И там много чего происходит. Проверьте этот список компонентов . Конечно, может быть меньше, чем то, что уже разработано с JCA, но каждый бит с открытым исходным кодом, и все это в одном месте. Кроме того, я считаю, что документация проще и полнее. Стремление к интеграции требует мощного SPI с множеством открытых исходных кодов, реальных примеров, разработанных таким же образом, которые можно найти в одном месте.
Я ненавижу негатив, но мне не нравятся полнофункциональные серверы приложений. Например, я бы пошел за котом и терракотой в любой день за другие "корпоративные" продукты, точно так же, как я бы пошел с верблюдом до JCA, пока не будет доказана необходимость JCA. Мне не нравится идея Комитета по Java рассказать, как я должен разрабатывать свои собственные приложения, потому что я им не доверяю. Я считаю, что в моих интересах, когда часть программного обеспечения может работать так же легко на Java SE / RCP, как в средах Java EE или в чистом контейнере сервлетов.