Besimple Soap Client Laravel Package

Technical Evaluation

Architecture fit. This is not a Laravel package — no service provider, no config publishing, no facade, no contracts, no PSR-3/PSR-18 integration. It is a standalone PHP SOAP client from the BeSimpleSoap family (soap-client, soap-common, soap-ws-security), and Reprovinci's fork exists mainly to keep a PHP 5-era library installable. In a Laravel codebase it must be treated as infrastructure, wrapped behind an internal interface, and never imported by domain or application code. Its historical differentiators — pure-PHP WSDL parsing, WS-Security (XML signature/encryption), WS-Addressing, and MTOM/SwA attachments — are the only defensible reasons to choose it over ext-soap or phpro/soap-client. If the target integration is plain SOAP 1.1/1.2 over HTTPS, the architecture fit is poor.

Integration feasibility. Feasible, but it is a "vendor and wrap" job, not a "composer require and configure" job. Realistic estimate: one week for a proof-of-concept against the actual counterparty WSDL plus adapter, then one to two weeks for contract tests and hardening. The gating unknown is PHP 8.x cleanliness. Upstream BeSimple code is PHP 5.3/5.4-era; whether this fork is 8.1–8.4 clean cannot be inferred from a version constraint and must be proven by running our own test suite on our target runtime.

Technical risk. High, and concentrated in supply chain rather than features. Zero stars, zero dependents, single maintainer, no visible release cadence, no security policy. Effectively unmaintained: if a PHP 8.5/9 incompatibility lands, there is no upgrade path. The transitive BeSimple sub-packages and xmlseclibs are likely equally stale, so CVE triage is entirely ours. Debuggability is worse than with transport-level clients — WSDL parsing and XML serialization happen in userland, so faults surface as library-internal exceptions rather than HTTP or XML errors, raising MTTR. Mocking is harder because there is no PSR-18 seam at the HTTP boundary.

Key questions before committing.

1. Which SOAP features are actually required? If none of WS-Security, WS-Addressing, or MTOM apply, reject the dependency outright.
2. What PHP and Laravel versions must this run on across the support window?
3. Does the fork pass a test suite on our target PHP with deprecations treated as errors, and who owns it if it does not?
4. Who owns the WSDL, and how often does the counterparty change it?
5. Can the counterparty offer a REST/JSON API or a newer service version instead?

Integration Approach

Stack fit. Isolate it hexagonally: a SoapGateway interface owned by the domain, an implementation in Infrastructure/Soap that constructs the BeSimple client, and a service provider binding the two. Nothing outside the adapter may import BeSimple classes — that single rule is what keeps the exit door open. Configure endpoints, timeouts, certificate paths, and WS-Security material through config/soap.php with secrets from env or a secrets manager. Pin the version exactly in composer.json (no caret, no wildcard) and commit the lockfile. If the fork fails our PHP bar, vendor it as a path repository under packages/ so we can patch it ourselves rather than blocking on upstream.

Migration path.

• Phase 0 — spike (one week). Stand up the client against the real WSDL on target PHP. Verify WSDL parse, WS-Security signing, and attachment handling. This is the go/no-go gate; do not proceed on optimism.
• Phase 1 — adapter and contract tests. Build the interface, the implementation, and fixture-based tests from recorded SOAP responses.
• Phase 2 — parallel run. Exercise the adapter in staging and diff payloads against a known-good reference (SoapUI, Postman, or counterparty tooling).
• Phase 3 — cutover behind a feature flag, with the old path retained until error rates normalize.

Compatibility and sequencing. Benchmark three options before Phase 0 closes: (a) ext-soap SoapClient — zero dependency, but WS-Security requires hand-rolled XML signing; (b) phpro/soap-client — actively maintained, PSR-18 based, code generation, weaker on WS-Security and MTOM; (c) a lightweight Laravel SOAP wrapper if the counterparty's service is plain. Choose BeSimple only where the security or attachment features are non-negotiable. Build the interface first, the spike second, the adapter third, wiring last. Retrofitting the boundary after types have leaked is expensive.

Operational Impact

Maintenance. Assume we own this code. Budget 10–15% of one engineer per quarter for dependency hygiene, PHP version bumps, and CVE response. Set an explicit expiry: a re-evaluation ticket at each PHP minor release and at twelve months, with defined triggers — upstream PHP incompatibility, unpatched CVE, counterparty API deprecation — that force a port.

Support and observability. No vendor, no SLA, no triage. Escalation path is the internal engineer who wrote the adapter, so document it. Instrument the adapter deliberately: log request and response envelopes with PII redaction for WS-Security payloads, emit latency and error-rate metrics, and alert on WSDL fetch failure separately from business-logic faults. The library provides none of this.

Scaling. Calls are synchronous and blocking. Under PHP-FPM each in-flight request holds a worker, so a slow counterparty becomes a worker-starvation incident. Mitigate with tight connect and read timeouts, queue-backed jobs for non-interactive calls, circuit breaking, and bounded retries with jitter — and only retry operations the WSDL shows to be idempotent. Expect a TLS handshake per call; there is no connection pooling to exploit.

Failure modes to plan for.

• Counterparty WSDL moves or changes → client construction fails at boot. Cache the WSDL locally and fail fast with an actionable error.
• XML canonicalization or signature mismatch → opaque rejection with no useful diagnostic. Maintain a captured-artifact runbook.
• PHP minor upgrade breaks userland XML handling → caught in staging unless contract tests are genuine.
• Fork abandonment → no security patches; the exit plan is the adapter boundary plus a documented port to phpro/soap-client.

Ramp-up. One to two days for an engineer fluent in SOAP and XML Signature; substantially longer for a REST-only engineer. Documentation is the original Symfony2-era BeSimple material, so expect to read source. Onboarding cost is contained by the adapter boundary, which is another reason to enforce it strictly.

Bottom line. Approve this as "adopt a legacy library we must maintain," not as "install a package," and only where a specific SOAP capability justifies it. Name an owner before the first commit; without one, use ext-soap or phpro/soap-client instead.