Network topology graph

Problem and backend

This example separates reachability, service impact, and isolated components in a network topology. It uses TinkerGraph to isolate modeling from container and network variance. Read core model and TinkerPop first; use the selection guide before production.

Model

• Nodes: Site/Device/Segment/Service
• Edges: CONTAINS_DEVICE/CONNECTED_TO/MEMBER_OF_SEGMENT/HOSTS_SERVICE
• Key properties: siteId, deviceId, segmentId, serviceId, cidr, tier, status

Prerequisites and release boundary

Use JDK 21, commit 3e0fa7cb9e3bc70c2743aeebda2487f3e45e4907, and the checked-in wrapper. Examples are not published; run this release fixture as a Gradle project from the release source checkout. In a consumer application, select only bluetape4k-dependencies:<ecosystem-version> and add the required graph module without an individual version.

Run and observe

./gradlew :network-topology-examples:test --tests "io.bluetape4k.graph.examples.networktopology.TinkerGraphNetworkTopologyImpactTest"

The test asserts that reachable devices, affected services, and isolated components match the topology fixture. A failure usually means a connectivity edge changed direction, an isolation edge is missing, or the impact traversal exceeded its intended boundary.

Reading order

1. Schema
2. Service
3. Shared executable contract
4. Concrete TinkerGraph test
5. Build file

Continue from security-attack-path, then read observability-graph. Also see paired APIs, testing, and operations.

Exercises and production gaps

Add one result-changing edge and assertion; repeat through the suspend API; then run a persistent-backend concrete test serially. Add disconnected and malformed inputs as diagnostics. This fixture does not prove throughput, clustering, authorization, tenant isolation, migration, backup, remote-driver timeout, or index quality.