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]>: > 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]> > 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 > > >
