-
Notifications
You must be signed in to change notification settings - Fork 0
Kernel Channel System
The Channel System, located within the kernel module, is responsible for enabling type-safe, resource-managed, and distributed message passing between various components of the SolaceCore framework. It is designed with platform independence as a key consideration.
The primary goal of the Channel System is to provide a robust and flexible mechanism for inter-component communication. It emphasizes:
- Type Safety: Ensuring that messages conform to expected types at both compile-time and runtime.
-
Resource Management: Proper handling and cleanup of resources associated with channels and ports, often leveraging a
Disposablepattern. - Distributed Operation: Designed to function effectively in distributed environments with minimal shared state and low-overhead message passing.
- Platform Independence: Core channel logic is intended to be common across all supported platforms.
The foundation of the Channel System is the Port.kt file, which defines the primary Port<T> interface and several crucial nested interfaces and classes for message handling, protocol adaptation, type conversion, and connection management. It leverages kotlinx.coroutines.channels.Channel for its underlying asynchronous communication and io.github.solaceharmony.core.lifecycle.Disposable for resource management.
Drawing from the Interface_and_Port_System_Design.md, the port system is a cornerstone of the actor interface within SolaceCore. It's engineered for flexible, type-safe connections between actors. Conceptually, while the underlying Port<T> interface is generic, ports fulfill distinct roles such as:
- Input Ports: Designated for receiving messages.
- Output Ports: Designated for sending messages.
- Tool Ports: Potentially used for specialized request/response interactions or utility functions (though less explicitly defined in the current codebase compared to input/output patterns observed in actor examples).
The design emphasizes dynamic connection capabilities between compatible output and input ports, leveraging Kotlin's KClass for type safety. This dynamism is vital for constructing adaptable and reconfigurable actor-based systems. The design document also noted that dynamic port creation and disconnection were areas of ongoing development, aiming to further enhance this flexibility.
This is the central interface for any communication endpoint in the system.
-
Inheritance: Implements
io.github.solaceharmony.core.lifecycle.Disposable. -
Key Properties:
-
id: String: A unique identifier for the port, automatically generatable. -
name: String: A human-readable name for the port. -
type: KClass<out T>: Specifies the Kotlin class of messages the port handles, ensuring type safety.
-
-
Key Methods:
-
suspend fun send(message: T): Sends a message through the port. Can throwPortException.Validation. -
fun asChannel(): Channel<T>: Returns the underlyingkotlinx.coroutines.channels.Channelassociated with this port.
-
-
Companion Object (
Port.Companion):-
fun generateId(): String: Generates a unique ID string (e.g., "port-xxxxxxxxxxxxxxxx"). -
fun <IN : Any, OUT : Any> connect(...): Factory method to create and validate aPortConnection(see below).
-
Defines a contract for processing messages.
-
Key Method:
-
suspend fun handle(message: IN): OUT: Processes an input message of typeINand returns an output of typeOUT.
-
Facilitates conversion between different data protocols or formats.
-
Key Methods:
-
suspend fun encode(source: SOURCE): TARGET: Encodes a source object to the target type. -
suspend fun decode(target: TARGET): SOURCE: Decodes a target object back to the source type. -
fun canHandle(sourceType: KClass<*>, targetType: KClass<*>) : Boolean: Checks if the adapter can handle conversion between specified types.
-
Represents a rule for converting an input type IN to an output type OUT.
-
Key Abstract Methods:
-
abstract suspend fun convert(input: IN): OUT: Performs the conversion. Can throwPortException.Validation. -
abstract fun canHandle(inputType: KClass<*>, outputType: KClass<*>) : Boolean: Checks if the rule applies to the given types. -
abstract fun describe(): String: Provides a description of the rule.
-
-
Companion Object (
Port.ConversionRule.Companion):-
internal inline fun <reified IN : Any, reified OUT : Any> create(...): Factory method to createConversionRuleinstances.
-
Note — verify against source: §1.1.2.6 below describes
PortConnectionas a validated connection wrapper. The wiki Kernel & Ports page describes the same type as additionally actively routing messages when started, while §1.1.7 (Future Enhancements) below says message piping is not implemented. These three claims need reconciling against the currentPort.ktsource — recorded here so it isn't lost.
Represents a validated connection between a source port and a target port, potentially involving handlers, a protocol adapter, and conversion rules.
-
Key Properties:
sourcePort: Port<@UnsafeVariance IN>targetPort: Port<@UnsafeVariance OUT>handlers: List<Port.MessageHandler<IN, Any>>protocolAdapter: Port.ProtocolAdapter<*, @UnsafeVariance OUT>?rules: List<Port.ConversionRule<IN, OUT>>
-
Key Methods:
-
fun validateConnection(): Validates if the connection is possible based on types, adapter, and rules. ThrowsPortConnectionExceptionon failure. - Internal methods
canConnect(),validateConversionChain(), andbuildConnectionErrorMessage()support the validation logic.
-
The relationships between these core abstractions can be visualized as follows:
classDiagram
direction LR
namespace lifecycle {
class Disposable {
<<Interface>>
+dispose()
}
}
namespace kernel_channels_ports {
class Port~T~ {
<<Interface>>
+id: String
+name: String
+type: KClass~out T~
+asChannel() Channel~T~
+send(message: T)
}
class MessageHandler~IN, OUT~ {
<<Interface>>
+handle(message: IN) OUT
}
class ProtocolAdapter~SOURCE, TARGET~ {
<<Interface>>
+encode(source: SOURCE) TARGET
+decode(target: TARGET) SOURCE
+canHandle(sourceType: KClass, targetType: KClass) Boolean
}
class ConversionRule~IN, OUT~ {
<<Abstract>>
+convert(input: IN) OUT
+canHandle(inputType: KClass, outputType: KClass) Boolean
+describe() String
}
class PortConnection~IN, OUT~ {
+sourcePort: Port~IN~
+targetPort: Port~OUT~
+handlers: List~MessageHandler~
+protocolAdapter: ProtocolAdapter
+rules: List~ConversionRule~
+validateConnection()
}
}
Disposable <|-- Port
PortConnection o-- Port : sourcePort
PortConnection o-- Port : targetPort
PortConnection *-- MessageHandler : handlers
PortConnection o-- ProtocolAdapter : protocolAdapter
PortConnection *-- ConversionRule : rules
Port o-- MessageHandler : can use
Port o-- ProtocolAdapter : can use
Port o-- ConversionRule : can use
SolaceCore SSOT wiki · published from wiki/ by .github/workflows/publish-wiki.yml · edit the source in the repo, not the wiki.
Orientation
- Architectural Deep Dive
- Architecture Overview
- Design vs Implementation
- Framework Actor System
- Framework Architectural Vision
- Framework Concurrency and Communication
- Framework Data Storage and Management
- Framework Deployment and Containerization
- Framework Development Roadmap
- Framework Hot-Pluggable System
- Framework Implementation Status
- Framework Observability and Monitoring
- Framework Port System
- Framework System Architecture
- Framework Workflow Management
- Project Status
- Project Status Report
- Quick Status
- Solace Core Framework Architecture
- SolaceCore Architecture Overview
- Vision & Solace AI
Runtime
- Actor Builder
- Actor Communication Sequence Diagram
- Actor Core Definitions
- Actor Graph View
- Actor Metrics
- Actor Module Architecture
- Actor Queue Hibernation and Correlation
- Actor Roadmap
- Actor State Recovery Subsystem
- Actor State Serialization Subsystem
- Actor Supervision Module
- Actor System Architecture
- Actor System Class Diagram
- Actor Usage Examples
- Compose App Features
- JVM Scripting Implementations
- Kernel & Ports
- Kernel Channel System
- Kernel Future Enhancements
- Kernel Module Architecture
- Kernel Port Implementations and Exceptions
- Kernel Port Usage Example
- Kernel Testing Strategy
- Lifecycle Class Diagram
- Lifecycle Management Architecture
- Pipeline DSL
- Real-Time UI Implementation
- Scripting Module Architecture
- Scripting Module Design
- Scripting Supporting Components
- Shared Memory
- Storage & Persistence
- Storage Abstractions Architecture
- Storage Caching Subsystem
- Storage Checklist
- Storage Compression Subsystem
- Storage Core Interfaces
- Storage Encryption Subsystem
- Storage File-Based Architecture
- Storage File-Based Implementations
- Storage In-Memory Architecture
- Storage In-Memory Implementations
- Storage JVM Serialization Utilities
- Storage Module Architecture
- Storage Serialization Compression Encryption
- Storage Specialized Interfaces Architecture
- Storage Status and Future Plans
- Storage Testing
- Storage Thread Safety Guide
- Storage Thread Safety and Deadlock Prevention
- Storage Transactions
- Storage Usage Examples
- Supervisor and Hot Swap
- SupervisorActor
- System Architecture Diagram
- Workflow Management Architecture
- Workflow Management Design Concept
- Workflow Orchestration
Solace AI
- Confusion Corrector
- Inference Cube
- Inference Cube Technical Architecture
- Long-Term Memory
- MCP and Tool Format
- Memory & Reflection
- Memory Compression
- Memory Feature Overview
- Memory Retrieval
- Mood & Emotional Model
- Mood Module Implementation
- Mouth Tool Technical Spec
- Multimodal Nudging
- Perception Actors
- Provider Specs
- Reflection Memory
- Solace AI Overview
- Supervisor AI
- Supervisor Emotional Model Integration
- Time Actor
- Voice & Mouth Tool
- Working Memory
- Zoom Level Technical Spec
- Zoom Levels
Reference
- Advanced Workflow Example
- Basic Actor Usage
- Build System and Dependencies
- Development Tooling and Practices
- Documentation Catalog
- Documentation Index
- Feature Index
- Glossary
- How the Wiki Publishes
- JVM Utilities
- Kotlin Implementation Details
- Kotlin-Aligned Architecture Overview
- Kotlin-Aligned Contributing
- Kotlin-Aligned Core Architectural Principles
- Kotlin-Aligned Daily Development Workflow
- Kotlin-Aligned Development Examples
- Kotlin-Aligned Development Workflow
- Kotlin-Aligned Documentation
- Kotlin-Aligned Implementation Status
- Kotlin-Aligned Key Concepts
- Kotlin-Aligned Known Issues
- Kotlin-Aligned Quick Start
- Kotlin-Aligned Running the System
- Kotlin-Aligned System Architecture
- LangChain Actor Code Changes
- LangChain Actor Usage Improvements
- LangChain ActorInterface Code Changes
- LangChain Best Practices
- LangChain Bugs
- LangChain Chain Implementation
- LangChain Code Changes
- LangChain Code Changes Rollout and Impact
- LangChain Configuration Management Improvements
- LangChain Configuration Recommendations
- LangChain Core Architecture Recommendations
- LangChain Directory Structure Changes
- LangChain Documentation Improvements
- LangChain Dynamic Wiring Rollout Notes
- LangChain Fix Proposal
- LangChain Implementation Priorities
- LangChain Lifecycle Management Improvements
- LangChain Memory Integration Recommendations
- LangChain Metrics and Observability Recommendations
- LangChain Migration Strategy
- LangChain New Files Needed
- LangChain New Packages to Add
- LangChain Package-by-Package Improvements
- LangChain Patterns
- LangChain Port Code Changes
- LangChain Port System Recommendations
- LangChain Port Usability Improvements
- LangChain Prompt Management Recommendations
- LangChain Recommendations
- LangChain Recommendations Rollout Plan
- LangChain Required Interface Changes
- LangChain Testing Changes
- LangChain Testing Improvements
- LangChain Testing Recommendations
- LangChain Tool Integration Recommendations
- LangChain Type-Safe Dynamic Wiring
- LangChain Type-Safe Dynamic Wiring System
- LangChain Usage Design Improvements
- Master Checklist
- Roadmap
- Roadmap Issues
- Roadmap Phase 1 Stability and Testing
- Roadmap Phase 2 Production Infrastructure
- Roadmap Phase 3 Documentation and Developer Experience
- Roadmap Phase 4 Graph Database Integration
- Roadmap Phase 5 Security Framework
- Roadmap Phase 6 Distributed System
- Roadmap Phase 7 Advanced Features
- Roadmap Phase 8 Ecosystem Development
- Roadmap Timeline and Success Metrics
- Setup Instructions
- Sketch Architecture
- Status Documentation
- Task 1 Core Tests
- Task 2 Connection Wiring
- Task 3 Concurrency Issues
- Task 4 Dynamic Registration
- Task 5 Integration Tests
- Task 6 Deadlock Detection
- Task Documentation
- Test Coverage Checklist
- Testing Strategy