Besimple Soap Common Laravel Package

Product Decisions This Supports

• Legacy SOAP integration reuse: This package is the shared helper layer beneath the BeSimpleSoap family (Bundle/Client/Server/Wsse) — WSDL/XSD type mapping, SOAP envelope handling, common utilities. It supports the decision to reuse existing integration plumbing rather than rebuild a SOAP client stack for an already-working B2B endpoint.
• Build vs. buy vs. keep: Frames the question as "maintain vs. migrate" rather than "adopt." Adopting adds no new capability beyond what the abandoned upstream already offered; the decision it informs is whether to keep a Symfony2-era integration alive for another release or schedule its replacement.
• Roadmap risk/exit planning: Zero stars, zero dependents, single-maintainer fork, abandoned upstream — this is a dependency-hygiene item for the roadmap, not a feature enabler. It supports scoping a migration ticket (e.g., to a maintained SOAP client) and freezing new SOAP work on this stack.
• Feature scoping for integration work: The realistic use cases are fixed-counterparty enterprise integrations — ERP, banking/payments, tax/government gateways. It helps decide not to invest product surface here, and to route new API work to REST/JSON/GraphQL instead.
• Vendor/tech-debt tracking: Useful input to a "supported dependency policy" decision: what we allow into the estate, what gets an adapter boundary, what gets a retirement date.

When to Consider This Package

Consider it only under these conditions:

• You already run Symfony2 (or a close fork) and maintain BeSimpleSoapBundle, and this fork's changes are what keep the stack installable on your PHP version.
• You need the shared SOAP common layer without pulling the full bundle, and your team explicitly accepts unmaintained code.
• The SOAP counterparty is fixed and non-negotiable, the integration is stable and rarely touched, and it's already in production — i.e., this is a containment decision, not an adoption decision.

Look elsewhere if any of the following is true:

• Greenfield project, or you need PHP 8+ / Symfony 5+ compatibility.
• You require security patches, an SLA, or a maintainer who responds — there is none here.
• You would be the first and only dependent (bus factor of one, no community test surface).
• A maintained alternative fits: phpro/soap-client, laminas/laminas-soap, or Symfony HttpClient with explicit XML handling.
• The counterparty can expose REST/JSON — do that instead.
• You need modern testing, PSR-7/PSR-18 transport, or observable request/response tracing out of the box.

How to Pitch It (Stakeholders)

Executives: This is a small, unmaintained open-source helper for legacy SOAP integrations. It carries no license cost but also no support, no security backport, and a single maintainer. Recommendation: contain, don't expand — treat it as documented technical debt with an exit path, and keep it out of any new product surface. It is not a strategic bet and should not appear in growth or platform narratives.

Engineering: It's a fork of an abandoned Symfony2-era library with effectively no community (0 stars, 0 dependents). It's usable only inside the existing BeSimpleSoap stack and only for fixed-counterparty integrations. If we keep it, pin the version, wrap it behind an adapter interface so callers don't depend on it directly, and budget a migration to a maintained SOAP client. If we're starting anything new, this is a hard no.