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 <[email protected]> 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 <[email protected]> > *To:* [email protected] > *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* > > >
