Agenda

Hi everyone, I'm here also, of course ;) I want to start off a discussion to generate an Agenda for soap development in PHP. Part of this is to get everyone on board with working towards the same end goal, part is to generate a requirements doc to define what SOAP support in PHP should consist of. I'm glad to see some lurkers here who work on projects like Horde, etc., input on needs and usage from people working on systems like that would be very useful. I'll start off with my idea's, then everyone can chop it all up :) Primary purpose of this list: Development of a base SOAP implementation that will be part of the default PHP distribution. This includes a C extension and a PEAR library, which would basicly replace and/or enhance what I've done in PEAR already. The reason for the dual development is to have a script based implementation that would be automaticly used if the C extension is not loaded. This also includes documentation, tutorials, whatever, on top of the actual library itself. Requests for help, etc. should be on another list, presumably on of the existing php lists. Right now, my assumption is that Brad's ext/soap and PEAR::SOAP will be used for the baseline of development, but that is not written in stone. Design Goals: A common, well defined API between C and script implementations C and script implementations should be able to interchange various parts. Transparency of usage Interoperability Expandability To define the above a bit further: Using the same API and class names between the C and script implementations allow for something like this: if (!class_exists('SOAPServer')) { include_once('SOAP/Server.php'); class SOAPServer extends SOAP_Server {

     function SOAPServer() {
        $parent::__constructor();
     }

} } A script wanting to use the SOAPServer class would always include the above script. This way the script is always garaunteed to have SOAP available either through the C library or the PEAR library, or even any other library that implements the same API. We should look at the existing PEAR::SOAP and NuSOAP, which are derived from Deitrichs earlier SOAPx4, Brad's ext/soap and then some other languages like SOAP::Lite, etc. to see what capabilities exist and how they've been implemented. There is also a well defined client side api we started developing here at ActiveState with several SOAP implementors, that could be looked at for some idea's: http://aspn.activestate.com/ASPN/WebServices/SWSAPI. I'm not pushing to use that API specificly, I feel there are certain issues with it that would make it difficult to use in PHP and other items that may not realy be effective for performance reasons, but a lot of good thought did go into it. Also, in defining the common API for PHP, I don't think we need to go as far as SWSAPI did. Being able to 'exchange parts' is crucial to rapid development or experimental development at the script level. For example, someone wants to implement the Jabber transport for SOAP. Being able to override the C extensions transport layer with PHP script enables a developer to quickly hash out issues in script, then decide whether to implement the transport at the C level or leave it in script. There are other parts that should be factored into classes, for example the soap message parser, and the serializer. Being able to use these seperately allows for a complete override of the soap client and server implementations that are made available by default. Transparency of usage implies that no knowlege of SOAP is necessary for a user to use and implement SOAP services. The current level of transparency requires a few lines of code to implement the server on top of a class the developer writes. It also requires good usage of WSDL to (de)serialization. PHP currently has some built-in XML serialization through a module, that uses some common serialization code in PHP. Hooking into that type of a model may provide some very interesting benefits. We could also consider taking this a step further, and give PHP the ability to handle SOAP requests the same way it handles POST data, but that's just a random thought. Interoperability is critical. There are lots of interop issues. It's something I have focused the bulk of my time towards when working on PEAR::SOAP. There is a body of SOAP developers that work on interop issues, called SOAPBuilders, both Deitrich and myself are on that list and involved in interop tests. Using a consistent API will allow us to leverage a single interop test suite to both the C and script level systems. Expandability allows us to easily add new features without needing changes in the API. This needs to be considered while generating the API. Shane