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/
