Psr18 Transport Laravel Package

Product Decisions This Supports

• Build vs. buy for SOAP integrations. Many enterprise integrations (ERP, payment gateways, shipping, banking, government/tax filing) are still SOAP-only. This package lets a PM standardize those integrations on the HTTP tooling the team already owns (Guzzle/Symfony HttpClient) instead of treating each SOAP endpoint as a bespoke, untestable black box. That is a build-vs-buy argument for adopting a small, MIT-licensed adapter over writing a custom SOAP client from scratch.
• Roadmap sequencing for cross-cutting concerns. Because the transport rides on PSR-18, middleware for auth (OAuth/SAML/mTLS token refresh), structured logging, tracing, rate limiting, retries, and circuit breaking applies uniformly to SOAP calls — the same policies already used for REST. This supports decisions to invest once in platform-level reliability and observability rather than per-integration, and to schedule that platform work ahead of new SOAP-dependent features.
• Feature scope and risk assessment. Choosing a PSR-18 transport signals that a team intends SOAP to be testable and mockable. That materially de-risks features like automated reconciliation, scheduled sync jobs, and order/inventory flows that depend on unreliable third-party SOAP endpoints — a PM can justify a feature on the grounds that failure modes (retries, timeouts, degradation) are addressable rather than accepted as inherent to SOAP.
• Vendor/legacy migration use cases. Useful when a product must integrate with a legacy SOAP service while the long-term target is a REST/HTTP API: the same HTTP client and middleware stack straddles both, so swapping an adapter later is a configuration change, not a rewrite. This informs how aggressively to commit to a particular vendor during a transition.
• Test strategy and QA investment. Mockable clients mean acceptance and contract tests can run in CI without hitting live third-party systems. PMs can fund integration-test coverage and shorten release cycles accordingly.
• Architecture and dependency governance. It's a deliberately narrow package in the php-soap ecosystem, not a framework or runtime — a low-coupling decision that supports keeping the domain layer transport-agnostic.

When to Consider This Package

• You are already using (or willing to adopt) php-soap. This is a transport plug-in for that ecosystem. If you are not on it, adoption is a package-decision, not a drop-in one — evaluate php-soap first.
• You need control over SOAP HTTP behavior. Adopt when the built-in ext-soap transport is a constraint: you need middleware-driven auth refresh, per-request logging and correlation IDs, retry with backoff, custom timeouts, proxies, or TLS/mTLS configuration.
• You need mockable SOAP for tests. If CI cannot reach live SOAP endpoints, or flaky vendor systems are blocking releases, the PSR-18 abstraction is the main argument.
• You already own a PSR-18 client and middleware stack. The value compounds if the team has Guzzle or Symfony HttpClient in place; it is much weaker if this would be the only place those libraries appear.
• The integration surface is meaningful. Several SOAP endpoints, or one business-critical one, justify the abstraction. A single throwaway call to a noncritical service may not.
• Look elsewhere when: the project has no SOAP footprint; the team is committed to ext-soap idioms and does not need middleware; no one can own Guzzle/Symfony client and PSR-7 wiring (the package provides the transport bridge, not the full client configuration or WSDL-to-PHP generation); or a managed integration platform (iPaaS, vendor SDKs, middleware like MuleSoft/Boomi) already covers the requirement with less internal ownership.
• Maturity caveat for the PM. A small (~18 stars) single-purpose MIT package is narrow-surface and auditable, but it is not widely battle-tested. Treat it as an owned dependency: assign a code owner, pin versions, and be prepared to vendor or fork the transport if maintenance lags. Verify the WSDL/type-generation story (that is other packages in the php-soap family) before promising end-to-end SOAP delivery.

How to Pitch It (Stakeholders)

• One-line summary for executives: a small, MIT-licensed adapter that lets our SOAP integrations use the same HTTP client, security middleware, and observability we already use for REST — reducing bespoke code, improving reliability, and making vendor integrations testable.
• Business value: lower integration cost and risk. Reliability features (retries, timeouts, auth refresh, circuit breaking) are applied consistently and can be tuned by configuration rather than per-partner code. Failed third-party calls become diagnosable and recoverable instead of silent outages.
• For engineering: decouples SOAP calls from ext-soap, works with PSR-7/PSR-17 messages and any PSR-18 client (Guzzle, Symfony HttpClient), and is a drop-in replacement for the default transport. It enables middleware for auth, logging, and retries, and full test coverage via client mocking. Trade-off: you own the client configuration and must maintain a pinned dependency; the package is small and not broadly proven, so we should treat it as an owned, auditable component.
• Decision requested: approve adoption as a platform dependency for the SOAP integration workstream, with a named code owner and a spike to confirm the php-soap + WSDL-generation path end to end. Success measures: fewer bespoke HTTP paths for SOAP, integration tests running without live vendor calls, and reduced mean time to diagnose vendor failures.