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).
To my taste, I would say that "SOA-based designs {introduce} enable agility";
whether you recognise it and take or not - it is up to you.
- Michael
________________________________
From: jp_morgenthal <[email protected]>
To: [email protected]
Sent: Thursday, May 14, 2009 1:32:25 PM
Subject: [service-orientated-architecture] Re: JP on defining SOA
Michael,
You've gone to a place where I cannot follow. Somehow the context of your
point is lost on me. Due to the nature of discussion threads, I will interpret
the question to state that you believe statements like "SOA-based designs
introduce agility" is simply useless buzzword drivel without substance. If I
am not correct, please feel free to correct me. If I am correct, then I
believe the context in which this was stated in my blog entry clearly
demonstrates where the value is derived and my further explanation of my vision
of how it is implemented in the case of shipping further adds clarification on
how I see SOA-based designs delivering agility. Moreover, I don't know if you
read the blog entry, but in there I go so far as to introduce the concept of
SOA as an archetype, from which many architectural designs can be fashioned
including the one you used at Morningstar. Hence, it doesn't make sense to
disassociate the approaches.
JP
--- In service-orientated- architecture@ yahoogroups. com, Michael Poulin
<m3pou...@.. .> wrote:
>
> JP, what do you mean by 'SOA-based designs introduce agility'? 'agility' to
> what? Why SOA-based designs introduce it while it is known for years in the
> form of Adapters? I did the same thing (for market quotes) with Reuters and
> Morning Star 5 years ago in plain J2EE w/o any services...
>
> - Michael
>
>
>
>
> ____________ _________ _________ __
> From: jp_morgenthal <jpmorgenthal@ ...>
> To: service-orientated- architecture@ yahoogroups. com
> Sent: Wednesday, May 13, 2009 12:26:52 PM
> Subject: [service-orientated -architecture] Re: JP on defining SOA
>
>
>
>
>
> Well, since the thread was based on my blog entry, let me reiterate the part
> of my definition that is pertient here:
>
> "SOA-based designs introduce agility by enabling interchangeability of
> service providers without requiring process changes in the consumers"
>
> This is exactly the example I gave with UPS and FedEx for shipping. The
> overall process does not need to change. I intimated nothing about the
> implications within a single step. Returning to my UPS/FedEx example, there
> is an impact in which shipper to choose, but even that can be parceled out as
> a service that decides for you and fills in the correct shipping label.
> Ultimately, tho, you have to hand the box to the right shipper, which means
> something will change at the task level, but it need not impact the entire
> process.
>
> JP
> --- In service-orientated- architecture@ yahoogroups. com, "Rob Eamon"
> <reamon@> wrote:
> >
> > JP,
> >
> > That's a good example. I suppose there may be others as well.
> >
> > I wonder how many such identical (or close enough) services might a typical
> > company encounter in their service portfolio.
> >
> > But I think I erected a strawman anyway. The original point by Ashraf was
> > to be able to change the implementation, which is different from swapping
> > one out for another.
> >
> > -Rob
> >
> >
> > --- In service-orientated- architecture@ yahoogroups. com, "jp_morgenthal"
> > <jpmorgenthal@ > wrote:
> > >
> > > Rob,
> > >
> > > Your pragmatism is partially correct here, but the effort need not be
> > > significant. From my favorite example, consider switching from FedEx to
> > > UPS for shipping. Most companies do this hundreds of times a day and the
> > > difference is how they prepare the package for shipping, which ultimately
> > > comes down to prepping the shipping label information. Yet, you can run
> > > the shipping process identically and choose a different shipping provider
> > > based on price with minimal overhead and effort as a single step.
> > >
> > > JP
> > >
> > > --- In service-orientated- architecture@ yahoogroups. com, "Rob Eamon"
> > > <reamon@> wrote:
> > > >
> > > > In other words, service interface is separate from service
> > > > implementation? This is the core SO principle.
> > > >
> > > > I'm still bearish on the notion that a service implementation can be
> > > > swapped out for another with zero consumer impact. I've never seen a
> > > > meaningful implementation of anything be swapped out without
> > > > significant effort. Some low-level technical components can and have
> > > > been swapped out but that's not the level we're addressing here?
> > > >
> > > > -Rob
> > > >
> > >
> >
>
