Proposal: Add Optional ISoapEndpointRegistry for Explicit SOAP Endpoint Discovery

[frankyjquintero]

Proposal: Add Optional ISoapEndpointRegistry for Explicit SOAP Endpoint Discovery

Motivation

SoapCore currently registers SOAP endpoints as a side effect of middleware or endpoint routing configuration, but does not expose a structured registry of these endpoints.

This creates a gap between runtime behavior and observability/tooling needs.

Today, SOAP endpoints are not first-class discoverable entities. Instead, discovery must rely on:

• ASP.NET Core EndpointDataSource (which is not SOAP-aware)
• Routing heuristics
• Middleware inference

These approaches are not deterministic and introduce coupling to ASP.NET Core internals.

Problem Statement

There is no official API in SoapCore to:

• Enumerate registered SOAP endpoints reliably
• Build external tooling (documentation, UI, gateway, catalog)
• Attach SOAP-specific metadata at registration time
• Support consistent runtime discovery across hosting models (middleware vs endpoint routing)

As a result:

• Discovery is fragile
• Tooling is limited
• Extensibility is constrained

Impact

This limitation affects advanced scenarios such as:

• SOAP service catalogs / UI dashboards
• WSDL aggregation and centralized metadata exposure
• Observability and tracing per SOAP endpoint
• Gateway or proxy layers for SOAP services
• Multi-service or multi-tenant SOAP hosting

It also prevents SoapCore from evolving toward a more extensible service model abstraction.

Proposed Solution

Introduce an optional abstraction:

public interface ISoapEndpointRegistry
{
    void Register(SoapEndpointInfo endpoint);
    IReadOnlyList<SoapEndpointInfo> GetAll();
}

Integration Point

During UseSoapEndpoint execution, SoapCore would optionally register endpoint metadata:

registry?.Register(new SoapEndpointInfo
{
    Path = soapOptions.Path,
    ServiceType = serviceType,
    Serializer = opt.SoapSerializer
});

Design Principles

• Fully backward compatible
• Zero breaking changes
• Opt-in feature (only active when registry is registered in DI)
• No changes required for existing middleware usage
• Minimal surface area

Fallback Behavior

If no ISoapEndpointRegistry implementation is registered:

• SoapCore behavior remains unchanged
• No additional overhead is introduced

Benefits

This addition enables:

• Deterministic SOAP endpoint discovery
• Decoupling from ASP.NET Core routing internals
• Foundation for external tooling (UI, documentation, gateway)
• Improved observability and diagnostics
• Extensible service catalog capabilities

Key Design Rationale

ASP.NET Core routing is not a SOAP service model. SOAP endpoints are semantic service constructs, not just HTTP routes.

A dedicated registry provides a stable abstraction layer for these semantics without relying on framework internals.

Conclusion

This proposal introduces a minimal, non-invasive abstraction that significantly improves SoapCore's extensibility and observability while preserving full backward compatibility.

It enables future ecosystem features without changing existing behavior.

limited: endpointDataSource.Endpoints

future extensions:

EnableEndpointDataSourceDiscovery for