--- In [email protected], 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
