State of the SOAP

The SOAP protocol is a critical communication protocol on the Internet due in large part to the fact that it has become native to so many development platforms. SOAP itself has also become an incredibly stable protocol. The WS-* Wars of the early millenium seem to have died down, and the few truly useful extensions to SOAP have been selected by the market.

Most SOAP toolkits as well have stablized along with the protocol. Relative to all those other toolkits, the status of this SOAP toolkit is fair to good. It differentiates itself from other toolkits by still being really easy to use for the majority of use cases. But as more and more people adopt document-literal as their preferred method of encoding, the roots and biases of SOAP::Lite in regards to XML::RPC begin to show and the toolkit is not as resilient.

As a result, SOAP::Lite has a number of known interoperability issues with more modern implementations of SOAP servers and clients. The task of keeping SOAP::Lite up to date is a difficult one. The source code is notoriously complex, a mark of the seriously ingenious Paul Kulchenko who created SOAP:Lite. As a result baffles most inexperienced Perl programmers, and indeed sends many of them running in shear terror. I myself am given the highest respect in my office for signing up to maintain the module for this fact alone - I work with some of the brightest and most experienced Perl programmers in the industry and they all look at SOAP::Lite in awe. And not the "good" kind of awe, the kind of awe that gives people a healthy, but fearful respect.

But I am not trying to inflate my ego, I am trying to set the stage for what should be next for Perl's only SOAP toolkit.

If SOAP::Lite as a project that is to attract more contributing authors, it is essential that the SOAP::Lite code base become easier to work with. SOAP::Lite could benefit a great deal from shedding a lot of the code written before the protocol had really matured, before the era of the WS-i, before a time where other toolkits and servers had agreed upon and embraced a set of best practices. It should consider severing itself from XML::RPC which is really a different protocol that operates under a totally different set of assumptions. SOAP::Lite should shift to a document-driven model, as opposed to an RPC driven one.

Therefore SOAP::Lite needs a re-write. SOAP::Lite needs to live up the "Lite" part of its name. SOAP::Lite should be built from the ground up to conform to the WS-i's requirements. It should be built first and foremost around a wicked WSDL parser and engine. It should be made more modular so that its components can be more easily swapped out for newer and better implementations without disrupting users and developers. It should take advantage of the number of perl modules that have evolved since SOAP::Lite was conceived to reduce code complexity and obscurity.

SOAP::Lite needs your help. SOAP::Lite needs a group of 2-3 passionate people to take a fresh look at this critical toolkit for Perl developers and to usher into a new age of utilization, community growth, usage, and utility.

Undertaking a project like this is not a trivial task. It requires months and months of dedicated time and attention. And then it must also be supported and maintained.

This project would not start from ground zero. There is a vision and a plethora of tried and true code already within SOAP::Lite that shouldn't be needlessly thrown away. What we endeavor to do is make SOAP::Lite easier to grok and easier to work with. What we hope to create is a new module, called SOAP::Easy.

Byrne Reese
Lead Developer and Maintainer, SOAP::Lite

Comments

[Jonathan Stowe]

Hi,
You must have seen my talk at YAPC::Europe last year :-)

I've got some ideas and a vague plan for something like this - you can count on my help if you need it.

[Mark Mc Keown]

Hi Byrne,
I have done some stuff extending SOAP::Lite to support WS-RF, WS-Addressing and WS-Security, see http://www.sve.man.ac.uk/Research/AtoZ/ILCT. Much of the stuff belongs in a proper Perl SOAP module, however I am not the world's greatest Perl developer and I found the SOAP::Lite module a nightmare to understand, though to be honest I am not sure I do understand it ;-) This is the reason I never pushed stuff back to SOAP::Lite, I was never sure it was good enough or that it was shoved into the right place. You are welcome to whatever you can salvage.

[Marc]

Hi,

there is a new set of Perl Modules out which could be used as a SOAP::Lite replacement in the future:

http://search.cpan.org/~markov/XML-Compile-0.17/

Maybe it makes sense to have a look at this Module and comulate development power to bring this one forward?

Marc

[Charlie Barker]

Document literal is definitely the way to go, parsing WSDL and creating proxies as in the .net world would also make life easier for programmers creating clients. There is also a new extension for passing binary files that supercedes DIME which is a good thing.

I admire your devotion to perl, speaking as a vb6 / Vb.net programmer who has just been asked to learn perl. It feels old, i'm not trying to put perl down it does have a charm of it's own but when you have to escape @ in a literal string that represents an email address, it tells you something about it's age.

Good luck with the new perl::lite toolkit there must be a ton of programmers out their having to code up their own soap headers and squinting at wsdl files right now.

[Michael Milewski]

Wow, so SOAP::Lite is not dead? you say "seriously ingenious Paul Kulchenko" yet to his code you mention "And not the \"good\" kind of awe" and to sum it up you say "Therefore SOAP::Lite needs a re-write" I find this all a bit too contradictory.

Come on, SOAP::Lite is great for a "hello world" like example but next to useless for any company level web service implementation. My current project is just that, communicating between Perl backend and a .Net financial system as well as some javascript which is to consume the web service. With no "round trip engineering" for code -> WSDL -> code I have tore my hair out just on making sure variables are correctly named.

I have started looking at writing my own from scratch or maybe an even better suggestion would be to use Inline::Java and one of the many trusted java implementations.

Anyway, it is definitely something that is necessary if perl is to survive beyond the "fetch temperature" like web services. I would love to help! I am happy to put my perl skills to work but would probably prefer to document and test the implementation, lets make it more completely documented then SOAP::Lite is so far.

[Jess]

Minor point, Marc, you only have to escape an @ if you double-quote the string, and thats because double-quoting means "interpolate vars in string", its fine in single-quotes. (I hope someone has told you that by now!)

Anyway, I agree that SOAP::Lite needs some re-work and a lot of improvement. I would suspect its easier to re-write than try and improve.. take the premise and start from scratch.

I've just ended up writing a perl-object-to-soap-data method, and wondered why SOAP::Lite can output these things, but can't be passed them without a bunch of SOAP::Data munging.. or am I missing something?

[beconase inhaler]

Honesty, integrity and a persuasive mentality are the most important qualities of an elected official
http://viramune.kadm.biz/index.php?qq=viramune viramune

See you

[Michael]

Thanks for the nice post!

Free PS3

[TMaxim]

SOAP itself has become an incredibly stable protocol.

[TMaxim]

Most SOAP toolkits have stablized along with the protocol.

Max

[Proflogistics]

Can tell more in detail about this protocol?

Proflogistics

[Korona]

More : It differentiates itself from other toolkits by still being really easy to use for the majority of use cases. But as more and more people adopt document-literal as their preferred method of encoding, the roots and biases of SOAP::Lite in regards to XML::RPC begin to show and the toolkit is not as resilient.

[Korona]

My current project is just that, communicating between Perl backend and a .Net financial system as well as some javascript which is to consume the web service. With no "round trip engineering" for code -> WSDL -> code I have tore my hair out just on making sure variables are correctly named.
Korona

[BaltikS]

Listed below are links to weblogs that reference State of the SOAP:

[TMaxim]

Much of the stuff belongs in a proper Perl SOAP module, however I am not the world's greatest Perl developer and I found the SOAP::Lite module a nightmare to understand, though to be honest I am not sure I do understand it ;-) This is the reason I never pushed stuff back to SOAP::Lite, I was never sure it was good enough or that it was shoved into the right place.

Грузоперевозки

[Genealogy]

SOAP::Lite needs your help. SOAP::Lite needs a group of 2-3 passionate people to take a fresh look at this critical toolkit for Perl developers and to usher into a new age of utilization, community growth, usage, and utility.
Genealogy

[Robbie Bow]

I would like to help with the development of SOAP::Easy. Let me know if I can be of any use.

[TMaxim]

I would like to help with development too.

Max

[Ryan]

Does anyone know of any ws-i compliant perl modules? I'm in a bit of a bind with a client that needs to interact with a webservice that formerly worked with soap::lite but is now ws-i compliant so my code no longer functions. Any pointers would be greatly appreciated.

[Ryan]

Never mind, I sorted it out by forcing Soap::Lite to speak document/literal and setting $soap->encodingStyle('');
for my Soap::Lite object. It's not that rough I guess once you figure out what the hell is going on but goddamn, this module is unwieldy. Is there really not a better soap toolkit for perl? I've always been able to do everything with perl but in this area it is certainly lacking.

Thanks anyway

[Martin Kutter]

I've heard some people here saying they want to help with SOAP::Lite's development.

Please use SOAP::Lite's development mailing list to contact me - I appreciate any help with SOAP::Lite.

Thanks,

Martin

[Shaman]

Sorry, where I can find development mailing list? Or please type your e-mail here. I what to ask you some questions.

Shaman

[Brian Fennell]

The SOAP::Lite developers Mailing List is here

h t t p s : / / l i s t s . s o u r c e f o r g e. n e t / m a i l m a n / l i s t i n f o / s o a p l i t e - d e v e l

(Or follow the links on the left hand navigation to "Mailing List")

The SOAP::Lite rewrite sounds like a perfect chance to use TDD or BDD

Brian Fennell

[Brian Fennell]

The SOAP::Lite developers Mailing List is here

h t t p s : / / l i s t s . s o u r c e f o r g e. n e t / m a i l m a n / l i s t i n f o / s o a p l i t e - d e v e l

(Or follow the links on the left hand navigation to "Mailing List")

The SOAP::Lite rewrite sounds like a perfect chance to use TDD or BDD

Brian Fennell