feat: [Orchestration] Spring AI integration

[CharlesDuboisSAP]

Context

AI/ai-sdk-java-backlog#8.

It's possible to use Spring AI and "under the hood" the AI SDK functionality is called

Feature scope:

• Added OrchestrationChatModel, a client
• Added OrchestrationChatOptions, that fits in the Spring AI Prompt
• Added OrchestrationSpringChatResponse
• Added a new SpringAiOrchestrationController end-to-end test

Definition of Done

• Functionality scope stated & covered
• Tests cover the scope above
• Error handling created / updated & covered by the tests above
• Aligned changes with the JavaScript SDK
• Documentation updated
• Release notes updated

[CharlesDuboisSAP]

Optional: T could be Parameter<ValueT> (from the class OrchestrationAiModel)
But I didn't find a way to do this...

[newtork]

I tested that:

private <T> Option<T> getLlmConfigParam(@Nonnull final String param) {
  return Option.of(getLlmConfigNonNull().getModelParams())
    .filter(p -> p instanceof Map<?,?>)
    .map(p -> (T) ((Map<?,?>) p).get(param))
    .filter(Objects::nonNull);
}

Unfortunately upon usage, the impliciit T is not recognized:

  public Double getPresencePenalty() {
-   return getLlmConfigParam(PRESENCE_PENALTY.getName());
+   return getLlmConfigParam(PRESENCE_PENALTY.getName()).getOrNull();
  }

However this would work, but it looks worse:

  public Double getPresencePenalty() {
-   return getLlmConfigParam(PRESENCE_PENALTY.getName());
+   return this.<Double>getLlmConfigParam(PRESENCE_PENALTY.getName()).getOrNull();
  }

[newtork]

(Question)

So we're planning to throw an exception, when the provided prompt argument does not contain an OrchestrationChatOptions object. This is implicit behavior. Users may not catch that limitation on design-time.

Would it be possible to make it explicit, e.g. by enforcing a constructor argument for OrchestrationChatOptions OrchestrationModuleConfig on OrchestrationChatModel? Thus passing it on for every call as fallback?

[CharlesDuboisSAP]

• call is part if the interface, cannot be modified.
• If we add a constructor param then there are 2 different places to add a config. We have to merge them which is implicit behaviour.

This is not solveable

[newtork]

If not constructor - offering an optional setDefaultChatOptions(..) is probably not helping either, right? Because then you would need to thin about merging options ._.

[newtork]

(Comment)

Why the drive-by changes 😅

[CharlesDuboisSAP]

this ## adds underlines which makes it more readable because the file is super long, it also aligns with the other files.

underline

[newtork]

(Major)

(I expect static code checks to flag warnings for) incomplete JavaDoc on public API.

[MatKuhr]

I can see that we only need this for copy. Did you check if we really need to support copy? If not, we could think about throwing a NotImplementedException

[CharlesDuboisSAP]

OrchestrationModuleConfig is immutable. I will turn the deep copy into a normal copy since config cannot be modified anyway.

[MatKuhr]

But the config inside of OrchestrationModuleConfig can be modified, e.g. LlmModuleConfig. Shallow copy is only okay if we are sure it won't be modified.

[newtork]

looks lgtm to me