Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Can you stand yet another SOAP-RPC vs HTTP GET question?
 Hi Paul, Paul said: > Now consider a SOAP message. You connect to the endpoint. That's like > the operator or FTP server. You send it a message (or invoke a method), > that's like the request for a file or phone connection. > > It might seem that we could build a declarative layer on top of SOAP as > we did on top of FTP and the phone number system, but it isn't that > simple. The side effects of FTP fetching and phone calls are well > understood. The side effects of calling some random SOAP method is not > explicit to clients of that call. So you need to think about how often a > method is going to get called in processing a request, or in what order > methods are going to get called. So you need to think about the HOW > things get done, not just the WHAT gets done. > Didier replies: It depends, from the RPC standpoint, if the function doesn't work, you just need an error returned to the calling function. There is no absolute necessity to know the marshalling process. However, I concede that this marshaling process (i.e. SOAP) is not without flaws notably from a security perspective. The more I think about it, the more I think that the HTTP protocol could have been used as a function call mechanism. If, for instance, Perl, Javascrip, java or python would allow the usage of an interface description file and if these languages would support an HTTP based marshaling process, we can envision that several lines of code[1] could be replaced by a single function call. After all, an HTTP transaction is composed of a verb, a target location and a collection of attributes/values. Everything we need to create a remote function call. Thus, a SIP session initiation could be replace by: sip_open(url..., etc...) The very nature of these function calls necessitate that the parameters are defined in a strict order and that the definition/type of each parameter to be defined somewhere. Each parameter's position is important since the location is also an indicator of its type. Thus parameters and verbs definitions are necessary to indicate to the system what's specific to each parameter location (i.e. the verb name and the parameter types). So, creating new verbs would be equivalent to creating a specification file a la WSDL. So to speak, SIP and Webdav could be defined by a WSDL file instead of an RFC. Every body would have been able to create their own function calls. Note: I should say that the main advantage of having an RFC is that the function calls (ex: SIP and Webdav) are better defined and documented than functions defined by the seat of the pants. Moreover, I think that we need two basic things: a) Custom functions with which an action is called and more precisely defined with parameters. Nothing more than an error code returned. Not a full document but only something in return that says if the function was or not successful. If the call wasn't successful, to return the kind of error that the calling program can use to take an appropriate action. b) Transactions. In that case, we ask to GET a document, POST a collection of parameters or a document and get back in return an other document. For instance, ask for an account statement or ask for the all the invoices due. Or ask for an information contained in a database. So in case (a), we want the other end to perform an action and this is not necessarily to get a document. We just want to know if the action worked or not. To return a document requiring several lines of code to process is simply overkill, We probably all want something as simple as we would do with the language's constructs. In the latter case (b) it is a document that we want. That said, I agree that we can use the actual HTTP architecture to encode a marshaling process between two or more procedures/programs. In fact several members of this industry did that in their own system. The problem is that no programming languages resolve the impedance mismatch. It is obvious that, if we only need to call for a remote action and need to know only if this worked or not, we will have to write more lines of codes than with a SOAP enabled language. Let's imagine that we need to activate a remote switch. The only response we want to get back form the called system is if it worked or not and if not, why. With a SOAP enabled language this is reduced to a single line of code, for example something like: if open_switch(front_light) != OK then (perform an error handling procedure) else (continue program....) In that case we do not want to process a returned document. Just benefit from the language constructs we are using. But for several business process it is obviously beneficial to use documents, something like, for instance, xml_edi to encode the business processes. We would also have these documents well authenticated and transported free of any potential manipulation by outsiders. Conclusion: what's missing is a language enabled with a REST marshaling process. A language having also a SOAP enabled marshaling process. This way we could compare both approaches. But actually, up to my knowledge there are no alternatives to SOAP. I mean, an implementation where all impedance mismatches between the marshaling process and the language's natural constructs have been resolved. For sure RPC/SOAP used for everything is also crazy, in several cases, document exchange is a lot better than an RPC. cheers Didier PH Martin [1] actually just to process the document's payload may require several lines of code. These extra lines of codes are pertinent to the problem to be resolved but extra effort needed to compensate for an immature system. 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
