PHP a SOAP

[M. N.]

Zdravím,

dostal jsem za úkol vyřešit komunikaci se službou postavenou na SOAP protokolu. V popisu rozhraní je zmíněn přenos souborů pomocí formátu zpráv MTOM. Jelikož se může jednat o opravdu velké soubory, je tento formát, z pohledu implementátora služby, jediný vhodný. Bohužel na toto není připravený standardní modul ext-soap v PHP - neporadí si s xop:Include, podle všeho.

Nenajde se někdo, kdo by měl v PHP zkušenost se zpracováváním takovýchto zpráv, případně poradil by knihovnu? Opravdu intenzivně hledám řešení už více než týden,  našel jsem spoustu starších, nešťastných, příspěvků na SO, Redditu i jinde, že je to opravdu opruz, ale rozumné a použitelné řešení ne. Implementovat celého klienta je nad síly a vzhledem k časové nouzi (dříve selhalo jiné řešení) není ani prostor.

V PHP má jít navíc jen o jakousi proxy, která bude získaná data vystavovat na vnitřním REST rozhraní. Takže pokud by šlo použít i nějaké známé SOAP2REST proxy řešení, které zvládá MTOM,  tak prosím o odkaz.

Díky,

M.

[Reklama]

[Josef Marianek]

Nevim jestli to pujde, ale zkuste NuSOAP
http://sourceforge.net/projects/nusoap/
Diskuze o MTOM https://sourceforge.net/p/nusoap/discussion/193578/thread/abe3287e/
My NuSOAP pouzivame, ale bez MTOM.

[M. N.]

Diskuze o MTOM https://sourceforge.net/p/nusoap/discussion/193578/thread/abe3287e/
My NuSOAP pouzivame, ale bez MTOM.

Dík, o tomto vím - naše zprávy mají tendenci být obrovské (desítky až stovky MB) z tohoto důvodu musíme číst multipart jako stream a rozhazovat do souborů. Ale pokus o vlastní implementace klienta je až krajní řešení. NuSOAP je už spoustu let neudržovaná. Narazil jsem na GH na phpro implementaci klienta, která je živá a udržovaná, ale té chybí podpora pro MTOM úplně ( https://github.com/phpro/soap-client )

[madmucho]

Co tenhle ?
https://github.com/debuss/MTOMSoapClient
Ale i tak to asi bude dost prasarna, poskládat si to pak z base64 zpět to bude trvat.

[M. N.]

Co tenhle ?
https://github.com/debuss/MTOMSoapClient
Ale i tak to asi bude dost prasarna, poskládat si to pak z base64 zpět to bude trvat.

O tomto vím - bohužel připojené části budou obrovské ... mám toto jako krajní "řešení" problému. Ale je to o vlastní implementaci __doRequest a čtení vstupu jako streamu, rozhození jednotlivých částí do souborů v tempu a nahrazení xop:Include řetězcem cesty k těm souborům... Tohle je náš "krizový" scénář ale regulérní řešení s klientem, který zvládá toto rozšíření SOAP o NS xop by bylo lepší ....

[Reklama]

[L..]

Pokud je to jen SOAP / REST proxy, nebylo by jednodušší ji napsat v Javě místo PHP? :-)

[to_je_jedno]

Pokud je to jen SOAP / REST proxy, nebylo by jednodušší ji napsat v Javě místo PHP? :-)

Nebylo by to jednodussi/rychlejsi v go?

[Death Walker]

Mate namapovane typy zo soap response na php typy? (classmap v options pre konstruktor soap klienta)
Ak ano, tak pre xop:include nadefinujete triedu, ktora poskytne stream na includovany zdroj.

Btw, REST proxy na SOAP server asi moc nenajdete, struktura xml je daleko komplexnejsia ako json. Na to si budete musiet napisat vlastny kod, prisposobeny jednak WDSL toho soapu, tak aj rozhraniu toho rest serveru.

[M. N.]

Mate namapovane typy zo soap response na php typy? (classmap v options pre konstruktor soap klienta)
Ak ano, tak pre xop:include nadefinujete triedu, ktora poskytne stream na includovany zdroj.

Btw, REST proxy na SOAP server asi moc nenajdete, struktura xml je daleko komplexnejsia ako json. Na to si budete musiet napisat vlastny kod, prisposobeny jednak WDSL toho soapu, tak aj rozhraniu toho rest serveru.

Jo, kolega má podobný nápad ale z "druhého konce" - úpravou definice v WSDL/XSD. Právě kvůli tomu, že existuje mapping to nemůžeme udělat jednoduše. Služba je hodně komplexní, nad jedním endpointem je nadefinovaných cca 700 datových typů (php tříd!) a právě ty, které v sobě mají odezvu z xop:Include jsou jako string a nikoliv spec. typ. Muselo by se to řešit na několika (mnoha) místech .... 

K té proxy: našel jsem tohle  https://github.com/membrane/service-proxy - java proxy SOAP->REST a nevypadá to zle, jen to teď musím otestovat

[M. N.]

Pokud je to jen SOAP / REST proxy, nebylo by jednodušší ji napsat v Javě místo PHP? :-)

Nebylo by to jednodussi/rychlejsi v go?

Bezpochyby, nicméně nic z toho nemáme interně dostupné ;-)

[Josef Marianek]

Diskuze o MTOM https://sourceforge.net/p/nusoap/discussion/193578/thread/abe3287e/
My NuSOAP pouzivame, ale bez MTOM.

Dík, o tomto vím - naše zprávy mají tendenci být obrovské (desítky až stovky MB) z tohoto důvodu musíme číst multipart jako stream a rozhazovat do souborů. Ale pokus o vlastní implementace klienta je až krajní řešení. NuSOAP je už spoustu let neudržovaná. Narazil jsem na GH na phpro implementaci klienta, která je živá a udržovaná, ale té chybí podpora pro MTOM úplně ( https://github.com/phpro/soap-client )

Napadlo me jeste jestli zkratka cteni tech souboru neudelat bokem, tj. mimo SOAP, a v SOAP nechat jen zbytek toho co je potreba komunikovat + vazbu na ty soubory.

[M. N.]

Napadlo me jeste jestli zkratka cteni tech souboru neudelat bokem, tj. mimo SOAP, a v SOAP nechat jen zbytek toho co je potreba komunikovat + vazbu na ty soubory.

Rozšíření MTOM je, IMHO, atypické v tom, že po SOAP klientovi požaduje specifickou funkcionalitu - xop:Include se má chovat jako něco, co vrátí obsah MIME multipart bloku do nadřazeného uzlu - a na tom asi selhává interní soap_client php. Řešení mám zatím tato:
- preprocessing MIME multipart body, kdy se čte jako stream, kde application/xop+xml uchovám pro parser a zbývající části si poukládám do souborů v temo a nody <xop:Include .../> vykousnu a zaměním regulárem za např. cestu k uloženému souboru. V rámci soap_clent v PHP se dostanu ke čtení dat před zpracováním parserem v metodě __doRequest(...)
- implementace vlastního soap_client, případně úprava/patch např. nu_soap balíku a doplnění požadované funkcionality
- použití externí SOAP:REST proxy npř. viz výše uvedená, kolega teď testuje použitelnost
- změna technologie, na které se má realizovat (Java/.Net)

Technicky mám průzkum hotový, děkuji přispěvatelům za nápady.

M.

[Tomáš Procházka]

Pokud je to jen SOAP / REST proxy, nebylo by jednodušší ji napsat v Javě místo PHP? :-)

Nebylo by to jednodussi/rychlejsi v go?

Ohledně soapu mam zkušenosti jen s klienty.
Kdysi jsem zkoušel EET klienta v Go, a ten SOAP bylo docela peklo. Balíčky s pochybnou kvalitou a životností, a tak podobně. Takže to za mě není ideální jazyk, repektive ekosystém.
I v PHP jsem dělal klienta, na C# SOAP server. Tam jsme naštěstí mohli vyžádat nějakou starší WSDL specifikaci, protože ta nová v tom PHP ne a ne fungovat.
Vždy to nějak jde, nakonec je to "jen XML". Ale nejsnazší a nejlevnější asi bude použít Javu nebo C#. A nebo se vyprdnout na SOAP. Záleží co je nejvíce průchodné.