On 06/07/06, Stuart Charlton <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > --- Steve Jones <[EMAIL PROTECTED]> wrote: > > > > I love the implication that business aligned is a > > bad thing. > > > It's not, normally ;-) And you certainly could > create business-aligned WSDL operations that are > shared within a supply network or an industry, if you > had the will and influence and political savvy. But > broadly speaking, human organizations disagree on > terms, definitions, and the relative "importance" of > one operation over a nother. And disagreement hurts > interoperability.
Which is why techies shouldn't be making those decisions. Businesses make those sorts of decisions all the time, so do decent engineers. > > Here's another take on it... > > If you want to interoperate the classic "RPC" way, you > build your operations, and then describe your > interface, and someone bends their worldview into your > worldview when they invoke you. EAI made this more > economical, and the latest web services tools (WSDL) > make this even more economical, but it's still a > matter of percentage points of productivity WSDL != RPC, but anyway, the point is that yes people need to agree on things. > > In the "SOA" way, your producers and consumers get > together, bang out a shared contract, and govern / > evolve that contract over time. That includes data > formats and shared operations. Costs start to drop > much more significantly, as you reduce the number of > potential transformations. With you so far... > > In the "REST" way, it's like SOA, but more constrained > -- we align the contract on the most general > operations possible -- In HTTP's case, > GET/POST/PUT/DELETE. If "everyone" can just agree on > one small thing, such side effects, or idempotence, > we've generated a universally interoperable operation, > one with tremendous value. Again this is where I disagree, the contract is so general as to be worthless. The SOA case above is (IMO) architecture, the REST case is implementation, that doesn't mean that REST couldn't be an implementation pattern but that REST gives no actual value as the operations achieve no actual goal. Simplicity is important at the service level, surely in 2006 we should consider the execution context to be pure commodity? > > Or, as Roy Fielding put it a few years ago, "The Web > creates more business value, every day, than has been > generated by every single example of an RPC-like > interface in the entire history of computers." Ahhh broad sweeping statements... aren't they great, especially when you don't have to quantify them. > > > > But to the point, there is no business value in PUT, > > its the actual EXECUTION that gives the value. > > > Actually, and this may come across as bizarre, but > most of the value is not in the execution. It's in > how these things are arranged in a system > configuration that provides the greatest value. Comes across as more than bizarre... > > The whole idea of large scale organization, going back > to Adam Smith in economics, Peter Drucker in > management, etc. is that the "system" is what's > productive, not the execution of any individual task. Not disagreeing, but the system is the agregation of all the capabilities and services into a network value chain etc, not the mechanism. > > > This is the argument for a market-based organization > of an economy vs. a planned economy. This was also > the insight of the Ford system, and is also the > insight of the Toyota production system, or "lean" > approaches. While you may be able to derive value out > of the execution of a task at a certain granularity, > the real value to be gleaned from how it is arranged > into an integrated system. Agreed, which means understanding the system. I really doubt that a decent LEAN approach would look at SOAP v REST and think from a system perspective that it matters. If something is "good enough" then leave it alone. > > And the whole REST argument is that there are some > styles of systems organization that have more powerful > & desirable properties for large-scale decentralized > computing than others do. Which I don't disagree with as a statement, but I've seen nothing in REST that is applicable at the business system level, it just seems to assume that the technical implementation actually matters and delivers value in and of itself. > > > > We become obsessed with technology and > > completely lose track of > > the business value and objectives. > > > I completely agree with this. But I also think that > REST v. WSDL is just a symptom of a broader issue, one > that has major business implications, and won't be > solved soon... ;-) Hope not, otherwise I'll be out of a job :) > > > Cheers > Stu > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > > > > ------------------------ Yahoo! Groups Sponsor --------------------~--> Yahoo! Groups gets a make over. See the new email design. http://us.click.yahoo.com/XISQkA/lOaOAA/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/
