Besimple Soap Laravel Package

Product Decisions This Supports

• Feature scoping for B2B/partner integrations. Whether to expose or consume SOAP/WSDL services at all — relevant when a partner contract mandates SOAP (travel/hotel suppliers, ERP, logistics, government filings, older payment gateways). This package is a candidate building block for those features, not for greenfield public APIs.
• Build vs. buy vs. wrap. The decision is rarely "should we use this package?" in isolation — it's "do we (a) use PHP's ext-soap directly with a thin internal wrapper, (b) adopt a maintained third-party client like phpro/soap-client, or (c) vendor a lightly-maintained bundle like this one and own the maintenance." This package sits firmly at the high-ownership end of that spectrum.
• Roadmap timing and cost of legacy support. Adopting it establishes an ongoing maintenance tax (PHP version bumps, dependency pinning, security patching). That cost should be added to the roadmap estimate for any SOAP feature, not just the initial integration.
• Use cases it can technically serve. WSDL parsing, generated client/server proxies, WS-Security, and MTOM/SwA attachment handling — i.e., the "complex SOAP" cases that ext-soap alone handles poorly. If your integration is a simple document-literal call, this package is over-scoped. The v1.3.5 fix to WSDL resolution/caching makes the WSDL-driven codegen path marginally more trustworthy in production, but does not change the scope argument.
• Deprecation and sunset planning. Because maintenance is community-driven and infrequent, adopting it should come with an explicit exit plan (e.g., a wrapper interface in your codebase so the underlying transport can be swapped without touching business logic).

When to Consider This Package

Consider it when:

• You have a hard, contractually fixed requirement to speak SOAP/WSDL, and the service needs features beyond plain SoapClient — WS-Security headers, MTOM/SwA binary attachments, or a PHP-side SOAP server.
• You inherit a Symfony codebase where it is already present, or you are porting an existing integration and want minimal behavioral drift.
• You are doing a time-boxed spike or proof-of-concept and want WSDL-driven generation quickly.
• You are comfortable pinning PHP/dependency versions and taking ownership of the code as a vendored fork.

Look elsewhere when:

• The project is greenfield, or the counterparty can offer REST/JSON — do not adopt SOAP tooling speculatively.
• You need active maintenance, security patches, or confirmed compatibility with current PHP and Laravel/Symfony versions. The only recent signal is v1.3.5 — a small community-contributed bugfix patch (test deprecation noise, WSDL resolution caching) that adds Symfony 2.8 and 3.4 to the test matrix. Symfony 2.8 and 3.4 are both end-of-life, so this release actually confirms the project's target environment is legacy; it does not establish PHP 8.x or current-framework support, and there is still no visible security-response process or release cadence. Treat it as unsupported code you would be adopting.
• A plain SoapClient + wsdl2phpgenerator-style codegen covers your calls — that is a far lower-risk baseline.
• A maintained alternative fits (phpro/soap-client is the usual comparison point for client-side work; laminas/laminas-soap for server-side).
• You are on Laravel specifically. This is a Symfony-oriented bundle; using it in Laravel means manual service wiring and bypassing framework conventions. The v1.3.5 test-matrix addition (Symfony 2.8/3.4) reinforces that the bundle's ergonomics and support target are a Symfony world you'd be adapting away from. That adapter cost is a real, recurring liability.
• Your team has no SOAP expertise and no appetite to own the transport layer long term.

How to Pitch It (Stakeholders)

For executives (one paragraph): SOAP is a legacy integration standard, but it still appears in enterprise partner contracts — logistics, travel inventory, ERP, and some payment rails. This package is one way to satisfy those contracts from PHP, but it is a lightly-maintained library: minimal adoption, no meaningful release cadence until a small community bugfix patch (v1.3.5) that fixes test deprecation noise and WSDL caching and confirms support only as far as end-of-life Symfony 2.8/3.4. Recommendation: do not put it on the critical path of the roadmap. Where a SOAP integration is unavoidable, fund a thin internal abstraction layer so the underlying library can be replaced without rework, and treat the dependency as a maintenance line item rather than a strategic bet.

For engineering (summary): Treat smartbox/besimple-soap as a reference implementation and a fallback, not a default. Prefer ext-soap plus a maintained client library for new work; the bundle's value is concentrated in the complex corners (WSDL-driven codegen, WS-Security, MTOM/SwA attachments, server-side SOAP) that SoapClient handles poorly. v1.3.5 is a positive but narrow signal: a one-off community patch fixing a real production concern (resolved WSDLs not being persisted correctly) and silencing deprecation output in tests. It contains no new features, no breaking changes, no PHP 8+ enablement, and no security fix. Key risks remain: no sustained maintenance or patch path, unverified modern PHP compatibility, EOL Symfony versions as the declared support matrix, and Symfony-bundle ergonomics that do not map cleanly onto Laravel. If adopted, vendor/pin it, wrap it behind an internal interface, and record an explicit exit criterion up front — for example, "replace if it blocks a PHP upgrade or a security requirement."