Web service is just an instance of a service. Regarding SCA, up to my understanding from IBM:
Service-Oriented Architecture (SOA) is a framework that *combines individual business functions and processes, called services, to implement sophisticated business applications and processes.* In a SOA framework, relatively *coarse-grained business components* are exposed as services. SOA structures IT assets as a series of reusable services, which are loosely coupled and are platform- and implementation-neutral. SOA designs solutions as assemblies of services, which are connected through well-specified interfaces and contracts. Service Component Architecture (SCA) is a specification which describes a model for building applications and systems using a SOA . It simplifies application development and implementation developed using SOA. *Motivation* SCA simplifies the *creation* *and integration of business applications built using a SOA*. *SCA provides a mechanism to build coarse-grained components as assemblies of fine-grained components.* SCA relieves programmers from the complexity of traditional middleware programming by abstracting it from business logic. It allows developers to focus on writing business logic and can free them from the need to spend significant cycles on more low-level implementation techniques. Regarding the service owner: In the world of traditional IT, the ownership of business applications is shared between the IT organization and the business unit that uses the application. This shared ownership drives a division of responsibility for business cases, project sponsorship and oversight, implementation, and benefits assessment. Service-oriented architecture (SOA) introduces a new dynamic: business services that are shared across business units and applications. These services in SOA become a new class of IT asset, requiring new governance models and a larger, more central IT role to avoid contention between business units. In this case, there will be only one SLA for a service that is shared and published in a public registry that all the business and its consumer know about it. All the best Ashraf Galal - On Wed, May 13, 2009 at 6:04 PM, Michael Poulin <[email protected]> wrote: > > > Ashraf, > why are you still talking about services while it is absolutely clear that > you operate with Web Services? You are not alone, many people do the same, > e.g., Service Component Architecture has NOTHING to do with services, it > is good for components and components only ( > http://www.ebizq.net/blogs/service_oriented/2009/05/if_you_lost_in_translation_from_sca_into_soa.php). > How many chances to find a match between WS-Policy > assertion and SLA of a service that have different ownership? IMO, VERY > little unless it is the same person who put the SLA (?) into the Registry > (what Registry?). > > - Michael > > ------------------------------ > *From:* A W <[email protected]> > *To:* [email protected] > *Sent:* Wednesday, May 13, 2009 3:39:56 PM > *Subject:* Re: [service-orientated-architecture] Re: JP on defining SOA > > The swapping one out for another is a very good example for changing the > service implementation dynamically at run time, better if using a UDDI > registry. > The consumer just scan the Registry to get the SLA according to some > WS-Policy definition in his side, then a decision could be made, either > manually or automatically, to swap the other provider if he prefers the > price. > > Another example for Service is implemented as a component. > An example is a CICS payment system that runs on IBM mainframe. > I wrapped this application an exposed it to different consumers. > The Mainframe, the web and the hand-held devices client can use it as is > with no modification at all to the service implementation. > In addition, it can be used in a synchronous or asynchronous way with no > modification to any client or the application itself. > The consumer can choose the mechanism that most fit his need, agree with > the SLA, and bind to the servcie. > > All the best > > Ashraf Galal > > On Wed, May 13, 2009 at 12:46 AM, Rob Eamon <rea...@cableone. > net<[email protected]> > > 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<service-orientated-architecture%40yahoogroups.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<service-orientated-architecture%40yahoogroups.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 >> > > >> > >> >> > > >
