Add Conversation AI to Java SDK

[siri-varma]

PR Overview: Conversation AI SDK Integration

This PR introduces the Conversation AI SDK with the Converse API. The implementation is structured into the following categories:

• Core Logic
• Models
• Unit Tests

---

Core Logic

The core logic is implemented in a key class, as detailed below:

Class	Description	Details
DaprConversationClient	Manages the Conversation API. Handles validations and async calls.	- Calls the Conversation API asynchronously. - Validates inputs and manages job execution.

---

API Contracts

The following is the method signature for the Dapr Converse API:

Dapr Converse API

This method interacts with the Dapr Converse API.

Mono<DaprConversationResponse> converse(
    String conversationComponentName,
    List<DaprConversationInput> daprConversationInputs,
    String contextId,
    boolean scrubPii,
    double temperature
);

Parameter	Description
conversationComponentName	Name of the conversation component.
daprConversationInputs	List of prompts that are part of the conversation.
contextId	Identifier for an existing chat session (e.g., similar to ChatGPT).
scrubPii	Whether to scrub personally identifiable information (PII) from responses.
temperature	Controls response randomness (lower = more predictable, higher = more creative).
Returns	DaprConversationResponse

---

Models

The SDK follows the builder pattern for constructing models, ensuring cleaner and more maintainable object creation.

---

Tests

The testing strategy includes:

• Unit Tests: Validate individual components and business logic.

---

Issue Reference

We ensure that all PRs are linked to a relevant issue where the problem or feature has been discussed before implementation.

This PR closes the following issue: #1101

---

Checklist ✅

Please confirm the following before merging:

• Code compiles correctly
• Created/updated tests
• Extended the documentation

---

[siri-varma]

@salaboy, @artur-ciocanu please let me know what you think. Working on integration and unit tests in the meanwhile

[yaron2]

Great contribution, thanks @siri-varma

[salaboy]

this is great @siri-varma ! I will start reviewing soon!

[siri-varma]

For integration tests, we must spin up a mock for third party LLM endpoint. Do we have similar patterns in the current setup? (where dapr is talking to a third party api and receiving responses)

[salaboy]

@siri-varma I assume that you know that we had a previewClient, why is this introducing a new separated client for the conversation API? I would assume that we want to include this in PreviewClient first. @yaron2 we might need your help here.

[salaboy]

and sorry for the confusion if the PreviewClient is an old thing that we are not supposed to use anymore. As the workflows now have their own separate client, this might be the way to go.

[siri-varma]

Just to clarify, we are fine with current approach right ?

[salaboy]

@siri-varma should we call it conversation? instead of ai? as ai is too generic

[siri-varma]

Changed to conversation

[salaboy]

@siri-varma please include the nexus plugin as shown in here: https://github.com/dapr/java-sdk/blob/master/dapr-spring/pom.xml#L95

[siri-varma]

added the nexus plugin

[salaboy]

@siri-varma this is looking good, I left some comments that basically highlight my doubts about some JDK general topics. But this is looking really good, are you planning to add integration tests inside the sdk-tests too? We have some Spring Boot tests using Testcontainers, I was thinking that you might want to test the APIs against a local model running in a docker container to see that everything works as expected.

[siri-varma]

@salaboy I have tested the code by running it locally and using my OpenAI API Key.

Regarding the integration test, I think we will need an LLM model for daprd to communicate with, which unfortunately are huge in size. That is why I did not add the integration tests

Will get back to you on the integ tests

[salaboy]

Yeah check this https://java.testcontainers.org/modules/ollama/

[siri-varma]

@salaboy thank you for providing the testcontainer urls.

Like how we have url overrides for Scheduler, I was looking one for conversation too because we will have to point dapr to the local llm model. But could not find any

I tried looking in the below places and could not find anything. https://github.com/dapr/dapr/blob/2e7c61e933099b9d40fcdefbd57cc3e81069915a/pkg/injector/annotations/annotations.go#L73
https://github.com/dapr/dapr/blob/2e7c61e933099b9d40fcdefbd57cc3e81069915a/pkg/injector/consts/consts.go#L51
https://docs.dapr.io/reference/arguments-annotations-overview/

@salaboy or @cicoyle Would you folks know about this ?

[artur-ciocanu]

@siri-varma thanks a lot for your contribution. I have reviewed your PR and I have a few comments similar to #1255:

• Let's make sure the Conversation API is part of the DaprPreviewClient
• Let's make sure that we use the Alpha1 suffix for the Conversation API
• Let's make sure we keep everything under sdk module and we don't create a separate module for Conversation API
• For the Conversation API converse let's make sure we add private methods to validate all the input parameters, before invoking the GRPC API
• For Conversation API converse method let's ensure we keep number of parameters to a minimum, having to pass 5 parameters is too much. I think a better option is to have a builder for ConversationRequest which should be part of the model classes for DaprClient. This way we can have sane defaults, but allow users to override some of the values if desired.

CC: @salaboy @cicoyle

[artur-ciocanu]

@siri-varma thanks a lot for your contribution, I have left a longer comment with some of my thoughts.

Please take a look and let me know what you think.

[siri-varma]

@siri-varma thanks a lot for your contribution. I have reviewed your PR and I have a few comments similar to #1255:

• Let's make sure the Conversation API is part of the DaprPreviewClient
• Let's make sure that we use the Alpha1 suffix for the Conversation API
• Let's make sure we keep everything under sdk module and we don't create a separate module for Conversation API
• For the Conversation API converse let's make sure we add private methods to validate all the input parameters, before invoking the GRPC API
• For Conversation API converse method let's ensure we keep number of parameters to a minimum, having to pass 5 parameters is too much. I think a better option is to have a builder for ConversationRequest which should be part of the model classes for DaprClient. This way we can have sane defaults, but allow users to override some of the values if desired.

CC: @salaboy @cicoyle

@artur-ciocanu Addressed all the comments here as well.
@salaboy Added Integration tests too.