Well, we're finally getting to the meat of the issue here as far as I'm concerned.
Let's get retro for a moment extending on your example Michael. Let's go back to getting a quote in 1973 (year chosen in respect for the loss of Life on Mars). If you wanted a quote from two different brokerage firms on a publicly-traded security, you had the beauty of having a common nomenclature to identify the security, but you'd still have to dial two different phone numbers. Hence, the process is identical, and you can switch as you would indicate, but ultimately, there is one piece of information that changes, in this case, and in the case of many SOA designs, it's the endpoint address. If one brokerage phone number is busy, you can call the other one. Today, we merely switch IP addresses. In Cloud Computing, we will want to leverage SOA in a similar manner to enable responsiveness and elasticity regardless of how the Cloud is implemented. These are real world examples of SOA @ work. However, many types of services will never lend themselves to switching based on endpoint. Case in point, UPS/FedEx/DHL. There's no impetus for them to standardize on the nomenclature and inputs to their shipping process. To alleviate this we can use "adapters" or and ESB to mediate on our end making it look like we merely need to change the endpoint. I believe ultimately, if this switch can be designed into the system, then you have SOA. JP --- In [email protected], Michael Poulin <m3pou...@...> wrote: > > JP, > I believe I am in the same place as was before and where you are. My comment > is based exactly on your example. > Substitution behind the interface is not the thing brought by SOA, it was > known before. I would say that your and my examples demonstrate that an > entity with available/accessible interface simply manages its resources - > mail providers and quote provides. Nothing is wrong with it. > > A pure SOA solution, IMHO, (though not the best one) would be, e.g., when > your consumer could switch from one service (provider) to another service > (provider) explicitly. In my case, consumer should be capable of watching for > the performances (availability and response time) of each quote service and > switching between them if any SLA was violated (this job was done by my > adapter that time but it treated providers as resources, not as services). >
