Besimple Soap Common Laravel Package

Technical Evaluation

Architecture fit. burti/besimple-soap-common is not a Laravel package — it is a shared library extracted from the BeSimple SOAP stack, a Symfony2-era (2011–2015) ecosystem of bundles for building and consuming SOAP services. It provides common SOAP type classes and WSDL/XSD primitives consumed by sibling packages (besimple-soap-client, besimple-soap-server), not standalone functionality. There is no service provider, facade, config file, or publishable asset, so it does not participate in Laravel's container, config, or package-discovery conventions. It would be a transitive dependency glued on rather than an integrated component.

Integration feasibility. Low. The namespace is BeSimple\SoapCommon, and the library assumes the surrounding BeSimpleSoap packages exist. It targets PHP 5.x/7.x and Symfony 2 components; modern Laravel (10/11/12) ships Symfony 6/7 components, so Composer resolution will either fail outright or require --ignore-platform-reqs and a conflict-ridden lockfile. There is no Laravel-facing adapter anywhere in the ecosystem, and the parent project has been effectively abandoned for the better part of a decade.

Technical risk. High. Specific concerns:

• No maintenance signal. 0 stars, 0 dependents, no visible CI, no release cadence. There is no CVE feed and no upstream to patch.
• PHP 8+ incompatibility. Code written against PHP 5-era conventions will hit removed functions, deprecated dynamic properties, and untyped signatures that break under E_DEPRECATED-as-error and static analysis.
• SOAP attack surface. WSDL/XSD fetching is an SSRF vector; XML entity handling on an unmaintained parser is an XXE risk unless disabled explicitly. This library will not have had those hardening patches applied.
• Dead dependency tree. Pulling this in drags in the rest of BeSimpleSoap, which itself depends on abandoned packages.

Key questions for the sponsor:

1. Which concrete SOAP endpoints must we talk to, and are machine-readable WSDLs available? (Frequently they are not — this is often why teams reach for legacy tooling.)
2. Is ext-soap available in our runtime? If yes, phpro/soap-client or a thin SoapClient wrapper is a materially better path.
3. Is this a new integration or a port of an existing Symfony2 service?
4. What PHP version is mandated, and can we pin it?
5. Who owns the code if we fork it, and is that a realistic commitment?

The "opportunity: 6.59" score should be discounted heavily against an adoption signal of zero — the opportunity is hypothetical, the risk is concrete.

Integration Approach

Stack fit. Poor as a direct dependency. The realistic architectural role is "reference implementation for SOAP type mapping," not "library we ship." If a specific WSDL genuinely requires the BeSimple type model, the correct pattern is a bounded adapter: define a SoapGateway interface in our domain layer, implement it with a BeSimple-backed driver, and never let BeSimple\SoapCommon\* types escape that namespace. All controller, job, and service code depends on the interface and on plain DTOs.

Migration path. Two viable routes, in order of preference:

1. Replace rather than integrate. Use phpro/soap-client (actively maintained, PHP 8-compatible, Laravel-friendly) or the built-in SoapClient plus a hand-rolled WSDL-to-DTO mapping. This library then serves only as a reference for type definitions.
2. Vendor-and-fork. If a legacy WSDL is intractable, fork the repo into a private VCS namespace (e.g. internal/soap-common), apply PHP 8 fixes and XXE/SSRF hardening, and pin the fork. Do not depend on Packagist for it — the upstream can vanish or be hijacked.

Compatibility. Expect to patch for PHP 8: each(), curly-brace string offsets, implicit nullable parameters, and missing return types. Budget for a static-analysis pass (PHPStan at a low level) to enumerate the breakage before committing. If the patch surface balloons past a few files, escalate to route (1) or isolate the SOAP calls in a separate sidecar service with its own pinned runtime.

Sequencing.

1. Spike (1 week): Stand up one real WSDL against the library in a scratch container. Record what breaks. This is a go/no-go gate.
2. Contract definition: Write the SoapGateway interface and DTOs from the WSDL before touching implementation.
3. Adapter build + hardening: XML external entity loading disabled, WSDL source allowlist for SSRF, request/response logging, timeouts, retry policy.
4. Contract tests against recorded SOAP fixtures — no live endpoint dependency in CI.
5. Shadow run: Route production traffic through the new adapter in parallel with the legacy path and diff responses.
6. Cutover with the legacy path retained as a kill switch.

Operational Impact

Maintenance. We become the de facto maintainer. There is no upstream to file issues against, no security mailing list, and no release notes to read. Every PHP minor version upgrade becomes a manual compatibility audit. Treat the fork as first-party code with a named owner and a documented patch log.

Support. 0 stars and 0 dependents means no Stack Overflow corpus, no GitHub issue history to search, and no third party to escalate to. Debugging is entirely first-principles. For a TPM this translates directly into an elevated mean-time-to-resolution on any SOAP incident and a hard dependency on one or two engineers who have read the source.

Scaling. SOAP is synchronous and request/response; the library adds WSDL parsing cost on top. Mitigations: cache parsed WSDL aggressively (APCu/Redis with a TTL tied to WSDL version), pool connections where the transport allows, and push slow partner endpoints behind queued jobs rather than handling them in the request cycle. The library itself does no caching for you.

Failure modes to instrument:

• WSDL fetch failure at boot or cold cache — the classic cascading outage.
• XML parse errors surfacing as opaque exceptions; wrap and normalize to a known exception hierarchy.
• SOAP Fault responses that the library may return as normal results rather than throwing.
• Character-encoding mismatches on international partner data.
• Silent behavior changes after a PHP upgrade — the most dangerous class, because they can pass tests and corrupt payloads.
• Unbounded payload sizes and missing timeouts causing worker exhaustion.

Ramp-up. Documentation is thin-to-nonexistent and the Symfony2 idioms it assumes are unfamiliar to most engineers now. Plan for a senior engineer to spend several days reading source before being productive, and document the adapter's behavior as they go. The team should assume this knowledge is single-owner and mitigate with a written runbook, recorded WSDL fixtures, and a second engineer paired through the spike.

Bottom line for the decision log: the package is a reference artifact, not a dependency. Approve a one-week spike to confirm that; default to a maintained SOAP client with a bounded adapter, and hold the fork in reserve only if a specific WSDL forces it.