Engine Laravel Package

Product Decisions This Supports

• Legacy integration roadmap: Building or maintaining features that must talk to SOAP/XML services (ERP, payments, logistics, government/healthcare APIs) without letting those integrations dictate the platform architecture.
• Build vs. buy on the SOAP client layer: Replacing hand-rolled curl/DOMDocument SOAP glue or the aging, hard-to-test native SoapClient with a maintained, PSR-compatible engine — a small dependency instead of an internal maintenance burden.
• Transport standardization: Reusing existing PSR-18 HTTP clients (retries, timeouts, logging, auth middleware, proxies, observability) for SOAP traffic rather than maintaining a parallel egress path.
• Testability and CI investment: Because transport and XML concerns are separated, SOAP interactions can be unit-tested with mocked clients and recorded fixtures — supports decisions to raise coverage and shorten release cycles on integration-heavy services.
• Use cases: WSDL-driven typed clients, SOAP 1.1/1.2 endpoints, multi-tenant integrations with per-customer WSDL endpoints, middleware for logging/retry/rate-limiting, and phased migration from legacy SOAP calls toward cleaner service boundaries.
• Namespace-aware type handling (2.21.0): TypeCollection::findByNameAndXmlNamespace lets generated/typed models be resolved by XML QName rather than local name alone. This matters for real-world partner WSDLs where the same type name (Address, OrderLine, Header) appears under multiple namespaces — previously a source of ambiguous lookups and silent mis-mapping. It makes typed-client generation and dynamic dispatch on multi-namespace schemas more reliable, and is additive/non-breaking (2.20.0 → 2.21.0), so no migration cost to adopt.
• Architecture decisions: Framework-agnostic design supports use in Laravel apps, non-Laravel services, queue workers, and CLI tooling under one integration approach — reduces platform lock-in risk.
• Maturity caveat to weigh: ~27 GitHub stars and an unknown repository reference mean this is a niche library. The 2.21.0 release is evidence of steady, incremental maintenance, but cadence is single-maintainer-ish and feature-scoped, not a support commitment. Roadmap decisions should include a fallback plan (fork, or the broader php-soap ecosystem) rather than treating it as a de-facto standard.

When to Consider This Package

Consider adopting when:

• You have one or more real SOAP/WSDL dependencies and want typed, discoverable operations rather than string-built XML.
• You need SOAP 1.1 and 1.2 coverage, or per-partner variation in SOAP versions and endpoints.
• Your WSDLs are multi-namespace or schema-heavy, and you need to resolve types unambiguously (as of 2.21.0, by name and namespace) — relevant for aggregator-style integrations where several partner schemas share local type names.
• You already have (or want) a PSR-18 HTTP client and PSR-7/17 middleware stack for retries, auth, and telemetry — avoiding duplicated resilience logic.
• Testability matters: you want to mock the transport and assert on serialized payloads in CI instead of hitting partner sandboxes.
• You want framework-agnostic code that can live in a shared integration package used by Laravel and non-Laravel services.
• The team is comfortable with explicit wiring (encoders, decoders, middleware) rather than a magic one-liner.

Look elsewhere when:

• You need zero SOAP exposure — if the vendor offers REST/JSON, that's the better product decision regardless of library quality.
• The team wants the battle-tested default: PHP's built-in SoapClient (or php-soap/psr18-transport plus the wider php-soap suite) has far more field mileage; this package is a smaller, less-proven component.
• You require long-term vendor support, SLAs, or a large community for a critical revenue path — 27 stars is a concentration risk, and a minor feature release does not change that profile.
• Your needs are trivial (one fixed call to one endpoint) — hand-rolled code may be cheaper than a new abstraction.
• You need WS-Security, WS-Addressing, MTOM/attachments, or WSDL generation — verify explicit support before committing; these often need adjacent packages or custom middleware.

Adoption criteria to enforce: pin the version, add contract tests against recorded WSDL fixtures (including a multi-namespace fixture to exercise QName-based type lookup), wrap the engine behind your own thin interface so it can be swapped, and confirm the license (MIT) and maintenance cadence fit your dependency policy.

How to Pitch It (Stakeholders)

To executives: We have integration work blocked on SOAP-based partner systems. This library lets us connect to those services using our existing, well-understood HTTP and monitoring stack instead of bespoke plumbing — lower build cost, faster delivery, and less risk of one-off code that only one engineer understands. The latest release improves handling of partner schemas that reuse type names across namespaces, which is exactly the failure mode that causes subtle mapping bugs in multi-partner integrations. It's MIT-licensed and small, so the cost of trying it is low; the main caution is that it's a niche project (few stars), so we'll isolate it behind our own interface and keep an exit path. Net: cheaper, testable integrations without a strategic dependency on the vendor.

To engineering: php-soap/engine is a framework-agnostic SOAP engine: WSDL-driven operation discovery and invocation, SOAP 1.1/1.2, PSR-18 transport, and pluggable encoders/decoders/middleware. It cleanly separates transport from XML, so we mock the client in tests, reuse our existing retry/auth/logging middleware, and avoid the untestable native SoapClient path. 2.21.0 adds TypeCollection::findByNameAndXmlNamespace, letting us resolve types by QName — use it whenever partner WSDLs share local type names across namespaces instead of relying on ambiguous name-only lookups. Trade-offs: small community and a narrow, incremental release cadence, so we pin versions, wrap it in an internal adapter, and cover it with fixture-based contract tests. Recommended for new SOAP integrations and as the target for migrating legacy SOAP calls — not for cases where the vendor offers a REST alternative.