Ashraf, I am sorry but: 1) your first statement is NOT confirmed by the following ones. Web Service (defined in WSDL) is NOT an instance of the service, it is an interface to the service, which in absence of service description is not defined in the Web Services technology.
2) The IBM's definition of SOA, BTW, is incomplete because it misses structural definitoin of 'business functions and processes'; I have such structural definition and business service includes business functions in it. I use this structural definition to define technical service scopes, hierarchy, and boundaries. 3) <<Service Component Architecture (SCA) is a specification which describes a model for building applications and systems using a SOA >> - nothing of the mind! Read this spec instead of repeating marketing buzz. I did it and found that SCA has nothing to do with SOA, believe it or not. I proved in in my BLOG by SCA's own quotes (http://www.ebizq.net/blogs/service_oriented/2009/05/if_you_lost_in_translation_from_sca_into_soa.php) 4) <<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.>> - Inever saw this, the owner is IT only, this is why it is in fault always. 5) <<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.>>- absolutely not necessaray having 'only one SLA'; the SLA may be per consumer, per communication channel, per consumer audience, per business and technical execution context. A service provider can have as many service SLA as it wants. This is why Service Description and Service Contracts are so important service attributes in SOA. - Michael ________________________________ From: A W <[email protected]> To: [email protected] Sent: Sunday, May 17, 2009 2:16:55 AM Subject: Re: [service-orientated-architecture] Re: JP on defining SOA 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 <m3pou...@yahoo. com> 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 NOTHINGto 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 <ashra...@gmail. com> To: service-orientated- architecture@ yahoogroups. com 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> 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 > > >
