While I've only been giving passing attention to this thread, Nick made a great point whether you're a WS-* fan, a REST fan, or just want to go back to green screens:Any given piece of software on the WWW is not anywhere nearly as good as dealing with crap and ambiguity as a person, but if all the "small pieces [of software] loosely joined" can each tolerate a little ambiguity, then the entire Web becomes incredibly robust. It doesn't even have to be the WWW. Any integration scenario can result in scenarios with ambiguity, exception conditions, change, etc. This is what makes it so difficult, since our systems are binary at their core. Even worse, the decisions associated with this cases are typically made at development time, thus requiring an unhandled case to go all the way back through the development cycles. To avoid this, it becomes a guessing game of predicting how something might change or might go wrong. We're attacking this probably through two means: 1) Shortening the development cycle. 2) Proper externalization of policies associated with the interaction. when done properly, it can eliminate the development cycle altogether, although the checks and balances associated with making change still need to be in place, whether its a code deployment or a policy change. A ZapFlash that Jason and Ron put out a while ago talked about the role of human tasks in business processes and workflow and how there are some tasks that simply should not be automated. Interpretation of ambiguity is a task that often falls into this category. The key is to allow the process to be as efficient as possible, leveraging both the person and the technology. -tb
SPONSORED LINKS
Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required) Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe __,_._,___ |
- Re: [service-orientated-architecture] Bray Prefers it Web-... Stuart Charlton
- Re: [service-orientated-architecture] Bray Prefers it... Nick Gall
- Re: [service-orientated-architecture] Bray Prefer... Todd Biske
- [service-orientated-architecture] Re: Bray Prefer... algermissen1971
- Re: [service-orientated-architecture] Re: Bra... Eric Newcomer
- Re: [service-orientated-architecture] Re: Bra... Nick Gall
- Re: [service-orientated-architecture] Re:... Mark Baker
- [service-orientated-architecture] Re... Gervas Douglas
- Re: [service-orientated-architec... Mark Baker
- Re: [service-orientated-architecture] Bray Prefer... Steve Jones
- Re: [service-orientated-architecture] Bray Prefers it... Radovan Janecek
