Ohhnews

分类导航

$ cd ..
DZone Java原文

Java企业级开发已为AI时代做好准备

#java#jakarta ee#人工智能#企业级开发#ai集成

人工智能正在改变软件工程,影响自动化、用户交互、数据分析和应用程序开发。开发者正在评估自己的技术栈如何适应这些变化。对于企业环境中的 Java 开发者来说,一个主要问题是 Java 企业生态系统是否为 AI 做好了准备。

简短的回答是:是的。你无需放弃 Java 或等待新平台即可构建支持 AI 的应用程序。Java 已经提供了成熟的 AI 库、模型提供商、API 和集成模式生态系统。Jakarta EE 提供了当今在生产级企业系统中部署这些技术所需的能力。该生态系统正在不断发展,新的举措正在探索将 AI 概念完美集成到 Jakarta EE API 和编程模型中。本文回顾了现有能力、Jakarta EE 在现代 AI 架构中的角色,以及潜在的未来发展。

AI 与软件工程

在软件工程中应用人工智能时,有必要区分 AI 在整个开发生命周期中的不同使用方式。AI 可以协助文档编写、测试、代码审查、架构探索和代码生成。从架构上看,这些用途分为两类:使用 AI 开发软件,以及将 AI 集成到软件本身之中。

第一类,即 AI 辅助软件开发,目前最为常见。开发者使用 AI 工具来生成、解释、重构或测试代码。虽然这些工具可以提高生产力,但如果没有适当的工程纪律,它们也会带来风险。上下文不足、未经审查的代码,或缺乏架构约束的工具,都可能导致缺陷、安全问题、复杂性或不一致的设计。AI 不会取代工程团队;如何有效使用 AI 仍然是团队的责任。

新的方法论正在涌现,以构建这种交互。像 vibe coding(氛围编码) 这样的方法侧重于通过对话式 AI 进行快速开发,而规格驱动开发(Spec-Driven Development)则在代码生成之前提供明确的规格、约束和上下文。基于代理的工作流越来越多地使用包含指令、规格和 Markdown 文件的仓库,为编码代理提供所需的上下文。这些方法不需要放弃 Java;Java 项目已经可以采用这些技术。

第二类则是将 AI 集成到应用程序本身之中,使 AI 成为应用程序运行时行为的一部分,而不仅仅是辅助开发者。应用程序可以使用大语言模型(LLM)来分类信息、生成内容、提取结构化数据、检索知识、执行工具,或在业务工作流中做出决策。这种结合带来了根本性的架构变革。

传统企业应用程序主要是确定性的:开发者通过方法、条件、规则、工作流和状态变更来定义流程。在输入和状态相同的情况下,执行路径是可预测的。相比之下,支持 AI 的应用程序可能呈现动态执行模型,其中部分行为在运行时由 LLM 决定。然而,并非每个支持 AI 的应用程序都应将控制权交给模型。

在实践中,AI 架构存在于一个自治频谱上。在一端,模型在严格控制下的确定性工作流中运行。随着自治程度的提高,模型可以选择工具、规划步骤、评估结果,并协调更复杂的操作。这种演进体现在核心自治模式(Core Autonomy Patterns)中,这些模式从确定性的有向无环图(DAG)工作流开始,逐步发展到更自治的方法,例如检索增强生成(RAG)、反思、规划、ReAct、多智能体系统和模型上下文协议(MCP)集成。随着灵活性的增加,可观测性、安全性、测试、治理、故障处理和控制等方面的架构责任也随之增加。

在评估 Jakarta EE 对 AI 的准备程度时,认识到这一区别至关重要。第一类已经与 Java 开发工具自然集成。第二类则凸显了企业平台的重要性:AI 应用程序仍然需要依赖注入、配置、REST API、持久化、消息传递、事务、安全性、可观测性、异步执行以及与外部系统的集成。这些正是 Jakarta EE 旨在提供的能力。

Jakarta EE 与 AI

现在,Java 和 Jakarta EE 已为 AI 时代做好准备。集成 AI 并不需要离开 Java 企业生态系统,也不需要等待新的规范。Jakarta EE 应用程序已经可以使用大语言模型(LLM),将 AI 嵌入业务工作流,并在更广泛的企业平台中运用这些能力。这在实际应用程序中显而易见。

例如,Skillwell Simulate 是一个基于 Jakarta EE 的平台,它与 AWS 服务集成,并使用 Amazon Bedrock 提供 AI 功能。这表明 Jakarta EE 应用程序可以采用现代 AI 服务,同时保留成熟企业架构的优势。

在最低抽象级别,应用程序可以使用 API 或 Java SDK 直接与 OpenAI、Anthropic、Google、Amazon Bedrock 等 AI 提供商集成。这种方法可以完全访问提供商特定的功能,但会增加耦合性。每个提供商使用不同的 API 模型、配置、格式、身份验证和功能。支持多个提供商会增加样板代码和复杂性。

企业开发者对这个挑战并不陌生。不同的供应商和技术提供不同的能力,因此抽象层提供统一的编程模型。AI 集成现在也采用了类似的方法。

OmniHai 是一个轻量级 Java AI 库,面向 Jakarta EE 和 MicroProfile 应用程序。OmniHai 不要求使用每个供应商的 SDK,而是提供一致的 AIService 抽象,并直接与提供商的 REST API 通信。它目前支持 OpenAI、Anthropic、Google AI、xAI、Mistral、Meta AI、Azure OpenAI、OpenRouter、Hugging Face、Ollama 以及自定义提供商

借助 CDI,AI 提供商可以直接注入到 Jakarta EE 组件中:应用程序与 AIService 交互,而不是与特定于提供商的 API 交互。这使得聊天交互可以在不同提供商之间使用一致的编程模型:OmniHai 还通过相同的抽象支持异步和流式操作。

从概念上讲,这种方法类似于 Jakarta Persistence 中 EntityManager 等抽象:应用程序使用通用 API,而实现细节保持隐藏。尽管这不是一个完美的类比,但它说明了 OmniHai 在管理多个 AI 提供商方面的作用。

LangChain4j CDI 提供了更高层次的编程模型。开发者无需直接操作 AIService 对象,而是将 AI 服务定义为 Java 接口。LangChain4j CDI 会检测带有 @RegisterAIService 注解的接口,并将其实现作为 CDI Bean 提供。

例如:开发者不需要编写实现类。基础设施会生成实现,并将接口连接到已配置的语言模型。生成的服务可以像任何其他 CDI Bean 一样被注入:这种编程模型对 Jakarta EE 开发者来说会非常熟悉。它类似于 Jakarta Data 中的仓库抽象,开发者通过接口定义契约,基础设施提供实现。虽然这些技术满足的需求不同,但这种模型减少了开发者必须编写的基础设施代码量。

LangChain4j 不仅仅支持基本的模型调用。它为超过 20 个 LLM 提供商提供了统一 API,并包含工具、检索增强生成(RAG)、聊天记忆、结构化输出、智能体、嵌入存储和其他 AI 功能的抽象。支持的集成包括 Amazon Bedrock、Anthropic、Azure OpenAI、Google AI Gemini、OpenAI、Mistral、OCI Generative AI 等。

这些选项代表了不同的抽象层次:

[LOADING...]

OmniHai 作为一种轻量级模板式抽象,允许应用程序通过通用的 AIService 调用操作。LangChain4j CDI 更进一步,提供了声明式的基于接口的模型,开发者描述 AI 服务,基础设施提供其实现。这两种方法都确保应用程序仍然是 Jakarta EE 应用程序。

一旦 AI 能力以 CDI Bean 的形式可用,它就能与平台完美集成。REST 端点可以暴露它,Jakarta Persistence 或 Jakarta NoSQL 可以提供数据,Jakarta Security 可以保护其操作,Jakarta Messaging 可以触发异步工作流,其他 Jakarta EE API 也继续发挥各自的作用。

问题不再是 Jakarta EE 能否与 AI 集成;它已经做到了。现在关键的架构决策是所需的抽象层次:为了最大控制而直接集成提供商,使用像 OmniHai 这样的轻量级通用 API,或者使用像 LangChain4j CDI 这样更丰富的 AI 编程模型。

Jakarta EE 与未来

Jakarta EE 已经支持 AI 集成,并且该平台仍在继续发展。Jakarta EE 12 专注于改进数据层,更新了 Jakarta Data、Jakarta Persistence、Jakarta NoSQL 以及新的 Jakarta Query 规范。这些改进对于依赖企业数据、持久化、检索和上下文内容的 AI 应用程序尤为重要。

主要的 AI 举措是 Jakarta Agentic AI,它已经发布了第一个里程碑版本。其目的不是取代 LangChain4j 或提供商 SDK,而是为使用 Jakarta EE 构建 AI 智能体提供一种标准编程模型。该规范定义了一小组概念,基于注解来构建智能体工作流,从而大大简化开发者的工作:

API用途
@Agent声明一个智能体类
@Trigger定义工作流入口点
@Decision决定工作流是否继续以及如何继续
@Action定义工作流中的一个步骤
@Outcome标记工作流的结束
@HandleException处理工作流内部的异常
@WorkflowScoped为每次工作流执行提供一个 CDI 上下文
LargeLanguageModel用于与 LLM 交互的可注入门面
Result表示决策的结果

该示例展示了一个简化的欺诈检测智能体,并说明了 Jakarta Agentic AI 如何与 Jakarta EE 编程模型集成。该智能体使用 LargeLanguageModel 门面进行 AI 交互,并利用 Jakarta Persistence 和 Jakarta NoSQL 访问企业数据。因此,AI 能力被纳入应用程序的一部分,而不是一个独立的编程环境。

结论

企业级 Java 如今已为 AI 做好准备,Jakarta EE 已经支持这种集成。开发者可以使用提供商 SDK、OmniHai 或 LangChain4j CDI 来添加 AI,同时继续利用 Jakarta EE 在持久化、安全性、消息传递、事务、REST API 和企业数据方面的功能。AI 作为一项集成能力增强了现有平台,而不是要求替换平台。

该生态系统持续进步。Jakarta EE 12 增强了数据基础,Jakarta Agentic AI 正在引入一种结构化的编程模型,用于构建与平台无缝集成的智能体。Jakarta EE 现在已为 AI 做好准备,并且随着平台的发展,其能力将不断提升。

本文表达的观点仅代表 DZone 贡献者本人。