On 24/11/06, Stefan Tilkov <[EMAIL PROTECTED]> wrote: > On Nov 24, 2006, at 7:47 PM, Paul Fremantle wrote: > > > Stefan > > > > My favourite internet Irish tin whistle music website uses SOAP to > > link to Google, and Yahoo uses SOAP to power its email client, so I > > don't think you can say SOAP on the internet is dead. I give the music > > website as an example of a small organisation that isn't "enterprise". > > > > Well, maybe dead is relative -- but I don't think SOAP/WSDL would be > the obvious first choice for anyone doing a "Web API" nowadays.
Unless of course they were a) Exposing an ERP b) Creating a cross industry standard c) Wanted it to be simply consumed via tools d) Wanted to have clear and standardised ways of adding reliability and security e) Wanted to include async processing (WSDL 2.0) and callbacks. f) Wanted to communicate with a partner/supplier Which is the first six reasons that came to mind, if I'm dealing with a commercial 3rd party then SOAP/WSDL would 100% be my first choice, they are going to have something commercial at their end, so am I, so SOAP/WSDL makes real sense. Now if I was knocking up a quick demo thing then I might go for REST (I'm looking to extend the georipper service with some extensions in REST only for instance). Aiming at a company = SOAP/WSDL Aiming at certain classes of developers = REST Aiming at other classes of developers = SOAP/WSDL > > > Anyway, that wasn't my main point! > > > > It is perhaps a little bit wrong to talk about REST as an option for > > a Service Oriented Architecture. Most existing services don't cleanly > > map into REST, except those directly backed by a resource model such > > as a database. Even a layer of stored procedures over the data is > > likely to mean that you cannot map it into REST. > > > > Really you should be talking about Resource Oriented Architecture > > (ROA). > > > > I agree, provided we're talking about SOA, the technology/ > architecture, not SOA, the business concept (as used e.g. by Steve > Jones). :) And I'll go along with that too, SOD and ROD (Service Oriented Development and Resource Oriented Development) are two viable approaches. > > > I actually think ROA has a number of attractive aspects, but I don't > > think its the solution to everything. I think that a POX (Plain Ole > > XML) or SOAP approach is going to be required because not everyone > > thinks in a resource oriented way. > > > > POX doesn't have a real definition, at least none that I know of. For > the sake of the argument, let's assume that POX can be just as non- > RESTful as SOAP 1.1 and as RESTful as the Atom Publishing Protocol > (which, after all, uses only plain old XML). IMO, the more RESTful, > the better, but I'm not zealous here. Obviously anything that works > is fine. Which is beside the point, I think. > > > I think its time to call the Rest-ians on their distinctions. There > > are plenty of RESTians taking a hard line on what is "REST" and what > > isn't, > > That's actually one of its benefits, IMO - it's pretty easy to assess > the "RESTfulness" of something. It's pretty hard to do that for > "service-orientation" :-) SOA-RM does it for me. I still don't know however how a business interface would be described using REST from the perspective of the consumer (producer side is simple), so far the REST interfaces I've used have been simple to use technically, but have assumed quite a bit of XML and system knowledge on the consumer side, its not as simple for a consumer as "import WSDL, generate client proxy, write in language of my choice" or just plug into my BPEL and use it straight away. This is my issue with REST, its going to have to link in with the process, security, reliability and other elements that are really demanded by businesses as they do more and more work across the internet. At the moment the claim is that its simpler and WS-* is complex, but only because REST-* doesn't exist. > > > and at the same time willing to say that REST is the only good > > solution for an SOA. Well, if you analyze most "services" and SOA they > > aren't based on state transitions of resources. Trying to have your > > cake and eat it? > > > > I don't get that point. Many existing SOAs use Web services and are > modeled in a way that could have been achieved with CORBA (and, as > Eric is sure to point out, some have even been built on CORBA). So > what? REST proponents suggest that there's a better way, and that > it's different. > > I agree that using your terminology, I'm advocating ROA instead of > SOA. Using Steve's terminology, I prefer REST as an implementation > architecture for (business) SOA as opposed to WS-*. Now if we are all agreed there are different options, can we just move on and start doing the buisness bit please :) > > Stefan > > > Paul > > > > On 11/24/06, Stefan Tilkov <[EMAIL PROTECTED]> wrote: > >> I agree with the notion that business is more important than IT, and > >> many, many IT folks should work to learn a lot more about the actual > >> business value and their part (or lack of) in it. > >> Whether or not REST vs. WS-* or Java vs. Ruby or C++ vs. Smalltalk or > >> Windows vs. Linux vs. OS X is relevant or not depends very much on > >> the topic of the discussion we're having. When we're talking about > >> business strategies for a telecommunications company, Java vs. Ruby > >> doesn't play a big role. That doesn't mean that they're the same — > >> even if they're both "just programming languages". > >> > >> Similarly, I refuse to agree with the assertion that when I look at > >> the technical, architectural properties of a system landscape, it > >> doesn't matter whether its architecture is built around DCOM/MTS, > >> J2EE, WS-* or REST. > >> > >> But that's all beside Steve's original point, which IIRC was "even if > >> it's cool, it doesn't matter because the vendors don't do it". I > >> disagree: Witness the inclusion of (admittedly bad) REST support in > >> Indigo/WCF and Axis2, or the Systinet 2 repository's REST interface, > >> or the fact that Google's Nelson Minar now asserts he'd never choose > >> SOAP and WSDL over REST again … on the Internet, it seems to me that > >> SOAP/WSDL has clearly lost, and this does not bode well for its > >> future in the enterprise. > >> > >> I will continue to help build good WS-based architectures — I'm not > >> as principled as Mark Baker :-) Whenever I can get someone to listen, > >> I will try to convince them of the REST alternative, though, and I > >> expect this to get easier over the course of the next few years. > >> > >> > >> > >> Stefan > >> -- > >> Stefan Tilkov, http://www.innoq.com/blog/st/ > >> > >> > >> > >> > >> > >> > >> > >> On Nov 24, 2006, at 4:55 PM, Anil John wrote: > >> > >>> > >>> <SteveJones> > >>> The problem isn't the technical standards IMO, its the modelling of > >>> the business and what a service should _be_ that is the biggest > >>> challenge to successful SOA adoption and implementation. > >>> </SteveJones> > >>> > >>> +1 > >>> > >>> I would add, if Steve does not already have it as part of his > >>> interpretation of modeling the business, that semantic > >>> understanding and agreement on the information that the business is > >>> working with, as well the cultural/organizational aspects are also > >>> a critical challenges to SOA adoption and implemenation. > >>> > >>> Regards, > >>> > >>> - Anil > >>> > >>> :- > >>> :- Anil John > >>> :- http://www.aniltj.com/blog > >>> :- > >>> > >>> > >>> > >> > >> > >> > >> > > > > > > -- > > Paul Fremantle > > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair > > > > http://bloglines.com/blog/paulfremantle > > [EMAIL PROTECTED] > > > > "Oxygenating the Web Service Platform", www.wso2.com > > > > > > > > > > Yahoo! Groups Links > > > > > > [EMAIL PROTECTED] > > > > > > > > Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
