On Sun, Mar 30, 2008 at 1:08 PM, Michael Poulin <[EMAIL PROTECTED]> wrote: > Nothing personal, but all developers prefer a more concrete instructions and > coding as possible to complete the work. This is the nature of the job.
-1 (my reply will be perfect to pick apart and attack each little part, ripe as it is with rambling and ideas and thoughts. Be brave, though, and let's talk about the whole rather than the parts :) What's "the job"? It seems that in all discussions we talk about "whatever it takes to get the job done", but we never ever really talk about the "job" itself. Funny thing, that, and it's because all of this talk, whether it's SOA or whatever else we mean by "architecture", comes down to getting the job done, right? But the job *isn't* defined! The job isn't transactions, or objects, or pooling, or dealing with versioning, or handling parallel threads, or cross-domain object retention, or Java vs. .Net, or static vs. typed : all of this is just various tools we use to "get the job done." This whole thing about "all developers prefer a more concrete instructions and coding as possible to complete the work" is just not true, nor is it interesting. You may *think* it's your job to have a match between the business requirement and your code or method, but it isn't; our job is to create sensible infrastructure that match and extend the business. It's not about rigidness, or solid objects, or defined requirements, it's about being smart, always has, always will. You talk a little later of those fabled User Experience Requirements, which is a step in the right direction, but they are also just tools we use. Nothing more. You can enforce the cleverest tools around, and you can still produce muck. Saying that SOAP vs. REST even is a debate is just plain stupid. It isn't. They're tools, and we don't measure how clever we are by the tools we use. Some do, though, and maybe that's the problem. We tend to think that our tool, or our understanding of it, will somehow solve most problems just because it solves some, or simply because we understand that one better than the other. We're all guilty of this. I hate one thing (out of ignorance) and love something else (because that's what I use now), and it certainly makes sense in my world, but outside it - especially when there's more than just me that's dealing with it - it falls apart and turns into bickering about the tools to use. Does it *really* matter what tools we use if no matter the tool we can dig the hole we need? Pickaxe for some, shovel for some, hands for some. The hole *is* the job. > We > are talking about architectural, long-living solutions which can lead to new > architectural models and/or new usability models of old/known things. Which has got nothing to do with your previous statement of developers preferring clear instructions on what to do. Maybe the unimaginative ones do (I know, cheap stab), but there's no rule that says that this is the modus operandi. There's no evidence that strict, typed, rigid, schematized, constrained, limited or otherwise controlled code and / or instructions creates long-living systems (not to mention we haven't defined if this is good or bad; long-lived can be a curse as much as a good thing) any more than flexible, loose, haphazard, prototyped or otherwise thrown out there systems do. It could be *your* preference, of course, but that's a different matter. > Anne has confirmed that RIA is friendly with fine-grained service > interfaces. Just as she's confirmed that RIA can be hostile with them as well. She's not giving you one answer here; she's saying this is contextual, as everything really is. There is no one solid answer. We can really only talk about experience and cleverness in terms of success. The constraint wrappers we put around our systems (be it rules, tools or fools) do in themselves guarantee no success. People say SOAP is better controlled, which is a pipe-dream at best, just like the chaos of REST is equally rubbish. They're two different styles, and if you can't wrap your head around resource orientation, SOAP is the *best* tool. Or, if you can't wrap your head around service endpoints, REST might be the *best* tool. So let's take this from the generic personal individual scope and make it organizational, and it's pretty obvious that we will have problems *regardless* of whether we choose SOAP or REST. And this example of SOAP vs. REST applies to most technology decisions we have ever had, or ever will. The key is to best match the infrastructure against the personalities and culture of that organizations. You cannot choose SOAP and think you've made the best decision because your current vendor is big on SOAP. This is just foolish. The whole reason we got into the SOA business was not because we thought being agile was a good tool, but because it's essential to move and shape the infrastructure *with* the culture. A lot of people don't spell it out like this, but this is essentially what it's all about; the services (simulating people) needs to be loosely coupled (simulating conversations) in order to create better systems (simulating society). > Now, I can move onto RIA itself. RIA is driven by requirements called User > Experience Requirements. Users demand what they saw already and found > convenient. I think what you're referring to here is the common models of human cognition. Even across differing cultures there are common models that's based on our physiology that comes to expression in our various languages and cultures, and we can tap into these as we try to map those models. However, they're very fluid, and can't be pinned down (otherwise there would be millions of designers without a job right now :) All UX tests and IA work more or less confirms one thing; there are commonalities across most domains, some more than others, but innovation and success mostly happens between the cracks and are seldom planned. So, RIA isn't driven by user requirements per se, but are driven by those models which we perceive as requirements (a subtle but important difference). > This does not mean that they would not find convenient something > that they have not seen yet. My point here is that the best result in > RIA+SOA may be reached when User Experience gets influenced from BOTH sides: > since SOA prefers coarse-grained service interfaces, it makes sense to try > to redesign User Interface in the same manner. That is, the UI might be > transferred from the field updates philosophy into task execution and result > updates. Amen to that. > Ajax (as a part of RIA) is the right tool for this because it can > asynchronously perform a tasks in a windows area realizing the User form > "instant" dialog (as I see today, developers picked up what is on the > surface of Ajax - asynchronous update per window widget or field. This is > what leads to a fine-grained service interface). Well, both yes and no. Sometimes it's perfectly fine to have one page represent a cognitive model (or an important step of one). It's all about representation of how we perceive the models of "jobs we want to do" less than creating new models which AJAX fits into. Don't use it if you don't have to, or if it doesn't make sense. Alex -- --------------------------------------------------------------------------- Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps ------------------------------------------ http://shelter.nu/blog/ --------
