[
Lists Home |
Date Index |
Thread Index
]
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.
|
