[STORM-3860] Decouple Topology Definition from Java Code

Current Topology definition is tightly integrated with Java code. Even though the topology definition is defined in thrift, the Java class itself is serialized at the ComponentObject level as a binary serialized java object.

If the ComponentObject contains, two fields:

• type of Component (shell or java..) - string


• name of class - string
  
  then the topology definition can be decoupled from Java code (and serialization requirement). The topology can be displayed directly from the definition. And the definition can be created via other visualization tools.

Jars used by the topology can be part of deployment rather than topology definition.

In future, the same topology definition can be deployed in a different way, in a different environment (i.e. Kubernetes) in a much lightweight manner to achieve higher throughput per megabyte CPU.

---
Originally reported by bipinprasad, imported from: Decouple Topology Definition from Java Code

• status: Open
  
• priority: Major
  
• resolution: Unresolved
  
• imported: 2025-01-24
  

Start by tracing how the ComponentObject represents topology components and how the thrift topology definition relates to the serialized Java class. Define the boundaries between topology definition and deployment artifacts, including component type, class name, and jars. Done means topology definitions can be displayed and created without Java object serialization.

Written by the indexing model from the issue text.