Besimple Soap Laravel Package

Technical Evaluation

What the package actually is. smartbox/besimple-soap is a single-company fork of the long-dormant BeSimpleSoap project. It is a thin, opinionated convenience layer over PHP's native ext-soap: a client (BeSimple\SoapClient), a server (BeSimple\SoapServer), shared WSDL/type utilities, and a Symfony bundle (BeSimpleSoapBundle) that wires client factories, server controllers, routing, and WSDL caching into a Symfony application.

Architecture fit. The core libraries are framework-agnostic; the integration layer is Symfony-first. There is no Laravel service provider, no publishable config, no facade, no HTTP-kernel integration. Calling this a "Laravel/PHP package" is a packaging artefact — in a Laravel app you would consume the three core components directly and write the glue yourself. That is a bounded, well-understood piece of work (roughly one to two senior-dev days), but it means the real decision is "adopt a Symfony library and build our own adapter," not "install a supported Laravel package." v1.3.5 does nothing to change this: no Laravel support was added, and the release explicitly targets Symfony 2.8 and 3.4.

Where it differentiates. The one genuinely distinctive capability is server-side WSDL generation from annotated PHP classes (docblock/annotation-driven schema derivation). If the requirement is only to consume a SOAP service, this library adds little over \SoapClient and nothing over phpro/soap-client or the Laravel SOAP client packages. Scope that question before anything else.

Technical risk, ranked:

1. Abandonment. 1 star, 0 dependents, prior last release 2020-06-12. v1.3.5 shows a pulse, but it is a maintenance patch from a single contributor, with PR numbers (#18, #19) that indicate a very shallow lifetime change history. Still no security policy, no CVE response path, no issue triage commitment, no roadmap. Every defect we encounter remains ours by default.
2. Dependency decay. The stack leans on zendframework/zend-code (abandoned, superseded by laminas) and doctrine/annotations (deprecated in favour of PHP attributes). Pulling the bundle into a Laravel 10/11 app drags in Symfony 2.8–4.x constraints that collide with Laravel's Symfony 6/7 requirements. v1.3.5 is actively widening support for Symfony 2.8 and 3.4 — both long EOL — rather than modernising. This is a maintenance posture signal, not a feature. Plan on never installing the bundle inside Laravel.
3. PHP version horizon. A 2020-era fork realistically targets PHP 7.2–7.4. v1.3.5's test matrix changes cover Symfony versions only; there is still no published evidence of PHP 8.1/8.2/8.3 correctness. Verify empirically against our runtime before committing — the deprecation fixes in #18 are a mild positive signal but they were raised by test output on the maintainer's own stack, not by a broad 8.x matrix.
4. Runtime prerequisite. ext-soap is frequently compiled out of hardened and distroless images. This is a container rebuild item and a CI parity item, not a footnote.
5. XML safety. Confirm that every parsing path disables external entity loading and entity substitution. Do not assume the library's defaults match PHP 8's hardening. Note that a WSDL-resolution caching path that was silently failing to persist (#19) meant some installations were re-fetching or mis-resolving remote WSDLs — exactly the code path where external document fetching happens. Treat this as an area to inspect rather than a resolved concern.

What v1.3.5 changes for us. No breaking changes, no new capability, no new framework target. Two substantive items: (a) resolved-WSDL persistence was broken and is now fixed, which is directly relevant to our "never fetch the WSDL per request" mitigation — it means the built-in caching path was unreliable through 1.3.4, and prior adopters may have been silently re-resolving WSDLs; (b) test suite deprecation cleanup plus Symfony 2.8/3.4 matrix entries, which confirms rather than relieves the legacy-framework lock-in. Net effect on the decision: none. Net effect on the notes: the WSDL caching caveat and the "no modern PHP matrix" caveat get sharper.

Reading the signals. A composite score of 0.515 and opportunity of 25.74/100 are consistent with a single-company fork that nobody else consumes. A one-off patch release does not constitute a community safety net — treat the underlying library as respectable-in-its-day and unmaintained-in-practice.

Key questions to resolve before any commitment:

1. Is SOAP contractually mandated by a partner, or is it a legacy internal integration we could retire or re-platform?
2. Do we need WSDL generation (we are the provider) or only consumption (we are the consumer)? This single answer determines whether this package is even a candidate.
3. Does the counterparty require WS-Security, WS-Addressing, MTOM/SwA attachments, or bespoke SOAP headers?
4. What PHP and Laravel versions must this run on over the next 24 months?
5. Is ext-soap enabled in every target environment, including CI and production images?
6. Who is the named long-term owner of a fork, and is that person's time funded?
7. Does the #19 WSDL-persistence fix materially change behaviour for our specific WSDL topology (imports/includes, remote vs local), and do we intend to rely on the library's cache at all or supply our own?

Integration Approach

Stack-fit determination comes first. If the requirement is client-only, the recommendation is native \SoapClient with a classmap, or phpro/soap-client (actively maintained, PHP 8.x, PSR-18 transports, genuinely testable) — both behind a framework-owned interface. Only if server-side WSDL generation is a hard requirement does BeSimple become a candidate, and then only as a vendored core library, never via the bundle. v1.3.5 does not alter this calculus; a Symfony 2.8/3.4 test matrix is not evidence of fitness for a Laravel 10/11 runtime.

Adapter boundary is the highest-value decision. Define a narrow, framework-owned contract — SoapGateway::call(string $operation, array $payload): Result — with a BeSimple adapter and a native/phpro adapter behind it. That caps the blast radius at one class and makes the build-vs-adopt choice reversible inside a sprint instead of a quarter.

Laravel wiring, if adopted. A package-level service provider binding the generated client as a container singleton; a config file for WSDL location, endpoint override, connect/response timeouts, and cache settings; a facade for ergonomics; and an interface binding (not a concrete class) so tests can substitute a fake. Generated WSDL artefacts and classmaps belong under version control in our repo, not inside vendor.

WSDL resolution and caching — updated position. The #19 fix is the one release item with real integration impact. Do not rely on the library's own resolved-WSDL cache as the primary mechanism: ship a local WSDL artefact in-repo, point configuration at the file path, and treat any remote resolution as a build-time step rather than a runtime behaviour. If we adopt on a version ≥1.3.5, additionally verify the cache persistence path behaves correctly for our WSDL's imports/includes during the spike, and confirm no unexpected outbound fetch occurs at request time.

Testing needs explicit budget. ext-soap does not route through Laravel's HTTP client, so Http::fake() is useless here. Either record/replay at the transport level with fixture XML for requests and responses, or adopt a PSR-18-based transport from phpro/soap-client to regain testability. This is the most consistently under-scoped part of SOAP integration and the reason many teams end up with zero meaningful coverage on the integration. Note that the v1.3.5 deprecation fixes were themselves driven by the maintainer's test suite — the project's own test coverage is the only QA gate that exists, and it does not span our runtime.

Observability as a first-class deliverable. Enable trace => true and persist __getLastRequest/__getLastResponse (redacted) to a dedicated log channel with correlation IDs. Without envelope logging, SOAP failures are opaque and every incident becomes a multi-hour forensic exercise.

Migration path.

• Already on BeSimple: take the 1.3.5 WSDL-persistence fix if you rely on remote resolution, freeze the version, pin the lockfile, wrap behind the interface, add contract tests against recorded fixtures, and schedule an exit to native or phpro.
• Greenfield: run a time-boxed spike (3–5 days) — install on the target PHP/Laravel, generate or consume one WSDL, exercise one operation end-to-end, confirm envelope logging, fault handling, and WSDL cache behaviour. Decide on evidence, not documentation.
• If the WSDL-generation capability is uniquely required and the spike passes: vendor the source into our monorepo or a private fork rather than taking a Packagist dependency. This removes abandonment risk from the supply chain and makes patching a normal PR. Taking 1.3.5 as the vendoring baseline is marginally preferable to 1.3.4 given the caching fix.

Compatibility and sequencing. Validate Composer resolution against the current Laravel skeleton before writing any application code; do not attempt the Symfony bundle in Laravel at all. The 1.3.5 test matrix additions confirm the bundle's supported range is anchored in EOL Symfony, which reinforces this. Then sequence: capability spike → interface plus fake adapter → live adapter → observability → contract tests → runbook. Each step independently shippable, each step reversible.

Operational Impact

Maintenance. Assume we own the code. A vendored fork needs a named maintainer, a tracked ticket per platform upgrade, and a standing line in the dependency-review process — it will never appear in advisory feeds, so it must be explicitly listed. Budget 0.1–0.2 FTE ongoing, spiking around PHP major versions. The v1.3.5 release shows the upstream maintainer will occasionally land patches, which is mildly reassuring, but it is one person acting on their own schedule with no obligation to us; it does not reduce the budgeting case.

Support. No formal upstream support, no release cadence commitment, no CVE channel, no community forum. Escalation path is "read the source, then hope the maintainer responds to a PR." For a revenue-adjacent integration that is a permanent tax, and the business sponsor should see it stated plainly rather than buried in a design doc.

Scaling. SOAP calls are synchronous and blocking, so throughput is bound by downstream latency rather than worker count. WSDL parsing and classmap generation are per-process costs — cache the WSDL locally (never fetch per request), enable opcache, consider preloading. The #19 fix improves the library's own caching reliability but does not remove the need for a locally pinned WSDL artefact. Put a circuit breaker in front of any flaky partner, set aggressive connect and response timeouts, and queue or defer anything that can be asynchronous.

Failure modes to design for:

• WSDL unreachable at boot — fatal. Always ship a local WSDL copy and never depend on the partner being up at deploy time.
• Silent WSDL re-resolution or cache-write failure (the class of defect fixed in #19) — degraded latency and possible boot failures. Assert cached-WSDL behaviour in the spike and monitor outbound calls to the partner's WSDL endpoint.
• Upstream schema drift breaking the classmap — fatal at hydration. Add a schema-drift canary against a pinned WSDL checksum.
• Retry storms against a partner endpoint after a transient failure.
• PHP fatals on unexpected XML constructs the classmap did not anticipate.
• XXE if any custom parsing path is ever introduced, and any residual exposure in the WSDL resolution path.
• SOAP Fault returned with HTTP 200 — code that inspects only the HTTP status misclassifies failure as success. This is the single most likely production incident; it must be an explicit, asserted test case.

Ramp-up. Expect 3–5 days for a senior PHP developer to be productive with WSDL/XSD, document-literal versus rpc-encoded bindings, and annotation-driven generation. That knowledge is thin in the hiring market and the bus factor is 1 by default — both on our side and upstream. Mitigate with a written runbook, recorded fixtures as executable documentation, and deliberate cross-training; do not let bespoke SOAP knowledge live in one person's head.

Recommendation. Adopt only where WSDL generation is the deciding requirement and the spike passes. Otherwise implement the client on native ext-soap or phpro/soap-client behind our own interface. Either way, do not take a direct Packagist dependency on this fork — vendor it, own it, and keep the exit door open. v1.3.5 is a patch that improves the caching story and signals token maintenance; it does not change the strategic assessment.