OASIS Web Services Composite Application Framework is fine but where service orientation in it? - Michael
________________________________ From: Rob Eamon <[email protected]> To: [email protected] Sent: Saturday, March 21, 2009 3:10:09 PM Subject: [service-orientated-architecture] Re: Joe on SOA without service-enabled apps +1. -Rob --- In service-orientated- architecture@ yahoogroups. com, A W <ashra...@.. .> wrote: > > What about a payment component that runs on mainframe using CICS/COBOL/IMS > Data base. > I wrapped it within a week and worked well with the java and .Net Web > applications very well. > They were not designed to be a service since more than 10 years ago. > Because it is built to support a business function/ process, it is a > service. > > *business service* as "the logical encapsulation of business function." > All the IT applications are built and incorporate business functions on it. > The term *composite application, as defined by wikipedia,* expresses a > perspective of software engineering that defines an application built by > combining multiple existing functions into a new application. > The technical concept can be compared to > mashups<http://en.wikipedia.org/wiki/Mashup_%28web_application_hybrid%29>. > However, composite applications leverage enterprise and enterprise-ready > sources (e.g., existing modules or even enterprise web services) of > information, while mashups usually rely on web-based, and often free, > sources. > > It is wrong to assume that composite applications are by definition part of > a service oriented architecture (SOA). > > One can build composite applications using any technology or architecture. > > But we can build SOA composite application too. > WS-BPEL is an executable language for specifying interactions with > <http://en.wikipedia.org/wiki/Web_Services>web services. > Please refer to OASIS Web Services Composite Application Framework (WS-CAF) > TC. > > All the best > > Ashraf Galal > > > On Thu, Mar 19, 2009 at 2:37 PM, Michael Poulin <m3pou...@.. .> wrote: > > > IMO, Kumar is right and Joe is wrong, that simple. > > > > Legacy apps in IT never been services (if they were not designed as such) > > and they are not services (under the same conditions). The best thing the > > Legacy apps can do for SOS is to become reliable RESOURCES. The ""modern" > > systems" operation based on SO principles not wrap but shield Legacy apps > > when treat them as resources. > > > > This is why I think that so-called 'Composite Applications' so dear to Sun > > Microsystems have very little to do with SOA. There 'Composite Applications' > > are classical integration products with no service orientation in them. If > > the goal is 'reuse legacy systems', then do it, and SOS is not needed to > > reach this goal. > > > > - Michael > > > > ------------ --------- --------- > > *From:* Gervas Douglas <gervas.douglas@ ...> > > *To:* service-orientated- architecture@ yahoogroups. com > > *Sent:* Thursday, March 19, 2009 3:41:37 PM > > *Subject:* [service-orientated -architecture] Joe on SOA without > > service-enabled apps > > > > <<"SOA Possible Even Without Service-Enabled Apps." > > > > This is a statement that goes against the conventional wisdom, so, being a > > fan of things that go against conventional wisdom, I checked out this Q&A > > interview with Shailender Kumar<http://www.cxotoday .com/India/ CXO_Views/ > > SOA_Possible_ even_without_ Service-enabled_ Apps/551- 100089-1006. html>, > > vice president of Oracle Fusion Middleware for Oracle India, to see what his > > thinking was. I wasn't dissapointed. > > > > As Kumar put it, the idea that SOA requires that participating applications > > be service-oriented is a "myth." Most IT shops, in fact, will have a mix of > > approaches. There will be legacy systems, and there will be "modern" > > systems, there will be all kinds of middleware and messaging brokers. As he > > explains it: > > > > "If you have an application that is service-enabled, and a whole bunch of > > applications that are not service-enabled, you can still connect these by > > deploying adapters. Once [people] realize that, they start to see where SOA > > can fit in bringing connectivity between diverse transaction engines." > > > > Oracle's strategy is to position Fusion as the platform that will bring > > together a lot of diverse assets from across the enterprise into a service > > layer, and, not surprisingly, this is reflected in Kumar's statement. But > > unless an organization throws out all its systems and starts entirely from > > scratch these days, most SOA efforts will be very ungainly and unique > > contraptions — and that's okay. In surveys I have seen and conducted, even > > the most advanced SOA-savvy companies have less than 20% of their portfolios > > SOA-ready. And, of course, > > JBOWS<http://www.webservices.org/weblog/joe_mckendrick/the_rise_of_the_jbows_architecture_or_just_a_bunch_of_web_services>is > > the predominant architecture at this point. And that's okay, too. It's a > > stage in evolution. And in all likelihood, there will be no compelling need > > to service-enable 100% of everything. > > > > But SOA is in a lot of places, Kumar also reminds us. For example, every > > time we order from Amazon (an Oracle Fusion customer), the order is > > processed via a service-oriented framework.>> > > > > *You can read Joe's blog at: http://blogs. zdnet.com/ service-oriented > > /?p=1725 <http://blogs. zdnet.com/ service-oriented /?p=1725> > > * > > > > *Gervas* > > > > > > >
