Loading ...
Sorry, an error occurred while loading the content.
 

Re: [service-orientated-architecture] Re: Meehan on RIA meets SOA

Expand Messages
  • Michael Poulin
    I do not think many people would digg into this. So, I let myself to respond Alex inside his text. - Michael ... From: Alexander Johannesen
    Message 1 of 26 , Mar 31, 2008
      I do not think many people would digg into this. So, I let myself to respond Alex inside his text.
      - Michael

      ----- Original Message ----
      From: Alexander Johannesen <alexander.johannesen@...>
      To: service-orientated-architecture@yahoogroups.com
      Sent: Monday, March 31, 2008 12:11:07 PM
      Subject: Re: [service-orientated-architecture] Re: Meehan on RIA meets SOA

      On Sun, Mar 30, 2008 at 1:08 PM, Michael Poulin <m3poulin@yahoo. com> 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.

      MP: I am glad, I’ve met a person who respects a job of being smart. Many years ago I had the same opinion but have never met (for two decades) a PM or employer who would pay a penny for being smart. BTW, I think that @being smart@ is a gift, not a job. Why? Because the meaning of “smart” is exclusively cultural and individual; it is almost impossible to discuss this. For one, it is smart to outsource corporate pension application to support in the foreign country with no background checks, get promoted and forget about the ruins left behind. For another one, it is to see into the future and build for this vision.  Plus, the talks about SOA are not about “getting job done” but getting the revenue for the company in the least painful way. This is the job, but many still think the job is code writing.


      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.

      MP: This is scary, brrrrr. Well, the more we know, the less we know, isn’t it?

      In mathematics, there are two methods - induction (from facts to conclusion) and deduction (from conclusion to facts to be). Both of them are tested by practice. If I offer a solution based on induction I must know its area of applicability, to my world and/or to your world too.


      > 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.

      MP: The sense of my statement is very simple, long-living solutions are rarely observed by developers; in some cases because they are forced to think inside delivery time-line, in concrete things that matter today.

      About long-living and flexibility. I am sorry but have to point to biology and cybernetics -  the more flexible, i.e. more adaptable, a system is, the more chances it has to survive an environment change. Here is nothing about my or your preferences. It happens without us, in us, and outside of us. I would consider an attempt of proving this in CS as a waste of time.


      > 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.

      MP: Didn’t you notice that my “friendly” and Anne’s contextual are from the same category?


      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).

      MP: Agree with the last statement. But I did not get the point about @culture@. Did MVC pattern was adapted because of a culture in the organization or because of a pain the organization had w/o it? I really do not care if it is SOAP or REST, I was told that RIA and SOA are orthogonal which I wanted to discuss here.

      > 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).

      MP: Sorry, I did not get your logic. User Experience requirements is one of the major reasons why so many UI designers do have the job. Is it “very fluid”? Of cause. And it can be “pinned down” in each particular case – this is why there are so many UI designers ( as many as personalities ). Talking about models, aren’t they driven by User Experience in significant part of them?


      > 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.


      MP:What a disappointment!  The whole thing was for the sake of this paragraph and I do not have a discussion here…


      > 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.

      MP: Define “have to”. What perspective to use for this have/ not_have?


      Alex
      --
      ------------ --------- --------- --------- --------- --------- -
      Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps
      ------------ --------- --------- --------- --- http://shelter. nu/blog/ --------




      No Cost - Get a month of Blockbuster Total Access now. Sweet deal for Yahoo! users and friends.
    • Steve Jones
      I m looking at my bookshelf and wondering what the difference between RIA and X/Xt/Motif is :) What I mean by this is that the principles in a good interface
      Message 2 of 26 , Apr 1, 2008
        I'm looking at my bookshelf and wondering what the difference between
        RIA and X/Xt/Motif is :)

        What I mean by this is that the principles in a good interface (my
        last year at Uni was on interfaces and the first 5 years of my career)
        haven't changed greatly in the last 20 years, the WILI v KISS problem
        still remains but architecturally the problem is similar. Instead of
        using X we are now using HTTP (why isn't X REST would be a question!)
        but the basic rules remain

        1) Rendering is separate from communication - i.e. two threads at
        least and keep the interface drawn while you make requests
        2) Cache - don't always round trip to the server if you can avoid it
        3) HMVC - Hierarchical MVC works, but have different view models (but
        linked automatically) to information models.
        4) anticipate - have the information available before the user asks
        whenever possible.
        5) minimise the network traffic

        There are a whole bunch more but the RIA piece feels, at the moment,
        like coding in Windows 3.1 over Motif, the widget sets don't have the
        sophistication and the model isn't very clean.

        So on the Ajax front its good that it does async but a "better"
        solution will be when technologies like Google Gears is more commonly
        available as this will enable two sets of async, one to retrieve
        information into the cache and one to get information from the cache.

        Coding like its 1994.... :)

        Steve


        On 30/03/2008, Michael Poulin <m3poulin@...> wrote:
        >
        >
        >
        >
        >
        >
        >
        >
        > +1
        >
        > 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. We are talking about architectural, long-living solutions which can lead to new architectural models and/or new usability models of old/known things.
        >
        > Anne has confirmed that RIA is friendly with fine-grained service interfaces.
        >
        > 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. 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.
        >
        > 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).
        >
        > - Michael
        >
        >
        > ----- Original Message ----
        > From: Steve Jones <jones.steveg@...>
        > To: service-orientated-architecture@yahoogroups.com
        > Sent: Friday, March 28, 2008 10:55:56 PM
        > Subject: Re: [service-orientated-architecture] Re: Meehan on RIA meets SOA
        >
        >
        >
        >
        > Or to put it another way
        >
        > Java and .NET developers like clearly defined elements as they know that this reduces support costs. PHP and Ruby developers are concentrating just on the development part so don't consider the long term....
        >
        > :)
        >
        > Fast should be about the lifetime, not about the first go live.
        >
        > Steve
        >
        >
        >
        > On 28/03/2008, Scott C. Sanchez <scottsanchez@ gmail.com> wrote:
        > >
        > >
        > >
        > >
        > >
        > >
        > > I've noticed that when I talk to developers, Java and .NET developers prefer to consume SOAP (wsdl-based) services that they can easily import into their IDE, where as PHP and Ruby developers prefer to consume REST-based services since they are simple and fast, much like their choice of language.
        > >
        > > -Scott
        > >
        > >
        > >
        > >
        > >
        > >
        > > On Fri, Mar 28, 2008 at 10:23 AM, Anne Thomas Manes <atmanes@gmail. com> wrote:
        > >
        > > >
        > > >
        > > >
        > > >
        > > >
        > > >
        > > > On Wed, Mar 26, 2008 at 3:44 PM, Michael Poulin <m3poulin@yahoo. com> wrote:
        > > > >
        > > > > One of lead architects around me said that SOA and RIA are almost orthogonal
        > > > > because RIA demands fine-grained operations while SOA tends to
        > > > > coarse-grained ones...
        > > > >
        > > > > - Michael
        > > >
        > > > Hence my assertion that RIA and mashups will become more intimately
        > > > connected with SOA if/when
        > > > REST becomes a predominant approach for building services.
        > > >
        > > > REST exposes capabilities through a resource interface. (see my recent
        > > > post, REST is about Resources
        > > > [http://apsblog. burtongroup. com/2008/ 03/rest-is- about-r.html]). The
        > > > resource interface is fine-grained. Any "thing" that you want to
        > > > interact with has a URL. RESTful services are significantly easier to
        > > > interact with than SOAP APIs, particularly from the RIA and mashup
        > > > tooling perspective.
        > > >
        > > > (Note that the RESTful service can still be coarse-grained -- but the
        > > > interface [the resources it exposes] is fine-grained. )
        > > >
        > > > Anne
        > > >
        > > > >
        > > > >
        > > > > ----- Original Message ----
        > > > > From: Rob Eamon <reamon@cableone. net>
        > > > > To: service-orientated- architecture@ yahoogroups. com
        > > > > Sent: Tuesday, March 25, 2008 2:37:30 PM
        > > > > Subject: [service-orientated -architecture] Re: Meehan on RIA meets SOA
        > > > >
        > > > >
        > > > >
        > > > >
        > > > > Why is that? Why would an RIA be "more connected" to services based on
        > > > > the interaction style? Why would accessing services via REST vs. any
        > > > > other mechanism be considered more connected? A service consumer is a
        > > > > service consumer, regardless of the service interface, no?
        > > > >
        > > > > Or are you referring to the relative prevalence of an RIA's use of
        > > > > services compared to other approaches?
        > > > >
        > > > > -Rob
        > > > >
        > > > > --- In service-orientated- architecture@ yahoogroups. com, "Anne Thomas
        > > > > Manes" <atmanes@... > wrote:
        > > > > >
        > > > > > RIA and mashups will become more intimately connected with SOA
        > > > > > if/when REST becomes a predominant approach for building services.
        > > > > >
        > > > > > Anne
        > > > >
        > > > >
        > > > >
        > > > > ____________ _________ _________ __
        > > > > Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it
        > > > > now.
        > > >
        > >
        > >
        > >
        > > --
        > >
        > > ------------ --------- --------- --------- --------- --------- --------- -------
        > > This message contains confidential information and is intended only for the intended recipient(s) . If you are not the named recipient you should not read, distribute or copy this e-mail. Please notify the sender immediately via e-mail if you have received this e-mail by mistake; then, delete this e-mail from your system.
        > >
        > >
        >
        >
        >
        > ________________________________
        Like movies? Here's a limited-time offer: Blockbuster Total Access for
        one month at no cost.
        >
        >
      • Michael Poulin
        The initial question was: are RIA and SOA orthogonal or compatible considering that SOA is coarse-grained while RIA is fine-grained ? (I do not support neither
        Message 3 of 26 , Apr 1, 2008
          The initial question was: are RIA and SOA orthogonal or compatible considering that SOA is coarse-grained while RIA is fine-grained ? (I do not support neither of these granularity statements as absolute truth). My point was that previous versions of HTTP enforced a sort of fine-granular communication while Ajax can provide both models. Based on this, why wouldn't we review familiar Web/HTTP dialog making it more function-oriented, i.e. coarse-grained?

          - Michael

          ----- Original Message ----
          From: Steve Jones <jones.steveg@...>
          To: service-orientated-architecture@yahoogroups.com
          Sent: Tuesday, April 1, 2008 9:29:40 AM
          Subject: Re: [service-orientated-architecture] Re: Meehan on RIA meets SOA

          I'm looking at my bookshelf and wondering what the difference between
          RIA and X/Xt/Motif is :)

          What I mean by this is that the principles in a good interface (my
          last year at Uni was on interfaces and the first 5 years of my career)
          haven't changed greatly in the last 20 years, the WILI v KISS problem
          still remains but architecturally the problem is similar. Instead of
          using X we are now using HTTP (why isn't X REST would be a question!)
          but the basic rules remain

          1) Rendering is separate from communication - i.e. two threads at
          least and keep the interface drawn while you make requests
          2) Cache - don't always round trip to the server if you can avoid it
          3) HMVC - Hierarchical MVC works, but have different view models (but
          linked automatically) to information models.
          4) anticipate - have the information available before the user asks
          whenever possible.
          5) minimise the network traffic

          There are a whole bunch more but the RIA piece feels, at the moment,
          like coding in Windows 3.1 over Motif, the widget sets don't have the
          sophistication and the model isn't very clean.

          So on the Ajax front its good that it does async but a "better"
          solution will be when technologies like Google Gears is more commonly
          available as this will enable two sets of async, one to retrieve
          information into the cache and one to get information from the cache.

          Coding like its 1994.... :)

          Steve

          On 30/03/2008, Michael Poulin <m3poulin@yahoo. com> wrote:
          >
          >
          >
          >
          >
          >
          >
          >
          > +1
          >
          > 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. We are talking about architectural, long-living solutions which can lead to new architectural models and/or new usability models of old/known things.
          >
          > Anne has confirmed that RIA is friendly with fine-grained service interfaces.
          >
          > 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. 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.
          >
          > 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).
          >
          > - Michael
          >
          >
          > ----- Original Message ----
          > From: Steve Jones <jones.steveg@ gmail.com>
          > To: service-orientated- architecture@ yahoogroups. com
          > Sent: Friday, March 28, 2008 10:55:56 PM
          > Subject: Re: [service-orientated -architecture] Re: Meehan on RIA meets SOA
          >
          >
          >
          >
          > Or to put it another way
          >
          > Java and .NET developers like clearly defined elements as they know that this reduces support costs. PHP and Ruby developers are concentrating just on the development part so don't consider the long term....
          >
          > :)
          >
          > Fast should be about the lifetime, not about the first go live.
          >
          > Steve
          >
          >
          >
          > On 28/03/2008, Scott C. Sanchez <scottsanchez@ gmail.com> wrote:
          > >
          > >
          > >
          > >
          > >
          > >
          > > I've noticed that when I talk to developers, Java and .NET developers prefer to consume SOAP (wsdl-based) services that they can easily import into their IDE, where as PHP and Ruby developers prefer to consume REST-based services since they are simple and fast, much like their choice of language.
          > >
          > > -Scott
          > >
          > >
          > >
          > >
          > >
          > >
          > > On Fri, Mar 28, 2008 at 10:23 AM, Anne Thomas Manes <atmanes@gmail. com> wrote:
          > >
          > > >
          > > >
          > > >
          > > >
          > > >
          > > >
          > > > On Wed, Mar 26, 2008 at 3:44 PM, Michael Poulin <m3poulin@yahoo. com> wrote:
          > > > >
          > > > > One of lead architects around me said that SOA and RIA are almost orthogonal
          > > > > because RIA demands fine-grained operations while SOA tends to
          > > > > coarse-grained ones...
          > > > >
          > > > > - Michael
          > > >
          > > > Hence my assertion that RIA and mashups will become more intimately
          > > > connected with SOA if/when
          > > > REST becomes a predominant approach for building services.
          > > >
          > > > REST exposes capabilities through a resource interface. (see my recent
          > > > post, REST is about Resources
          > > > [http://apsblog. burtongroup. com/2008/ 03/rest-is- about-r.html] ). The
          > > > resource interface is fine-grained. Any "thing" that you want to
          > > > interact with has a URL. RESTful services are significantly easier to
          > > > interact with than SOAP APIs, particularly from the RIA and mashup
          > > > tooling perspective.
          > > >
          > > > (Note that the RESTful service can still be coarse-grained -- but the
          > > > interface [the resources it exposes] is fine-grained. )
          > > >
          > > > Anne
          > > >
          > > > >
          > > > >
          > > > > ----- Original Message ----
          > > > > From: Rob Eamon <reamon@cableone. net>
          > > > > To: service-orientated- architecture@ yahoogroups. com
          > > > > Sent: Tuesday, March 25, 2008 2:37:30 PM
          > > > > Subject: [service-orientated -architecture] Re: Meehan on RIA meets SOA
          > > > >
          > > > >
          > > > >
          > > > >
          > > > > Why is that? Why would an RIA be "more connected" to services based on
          > > > > the interaction style? Why would accessing services via REST vs. any
          > > > > other mechanism be considered more connected? A service consumer is a
          > > > > service consumer, regardless of the service interface, no?
          > > > >
          > > > > Or are you referring to the relative prevalence of an RIA's use of
          > > > > services compared to other approaches?
          > > > >
          > > > > -Rob
          > > > >
          > > > > --- In service-orientated- architecture@ yahoogroups. com, "Anne Thomas
          > > > > Manes" <atmanes@... > wrote:
          > > > > >
          > > > > > RIA and mashups will become more intimately connected with SOA
          > > > > > if/when REST becomes a predominant approach for building services.
          > > > > >
          > > > > > Anne
          > > > >
          > > > >
          > > > >
          > > > > ____________ _________ _________ __
          > > > > Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it
          > > > > now.
          > > >
          > >
          > >
          > >
          > > --
          > >
          > > ------------ --------- --------- --------- --------- --------- --------- -------
          > > This message contains confidential information and is intended only for the intended recipient(s) . If you are not the named recipient you should not read, distribute or copy this e-mail. Please notify the sender immediately via e-mail if you have received this e-mail by mistake; then, delete this e-mail from your system.
          > >
          > >
          >
          >
          >
          > ____________ _________ _________ __
          Like movies? Here's a limited-time offer: Blockbuster Total Access for
          one month at no cost.
          >
          >




          OMG, Sweet deal for Yahoo! users/friends: Get A Month of Blockbuster Total Access, No Cost. W00t
        • Gervas Douglas
          This is an interesting example of topic drift that often occurs in this Group. My original question was, Just how relevant do you think RIA is to SOA and
          Message 4 of 26 , Apr 1, 2008
            This is an interesting example of topic drift that often occurs in
            this Group. My original question was, "Just how relevant do you think
            RIA is to SOA and vice versa?"

            Gervas

            --- In service-orientated-architecture@yahoogroups.com, Michael Poulin
            <m3poulin@...> wrote:
            >
            > The initial question was: are RIA and SOA orthogonal or compatible
            considering that SOA is coarse-grained while RIA is fine-grained ? (I
            do not support neither of these granularity statements as absolute
            truth). My point was that previous versions of HTTP enforced a sort of
            fine-granular communication while Ajax can provide both models. Based
            on this, why wouldn't we review familiar Web/HTTP dialog making it
            more function-oriented, i.e. coarse-grained?
            >
            > - Michael
            >
            > ----- Original Message ----
            > From: Steve Jones <jones.steveg@...>
            > To: service-orientated-architecture@yahoogroups.com
            > Sent: Tuesday, April 1, 2008 9:29:40 AM
            > Subject: Re: [service-orientated-architecture] Re: Meehan on RIA
            meets SOA
            >
            > I'm looking at my bookshelf and
            wondering what the difference between
            > RIA and X/Xt/Motif is :)
            >
            > What I mean by this is that the principles in a good interface (my
            > last year at Uni was on interfaces and the first 5 years of my career)
            > haven't changed greatly in the last 20 years, the WILI v KISS problem
            > still remains but architecturally the problem is similar. Instead of
            > using X we are now using HTTP (why isn't X REST would be a question!)
            > but the basic rules remain
            >
            > 1) Rendering is separate from communication - i.e. two threads at
            > least and keep the interface drawn while you make requests
            > 2) Cache - don't always round trip to the server if you can avoid it
            > 3) HMVC - Hierarchical MVC works, but have different view models (but
            > linked automatically) to information models.
            > 4) anticipate - have the information available before the user asks
            > whenever possible.
            > 5) minimise the network traffic
            >
            > There are a whole bunch more but the RIA piece feels, at the moment,
            > like coding in Windows 3.1 over Motif, the widget sets don't have the
            > sophistication and the model isn't very clean.
            >
            > So on the Ajax front its good that it does async but a "better"
            > solution will be when technologies like Google Gears is more commonly
            > available as this will enable two sets of async, one to retrieve
            > information into the cache and one to get information from the cache.
            >
            > Coding like its 1994.... :)
            >
            > Steve
            >
            > On 30/03/2008, Michael Poulin <m3poulin@yahoo. com> wrote:
            > >
            > >
            > >
            > >
            > >
            > >
            > >
            > >
            > > +1
            > >
            > > 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. We are talking about architectural, long-living
            solutions which can lead to new architectural models and/or new
            usability models of old/known things.
            > >
            > > Anne has confirmed that RIA is friendly with fine-grained service
            interfaces.
            > >
            > > 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. 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.
            > >
            > > 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).
            > >
            > > - Michael
            > >
            > >
            > > ----- Original Message ----
            > > From: Steve Jones <jones.steveg@ gmail.com>
            > > To: service-orientated- architecture@ yahoogroups. com
            > > Sent: Friday, March 28, 2008 10:55:56 PM
            > > Subject: Re: [service-orientated -architecture] Re: Meehan on RIA
            meets SOA
            > >
            > >
            > >
            > >
            > > Or to put it another way
            > >
            > > Java and .NET developers like clearly defined elements as they
            know that this reduces support costs. PHP and Ruby developers are
            concentrating just on the development part so don't consider the long
            term....
            > >
            > > :)
            > >
            > > Fast should be about the lifetime, not about the first go live.
            > >
            > > Steve
            > >
            > >
            > >
            > > On 28/03/2008, Scott C. Sanchez <scottsanchez@ gmail.com> wrote:
            > > >
            > > >
            > > >
            > > >
            > > >
            > > >
            > > > I've noticed that when I talk to developers, Java and .NET
            developers prefer to consume SOAP (wsdl-based) services that they can
            easily import into their IDE, where as PHP and Ruby developers prefer
            to consume REST-based services since they are simple and fast, much
            like their choice of language.
            > > >
            > > > -Scott
            > > >
            > > >
            > > >
            > > >
            > > >
            > > >
            > > > On Fri, Mar 28, 2008 at 10:23 AM, Anne Thomas Manes
            <atmanes@gmail. com> wrote:
            > > >
            > > > >
            > > > >
            > > > >
            > > > >
            > > > >
            > > > >
            > > > > On Wed, Mar 26, 2008 at 3:44 PM, Michael Poulin
            <m3poulin@yahoo. com> wrote:
            > > > > >
            > > > > > One of lead architects around me said that SOA and RIA are
            almost orthogonal
            > > > > > because RIA demands fine-grained operations while SOA tends to
            > > > > > coarse-grained ones...
            > > > > >
            > > > > > - Michael
            > > > >
            > > > > Hence my assertion that RIA and mashups will become more
            intimately
            > > > > connected with SOA if/when
            > > > > REST becomes a predominant approach for building services.
            > > > >
            > > > > REST exposes capabilities through a resource interface. (see
            my recent
            > > > > post, REST is about Resources
            > > > > [http://apsblog. burtongroup. com/2008/ 03/rest-is-
            about-r.html] ). The
            > > > > resource interface is fine-grained. Any "thing" that you
            want to
            > > > > interact with has a URL. RESTful services are significantly
            easier to
            > > > > interact with than SOAP APIs, particularly from the RIA and
            mashup
            > > > > tooling perspective.
            > > > >
            > > > > (Note that the RESTful service can still be coarse-grained
            -- but the
            > > > > interface [the resources it exposes] is fine-grained. )
            > > > >
            > > > > Anne
            > > > >
            > > > > >
            > > > > >
            > > > > > ----- Original Message ----
            > > > > > From: Rob Eamon <reamon@cableone. net>
            > > > > > To: service-orientated- architecture@ yahoogroups. com
            > > > > > Sent: Tuesday, March 25, 2008 2:37:30 PM
            > > > > > Subject: [service-orientated -architecture] Re: Meehan on
            RIA meets SOA
            > > > > >
            > > > > >
            > > > > >
            > > > > >
            > > > > > Why is that? Why would an RIA be "more connected" to
            services based on
            > > > > > the interaction style? Why would accessing services via
            REST vs. any
            > > > > > other mechanism be considered more connected? A service
            consumer is a
            > > > > > service consumer, regardless of the service interface, no?
            > > > > >
            > > > > > Or are you referring to the relative prevalence of an
            RIA's use of
            > > > > > services compared to other approaches?
            > > > > >
            > > > > > -Rob
            > > > > >
            > > > > > --- In service-orientated- architecture@ yahoogroups.
            com, "Anne Thomas
            > > > > > Manes" <atmanes@ > wrote:
            > > > > > >
            > > > > > > RIA and mashups will become more intimately connected
            with SOA
            > > > > > > if/when REST becomes a predominant approach for
            building services.
            > > > > > >
            > > > > > > Anne
            > > > > >
            > > > > >
            > > > > >
            > > > > > ____________ _________ _________ __
            > > > > > Be a better friend, newshound, and know-it-all with Yahoo!
            Mobile. Try it
            > > > > > now.
            > > > >
            > > >
            > > >
            > > >
            > > > --
            > > >
            > > > ------------ --------- --------- --------- --------- ---------
            --------- -------
            > > > This message contains confidential information and is intended
            only for the intended recipient(s) . If you are not the named
            recipient you should not read, distribute or copy this e-mail. Please
            notify the sender immediately via e-mail if you have received this
            e-mail by mistake; then, delete this e-mail from your system.
            > > >
            > > >
            > >
            > >
            > >
            > > ____________ _________ _________ __
            > Like movies? Here's a limited-time offer: Blockbuster Total Access for
            > one month at no cost.
            > >
            > >
            >
            >
            > <!-- #ygrp-mkp{ border:1px solid
            #d8d8d8;font-family:Arial;margin:14px 0px;padding:0px 14px;} #ygrp-mkp
            hr{ border:1px solid #d8d8d8;} #ygrp-mkp #hd{
            color:#628c2a;font-size:85%;font-weight:bold;line-height:122%;margin:10px
            0px;} #ygrp-mkp #ads{ margin-bottom:10px;} #ygrp-mkp .ad{ padding:0
            0;} #ygrp-mkp .ad a{ color:#0000ff;text-decoration:none;} --> <!--
            #ygrp-sponsor #ygrp-lc{ font-family:Arial;} #ygrp-sponsor #ygrp-lc
            #hd{ margin:10px 0px;font-weight:bold;font-size:78%;line-height:122%;}
            #ygrp-sponsor #ygrp-lc .ad{ margin-bottom:10px;padding:0 0;} -->
            <!-- #ygrp-mlmsg {font-size:13px;font-family:arial, helvetica,
            clean, sans-serif;} #ygrp-mlmsg table {font-size:inherit;font:100%;}
            #ygrp-mlmsg select, input, textarea {font:99% arial, helvetica, clean,
            sans-serif;} #ygrp-mlmsg pre, code {font:115% monospace;} #ygrp-mlmsg
            * {line-height:1.22em;} #ygrp-text{ font-family:Georgia; } #ygrp-text
            p{ margin:0 0 1em 0;}
            > #ygrp-tpmsgs{ font-family:Arial; clear:both;} #ygrp-vitnav{
            padding-top:10px;font-family:Verdana;font-size:77%;margin:0;}
            #ygrp-vitnav a{ padding:0 1px;} #ygrp-actbar{ clear:both;margin:25px
            0;white-space:nowrap;color:#666;text-align:right;} #ygrp-actbar .left{
            float:left;white-space:nowrap;} .bld{font-weight:bold;} #ygrp-grft{
            font-family:Verdana;font-size:77%;padding:15px 0;} #ygrp-ft{
            font-family:verdana;font-size:77%;border-top:1px solid #666;
            padding:5px 0; } #ygrp-mlmsg #logo{ padding-bottom:10px;} #ygrp-reco
            { margin-bottom:20px;padding:0px;} #ygrp-reco #reco-head {
            font-weight:bold;color:#ff7900;} #reco-grpname{
            font-weight:bold;margin-top:10px;} #reco-category{ font-size:77%;}
            #reco-desc{ font-size:77%;} #ygrp-vital{
            background-color:#e0ecee;margin-bottom:20px;padding:2px 0 8px 8px;}
            #ygrp-vital #vithd{
            font-size:77%;font-family:Verdana;font-weight:bold;color:#333;text-transform:uppercase;}
            #ygrp-vital ul{ padding:0;margin:2px 0;}
            > #ygrp-vital ul li{ list-style-type:none;clear:both;border:1px solid
            #e0ecee; } #ygrp-vital ul li .ct{
            font-weight:bold;color:#ff7900;float:right;width:2em;text-align:right;padding-right:.5em;}
            #ygrp-vital ul li .cat{ font-weight:bold;} #ygrp-vital a{
            text-decoration:none;} #ygrp-vital a:hover{
            text-decoration:underline;} #ygrp-sponsor #hd{
            color:#999;font-size:77%;} #ygrp-sponsor #ov{ padding:6px
            13px;background-color:#e0ecee;margin-bottom:20px;} #ygrp-sponsor #ov
            ul{ padding:0 0 0 8px;margin:0;} #ygrp-sponsor #ov li{
            list-style-type:square;padding:6px 0;font-size:77%;} #ygrp-sponsor #ov
            li a{ text-decoration:none;font-size:130%;} #ygrp-sponsor #nc{
            background-color:#eee;margin-bottom:20px;padding:0 8px;} #ygrp-sponsor
            .ad{ padding:8px 0;} #ygrp-sponsor .ad #hd1{
            font-family:Arial;font-weight:bold;color:#628c2a;font-size:100%;line-height:122%;}
            #ygrp-sponsor .ad a{ text-decoration:none;} #ygrp-sponsor .ad a:hover{
            text-decoration:underline;}
            > #ygrp-sponsor .ad p{ margin:0;} o{font-size:0;} .MsoNormal{
            margin:0 0 0 0;} #ygrp-text tt{ font-size:120%;} blockquote{margin:0 0
            0 4px;} .replbq{margin:4;} -->
            >
            >
            >
            >
            >
            >
            ____________________________________________________________________________________
            > OMG, Sweet deal for Yahoo! users/friends:Get A Month of Blockbuster
            Total Access, No Cost. W00t
            > http://tc.deals.yahoo.com/tc/blockbuster/text2.com
            >
          • Rob Eamon
            I ll revise my initial response a bit. RIA is no more or less relevant to services than any other presentation layer effort. The services don t care that the
            Message 5 of 26 , Apr 1, 2008
              I'll revise my initial response a bit.

              RIA is no more or less relevant to services than any other presentation
              layer effort. The services don't care that the consumer is RIA or not.
              And the RIA will need the ability to interact with more than just
              services--or did we get to 100% services when I wasn't looking? ;-)

              -Rob

              --- In service-orientated-architecture@yahoogroups.com, "Gervas
              Douglas" <gervas.douglas@...> wrote:
              >
              > This is an interesting example of topic drift that often occurs in
              > this Group. My original question was, "Just how relevant do you
              > think RIA is to SOA and vice versa?"
              >
              > Gervas
            • Steve Jones
              Adding to that, Services make RIA easier, as they make all interactions easier as they present a logical representation of what is being done. RIA can, as
              Message 6 of 26 , Apr 1, 2008
                Adding to that, Services make RIA easier, as they make all interactions easier as they present a logical representation of what is being done.  RIA can, as Motif can, interact with lots of different function providing things but the more standardisation there is and the more sense those things make then the easier it will be.

                Steve


                On 01/04/2008, Rob Eamon <reamon@...> wrote:

                I'll revise my initial response a bit.

                RIA is no more or less relevant to services than any other presentation
                layer effort. The services don't care that the consumer is RIA or not.
                And the RIA will need the ability to interact with more than just
                services--or did we get to 100% services when I wasn't looking? ;-)

                -Rob

                --- In service-orientated-architecture@yahoogroups.com, "Gervas
                Douglas" <gervas.douglas@...> wrote:
                >
                > This is an interesting example of topic drift that often occurs in
                > this Group. My original question was, "Just how relevant do you
                > think RIA is to SOA and vice versa?"
                >
                > Gervas


              Your message has been successfully submitted and would be delivered to recipients shortly.