2008/7/30 Michael Poulin <[EMAIL PROTECTED]>: > Well, RIA is a tricky thing: it stands for Rich Internet Application while > in majority of cases it is taken as a Rich Internet Interface. An > application with interface can be a services; interface with requites the > applications in interesting animal... (I have a solution, now I am looking > for the task).
Most (90%+?) of RIA elements aren't really an application though they are just a rich GUI. Back in Motif days the very rich GUI we had was actually a standalone app in its own right, but the services still lived somewhere else. We had VERY rich models however that some could mistake for service but they weren't, at the front end we used OO. But you could indeed have services on the RIA side and I've worked on apps where we had just that, but we still separated the interaction part from the service part. This is at the SOFTWARE level however (which is where RIA lives), at the business level the separation is meaningless. > > Why interface becomes a service due to involvement of human factor? > > I think the problem is in the questions like Why do I have... and "What > should I do... that user interface developer asks. They should not have > those questions if the design starts right - from the application. An > interface has to interface something, otherwise it is like 'a smile without > a cat' But I can have multiple different interfaces (including multiple user interfaces) that spread across the same service estate. A call centre might share 80% of the services with the website but the interface could share nothing at all in terms of code due to the different working modes. > > If a application construction is delegated to the end-user, i.e. s/he can > choose from a list of available services, s/he also has to choose available > business functionality of the to-be application. If the list represents > business services, can you imagine how difficult task of reading through > Service Descriptions we put on the user? An alternative solution may be if > each offered service fulfill the to-be application task at once (then, there > is no composition). Watch out you'll have the Web 2.0 police on you... Seriously though I'm not talking about end-user developed interfaces (which could exist) I'm talking about developed interfaces that re-use corporate business services. HCI is a complex (and rarely understood) subject and where there is a need for richness or composition then its better to do that than have context switching between different service/application interfaces. > > If a hand-made composition is just a set of independent and isolated > business functions/services like RRS News and Currency Converter, then the > composition has to accept UIs from each business service and show them next > to each other (like Portlets in the Portal). So, where is a service function > in such composition? Why and how RIA differs from Portal? Now to be clear I don't drink the RIA is different cool aid, to me its getting us to where interfaces were in the 90s but with some pretty skins, but the difference of a portal and a decent interface is that a portal basically thinks that context switching doesn't occur as long as you display stuff on a single page, this is wrong. A portal also fails to optimise the interface and the process across multiple areas preferring to have independent interfaces and some complex back-end bit to update screens (possibly). The difference between RIA and a traditional portal for the sort of applications that RIA should really be used for is like the difference between having clothes fired at you from a cannon and going to a bespoke tailor. They might both end up with you dressed but the later will do it better and more effectively, but at a price. Steve > > - Michael > > ----- Original Message ---- > From: Steve Jones <[EMAIL PROTECTED]> > To: service-orientated-architecture@yahoogroups.com > Sent: Tuesday, July 29, 2008 9:41:45 PM > Subject: Re: [service-orientated-architecture] Re: RIA and Services (was > Seeley on Flex, Ajax and SOA) > > What SOA adds to RIA is the foundation, without a decent SOA then you > are building on an app estate, which is a painful thing. > > By Services here I mean business services that are surfaced using the > right technical paradigm for the problem. The business service > represents the structure and the capabilities which means that the RIA > can be built thinking from a business base rather than working about > "Why do I have 4 different places to get customer from" and "What > should I do to get a purchase order, and how do I link that to my > customer?". > > Now if you get to the level of considering the business service as the > full managed entity and being at a coarse grained level then yes I'd > agree that the interfaces (including RIA) may also be included, but at > the software level I think it needs to split. > > On the composition question the point here for me is that the RIA is > in effect a service, but its scope is not simply the interface it > includes the human at the other end as well. So conceptually its > still in the service domain (its why I always make sure actors are in > my service models) but technology wise the way you interact with a > person service is different for a tech to tech interface. > > Steve > > 2008/7/29 Michael Poulin <[EMAIL PROTECTED] com>: >> Steve wrote: >> <<but in order to give that new interactional model you need clarity on >> what the business services and the RWEs are>> >> >> I do agree with this. Nevertheless this does not explain why "I don't see >> the conflict, to me there really isn't a successful RIA >> world without a solid SOA". What SOA adds to RIA that RIA cannot get from >> anywhere else? What RIA requirements to its own 'A' part? I have an >> impression that in RIA world Application exists to serve its interface... >> To >> me it is absurd! >> >> <<A single HMVC environment could run off multiple different services >> >> What services are meant here; SOA business services or interface-"services >> " >> like Web Services and REST? Interesting to see an example of two business >> services sharing the same user interface. Isn't it more logical to suggest >> that one business service (implementing business model service, business >> function/feature, or business process) has multiple interfaces and >> 'interactional' interfaces among them? BTW, how much an 'interactional' >> interface with two buttons - Cancel and OK - is less interactive than an >> 'interactional' interface with two buttons - Cancel, OK, and Refresh? If >> we >> say that te niche of RIA is user-to-user interactions, then, probably, we >> need to use a special term for this, otherwise, it is just commonly used >> Web >> interface, which is fine w/o services. >> >> continued quote: >> <<... and indeed provide the user level integration between them>>. OK, >> now >> we are talking about a user level integration between services. I still >> see >> some inconsistency here but this is closer to the service oriented >> solution. >> In other words, a user interface becomes a place/entity, which >> orchestrates >> several SOA services. If we deal with real business services, why so >> important task as a composition of the services, i.e. the thing providing >> new business value, is out of the service realm? I think that in the >> service-oriented world service composition originates whatever needed >> interface, not vice verse. Rich or not so rich interface or even client is >> just an interface or just a client. It cannot be an integrating part of >> the >> service because, at least, it is out of the service control. >> >> I still believe, if an architecture proposes building a house >> (Application) >> starting with the clarity of window glass (rich interfaces), I better look >> up for another architectural solution. >> >> - Michael >> >> ----- Original Message ---- >> From: Steve Jones <jones.steveg@ gmail.com> >> To: service-orientated- architecture@ yahoogroups. com >> Sent: Monday, July 28, 2008 10:50:01 AM >> Subject: Re: [service-orientated -architecture] Re: RIA and Services (was >> Seeley on Flex, Ajax and SOA) >> >> I don't see the conflict, to me there really isn't a successful RIA >> world without a solid SOA (N.B. NOT TALKING WS-*) underpinning. The >> reason for this is that fundamentally RIA is about the interactional >> model which is predominantly the bit before the RWE in the SOA world, >> but in order to give that new interactional model you need clarity on >> what the business services and the RWEs are. If you start lobbing >> RIAs on top of an unstable, badly governed or ad-hoc infrastructure >> then you are building on sand. >> >> Way back when I was doing X/Motif/PEX development (and with large >> scale Swing dev later in Java) it was always critical to have a >> clarity of separation between the HMVC world and the services world. >> HMVC drove the client and its responsiveness and the services drove >> its impact on the business and its interaction with the rest of the >> world (B2B, A2A, etc). A single HMVC environment could run off >> multiple different services and indeed provide the user level >> integration between them, but without the clarity of the services (and >> the services hiding the implementation) you get to the stage where the >> interface becomes implicitly bound to the things it is calling and the >> flexibility of the interface is massively hindered. >> >> To my simple mind all we have now is a different set of technologies >> doing the same things, but without the huge layout power that was >> XmForm http://lesstif. sourceforge. net/Lessdox/ XmForm.html or >> simplicity for multi-display working. >> >> Steve >> >> 2008/7/28 Michael Poulin <[EMAIL PROTECTED] com>: >>> Please, see my comments by numbers: >>> >>> 1. RIA and SOA meet different types of requirements and do not share any >>> one. That is, I do not see a reason why RIA needs service-oriented >>> principles to run. >>> >>> From another hand, I take RIA as a client-server type of model with rich >>> client while the 'server' part stays in a shadow. With a risk of >>> oversimplification, I can say that RIA is about rich web interface. In >>> this >>> case, there is no new concept but rather new User Experience >>> requirements. >>> All known best practices created to Web interface stay (one of them - do >>> not >>> couple Presentation and Resource layers, i.e. do not go directly from the >>> Web page construction to the database). >>> >>> Saying so, I can see only one reasonable "need" of service orientation >>> for >>> RIA - RIA developers have to understand that they build business >>> interface, >>> not the business service; that the application part is the driver, not >>> the >>> interface (many will disagree with me, but if you recall how vulnerable >>> interface is during development and in the production, you might join me >>> that such things cannot drive, that something bigger is behind it). This >>> means that "thinking in particular about the data access layer of an >>> RIA," >>> is not SO thinking: RIA-interface serves the business service, not vise >>> verse, i.e. if a service gets used/reused in new execution context with >>> new >>> interface, RIA changes appropriately. Business service dictates what RIA >>> should provide in given User Experience requirements. Otherwise, we are >>> saying that it is the groom who gives a ride to the passengers, not the >>> horse. >>> >>> If an enterprise gets closer to SOE(enterprise) , the development stress >>> moves from the implementation of business operations who mostly >>> interested >>> in the interface to the implementation of business services, functions, >>> features, and processes where an interface is only interface, not a >>> driver >>> of the development. >>> >>> 2. I do not think I understood your answer. It was about how RIA >>> benefited >>> of SOA, not about other applications benefited of RIA. >>> >>> 3. "because RIA is such a good fit with SOA" - I would say - really? >>> Please, >>> explain the 'fit' part. >>> >>> "RIA to take advantage of SOA." - yes, everybody sees the world from >>> personal point of view. To me it is right opposite - SOA might have an >>> advantage of RIA via exposing service functionality and service results >>> (RWE) via the interface which now allows 'push' of right things, which is >>> more open to collaboration and influence by the 'application' part >>> (thanks >>> to things like Ajax) then previous Web applications. >>> >>> I see an emerging conflict between RIA and SOA. The latter directs toward >>> service-oriented business applications with variety of interfaces >>> including >>> the rich ones. The former worries primarily about interfaces assuming >>> that >>> the application must service the interface (that is, seeing world >>> up-side-down with regard to SOA)... [Well, we have it already with >>> regular >>> Web applications] >>> >>> - Michael >>> >>> ----- Original Message ---- >>> From: Kirstan Vandersluis <[EMAIL PROTECTED] com> >>> To: service-orientated- architecture@ yahoogroups. com >>> Sent: Sunday, July 27, 2008 9:10:10 PM >>> Subject: [service-orientated -architecture] Re: RIA and Services (was >>> Seeley >>> on Flex, Ajax and SOA) >>> >>> >>> --- In service-orientated- architecture@ yahoogroups. com, Michael >>> Poulin <[EMAIL PROTECTED] .> wrote: >>>> >>>> Kirstan wrote: >>>> <<I also think RIA >>>> developers need to be encouraged to use service-oriented >>> principles to >>>> the greatest extent possible, as opposed to splitting them into a >>>> "non-SOA" camp in which case service oriented principles wouldn't >>>> apply to them. The latter would be a missed opportunity and lead >>> to >>>> further IT chaos.>> >>>> >>>> I have a few questions: >>>> >>>> 1. Why RIA needs "to use service-oriented principles"? >>> >>> I'm suggeting an enterprise will be much better off if RIA >>> development uses SO principles. I'm thinking in particular about >>> the data access layer of an RIA, though service operations within an >>> SOA should be exploited as well. A fine-grained service approach >>> for an RIA would result in data services defined around related >>> fields on the screen. But such a service would be tightly coupled >>> to that particular screen and likely would not be reusable. Why not >>> apply a little service orientation here, and provide data services >>> aligned with business information more generally, course grained, >>> loosely coupled, reusable by other processing components in the >>> enterprise as well as RIA development? 10 years from now when an >>> enterprise is fully service oriented, I think the decision will be >>> automatic... RIA developers will use existing services in the >>> services catalog to drive their applications, rather than building >>> new, fine-grained services. >>> >>>> 2. What opportunities for RIA are in service-orientation ? RIA is >>> about UI widgets, their events and content, where is the place for >>> services in there? Is it in 'content'? Why Web was and is fine with >>> content management w/o any services? (Well, Yahoo! uses REST for the >>> content but it is optional) >>>> >>> >>> It is the information content driving the application that is the >>> main opportunity, though other services will apply too. I am >>> thinking about typical corporate applications here... order >>> management, sales force automation, customer management, billing, >>> reporting, dashboards, etc. Content management systems are great >>> for information and community-style portals. It might also be >>> possible to add new components to your content management >>> environment using RIA, and these could benefit from SOA. >>> >>>> 3. Why we try to mix User Experience and information >>> representation with services? Of cause, since we are going to build >>> business services, it is easy to assume that business services might >>> need UI. Why this UI has to be RIA? >>>> >>> >>> Applications require data and I think data services is a good way to >>> provide it. Data services is a key aspect controlled by an SOA, >>> though I understand there is disagreement on this point. Many of >>> the benefits of an SOA are benefits you would want at the >>> application layer: reuse, rapid development, ease of management & >>> governance, etc. Why have a completely different initiative to >>> attain these benefits in the application layer? I think a single, >>> all-encompassing SOA approach is better. >>> >>> As for the question about why a UI should use RIA technology? Maybe >>> because RIA is such a good fit with SOA :-) >>> >>>> I looked through many sites today trying to find any answers to >>> aforementioned questions and found none that was a bit more than >>> hope or speculations on analogy. May be I was not lucky... >>>> >>> >>> I'd have to agree. At this point, it seems like the RIA-SOA >>> compatibilities are mostly ideas and conjectures. But I think now >>> is the time to influence the direction of RIA to take advantage of >>> SOA. >>> >>>> >>>> >>>> ----- Original Message ---- >>>> From: Kirstan Vandersluis <[EMAIL PROTECTED] > >>>> To: service-orientated- architecture@ yahoogroups. com >>>> Sent: Friday, July 25, 2008 3:10:00 PM >>>> Subject: [service-orientated -architecture] Re: RIA and Services >>> (was Seeley on Flex, Ajax and SOA) >>>> >>>> >>>> --- In service-orientated- architecture@ yahoogroups. com, Michael >>> Poulin >>>> <m3poulin@ .> wrote: >>>> >>>> > Interaction between RIA and Web Cache is fine-grained; >>> Interaction >>>> between Web Cache and Serviced is coarse-grained. >>>> >>>> It does seem that an intermediary is required to handle the >>>> "granularity mismatch" between RIA and services. I think as RIA >>>> grows, the sheer number of services created to support them will >>>> vastly outnumber services created to support other aspects of the >>>> organization. (Side note: I know Rob and others will claim these >>>> aren't services at all, but good luck convincing developers of >>> this :-). >>>> >>>> The rise of services usage for RIA will raise real questions about >>> how >>>> to develop and manage this category of service. If anybody is >>>> interested, I wrote a blog about this called "The Long Tail of >>>> Services", which was picked up by ZDNet here: >>>> http://news. zdnet.com/ 2424-3515_ 22-199150. html. The blog simply >>>> raises the issues of management and reuse, recognizing the >>> different >>>> characteristics of each category of service. I believe service >>>> oriented tools need to accommodate both camps. I also think RIA >>>> developers need to be encouraged to use service-oriented >>> principles to >>>> the greatest extent possible, as opposed to splitting them into a >>>> "non-SOA" camp in which case service oriented principles wouldn't >>>> apply to them. The latter would be a missed opportunity and lead >>> to >>>> further IT chaos. >>>> >>>> -Kirstan >>>> >>> >>> -Kirstan >>> >>> >>> >> >> > >
