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?
 Didier PH Martin wrote: > >.... > > Didier replies: > In procedural languages you say *how* to do things. In functional languages > you say *what* you want. For instance, languages like Visual Basic are > procedural language because you specify to the system a sequence of actions > to perform, something like "display", "calculate", "store", "recall". In the > case of functional language, you do not have to say "display" you specify > what you want as final result. For instance by specifying a template. There > are also other more subtle elements to consider but these two elements catch > the essential spirit of procedural vs. functional or the opposition of "how" > vs. "what". In one case you tell the system what kind of action to perform, > in the other case you specify what you want as final result. I'm going to suggest different terms and definitions. Terms: declarative versus procedural. Declarative is "what you want". Procedural is "how to do it." But I do not think that the two are absolutes but rather a spectrum. XSLT is *more* declarative than Python but not AS declarative as CSS. (for instance in XSLT you must explicitly say to do the "apply-templates" whereas CSS just "knows") > Off course, Visual basic is a strange beast since you visually specify the > visual end result by placing components in a form. And this could be > considered as specifying "what" we want in terms of visual layout [1]. Yes, visual basic has a declarative screen layout strategy, whereas Java has a procedural one. Here are some examples. Here is a procedural way to download a file: ftp ftp.somesite.com > username: XXXX > password: YYYY > GET somefile.xml Here is a declarative way: ftp://ftp.sometsite.com Here is a procedural way to make a phone call: "Operator? Could you please see if there is a Jones in Smallville? Could you please connect me to that person?" Here's a declarative way: 223-555-2822 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. It isn't that REST allows you to move entirely into a declarative universe. Some methods WILL have side effects and you can't invoke them willy nilly. But REST says that barring a bug, GET will not have side effects. Therefore you can safely build declarative systems on top of GET. Examples of that include every web page in the world, Google, Yahoo, etc. Nobody ever hesitates to add a page to Yahoo because doing a GET on it will have bad side effects. The side-effect free GET method is the basis of hyperlinking which is a declarative way of relating information resources. For instance, here is a declarative way of relating a purchase order to a customer resource: <po> <customer href="http://www.ourcustomerdatabase.com/ourcustomers/customerid"/> ... </po> Then to get from a purchase order to a customer then I can use the declarative XPath expression: document(/po/customer/@href) This will allow any PO to refer to any customerID anywhere on "the web" (more likely the organizations intranet or maybe that of partners). The typical SOAP strategy would be more like: <po> <customer>0903426897432</customer> ... </po> Now to actually GO from the purchase order to the customer ID, you have to do something like this: someotherservice.someMethod(customerId) That can't be done in XSLT/XPointer/XInclude so I guess we'll have to add SOAP RPC features to all of those languages! Note that there are many who say that I unfairly talk about SOAP RPC as if it were the whole thing. But the situation *gets worse* if you avoid the RPC subset of SOAP because you don't *even* have a standardized concept of method, so you are even farther from interoperability. You don't even have the procedural "someotherservice.somemethod(...)" syntax. Paul Prescod 
|
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
|
|||||||||
