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.
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. 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. [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 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've seen approaches come close to this (RMI was close) but never across platforms, languages, etc., except in the case of the web. [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. 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. Cheers Stu ------------------------ Yahoo! Groups Sponsor --------------------~--> Great things are happening at Yahoo! Groups. See the new email design. http://us.click.yahoo.com/TISQkA/hOaOAA/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/
