RE: [soa-rm] Definition: Services

["George Ntinolazos" <georgios.ntinolazos@stratasoftware.com>]

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