[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: What does SOAP really add?

• To: "Simon St.Laurent" <simonstl@s...>, <xml-dev@l...>
• Subject: Re: What does SOAP really add?
• From: "Didier PH Martin" <martind@n...>
• Date: Mon, 22 Apr 2002 15:07:11 -0400
• References: <1019412854.444.19.camel@l...>

Hi Simon

Simon said:
> Now I'm seeing comments like Adam Bosworth's piece in the newly-titled
> "XML & Web Services Magazine".
> (http://www.fawcette.com/xmlmag/2002_04/magazine/departments/endtag/)
> ------------------
> Loose coupling is central to the nature of Web services-based
> application integration. That's why it seems to me that the right model
> for XML in Web services is a message-oriented, document-based one rather
> than one based on remote procedure calls.
> ------------------
>

Didier replies:
I think that loosely coupled systems are perfect in the case a request for
data or document is performed. If the document returned is semi-structured
or not structured then the receivers will need to perform more processing on
it to make it useful. Otherwise, if the only thing that we need to do is a
remote action like, for instance, setting a switch to ON, then an RPC is
well fitted to the job. When I say well fitted, it is simply in terms of
economies of code. I should need to write only a single line of code to set
the switch. If the system returns more than an error code, something like a
document, this may require from my part more work. That extra work is
outside the problem I am trying to resolve and this is a reduction of my
productivity.

You know what seems to be missing to infosets manipulation is having more
semantics. For instance an element is a bit too generic, it would be more
useful if I could use the semantic part of this element. For instance if the
element is an address it would be more useful to access it as a variable
named address. This implies no impedance mismatch between the problem to
resolve and the object manipulated. What I need to manipulate is an address
not an element. This would lead to programs easier to maintain, etc...

So, I would say that I agree with Adam when we get some data. It is better
that a document is returned. It would be useful also if the language I am
using to perform some action on it gives me an access to the semantic part
of the data, not to generic blobs like elements. I my problem is to process
a part_description then I should be able to use part-description variables
in my program, not elements.

I think that the real problem we are facing is that actually, nobody
implemented something that could help us to process an xml document from the
semantic point of view. We are still trapped at the syntax level. Or if
anybody did that, please, speak loud, this is something I would experiment
in Didier's labs.

Cheers
Didier PH Martin.

• Follow-Ups:
  • Re: What does SOAP really add?
    • From: Mark Baker <distobj@a...>

• References:
  • What does SOAP really add?
    • From: "Simon St.Laurent" <simonstl@s...>

• Prev by Date: RE: Calling functions from XSLTs
• Next by Date: Re: What does SOAP really add?
• Previous by thread: Re: What does SOAP really add?
• Next by thread: Re: What does SOAP really add?
• Index(es):
  • Date
  • Thread