On 30/06/06, Anne Thomas Manes <[EMAIL PROTECTED]> wrote: > > > > > > > > > Steve said: > > > > We need to move on from these debates and start worring about A and B, > > rather than believing that the technology in the middle actually > > matters. > > Actually, I'm finding this debate really, REALLY good. It's the best one I've > ever seen comparing SOA and REST.
Eh? Now I'm really confused. Why can't REST be an implementation pattern in an SOA? I'm not saying that it has to be, but I see nothing stopping REST being one of the myriad of ways that an SOA could be implemented. > > Thanks guys! > > Anne > > > > On 6/30/06, Steve Jones <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > > On 29/06/06, Mark Baker <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > On 6/29/06, Steve Jones <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > I do wish GMail would do > indents.... > > > > > > > > > It does! That's what I use. Just select "Plain text" in the frame of > > > the response message. > > > > > > Top tip! > > > > > > > > > > > > > > On 29/06/06, Mark Baker <[EMAIL PROTECTED]> wrote: > > > > > > > [SJ] An interface defines the FUNCTION as well as the data. Data > > exchange is only one small part of a service definition. Some functions > > never exchange any data for instance. I might be very thick, but when I > > define a service interface I think in terms of the capabilities that it > > provides, these don't often get reduced to just resources and data. > > > > > > > > > They do when you're using REST. > > > > > > No they don't.... > > > > > > > > > > That's what I'm trying to explain; when you're using REST to develop a > > > Web based app, you don't define your operations, you just define how > > > those predefined operations map to your system (i.e. identify your > > > resources). > > > > > > Lets assume I'm thick for a minute (not hard I know) but lets reduce > > it to two Java classes, one at point A (consumer) and one at point B > > (service provider) and B has a method called C. > > > > From the perspective of the consumer and the service they don't care > > what happens in between just that it happens. How is REST > > fundamentally different from the perspective of A and B when I don't > > want EITHER of those caring about the execution context that is in > > use? I want developer at A to "discover" the service description of B > > and write B.C and for everything else just to happen. I want B to > > write their service and for something to expose that service to the > > internet/intranet/project/etc > > > > This is why I think its a pointless argument, we are arguing about the > > best execution context. We are the golgafrinchans. > > > > > > > > > > That's why REST development is fundamentally different than RPC > > > approaches like CORBA, DCOM, DCE, and Web services. > > > > > > Or how REST pushes more systems comprehension back onto the consumer. > > NONE of these approaches get away from the basic point that consumer A > > wants to call capability C on Service B. They are all JUST examples > > of execution context implementation, and the execution context adds > > ZERO value to the interaction. > > > > We need to move on from these debates and start worring about A and B, > > rather than believing that the technology in the middle actually > > matters. > > > > Note, I'm not saying that WSDL/SOAP is the best in the world, but that > > it is GOOD ENOUGH, and for something as marginally valuable as the > > execution context that is enough. > > > > Steve > > > > > > > > Mark. > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------ Yahoo! Groups Sponsor --------------------~--> Check out the new improvements in Yahoo! Groups email. http://us.click.yahoo.com/6pRQfA/fOaOAA/yQLSAA/NhFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> 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/
