Re: [SOAP] Re: soap stuff

I'm not meaning to be rude or anything, but before everyone makes assumptions about my examples, perhaps you should heed your own advice and examine pear::soap's api, which can use a class proxy (or class overloading with the overload extension) to do the following: $soapclient = new SOAP_Client("interop.wsdl"); $soapclient->echoStringArray(array('good','bad','ugly')); However WSDL is required for that kind of thing to work. Otherwise, you have to have the capability to be explicit in what you are doing, as the example did. A soap library has to be able to work without WSDL also, since WSDL is not a requirement for soap operations. I don't arbitrarily make up idea's, the example is a real working example, and I have dug deep into brad's code and know that generaly the api is similar to pear::soap, soap::lite, nusoap, etc. Shane phpsurf wrote:

hi i've not been too far through your mail yet, but there's just one thing that raised to me : PLEASE, before designing you API, please have a deep look to brad's extension, and study how simple it is to call methods on a soap object ! you don't have to do such complex calls :

$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);

but simply : $soapclient = new SOAP_Client("somewebservice.wsdl"); $return = $soapclient->remoteMethodName($anySerializablePHPVariableDescribedInTheWsdl) ; all the boring staff (namespaces, message structures, ...) which is specific to the called service, is described in the WSDL and doesn't need to be defined in PHP for each call. and the method is transparently called remotely, when its syntax seems to be local. this all really makes life A LOT easier ! I think to have such a behaviour with PEAR (i mean PHP-side, vs C-side) you could maybe use the new overload extension, using especially the method call overloading feature ... hope you agree with an API like this one !

-----Original Message----- From: Shane Caraveo [mailto:shane@caraveo.com] Sent: mardi 28 mai 2002 23:11 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

______________________________________________________________________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... http://www.ifrance.com/_reloc/email.emailif