> 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.
Rob, you are firing into "milk" - did I say a word "application" or "implementation"? I was talking about everything around application. All these surrounding "small things" making development of the services. If a PM does not understand that s/he may not manage all components of the project deliverable or has to test 10 times more than in usual application project - we will get a piece of crap instead of the service. SO must go everywhere, not into the code only. A trivial example: we were building relatively complex aggregated service but used only SOAP UI testing tool. The services never failed in the interfaces but crashed everywhere else. Why? SOAP UI tests Web Service only; service body was not tested in the form of service ( while separate parts were tested independently). To test SOA service we need tools like LISA (this is not a promotional case - I have no relationship to iTKO whatsoever), which tests interface and everything behind it. This is the same issue as we talked before - it is impossible to do a bit of SO here and old application things there, this is the receipt for troubles. Actual implementation of the service does not matter indeed, but the manner of implementation does and very much does. Talking about SOA governance, I have to say - so much attention is put on it because SO (when it becomes real task, not an popular article) requires different mentality and approach from those who are doing the work. This shift in mind is similar in its power and volume to the shift into client/server model. A lot of people, including a lot of managers, did not get it. They thought it was a new technology while it was a new way of thinking about the things and acting respectively, in in old style. The same issue with governance happened in transition from monolithic apps in to client/server. The more mature SO in the company, the more relaxed SO governance. > 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. Exactly, service needs and has to "use CAPABILITY from an existing application", not the application. How to extract the capability and retire the rest - this is the problem, but it is problem #2. Problem #1 is how much I can rely on or trust that this capability would work well in the service environment (workload, concurrency, reachability, etc.)? Implementation of the service is invisible, it does matter for QoS and SLA. Are you still disagree? Beside this, aforementioned list is fine! - Michael ----- Original Message ---- From: Rob Eamon <[EMAIL PROTECTED]> To: [email protected] Sent: Tuesday, July 1, 2008 4:39:29 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: > > > > 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
