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

> It's true I fall into the opinionated camp, but I thought I tried to
> disguise my opinions in the original email.

I was getting that, but the disguise was thinly veiled :-) But seriously, making overtly provocative statements as an opening gambit to a debate is bound to have the effect of polarising views (imho), whereas I suspect that perhaps your motivation was different ?

> The two first points of my list should be evidently in reference to people that conflate SOAP

> and SOA as being synonymous

Yes, I find this somewhat irritating too, but as per your experience suggests, levels of understanding differ by company and even by project.

I guess some of us get paid to help reconcile these mis-understandings when/where we come across them. Not that that necessarily means you can always *do* anything about delivery pressures that, from the perspective of the chosen design of a solution you would consider to be weak !

> This of course compares poorly with the number of REST based services of different levels

> of Restfulness that I use regularly.

Agreed, at least within the context of where a RESTful solution can at least in theory be assumed to provide superior characteristics.

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.

> perhaps this is just because every project I have ever worked on using them could have

> been better implemented using REST principles

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 ?

> 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. My apologies if you have and your opinion *is* based on that of a practioner, but its a criticism that I often see (and recognise for myself) that many people who denegrate REST or SOAP/WS* have never actually tried 'the other one' (for real). I confess to being in that camp and thats why at present I don't offer a [strong] opinion for or against REST just based on what I've read (which is quite a lot but ... 'the proof of the pudding ...').

> I tried to make sure not to become exceedingly negative about SOAP in my original mail

> because it was not these things I wanted to talk about.

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. 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 ?

> The SOAP and REST war seems to have been won by REST (this seems to be common

[sigh] Only for those who see it in those terms, I don't. The 'common wisdom' statement also covers the same group.

Question: Is there an acceptance that REST is an important addition to the potential solution set from current proponents of SOAP/WS* ?

Answer: I certainly hope so.

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.

> I suspect seem successful because they are only used in a locked network but if

> they ever got exposed over the Web would fall apart not to mention prove to be full of

Yes I have experienced these also. But having said that, in some cases it is OK to have a strategy for internal integration which differs from that of external since some of the concerns apply more to one than the other ( e.g. interop). 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. In my experience how this service actually gets implemented is often a trade off between the delivery pressures of its business sponsor and the IT architects thinking about re-usability (almost always the first wins).

> That recently I have started to notice that people have started to say that there is no

> connection between SOA and SOAP

One's an architectural approach, and one is one possible implementation style, so no, I don't think they are 'joined at the hip'.

> And that I had noticed some people who had been on the REST side seemed to not like

> this and not to think highly of the SOA arguments

Yes indeed, and many of them are highly respected and very smart people with lots of experience, so of course we should pay [some] attention.

> So for me the interest is mainly of the popcorn popping entertainment variety: Will the SOA

> acronym achieve separation in the popular understanding from the dead weight of SOAP

> and WS* or not? Will REST be understood as a SOA or will it also beat down SOA as it did

Oh, OK. Don't much care .. accronyms tend not to last long in terms of the purity of their original intent. Marketeers hi-jack them all and pretty soon everything has the same set of 'labels' thus making their original importance moot.

SOA = Save Our Assets, right ?

> Mark Baker IIRC has spent some energy on saying that REST is better than SOA.

As have others (e.g. Steve Vinoski). 'Better' is a somewhat unqualified term though ...

> But actually since you are a SOA proponent and in this mail to the list you seem to argue

> that SOA and SOAP are still related perhaps I was wrong in my observation that currently

> there is some effort to unlink the two in the common understanding?

However, some would suggest that :-

On 04/12/2007, bryan rasmussen <rasmussen.bryan@gmail.com> wrote:

>
> why do you refer to these differences in implementation style as a *war* in
> which there are winners and losers ?
>
Because that seems to have been the presentation of the situation for
the last few years. I'm sure I'm not the first or even the tenth to
refer to it in this way.

> I see quite a lot of similar commentary from both sides of this apparent
> divide and for me anyway, it leaves me equally unimpressed.
>

Ok.

> I have been involved in a number of successful business services
> implementations using SOAP and a small set of core WS-* protocols for a
> large, standards based community effort (B2B) across one of the largest
> financial service sectors in the UK.
>
> More recently I've seen plenty to commend RESTful approaches and would
> certainly consider it for some of the business services that we offer and
> call. But it doesn't fit all my requirements, neither do I necessarily
> expect it to.
>
> These debates still seem to rage ad-nausium, but there seem to me to be few
> objective facts, and commentator's appear to be keen to exaggerate to make
> their point or at least be equally opinionated or selective (I'm afraid your
> comments fall into that camp)
>

It's true I fall into the opinionated camp, but I thought I tried to
disguise my opinions in the original email.

> Personally I don't see it as SOAP/WS* = wrong, REST = right
>
> If you think I'm sadly deluded, that's fine, I am always willing to be
> educated. But you will have to try a bit harder than throwing around the
> idea that everyone who does or has done SOAP/WS* is either stupid or misled.
>

Either my command of the English language is much worse than I thought
or you have something on your mind here. The two first points of my
list should be evidently in reference to people that conflate SOAP and
SOA as being synonymous, and the description of the list itself should
clarify that I mean it not as my particular opinion of SOAP/WS* but
rather as two possible explanations as to why this conflation of SOA
and SOAP has happened, with a following observation that I did not
think these where the especially likely to be correct explanations.
Now as it happens I do have a very negative opinion of SOAP and WS*,
perhaps this is just because every project I have ever worked on using
them could have been better implemented using REST principles - this
is of course just an opinion since I have not proved the point by then
going out and implementing the project on REST principles after
implementing them using SOAP (and sometimes the implementation
problems were more based on SOAP's attendant technologies: WSDL, XSD,
than they were on SOAP itself).

> Many of us (or perhaps more importantly our business sponsors) are somewhat
> tired of hearing, 'oops, sorry, we didn't do a very good job of that, but
> don't worry we have another bright idea about how to sort it all out'. Most
> times I get challenged with, '.. OK, how is the business going to benefit
> from yet another 'rip and replace' and how long is it going to take us and
> all our trading partners to get back to a position of doing business
> successfully (ideally more successfully than before)...'. This sort of
> challenge seems perfectly reasonable to me.
>
> Have you really never seen a successful implementation of SOA using SOAP/WS*
> ?

I have seen three (to varying definitions of success - one of which
people who use it all compliment but which I personally would not
classify as a success because the core services cannot meet the demand
and it is basically just doing a data lookup of data that is not
especially dynamic [addresses]) and worked on one that I could
classify as pretty successful (and worked on another that got us paid
and got done on time but was an embarrassing mess architecturally and
code-wise, based mainly on additional requirements in the last week
before delivery) and contributed on a third that could be classified
as an interim success given that it is part of a very big set of
services and architecture that will not really be done for at least
another year, and finally I have to use some regularly that I suspect
seem successful because they are only used in a locked network but if
they ever got exposed over the Web would fall apart not to mention
prove to be full of security holes (but this is just my personal
suspicion I have not attempted to write any proof of concept
exploits). This of course compares poorly with the number of REST
based services of different levels of Restfulness that I use
regularly.

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,
so I do have some animosity for these reasons, however although my
animosity may have shone through in my email, or I may have expressed
it before, I tried to make sure not to become exceedingly negative
about SOAP in my original mail because it was not these things I
wanted to talk about.

What I did try to state, and obviously not well or I would not have
been so  misunderstood, was:

The SOAP and REST war seems to have been won by REST  (this seems to
be common wisdom, just as it seemed to be commonly referred to as a
war, and often disparagingly as a Religious war - which Religious wars
are often used to denote conflicts over technical matters of little
import, obviously I implied that there was some importance to the
disagreements)

That recently I have started to notice that people have started to say
that there is no connection between SOA and SOAP, which seems to go
against all the the earlier assumptions as to what SOA was. I don't
much care, basically because from what I have ever been able to figure
out about SOA is that it seems to be the way I like to build things
(in the few cases where I can understand what is being discussed with
SOA).

That even more recently I have started seeing articles about using SOA
with REST. And that I had noticed some people who had been on the REST
side seemed to not like this and not to think highly of the SOA
arguments. (Allow me to note that I don't much care about that either
other than having a spectator's interest in how the fight will go over
the persistence of the acronym. If someone comes to me and says we
need this to be SOA and I can say I do SOA using REST principles blah
blah blah then it is fine for me, and I believe that I can say this to
anyone who comes asking about SOA because for a great number of people
SOA seems very vague.)

So for me the interest is mainly of the popcorn popping entertainment
variety: Will the SOA acronym achieve separation in the popular
understanding from the dead weight of SOAP and WS* or not? Will REST
be understood as a SOA or will it also beat down SOA as it did SOAP -
Mark Baker IIRC has spent some energy on saying that REST is better
than SOA.

But actually since you are a SOA proponent and in this mail to the
list you seem to argue that SOA and SOAP are still related perhaps I
was wrong in my observation that currently there is some effort to
unlink the two in the common understanding?

Cheers,
Bryan Rasmussen

> On 04/12/2007, bryan rasmussen <rasmussen.bryan@gmail.com> wrote:
> >
> >
> >
> > Hi,
> >
> > It seems to me that SOA is quite clearly associated in most people's
> > minds with SOAP and the various Web Services specs. Now there may be
> > various reasons for this, for example:
> >
> > 1. The association is wholly the product of uninformed people
> > associating the generic term services with Web Services, or the use of
> > the term Web Services in descriptions of SOA with SOAP based
> > webservices.
> > 2. The association is wholly the product of uninformed people thinking
> > that the three letters SOA are somehow related to the first three
> > letters of SOAP, which they are in an alphabetical manner but
> > otherwise not. (I've seen this argument once, I thought it was
> > interesting)
> > 3. The association is quite clearly caused by every SOA and SOAP guru
> > talking up that association over the last couple years.
> > 4. some confluence of these factors.
> >
> > Now I am pretty much prone to accepting number 3 as the reason,
> > especially when I go through the various SOA books in Safari and they
> > all talk about the marvels of WS-* and so forth and mention REST in
> > very disparaging tones, if at all.
> >
> > This brings me in a round about way to something I have noticed in the
> > last few months (I guess more accurately over the last year since it
> > was evident the WebServices winner had been declared) which is SOA
> > evangelists and architects and so forth first trying to downplay the
> > association with SOAP instead of embracing it(it seems to me it is the
> > last year when I have started to hear more often the argument #1 in
> > the above list)  and to start to talk about REST and SOA together.
> >
> > In the case of people talking about REST as SOA or other combinations
> > of these terms it seems that there has been a marked hostility in the
> > community of people who were on the REST side in the recent religious
> > war (although maybe religious war is not the right term since these
> > are generally considered to be wars over meaningless things and not
> > wars over important technical principals) to the linking of SOA and
> > REST.
> >
> > So the question now is: with REST the winner just how forgiving will
> > the new dominion be, and how ruthlessly will the spoils be divided?
> > (please formulate own poetical metaphors for the destruction of
> > heretics and associated activities: scourging etc. )
> >
> > Cheers,
> > Bryan Rasmussen
> >
> > _______________________________________________________________________
> >
> > XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> > to support XML implementation and development. To minimize
> > spam in the archives, you must subscribe before posting.
> >
> > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> > subscribe: xml-dev-subscribe@lists.xml.org
> > List archive: http://lists.xml.org/archives/xml-dev/
> > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> >
> >
>
>