> > However, the part which claims it is in SOA, must be in SOA in > > full. This is not about a level of automation, it is about > > preservation of the service orientation.
> If implementation is a behind the scenes aspect, then who cares if a > service is backed by a legacy application? Well, if one cares about theoretical abstractions only, it it does not matter, indeed. However, if one wants to build corresponding governance, management, development and maintenance cycles and testing for SO, my statement very much matters. > I don't understand how this applies to your "service-wrapped legacy > applications aren't SO" position. The following seems perfectly valid to me: > > 1. Create the service description. > 2. Implement the service using some means, which may include calling > existing application capability. Such a call may be just a part of, > or comprise the entire service. I gave an example not about service-wrapping but about more generic approach to SO realization. It has to be SO even in such *small* thing like a Service Description. > IMO. App A and App B talking to each > via any number of direct means is still integration. Same goes for > provider x and provider y. . I do not think we reach an agreement in this ever. - Michael ----- Original Message ---- From: Rob Eamon <[EMAIL PROTECTED]> To: [email protected] Sent: Monday, June 30, 2008 9:30:20 PM Subject: [service-orientated-architecture] Re: Legacy into SOA (was Vandersluis on a Data Abstraction Layer's Benefits) --- In service-orientated- architecture@ yahoogroups. com, Michael Poulin <[EMAIL PROTECTED] .> wrote: > > Please, allow me to remind the nightmare in IT in late 90s and > early 2000s when massive flow of internal applications we made Web- > enabled. It took us a few years before we understood with > confidence that Web Application and Web-enabled Application are two > different animals. Hmm. I thought we spotted the difference right away. We *knew* web- enabled was not as desirable, but practicality meant that sometimes that was the route taken. > > The same happening right now with SOA. "Practical SOA" where > applications may play instead of services (it does not matter if > the are legacy or just fresh-cooked) sounds to me as somebody clams > she is pregnant a little bit (sorry, ladies). A poor, poor analogy. Applications can still exist in an SO solution, IMO. I know many disagree. > I do not buy Practical, or Half-Way, or partially matching SOA. It > is not SOA, We disagree. > it is a way to SOA. This is why we have Enterprise SOA Maturity > Models, not SOA Maturity. > > An enterprise can adopt SOA in steps; not everything that might be > a service must become a service at once. We agree completely here. > However, the part which claims it is in SOA, must be in SOA in > full. This is not about a level of automation, it is about > preservation of the service orientation. If implementation is a behind the scenes aspect, then who cares if a service is backed by a legacy application? > For example, SOA Service is supposed to be accompanied by a Service > Description. The latter is a document to be read by humans and > may be used programmatically, e.g., it is in an XML format. I am > saying that a Service Description in a Word format (not > programmatically readable - for the sake of discussion) or just a > document hand-written on a paper is the SO solution while an > absence of such documents, explained by inability to read Word > format with available IT tools, is not SO solution. I don't understand how this applies to your "service-wrapped legacy applications aren't SO" position. The following seems perfectly valid to me: 1. Create the service description. 2. Implement the service using some means, which may include calling existing application capability. Such a call may be just a part of, or comprise the entire service. > > This gets into defintions I suppose. Strictly speaking, two > > services that interact are "integrated. " > > I am not sure what you mean by placing quotes on INTEGRATED, The quotes (which I think I use far too much!) were just to add emphasis to the term. Nothing more. > but integration assumes a 3rd party which performs connection > between to-be integrated entities. That's an invalid assumption, IMO. App A and App B talking to each via any number of direct means is still integration. Same goes for provider x and provider y. Or consumer m and provider n. > Service consumer can connect to the service provider's service with > out a middleman [Oh, in this case you will argue that they are > integrated via a network between them :) ] You judge me too harshly! ;-) Consumer talking to provider via the exposed interface is integration, IMO. But I understand that conventional wisdom is such that integration: 1) means the use of 3rd party tools; 2) is the reconciliation of "incompatible" components; 3) is a Bad Thing and is to be avoided. What would you call the act of connecting a presentation layer component that to a variety of other, independent, self-sufficient components? Is "assembly" simply a more acceptable term that attempts to shrug off the negatives of integration? >From Wikipedia in integration: "...the process by which smaller pieces of software are brought together to form a larger piece of software that was designed to solve a problem." >From the SAP site: "Individually, SAP Business Suite applications help you manage your most critical business processes. Collectively, they form a tightly integrated suite..." -Rob
