Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: The association of SOA with SOAP, and to the inevitable en
 > > 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 
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
