Why is ext-soap-engine required?

[rimas-kudelis]

Q	A
Version	2.2.0

Support Question

As I understand it, php-soap/ext-soap-engine is a concrete implementation of interfaces and contracts defined in php-soap/engine. So my question is: why does this package require both of them? Doesn't this nullify the point of abstracting out interfaces and contracts in the first place?

[veewee]

Hello there,
Good question!

This package is an oppinionated implementation of soap presets that have proven to work for us.
Where the php-soap organisation is a set of packages that you can use in order to build a SOAP client implementation from scratch.

The main reason for including the ext-soap-engine is that we currently don't have any other working implementation of the engine. Once we have one, we can make the implementation opt-in or choose the best one as a default preset.
Adding a PHP based engine instead of using ext-soap is on the roadmap - if we can find time for it some day :)

However : It's not because we include it by default, that you have to use that specific implementation.

[rimas-kudelis]

Wouldn't it make more sense for ext-soap-engine to "provides" an abstract php-soap/engine-implementation (or similar) package, and for phpro/soap-client to require that instead? It would allow for third-party implementations you might not even be aware of.

I was actually quite surprised that soap-client now indirectly requires ext-soap. This wasn't the case with 1.7, but you specifically disallow using 1.7 with PHP8.1 now, so, in a way, I'm being forced to choose between a PHP downgrade and an extension.

Is the rationale for these choices laid out anywhere? :)

[veewee]

You can read about it more here:
https://github.com/phpro/soap-client/blob/v2.0.0/UPGRADING.md

Basically the codebase of 1.7 got split up into a separate organisation, which is php-soap.
This organisation contains the core building blocks for creating your own SOAP client implementation.
The 1.7 version of this package did have the flexible engine logic and therefore didn't require ext-soap - which is basically a lie. Splitting that repo up into separate repo's made it easier to maintain the dependency graph per what component you want to use.
So in the old version, you might got the false impression that you didnt need ext-soap, but trust me you did need it!
In short : You never had a choice of not having ext-soap in 1.7 either.

Adding a provides would indeed make sense for the ext-soap-engine. Feel free to do so.
As mentioned before, this is a very oppinionated implementation that aims to give you sensible defaults so that you don't receive too many strange erors (of which we have had plenty!).
Therefore we created a DefaultEngineFactory that trusts the ext-soap-engine and the psr-18 implementation to be there.
See:
https://github.com/phpro/soap-client/blob/master/src/Phpro/SoapClient/Soap/DefaultEngineFactory.php
That is why we cannot drop the dependency in this package.

It would allow for third-party implementations you might not even be aware of.

It is possible, but I know how much work it would be to implement this.
I'dd rather co-work out something we can all manage and fine-tune
Life is too short to make too many SOAP engines ;)

[rimas-kudelis]

Hm, thanks for your patient explanations!
Feel free to convert this issue to a discussion – that seems more appropriate.

[rimas-kudelis]

Hmm, to my untrained eye SOAP always seemed like just an old and thus enreprisely complicated dialect of XML (or rather that in combination with HTTP). I do understand that a WSDL allows listing operations and their required and optional arguments, but what causes SOAP to be so special that it needs a whole dedicated PHP extension is beyond my comprehension.

Perhaps ext-soap might be useful when you're interacting with a specific SOAP API a lot, but if you only need to call an endpoint or two, any HTTP client should be good enough, no?

[veewee]

The extension enables you to do quite complex things without having a big understanding of the complicated enterprise dialect.
It abstracts away the envelopes, headers, ... and enables you to just care about sending and receiving information from a SOAP method.
Parsing and understanding a WSDL is a tedious task by itself.
Even if regular SOAP is understandable at itself, mixed with some WSDL parsing and e.g. an extension like WSSE - it can become very very complex!
I do understand why the extension is there and I sure see the benifits from it.

However, The ext-soap extension is quite broken at the moment. There is even a discussion about removing it.
See php/php-src#8019

As you can see, I also pointed out in that discussion that for all I care it can be removed at some point in time. However, I do feel that that time not today YET - since there is no real alternative at this moment.

So at some point in time, we will have to provide metadata parsing and encoding/decoding features.
At that point, at least this package would be able to provide a drop-in replacement for the existing extension.
I've investigated this path many times already. It's on my planning for quite some time - but it will take way too much of my precious free time at this moment in life.

An other alternative would be to send some XML over the HTTP wire - which I have also provide lot's of tooling for. But it requires you to know a lot about SOAP - which is just a boring skill to have these days. I don't really see the benifit in that either.

[rimas-kudelis]

@veewee, the (perceived) brokenness of ext-soap is exactly why I didn't want to depend on it in the first place. I had to implement a couple small integrations (a few very specific small requests in each) a few years ago, and already then I was explicitly advised not to use ext-soap, because it's broken, but to just write a client on top of Guzzle instead. Which I did, and everything worked just fine.

I read through the discussion you pointed to, and while I understand that there's a lot of existing code depending on ext-soap, I don't see why it couldn't be at least unbundled from the core, this way giving everyone a really strong signal that 1. it's barely maintained, and thus 2. it's time to buckle up and build a proper userland replacement.

By the way, looking at the image in the readme of php-soap/engine, I find it a bit hard to understand why you want packages to provide an Engine as a whole. To me, the responsibilities of Driver and Transport seem hardly related, and your own ext-soap-engine couldn't illustrate it better (has two Transports, none of which even uses ext-soap). Wouldn't it make sense to split that package into a set of smaller ones, each responsible for just one specific block (encoding, decoding, metadata, transport)? This way the feat of replacing ext-soap would also be split into a set of smaller tasks, and the module could be replaced more gradually. WDYT?

[veewee]

the (perceived) brokenness of ext-soap is exactly why I didn't want to depend on it in the first place

This package covers most of the brokenness for you to be honest.
There are good parts in there as well, which we use in here : encoding/decoding to give an example.
(even though it lacks support for namespaces - it is pretty good)
It ain't all that bad and it is just very easy to use.

I don't see why it couldn't be at least unbundled from the core,

That would mean having to manually install the extension and it still needs to be kind-off maintained. So I don't see that as a big solution either. Anyways, I'll keep that discussion for PHP internals. Since they know best.

I find it a bit hard to understand why you want packages to provide an Engine as a whole

It has grown historically. Rome wasn't build in a day you know :)

The Engine is just that class that makes it easy to do whatever soap action. You might as well skip it and use the driver and transport directly. But then you need to know how to glue it all together. So I see engine more as something you inject in your own custom soap client implementation to make it easier to access everything. The driver is the thing that understands the soap protocol (encoding, decoding, wsdl stuff) and the transport is something that talks HTTP. The engine is just there to help you doing it the easy way. (Think of it as current PHP's SoapClient : it makes it easy for people that don't know SOAP to do SOAP). It also gives you a central place for bundling the congifuration of all parts, which you can even wrap with lazy loading e.g.

I Do understand your point and it's good. But I think the engine is just a convenience wrapper - which is quite OK from my point of view.

ext-soap-engine has two Transports, none of which even uses ext-soap

They do use ext-soap : see AbusedClient which is an implementation of SoapClient and SoapServer.

Wouldn't it make sense to split that package into a set of smaller ones, each responsible for just one specific block (encoding, decoding, metadata, transport)? This way the feat of replacing ext-soap would also be split into a set of smaller tasks, and the module could be replaced more gradually. WDYT?

As I mentioned before, I've analysed that path a lot already and do know the direction I want it to take.
How I see it:

• A vanilla PHP WSDL parser package that provides metadata about types (xsd) and methods (in php-soap terms an extended metadataprovider)
• A vanilla PHP driver that provides encoding + decoding based on top of the vanilla WSDL parser (In php-soap terms this would be a driver), we could add a convenience engine in here as well with some options similar to ext-soap's options.

Since encoding and decoding are so closely related, it doesn't make a lot of sense to me to split them.
However, they do need the wsdl data in order to make it possible to do the work. So it's also in that order that stepds need to be taken.

Transport is already covered, since we have the psr-18 transport which is the recommended way of doing transport. (Since that is a part in ext-soap that is very broken)

If you are interested and care that much about doing SOAP properly, I am always looking for people who want to help set this up and maintain in the php-soap namespace by the way ;)

[rimas-kudelis]

If you are interested and care that much about doing SOAP properly, I am always looking for people who want to help set this up and maintain in the php-soap namespace by the way ;)

To be honest, I only care about all this for the duration of my current assignment, and even that assuming I won't end up simply sending a manually crafted request and using Symfony Serializer to deserialize the response I receive from XML (will see about that in the next few days). I probably wouldn't be of much use as a partner in crime. :)

[veewee]

No problem, good luck on the job then :)