On 08/02/07, Mark Baker <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
>
> On 2/7/07, Steve Jones <[EMAIL PROTECTED]> wrote:
>  >
>  >    If it was CLOUD oriented architecture then of course Grady would be all 
> in favour :)   To be fair if he is saying that _technical_ SOA is snake oil 
> then I'm with him. The WS-* is "complex" v "simple" REST however misses the 
> point that there is no REST-* yet so the comparison is fatuous,
>
>  Sure there is.  There's a rich and mature set of specifications which
>  address common problems with the Web, and otherwise add features to
>  it.  What do you need specifically?

Security and reliability leap to mind.

>
>  That's not to say there aren't things missing, just that there's a lot
>  more there than you think.

I'm aware of quite a bit of it, and having to cope without the likes
of WS-Security by using HTTPS with client side certificates to give
fuller authentication.  The problem with that is that there is a
documentation overhead in word to explain it.

>
>  > its hard to see how IBM and MSFTs "REST" implementations will be any 
> better at interacting out of the box than their WS equivalents, hand coding 
> everything isn't interoperability.
>
>  What does the means by which code is produced have to do with 
> interoperability?

Anyone good can hand code anything that isn't impossible.  The less
talented (the majority) need their hands held and need tooling to
support them.  This is why I use a JVM because doing manual memory
collection sucked and regularly led to issues as people either a)
forgot or b) deallocated before they should have.  Sure we could also
both write binary class files and mimic RMI using C and thus be
"interoperable" with Java, but that would a dumb idea and limited to a
very small set of people, thus we all use Java to interact with Java
via RMI and we use the tools provided to achieve that end.

We need solutions for the majority, not for the elite because to be
quite honest the elite can always cope.

>
>  What affects interoperability is well-defined message semantics, and
>  REST is self-descriptive so you can't do any better than that (as the
>  size of the Web demonstrates).

The phone network is self-descriptive as the number of phone calls
demonstrates.... we are talking here about computer to computer
scenarios, not about rendering things for people.  REST is not, and
we've been over this lots of times, self-descriptive at that level.
If it was there would be no documentation required for any developer
to invoke any REST service and tools would be already available which
could automagically consume and interact with any REST service.


>
>  Mark.
>  --
>  Mark Baker.  Ottawa, Ontario, CANADA.         http://www.markbaker.ca
>  Coactus; Web-inspired integration strategies  http://www.coactus.com
>                    

Reply via email to