<firing into the "milk"> stands for missing the target... > In any case, I think I'm missing your point. This seems to be a > testing planning failure rather than an example of how applications > are not good in an SO environment.
It is about misunderstanding of what SO is about from the project management and testing team. It is not about applications. I am saying - doing SO work, you have to think in SO all way down to production. > What's more likely are applications > evolving, still being the same ol' vertically integrated monolith, > but adding the ability to expose capabilities as services. Nobody saying that apps would go away soon. I only question the ability "to expose capabilities as services" by adding just a publicly accessible interface. I believe, and all my experience confirms it, that it is simply not enough. This is why I state that a Web Services interface on a monolithic app does not make it a service. Nothing more. > The best governance is when you don't explicitly think of it as > governance-- it's just your day-to-day work and processes. This means you are doing things in the governed way, and Governance controls may relax. For example, instead of controlling project 4 times during its life-cycle, we can do it only 2 times. > You seem to be saying that since one needs to consider these things > when repurposing an app, or a portion of it, that apps in general are > ill-suited to participating in an SO environment. Am I understanding > your position correctly? Not exactly. It may be a healthy app but we do not know about it up-front. Finding a useful function in the app is a 1/2 of work. Now we have to confirm that this function can properly work in SO environment (retiring the rest of the app or not) - this is the second 1/2 of work. For instance, in many cases, the knowledge of the internal dependencies inside the app is lost in the company and we may get surprises when call the function directly... > It seems to me that the > issues should considered on a case-by-case basis. Some apps will play > fine. Others will not. AGREE - Michael ----- Original Message ---- From: Rob Eamon <[EMAIL PROTECTED]> To: [email protected] Sent: Wednesday, July 2, 2008 6:34:12 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: > > Rob, you are firing into "milk" I'm not familiar with that phrase/colloquialis m. I assume it means my logic is faulty, or that I've set up a strawman argument or something. Can you clarify? > 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) . I'm confused. How does one test an interface to a service such that it doesn't test the service "in the form of service?" In any case, I think I'm missing your point. This seems to be a testing planning failure rather than an example of how applications are not good in an SO environment. > 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. I disagree. There are challenges certainly but we *must* have an architecural approach that allows for services, traditional applications and more. Traditional applications are not going away any time soon. IMO, it will be a long, long, long time (if ever) before applications disappear, replaced by presentation layer clients accessing a web of services. What's more likely are applications evolving, still being the same ol' vertically integrated monolith, but adding the ability to expose capabilities as services. How well an app vendor manages that will determine their success, IMO. Pure approaches typically are not practical nor achievable nor necessary. > 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. There are still some monolithic apps around. This speaks a bit to notion that purity is not achievable. We're not going to be able to SO everything-- I think even the most ardent supporters of SO say that not everything needs to be SO. I know, I know, most everyone says that *applications* as we know them must disappear in favor of SO but that's a notion I haven't quite gotten on board with. Applications can still have a meaningful role alongside SO, IMO. > The more mature SO in the company, the more relaxed SO governance. I'd say it isn't so much relaxed as it is just the way things are done. The best governance is when you don't explicitly think of it as governance-- it's just your day-to-day work and processes. > 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. Point taken (even though it could be viewed as splitting hairs). But I would not presume that the rest must categorically be retired. For a given situation, that may make perfect sense. In other cases, it may make sense for the app to live on. I don't subscribe to the notion that "if it is not a service, it must go." > 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? I agree that the performance characteristics are important. Aren't they always? When changing the tasking/workload/ user base of an app, one needs to consider these items (SO or otherwise). It is risky not to. You seem to be saying that since one needs to consider these things when repurposing an app, or a portion of it, that apps in general are ill-suited to participating in an SO environment. Am I understanding your position correctly? The threading issue you brought up is a great example of a technical detail that must be addressed in some manner. I agree too, that sometimes the technical aspects of an app may be such that they cannot be overcome for the new tasking. It seems to me that the issues should considered on a case-by-case basis. Some apps will play fine. Others will not. -Rob
