Jan Algermissen wrote: > Dan, > > sorry, I missed this one. Didn't mean to skip it :-) >
No big deal - my email has been all over the place order of delivery wise just recently, mutter. > On 29.01.2007, at 15:03, Dan Creswell wrote: > >> An architecturally meaningful definition in a similar style to REST >> right? >> >> What does that give me? Why do I care? > > Suppose you want a certain amount of scalability for your system. If > you choose an architectural style that includes a stateless-server- > constraint (leading to all application state residing on the clients) > the style guarantees that the system will scale as you add server > after server. Without that constraint there is no architectural > constraint. IOW, architectural constraints (as opposed to design > decisions) **guarantee** a system property. You know that as long as > you stick to the style, the property will be there. Constraints also > allow you to choose between design decisions; if you have option A or > B of doing something, constraints can guide you, to weigh your > decisions (seeing the architectural pros and cons). That's what > principled design is all about. > And I'd buy that but constraints don't just bring benefits, they bring costs too and whilst there's no doubt statelessness is a way to get scaling it can be painful to implement. Ultimately, I agree with principled design and the use of constraints to reason about systems but I pick and mix across styles when I build things being mindful of my constraints. i.e. if I end up using a single style it might well be due to the kind of system I'm constructing rather than my rigid application of a single style. >> When I design a system, I like available a broad range of design >> patterns, frameworks etc available. I don't like constraints >> because I >> will have plenty of those already. > > Can you name a few of these constraints? Maybe we are talking past > each other. > Could be - when I describe constraints I'm referring to non-functionals, or the need to use certain pieces of software cos the enterprise has negotiated cheap licenses for it and all the other nastiness one sees in the enterprise. >> REST? SOA? Classify a system as you wish because all I care about >> is: >> >> (1) Working/not-working >> >> (2) Copes with my load/doesn't cope with my load >> >> (3) Maintainable/not-maintainable >> >> (4) Simple/complex > > as Mark said, there are more properties to consider, especially in > networked, decentralized, systems where you are not the only designer > and changes happens anytime, everywhere, without central authority. > Sure - but note that many enterprises are full of centralized authorities so there would at least appear to be some mismatch between what you describe and how enterprises are? Thanks for getting back to me, Dan. > > Jan > >> Don't get me wrong, I like to have my terms mean something specific, >> it's good for communication but beyond that, I'm not sure what other >> value it has? >> >> Enlighten me, >> >> Dan. >> >> >>> <throwing-the-gauntlet-mode> >>> My take is that SOA does not have to say anything about 1 or 2 >>> that is testable. >>> </throwing-the-gauntlet-mode> >>> >>> >>> Cheers, >>> Jan >>> >>> >>> >>> >>> >>>> Mark. >>>> >>>> >>>> >>>> Yahoo! Groups Links >>>> >>>> >>>> [EMAIL PROTECTED] >>>> >>> >>> >>> >>> Yahoo! Groups Links >>> >>> >>> >>> >> >> >> >> Yahoo! Groups Links >> >> >> [EMAIL PROTECTED] >> > > > > > Yahoo! Groups Links > > > >
