On 30/06/06, Stuart Charlton <[EMAIL PROTECTED]> wrote: > > > > > > > > See inline > > > ----- Original Message ---- > > [SJ] 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. > > > [SC] If you're purely focused on the delivery-model aspects of > services-oriented development, in terms of reducing lead times and > deliverable sizes, then perhaps the architectual style is pointless. This > becomes really about balance of power and governance issues, then.
SOAP/WSDL v REST is not (in my little universe) an architectural question, its an implementation question. There is a big difference between the two. I'm definately focused on the delivery model... but I've found that I can reduce the development time more when considering it architecturally than I can when considering it technologically. > > I think the second side of the SOA coin is the network effects from autonomy > and loose coupling -- which potentiall reduce the marginal costs of > integration to zero. Sorry for this, but I call snake oil. REST does not improve loose coupling, I still need to know the document formats and the URIs. The other part is that using a decent IDE then the SOAP/WSDL bit is hardly tricky either, this is the point I'm trying to make, we are shaving off minor elements at the part in the problem where there is the least issue. I don't really care if we all go for REST rather than WSDL (though I can't see it), I just don't see the value in having both. > > Your example strikes me as classic RPC-based development, and focused on the > individual developer rather than on the network application itself. It > really doesn't illustrate any incremental benefit compared to what we've been > doing for 10 years now in CORBA or EAI. Spot on from one perspective, architecturally (and I mean architecture here, not implementation) the whole point is that A wants to interact with B. REST doesn't change that. > > [SJ] 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. > > > [SC] REST has a very different way of describing capability "C" than CORBA, > DCOM, or DCE... > > C is split into > - what operations I have > - what data types are required > - how do I refer to C on service B > - how do I describe the required data types C is a capability, it doesn't have operations, it is the operation. But apart from that you've not described anything different to SOA. > > The point is that these descriptions of capability C should be shareable > across any service producer and consumer -- even those that never new that > service B existed, or else every integrated endpoint costs labour $$$. I love getting confused late on a Friday, but how can anyway use a capability when they don't know about the service? The whole point of a service is that it provides access to a capability. You also seem to be suggesting that REST is magic pixie dust that requires no effort. Lets be clear, I'm not arguing that REST is rubbish, just that its pointless having these two competing ideas at the most unimportant part of the problem. > > I've seen approaches come close to this (RMI was close) but never across > platforms, languages, etc., except in the case of the web. So when I used to do CORBA tunnelled over HTTP between multiple programming languages I never actually did that? Bit confused again. > > [SJ] 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. > > > [SC] I think the focus definitely should be on contracts and shared data > semantics, sure. But the rubber does have to meet the road somewhere. IT > and computing isn't JUST about people, politics, economics & semantics, it's > also computer science -- and most people are poor at both. And here I'd disagree. Computing is littered with examples where we've excelled at the computer science and buggered up on the people. And its also littered with fantastic examples where (too be blunt) we got our heads out of our arses and just coped with what we had. 802.11x is a classic example, as is GSM, as is OSS/J, PC/BIOS and Java are others. Computer Science is something that people should understand (and its sad how few people do), but the difficult bit is the people, politics, economics and semantics. And in the history of IT there haven't been many areas that have been better attacked and understood than shifting bytes from A to B. We love re-inventing the wheel in IT and pretending its actually new. > > If your goal is to reduce the marginal cost of integration to "near zero", > there are some architectural styles (and their technologies) that have > constraints that will lead to more success when building such contracts than > if you use a style with fewer constraints. That's why these arguments are > not pointless. Again I have to say snake oil. REST does nothing to manage the challenges of integration around versioning, dependency management, communication, enforcement, audit (not that SOAP/WSDL does much better mind). Its one of the things in IT that people continue to make the mistake of... believing that reducing implementation costs reduces TCO. REST is nice, REST can work. I just don't see an actual point to it over using WSDL. I might be missing the great epiphany, but architecturally I've worked the same in Java with RMI, Java/.NET with Web Services as I did in C using Pipes to communicate and I could definitely argue that C Pipes were exactly the same approach as REST, which doesn't make REST wrong, but it does mean that it probably isn't new. In that application we used pipes to communicate between C and Ada (two different languages). Steve > > Cheers > Stu > > > > ------------------------ Yahoo! Groups Sponsor --------------------~--> See what's inside the new Yahoo! Groups email. http://us.click.yahoo.com/2pRQfA/bOaOAA/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/
