AW, please, find my comments in your text - Michael
________________________________ From: A W <[email protected]> To: [email protected] Sent: Saturday, March 21, 2009 1:04:19 PM Subject: Re: [service-orientated-architecture] Joe on SOA without service-enabled apps MP, Service is defined as “an act or performance offered by one party to another. Although the process may be tied to a physical product, the performance is essentially intangible and does not normally in ownership of any of the factors production.” MP: I disagree with such definition of SOA service. One SOA service differs from another SOA service by two attributes values only: Business Functionality promised but the service to be realized and Real World Effect (RWE), which can be viewed as a service result. Moreover, service may result in RWE, which is not necessary returned to the consumer (“offered by one party to another”), but may be made available to other parties. In technology, we have a lot of examples of such behavior. I do not know where you’ve got your service definition, but it is too weak and oversimplified to become a standard. Web service is just an instance of service. MP: I strongly disagree. Web Service technology is well-defined and its definition does not include your statement. This technology assumes an existence of the service instance somewhere but Web Service is defined as an interface, which as any other interfaces, abstract entities underneath. Moreover, Web Service and other interfaces are not necessary define or restrict the core of the service (instance or whatever) – theBusiness Functionality and RWE; these two may be simply invisible through the interface. The only thing Web Service is doing is providing requests to the service and, sometimes, returning results. It is an application programming Interface (API) that runs on a network, so it is the run time implementation of the service (component). W3C definition of web service is “A Web service is a specific instance of a component (or components) that has a public interface defined and described in XML and that other systems can discover and use by passing messages transported via existing Internet protocols.” MP: it is time for W3C to look into reality instead of whishes. Aforementioned definition does not define what is so specific about this instance; a lot of absolutely different components may have public interfaces, be discoverable and use Internet for message exchange and not being Web Services or services at all. I think, we can interpret REST as Web Service based on such “definition”If it is not important how the service is built, so what do you mean by "it would be better if it was built using the same SO principles)" and why? MP: if an entity is built based on SO principles or built with consideration of SO principles, the probability that this entity would act based on SO principles is much higher than in the opposite case. If an entity operates based on SO principles, I can call Service. I will be more than happy to read your book when it is published MP: Thank you All the best Ashraf Galal On Sat, Mar 21, 2009 at 7:50 AM, Michael Poulin <m3pou...@yahoo. com> wrote: AW, an access to a business functionality does not make it a service; it is just one of many access channels: an interface does not change the core of the things. The fact, that component in on Mainframe and was built 10 years ago does not proof that it was not built as a service. business service as “the logical encapsulation of business function” and is realised as an entity (application, if you like) that operates on the SO principles (how it is built - does not matter, though it would be better if it was built using the same SO principles) As of your comment for composite application (CA), I do not see any service orientation in it. According to referenced definition, there is no enterprise elements in it as well. Why do you stay that "composite applications leverage enterprise and enterprise-ready sources (e.g., existing modules or even enterprise web services)"? CA is just a composition of other apps that may have nothing to do with 'enterprise and enterprise-ready sources'. What does mean 'enterprise web services'? If it is about Web Service technology, I do not see how an interface may be an enterprise interface... "It is wrong to assume that composite applications are by definition part of a service oriented architecture (SOA)?" - in my opinion, it is wrong. Not everything that is integrated or composed is a service. "But we can build SOA composite application too" - absolutely agree! In my book-in-printing, I define SOA Application as a composition/ collaboration of SOA services (keeping in mind that a process is one of possible implementations of a service). Whether Web Survives are used for SOA services or not - does not matter. Tomorrow there will be another communication technology but the SOA Application will not change until its business logic changes. - Michael ________________________________ From: A W <ashra...@gmail. com> To: service-orientated- architecture@ yahoogroups. com Sent: Friday, March 20, 2009 5:08:44 PM Subject: Re: [service-orientated -architecture] Joe on SOA without service-enabled apps 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. 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 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...@yahoo. com> 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@ gmail.com> 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, 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 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 Gervas
