I'm with you 100% Steve. That's why I object to comments from the fervently religious REST proponents that claim that WS-* is a complete and utter failure. As Eric has pointed out, quite a few companies are doing very well, thank you, implementing services and integrating systems using WS-*. It may not be the most technically elegant solution available, but it works. It meets business requirements. And from a business perspective, that's all that matters.
But that doesn't mean that it isn't appropriate to examine software architectures and technology options from a technical perspective. Although you can use almost any technology to implement a solution, the option chosen will have a significant impact on the long-term maintenance costs of that solution. The IT organization has a vested interest in improving the elegance (e.g., scalability, evolvability, maintainability) of its technical infrastructure. So this debate is valid. Anne On 6/8/07, Steve Jones <[EMAIL PROTECTED]> wrote:
Nope. The point I'd stress is the one you've made here is that this is about SOFTWARE architectures. The point I've made over and over again is that part of the IT problem is that we are still looking at the software level and we aren't moving upwards towards the business architecture. So one of the reasons I make the comments I do is that I look from a business service perspective and assess whether at that level there is any different between approaches. The basic test is "if I replaced this with flying monkeys, and it worked, would the business care" and for any competent software architecture the answer is "no", the question on software architecture is competence not perfection and too often in IT we become obsessed with IT perfection to the detriment of business competence. On 08/06/07, Mark Baker <[EMAIL PROTECTED]> wrote: > > Hey, I thought I said we wouldn't discuss REST in this thread, Eric! > 8-) > > But I interpret your "Yes" there as agreeing with me, that these are > useful models for evaluating architectures and architectural styles. > Does anybody *dis*agree? > > Mark. > > > On 6/8/07, Eric Newcomer <[EMAIL PROTECTED] <e_newcomer%40yahoo.com>> > wrote: > > > > > > > > Yes but the problem starts when comparing theory to practice - the > discussion tends to compare Web services as they are implemented with REST > as its defined in a thesis. > > > > Lots of implemented HTTP is not RESTful, either. > > > > Eric > > > > > > ----- Original Message ---- > > From: Mark Baker <[EMAIL PROTECTED] <distobj%40acm.org>> > > To: [email protected]<service-orientated-architecture%40yahoogroups.com> > > Sent: Thursday, June 7, 2007 4:07:09 PM > > Subject: [service-orientated-architecture] Software architecture > > > > > > > > > > Perhaps we can all step back for a second... > > > > Let's - for a moment at least 8-) - forget about REST, WS-*, SOA, > > etc.. and just talk about software architecture. Pete laid out a > > summary (below) of how, IMO, it all works: how constraints on the > > relationship between architectural elements induce certain > > architectural properties. > > > > Can we agree that this is a useful way for evaluating architectures & > > architectural styles? Or more exactly, can we agree that papers like > > Perry & Wolf's "Foundations" , or chapter 1 of Roy Fielding's > > dissertation, describe useful evaluation methodologies? > > > > Mark. > > > > On 6/7/07, Peter Lacey <[EMAIL PROTECTED] que.com> wrote: > > > I'll admit to a little trolling, but this is not hyperbole, it is > not a > > > matter of opinion, and it is not a blanket statement based on > religious > > > fervor. The fact is that there is a paper out there -- you know the > one > > > -- that analyzes all prevalent means of distributed computing and > teases > > > out the properties they exhibit and the design factors that brought > > > about those properties. Then, emphasizing "constraint and > understanding > > > of the system context," applies those design factors (constraints) > to a > > > new architectural style such that the end result is a system that > > > provably! exhibits the properties desired. Those properties being > > > separation of concerns, scalability, reliability, visibility, > > > performance, simplicity, and evolvability. > > > > > > > > ________________________________ > Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see > what's on, when. > >
