RE: [SOAP] Re: soap stuff

excellent summary of document/rpc & literal/encoded, Shane! you really should publish that in an article somewhere. i get so many emails from people using NuSOAP to access .NET doc/lit services, and they are always very confused about why it's not working like an RPC style service. Now i can point them to your email :) regarding document style messages: AFAIK, document style basically says "look to the schema for all answers". a message may or may not have an RPC style wrapper-element around it. if it does, it will be defined in the schema. the way i've implemented document in NuSOAP is to capture the body of the message and make it accessible as a string. this allows the user to use their own discretion as to how they want to process it. many users do not have the domxml extension, or use their own xml processing class. d. > -----Original Message----- > From: Shane Caraveo [mailto:shane@caraveo.com] > Sent: Tuesday, May 28, 2002 2:11 PM > To: brad lafountain; soap@lists.php.net > Subject: [SOAP] Re: soap stuff > > > >>> So again... now what. I currently have everything hosted on SourceForge. > >>>Including the website, cvs and all the stuff SF offers you. > >> > >>Ok, so first, does it go in PECL or in PHP main distribution. I would > >>say PECL for now, then mirror to the main distribution when a "stable" > >>release is done and documented. > > > > I would agree here... but... Has anyone thought about how confusing it might > > be to move things to and from PECL/main to end users? Im not exactly up to par > > on the PECL stuff. Or where its going. > > > > My understanding of PEAR/PECL: > > PECL is part of PEAR, for C extensions (doesn't make any dependencies on > pear code). The pear installer will know how to download and build > PECL extensions. Some PECL extensions will end up being mirrored, or > branched, via CVS controls into the main distribution. That mirroring > will happen at times when the PECL extension is at a 'stable' release, > so the PHP distribution will always have a stable release of an > extension. Meanwhile, between php releases, the PECL extension can do > another 'stable' release independently of PHP. When the next release of > PHP occures, the latest 'stable' release of core PECL extensions will be > included. It's a very sweet system once it gets finished, which should > be relatively soon. This is also very similar to the way CPAN works, > and how we run PPM (Programmers package manager, which is for Perl and > Python). > > >>The next part is to get people on board with the change. Currently xpat > >>is bundled. What will change by bundling libxml? Do we replace xpat? > >>How does that effect other modules (xmlrpc, domxml, xslt, etc.)? > >>Xmlrpc, since that depends on xpat and *will* be bundled starting with > >>php 4.3. We need to talk with Stig about this if libxml is to be an > >>xpat replacement. For now, it might be easier not to bundle libxml just > >>to get started with putting soap into the php cvs. > > > > xmlrpc is being bundled? hmm.. thats too bad. I was hoping that phpsoap could > > have a xmlrpc encoding/transport layer incorperated with it. Oh well. > > Yes, and Stig is very big with xmlrpc-epi. However, if xmlrpc-epi can > use libxml, or be easily modified to do so, and libxml is indeed faster > than xpat, perhaps we can make a convincing argument to drop xpat. > > >>I definitly want to be involved at *least* with the design of the for > >>the transport layer. > > > > Sounds good... Maybe you can give me a brief run down how the transport works > > before I start looking at your code. Then after i look at your stuff i can give > > you feedback on my ideas. Then we can decide where to go. > > It's quite simple. A small wrapper class (SOAP/Transport.php) is used > by the soap client class. The uri passed to it is parsed, and based on > the scheme of the uri, the real transport class is loaded > (SOAP/Transport/HTTP.php for example). The transport classes essentialy > have a send function and a few supporting functions, that is it. > > The issue is more about how the script passes parameters necessary for > the transports. It needs to be done in a way generic enough that an > arbitrary transport can be added without needing to change the soap > client api (SOAPObject in your library). The way I accomplished this is > to have one parameter be an associative array. I can then add any > parameters that may be needed. So for example, below is a client > sending soap via smtp. The 'host' is the smtp server to connect to. > 'port' could also be passed. Additional headers can be passed by doing > 'headers'=>array(...). > > include("SOAP/Client.php"); > > $soapclient = new > SOAP_Client("mailto:user@domain.com"); > > $options = > > array('namespace'=>'http://soapinterop.org/','from'=>'user@domain.com','host'=>'localhost'); > > $return = $soapclient->call("echoStringArray",array('inputStringArray' > => array('good','bad','ugly')), $options); > > // the result contains the messageid of the email that was sent, > // or a fault on failure > print_r($return); > > > >>I can start right away with the interop tests, probably get something > >>out by next week. This will tell us where the library stands with > >>interop against other soap implmentations. > > > > > > Cool.... If you want to wait for 2 or so days I want to get some stuff in > > there before you start on the interop tests... I have some stuff that is > > commited and isn't commited that i would like to get into a release. > > No problem. The time have have to work on stuff is generaly late at > night after work, or during the weekend. I have plenty to do ;) > > >>What is the status of literal encoding and document support in the > >>library right now? I spent my weekend examining that stuff and found it > > > > Here is my understanding... > > rpc is using native data structs and doc/lit is different becuase it doesn't > > pass the data in a lang struct it returns more like a xml document used for > > data processing? > > You can pass native data structures in doc/lit just fine. One of the > big things that helped me understand doc/lit was the realization (I knew > it, but didn't REALIZE it ;) that you have to seperate the document > style (rpc or document) from the encoding (literal or encoded). So you > get four combinations: > > rpc/encoded > rpc/literal > doc/encoded > doc/literal > > Further, each method in the wsdl can define it's encoding style, so you > can have mixed encoded/literal in a soap message as defined in > wsdl:message/wsdl:part. Different bindings may choose to use rpc or > document style, but that effects the entire soap message (as far as I > can tell). > > So the easiest thing to get right first is the encoding. encoded = > typed, literal = untyped. For literal encoding, you do not set any > attributes related to encoding (xsi:type, wsdl:arrayType, etc.). > Essentialy, you do not have to do any of the Section 5 encoding rules. > Makes life a bit easier when serializing/deserializing data, but it's > not terribly different. > > Document is a little trickier, and I'm still working out some of the > details in my head. A document style message MAY OR MAY NOT have a > rpc-like call in the body. That is where things get a little fuzy in > the documentation, and when I get some more time I will figure that out > in full. Document style is preferable if you want to pass 'arbitrary' > xml data. > > How the soap implementation handles return data is up to the > implementation. You can parse it into DOM, leave it as an xml string, > or attempt to parse it into native data types. I think the result > should be an option set by the script, probably with DOM as the default. > > > > ps. > > Are you saving this email chain... It would be nice to have this up on some > > email board. > > Lets move the rest of this onto the soap list. > > Shane > > > > -- > PHP Soap Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > >