--- In [email protected], Michael Poulin <[EMAIL PROTECTED]> wrote: > > > > 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.
You seem to have started a trend of dimissing my arguments as theoretical points. Hmmm, guess I'll have to keep an eye on that. ;-) At some level of concern, the service implementation certainly matters. But from an SO view, it does not. > However, if one wants to build corresponding governance, > management, development and maintenance cycles and testing for SO, > my statement very much matters. I guess applications never worried about those things, eh? ;-) No, it does not. Each of those management areas can get along fine with a service implementation that uses a legacy application. We don't tackle those tasks "for SO." Those tasks are good practice whether or not SO techniques are followed. [Side note: That's one of the things that really irks me about "SOA governance"--it's as if governance never existed before, SOA is the only thing that needs it, and SO is the only thing to consider. SO is only a part of the whole picture. SO myopia seems to be becoming a real problem.] The implementation of a service, from an SO perspective, is explicitly immaterial. Virtually every description of SOA explicitly states that the implementation of the service *does not matter* or words to that effect. I understand your concern about the risks in simply slapping service wrappers in front of traditional applications. There are plenty of things that could go wrong. But the categorical dismissal of any and all uses of application capability within an SO environment is as ill- advised as blindly placing service wrappers on everything. Neither extreme is good. The balanced and reasoned approach is somewhere in between. > > 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. I don't disagree. How does that limit the usefulness of an application as service implementation? I guess I'm missing something in your to-be-SO-it-must-have-all-these-things checklist? 1. I have a service description. 2. I have a service contract. 3. Service is registered in a registry (optional, right?). 4. Service definition was derived from top-down analysis, from a BA. 5. Interface stands separately from implementation. 6. Implementation happens to use capability from an existing application. What's missing? > > 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. Not surprising. Not many agree with me on that particular point--it's viewed as too generic a definition of integration. What do you call it? -Rob
