[
Lists Home |
Date Index |
Thread Index
]
Paul Prescod wrote:
> To be honest, I don't want to think too deeply about this but all I'll
> say is:
>
> * these kinds of visual interfaces have the most success when the
> underlying format is declarative, like SQL rather than programmatic,
> like code.
>
> * the SOAP web services model is ultimately about gluing things
> together with code. As my article shows in detail, it falls apart
> dealing with declarative languages like XInclude, XSLT,
> XQuery, RDF etc.
> To some in the SOAP world this is considered "no great loss" but my
> sense is that it would be a major impediment in the project
> you outline.
>
> * similarly, visual interfaces work best when the objects being
> manipulated have standardized inputs and outputs. When one glues VB
> components together one often (usually?) must resort to basic code
> because there is no data flow model and adding things to a "listbox"
> requires totally different methods than adding them to a "listview".
> SOAP RPC does not help. REST might ... or it might not. It isn't
> designed for that but at least the interfaces are consistent. (maybe
> interesting product ideas there)
So what is it designed for? My feeling is that you've made a very compelling
case for REST being a better technical solution than SOAP, but what is
lacking is to tie this into some use cases that show what is possible with
the former and not with the latter. This requires making some intelligent
guesses about what people will actually be using web services for, which is
what I was attempting to do. I wouldn't see this as a "visual interface"
issue, but rather as a data consolidation and workflow customization issue.
What are the use cases that you see where a SOAP solution just doesn't work?
I don't feel so dense asking this question, since a lot of other people
appear to be confused about this.
> Vendors claim they have this for web services today. I doubt it but
> maybe I'm wrong.
If anyone can point me to some specific vendors, I'd like to take a look.
Matt
|
