[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Definition: Services
In this context, it is the abstract concept of the service. It does not infer anything concrete. Duane George Ntinolazos wrote: >Duane, Matt > >What is the 'thing' that you refer to as a 'service'? Is the service a >'thing' in the 'real' world, the WSDL file in the hard drive, or the binary >loaded in the VM or ...? Can you give an example? > >What I am trying to say is that we need to either qualify the term service >or use alternative terms to distinguish the different forms/views of a >service thought its lifecycle. > >George > > >-----Original Message----- >From: Duane Nickull [mailto:dnickull@adobe.com] >Sent: 12 April 2005 17:13 >To: George Ntinolazos >Cc: 'Don Flinn'; soa-rm@lists.oasis-open.org >Subject: Re: [soa-rm] Definition: Services > >George: > >Going back to the W3C Technical Note, one of the core principles of >services is that they are autonomous. They do not care whether they are >part of a business process or any other process. They are self >sufficient atoms. The concepts of BPM really belong in a POA reference >model (which no one has done to my knowledge) or a process oriented view >of a specific architecture, not in a reference model for service >oriented architecture. > >Perhaps we should ask the editors to consider this sentence as a >placeholder: >=> There is no need to make architectural distinctions between a service >that is consumed as part of a process vs. one that is not. > >I would also assert that a specific architecture can concurrently be >both SOA and POA. > >Furthermore, another key concept of the W3C WSA is that services are >independent from underlying implementation technology. If we start >looking at the specific function()'s , including one service that >functionally calls 2 others, we are violating this principle. > >I would like to ask the editors to keep this sentence as a placeholder too: >=> Services are opaque and independent from underlying technology. > >Both of these concepts need to be completely abstract to be included in >the RM. > >Duane > >George Ntinolazos wrote: > > > >>I think, in our attempt to define what a service is, we will need to >>distinguish between the world of business processes and the software world >>which automates some aspects of those processes. (Here by business, I mean >>the domain of interest or problem domain) >> >>This distinction will allow for qualified terms such as business service, >>software service, and functional service: >> >>A business service represents a step or set of steps within a business >>process that is atomic and potentially fully automatable. For example, an >>openAccount business process may contain an atomic step such as >>identifyCustomer which is a business service. >> >>A functional service is a software service which automates all, or part, of >>a business service. A functional service is an abstraction which defines >> >> >the > > >>contractual aspects of a service independently of the implementation >>technology choices. By definition, is always 'business' focused. >> >>A technology service is the realization of all, or part, of a functional >>service in a given implementation technology. For example, a Java operation >>invoked using RMI, or a Web Service could both be elements of technology >>services. >> >> >>A second important distinction is between design-time and runtime. At >>runtime, objects that offer services may be associated with state. Consider >>the indetifyCustomer software service. At runtime this software may be >>associated with more than one set of customers, that is, it might be >>deployed multiple times pointing to different data. Is this one service or >>many? >> >>Yet another aspect we need to take into account is the service granularity. >>A service specification can be represented at a number of candidate levels >>ranging from a typed set of operations (usually referred to as an >>interface), to the more abstract notion of a set of such interfaces. >>Further, some existing definitions of service refer to the set of >> >> >interfaces > > >>which constitute a particular interaction between parties (for example a >>CORBA service or a WSDL composition), whereas some focus on the >>responsibilities of a particular party (or role) within that interaction >>(Design by Contract approach). >> >>George >>______________________________________ >>George Ntinolazos BSc(Hons), MSc, MBCS >> >>Product Director >>Strata Software Ltd. >>Office: +44 (0)1483 422515 >>Mobile: +44 (0)7966 652063 >>www.stratasoftware.com >>Best Practice for Service-Oriented Architectures >> >> >> >> >>-----Original Message----- >>From: Duane Nickull [mailto:dnickull@adobe.com] >>Sent: 11 April 2005 20:31 >>To: Don Flinn >>Cc: soa-rm@lists.oasis-open.org >>Subject: Re: [soa-rm] Definition: Services >> >>I do not like this definition since it assumes that all services are >>used for business processes, which is simply not true. >> >>I liked Matt's definition from this morning or some variation of it. We >>had one from the SOA Q&A we did and referenced it form the charter. Not >>sure if this one still works or if it rubs folks the wrong way. >> >>Q: What is a service? >> >>A: A service is a contractually defined behavior provided by a component >>for use by other component(s) based on the contract. >> >>Google had too many definitions ranging from Church services to >>implementation specific definitions. Didn't find anything there that >>was abstract. >> >>I tried to write another one: >> >>Service: an externally visible behavior of a component offered for >>consumption by other components. not happy with that. >> >>The W3C technical note had a pretty interesting definition, albeit once >>more implementation specific to WS*: >> >> >> 2.3.2.10 Service >> >> >> 2.3.2.10.1 Definition >> >>A service is an abstract resource that represents a capability of >>performing tasks that represents a coherent functionality from the point >>of view of provider entities >><http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#provider_entity> and >>requester entities >><http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#requester_entity>. To >>be used, a service must be realized by a concrete provider agent >><http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#provider_agent>. >> >> >> 2.3.2.10.2 Relationships to other elements >> >>a service is a <http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#isa> >> >> resource <http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#resource> >> >>a service performs >> >> one or more tasks >> <http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#service_task> >> >>a service has <http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#hasa> >> >> a service description >> <http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#service_description> >> >>a service has a <http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#hasa> >> >> service interface >> <http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#service_interface> >> >>a service has <http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#hasa> >> >> service semantics >> <http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#service_semantics> >> >>a service has <http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#hasa> >> >> >> >> >> >> >>Duane >> >>Services: >> >>Don Flinn wrote: >> >> >> >> >> >>>I just ran across a definition of a service in the paper "Composition >>>Contracts for Service Interaction" Andrade, L. and Fiadeiro, J., which >>>looks good. >>> >>>Slightly modified - >>>Services are granular software components that can be used as building >>>blocks for the assembly of business processes. >>> >>>Original - >>>Services can be seen as granular software components that can be used as >>>building blocks for distributed applications or for the assembly of >>>business processes. >>> >>>Don >>> >>> >>> >>> >>> >>> >>> >> >> >> >> > > > -- *********** Senior Standards Strategist - Adobe Systems, Inc. - http://www.adobe.com Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/ Adobe Enterprise Developer Resources - http://www.adobe.com/enterprise/developer/main.html ***********
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]