Yes, Mark, I've read it. I do respect and like yours and Eric's work not only in this standard very much (your distributed transaction solution is a 'piece of cake'!). I think, that for Web Services this standard is very valuable as well as for component-based architecture: "The group paradigm is central to coordination, whether it is coordinating 172 the outcome of distributed transactions, security domains, replica consistency, cache coherency 173 etc. Because WS-CF is meant to support a range of coordination protocols, each possessing 174 different protocol messages and potentially different coordinator interfaces, WS-CF does not 175 define how or when coordination occurs."
For its time (2005) it was the strong standard, no doubts. Nonetheless, starting in 2006, the understanding of service orientation started to deviate from Web Services, you know this better than me. Now, the understanding has reached the point that the presence of a Web Service in the solution does not make it service oriented. In the standard, you do not define 'service' because you clearly refer to known technology - Web Service. Since Web Service may be an interface to a Service or may be an interface to anything else, I suppose that operations with Web Services are not necessary about service orientation. I remember the time when we were offered a database driver Type 4, which was built based on CORBA with large distributed infrastructure behind the API. Similar thing may be done with Web Services - a regular Oracle database driver may be wrapped by Web Service and offered via Internet (is this a stupid solution or not is another question). So, does this wrap represent a Service or still a Driver with Web-bases access channel? So, OASIS Web Services Composite Application Framework is a great technical standard for Web Service interfaces but it has different appearance within the concept of service orientation, IMO. - Michael From: Mark Little <[email protected]> To: [email protected] Sent: Saturday, March 21, 2009 5:43:47 PM Subject: Re: [service-orientated-architecture] Re: Joe on SOA without service-enabled apps Have you read the specifications? [Disclosure: I'm one of the original authors as is Eric Newcomer.] Mark. On 21 Mar 2009, at 16:43, Michael Poulin wrote: OASIS Web Services Composite Application Framework is fine but where service orientation in it? - Michael ________________________________ From: Rob Eamon <rea...@cableone. net> To: service-orientated- architecture@ yahoogroups. com 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* > > > > > > >
