Re: [soa-rm] Definition: Services

[Matthew MacKenzie <mattm@adobe.com>]

NOOOO!!

:-)

A service is a service is a service, at least to a reference model.  I 
can't understand why we need to distinguish in the reference model.

-Matt
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
>>
>> 
>>
>>    
>>
>
>  
>