By "dynamic website" I mean something that isn't offering up static content / files, it's something that provides an HTTP interface to another program of some sort (J2EE app, Perl script, RDBMS, CICS transaction, etc.)
As for the web/REST vs. RPC - Yes, the architecture of either has a different set of constraints - And yes, the environment is different (the web is bigger and more decentralized) But they are not really different things in the way businesses tend to use them -- they're both used for business document data transfer. Now, certainly there are definite use cases that HTTP doesn't cover well (high throughput / low latency event notification & pub-sub data streams, for example), and likely a proprietary or WS-* approach could be suited for such cases. And, REST v. EAI do both share one problem: lack of shared data definitions & semantics. There's no magic sauce there, that's where the real work still is. But, the difference with the web is: - I can refer to any relevant information resource in the distributed system in a universally recognized human-readable way (URIs). - I know how to dereference any information resource in the distributed system in a universally recognized operation (GET) - I can deploy new resources into the system in a mostly decentralized manner, with only global domain naming as a centralized bottleneck - If I deploy hypermedia & forms as resources, I can also provide the interface for updates (POST) and state transitions (hyperlinks) These benefits occur whether the consumer is a human at a web browser, or a thick client that can understands my form language, or a piece of software using an HTTP library. Similar benefits could occur with doc/literal SOAP/WSDL and WS-Transfer. I think the above capabilities are far beyond just a debate on implementation, they have large architectural and business implications on centralized vs. decentralized control, and thus scalability (which is usually limited by the marginal costs of integrating an extra resource into the system). Cheers Stu ----- Original Message ---- From: Dan Creswell To: [email protected] Sent: Thursday, July 6, 2006 10:43:19 AM Subject: Re: [service-orientated-architecture] RESTful lightbulb Stuart Charlton wrote: >> So in the context of gaining tangible business benefit, REST vs >> SOAP is nowhere and therefore "pointless". You might be able to >> make some claim in respect of category (1) but it's going to be >> difficult to prove and I've seen very little of how REST vs SOAP >> means anything in respect of category (2). > > Contrast the marginal cost of integrating a dynamic website onto the > web vs. the marginal cost of integrating a system with EAI or RPC... > > Can you explain why you think such a comparison is valid? What do you consider a "dynamic website"? Did you really mean "integrating a system" or "integrating a website"? Can't tell and what to make sure I understand. Aren't these two entirely different things with two entirely different sets of constraints and two entirely different environments? Dan. 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/
