Re: [xml-dev] The association of SOA with SOAP, and to the inevitable en

["bryan rasmussen" <rasmussen.bryan@gmail.com>]

>
> Actually the main opposition to SOAP/WS* often (but not exclusively) centers
> on the ease of use characteristic, particularly from the perspective of the
> consumer. IMO this *is* a very important factor that is often overlooked in
> service design. Many seem to prefer a view that '.. its my service, so I
> will dictate the conditions under which it can be used.'. True enough
> perhaps, but if the point of offering a service is to 'do business' on the
> basis of as many people as possible being able to successfully call it
> (especially in the face of competitor services), then making it harder than
> necessary would appear to be a bit counter-productive.
>
ease of use is a primary consideration for me I think, mainly because
often when I build a service it is with the view that I will need to
be using it some months down the road for other things and probably
using other technologies than I am building with. In fact I often want
to build a service for this reason, that I am allowed to integrate
with some datasource using a particular technology due to company
restrictions but not with my preferred technologies.



>
> Wow, that's quite a recommendation. I cannot say the same, which either
> means I'm missing something really important, or there *are* actually some
> circumstances where SOAP/WS* *does* make sense but you just haven't come
> across one yet ?
>
I am willing to agree with this, and in fact I think I have seen these
circumstances but I have not had to work on them. The ones I have seen
where SOAP MAY make more sense all have to do with using it as a
backend protocol between various networked services where everything
has been developed together using basically the same suite of
technologies. SOAP is then the glue between the various services. I
guess that makes sense, I haven't had to work on one of those but when
I see them and see the progress on them it gives me an intrinsic
feeling of hmm that doesn't seem really wrongheaded or anything, but
part of that feeling can be because the knowledge of the various tools
and products being glued together was very highly developed and
specialized, and I didn't really understand all of them. Stuff like
WS-Management seems like, well okay, that's how you want to do it I am
not opposed.

>
> > Now of the ones I worked on that have been somewhat successful are the
> ones that I was
> > pretty sure I could implement much easier using REST,
>
> Fair enough, but you don't actually say that you *have* tried REST out 'for
> real' except from the consumer side.

Okay, I have tried out REST for real on the programmer side, these
projects however have been pretty small scale but in stress testing
them they responded well and I suppose they would scale up using the
techniques of web scaling (one of the more amusing anecdotes that I
have regarding SOAP was a well-respected SOAP guru in the Danish
Government telling some senior developers that were having problems
with their SOAP based webservices that the solution involved http load
balancing - so much for protocol agnosticism [there was no
specification of which protocol SOAP was running over, it was just
naturally assumed]),

the thing that I can say just for my own experience as both programmer
and consumer is: most programming involves data lookups, REST has a
model for safe data lookups that scales really well, it also has a
good model for informing consumers if they have to do the lookup, and
error reporting if the lookup goes wrong. Also with http 303 it
provides a way to bind the idempotent result of a non-idempotent
action (perhaps this isn't as important to everyone else as it is to
me but it recently proved useful to me and I think I will be using it
a lot in the future)

 That SOAP did not identify bindings for GET was I think its downfall
(sorry, I believe in the war metaphor).


>
> Ok. I think SOAP has some things to commend it (in the circumstances where
> it makes sense), at least as a convenient way of packaging up the various
> type of service data requirements. REST does this too, but chooses a
> different approach, the problem is still the same (scoping + metadata +
> method + payload + data types .. etc..).
>
>
> > This of course compares poorly with the number of REST based services of
> different levels
> > of Restfulness that I use regularly.
>
> Interesting this notion of 'different levels of Restfulness'. Sam Ruby and
> others still suggest that the majority of apparent RESTful services haven't
> really gotten away from RPC or they are hybrids.

That, and there are overuses on GET that can be problematic. I am not
certain that the REST architecture is really really the way the web
works, it is perhaps only an approximation.

>Perhaps this indicates a
> similar level of mis-understanding as the one that you are suggesting for
> SOAP/WS*/SOA. Admittedly its relatively early days for REST, but its perhaps
> a warning to make sure that the concept doesn't get undermined by poor
> practice ?
>

 I suppose every concept will have poor practice, and a lot of it. The
concepts that are worthwhile will last through the poor practice.
Whether or not the web is really based on REST it seems that the
usefulness of the web and the concepts that have proven to work have
lasted through lots and lots of poor practice.

>
> But its back to my point on the original post, REST doesn't need to 'rubbish
> the opposition' in order to be taken seriously. Unfortunately thats the
> approach that many people choose to take and leads to an awful lot of wasted
> time and effort arguing about points of irrelevence.

This was sort of my question originally (or at least part of it), was
the basic feeling that REST would rubbish SOA? In some ways I can see
the competition as meaningful, both are architectures, REST has a
particular well known implementation. SOA is an architecture. If SOA's
architectural model can cover both REST based webservices and SOAP
based webservices what does that say about SOA?

However I think that a lot of the rubbishing of SOAP from REST is
perhaps also do to REST having been rubbished by SOAP over the years.
>
>
>Personally I tend towards a view that suggests that if we design a
> business service initially for internal use, there is a reasonable chance
> that at some point we may want to offer it externally.

Indeed, that is the situation now for these services (by now meaning
that I can foresee it is going to be a major issue in the coming year)


>
> However, some would suggest that :-
>
> REST = Web Services

I have sort of that opinion, maybe more like

WebService = new REST();

The reason for this opinion is basically on the level of language, the
phrase Web Services implies certain things, and originally SOAP was
tied to these implications.

 It implies a service available from the Web but at a higher level it
also implies a service operating on the same principles as the Web.

 For example if we were unfamiliar with the phrase Windows Service and
we heard it for the first time we would assume from the name, hmm that
is an a class of services or an api for making services available in
Windows and that can be interacted with through common methods
available to the Windows System, I guess a service can be used by
other programs operating in Windows. I guess there is a common api for
working with these services, common way to get errors from services
etc. It would be very amazing to find out that Windows Services didn't
support a COM api or couldn't be monitored via WMI (sorry if this
analogy is somewhat poorly constructed, but I need to hop back on a
static code analysis project now and can't think up a better one).

Cheers,
Bryan Rasmussen