OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [soa-rm] Types of Services (RE: [soa-rm] Definition of"Service Consumer")


Joseph:

My thoughts are that this is not something we should be spending a lot 
of time on since it fails the "abstract" acid test.  All of these 
thoughts concentrate on concrete services.  A service, as a 
concept/abstract "thing", does not need to define itself in terms of its 
specific functions.

All services do have an abstract data model, regardless of what they 
do.  Even if there is a value of "null" required to invoke a concrete 
service, it is still conceptually representative of a data model.

One of the principles of SOA is the concept of interface based design.  
A service consumer does not care "how" something happens behind the 
service, nor should it.  

Let's try to keep the conversations on this list focused on the first 
task of the SOA RM.  If we do want to have a simultaneous sub-TC working 
on a concrete architecture and issues thereof, we have the option of 
setting up a separate list for those types of discussions.  I think this 
should be done after we have a core reference model established, 
hopefully after the face to face.

Duane


Chiusano Joseph wrote:

>I wonder if the roles a service can play - or, perhaps one can say, the
>general types of services that can exist - have any bearing on our RM at
>all, in an indirect way.
>
>Put in simple terms, one may say that there are - in general - 3
>overarching "types" of services. These correspond to 3 of the layers of
>the general "integration stack" (data, application, and process):
>
>(1) Data-Oriented Service: Primary role is to accept and process data,
>or provide data based upon a request. 
>
>Two general types:
>
>(a) Data Processor*: Accepts as input a set of data, processes that
>data, and (optionally) sends a response. The response may simply be an
>acknowledgement, or another set of data to be processed by the service
>requester**. 
>
>Ex: Simple form acceptance service, such as a loan application form
>service acting on behalf of multiple banks (routes to proper bank and
>sends back acknowledgement to form submitter)
>
>(b) Data Provider: Provides streaming data, or a set of data upon
>request.
>
>Ex's: RSS news feed (streaming data), stock quote (set of data upon
>request - given stock ticker symbol)  
>
>*need better term - using this for illustration purposes only
>**using term "requester" for now since we have not established our
>perferred term
>
>(2) Application-Oriented Service (aka "Function-Oriented Service"):
>Primary role is to accept a command and carry out processing based on
>that command, in a singular fashion (i.e. does not invoke other
>services).
>
>Ex's: Inventory verification service (accepts item #, responds with
>whether or not it is in inventory), shipment cost calculation service
>
>(3) Process-Oriented Service: Similar to Application-Oriented Service,
>but invokes other services in carrying out its processing (i.e. it
>embodies the definition of an overarching process).  
>
>Ex: Order processing service (checks customer credit, checks inventory,
>does shipment cost calculation, etc.)
>
>Thoughts?
>
>Joe
>
>Joseph Chiusano
>Booz Allen Hamilton
>Visit us online@ http://www.boozallen.com
> 
>
>  
>
>>-----Original Message-----
>>From: Christopher Bashioum [mailto:cbashioum@mitre.org] 
>>Sent: Thursday, April 07, 2005 12:49 PM
>>To: soa-rm@lists.oasis-open.org
>>Subject: RE: [soa-rm] Definition of "Service Consumer"
>>
>> When we talk about service consumer vs. provider in this 
>>sense, I think we need to separate the "static" entity from 
>>the dynamic role that said entity plays.  A given entity can 
>>be both service provider (in which case it publishes it's 
>>service description) and service consumer (in which case it 
>>binds to another service provider in order to accomplish its 
>>own service).
>>
>>So...to re-word your statement a little: An entity that binds 
>>with a service is playing the role of service consumer. 
>>
>>-----Original Message-----
>>From: Vikas Deolaliker [mailto:vikas@sonoasystems.com]
>>Sent: Thursday, April 07, 2005 12:21 PM
>>To: 'Frank McCabe'; soa-rm@lists.oasis-open.org
>>Subject: RE: [soa-rm] Definition of "Service Consumer"
>>
>>
>>Using the publish/find/bind framework of SOA... 
>>
>>The entity that publishes is certainly not the consumer. The 
>>entity that
>>finds may or may not be the consumer but the entity that 
>>binds is certainly
>>the consumer. 
>>
>>So an entity that "binds" with a service would be the closest 
>>to a service
>>consumer. 
>>
>>Vikas
>>
>>-----Original Message-----
>>From: Frank McCabe [mailto:frank.mccabe@us.fujitsu.com] 
>>Sent: Thursday, April 07, 2005 9:00 AM
>>To: soa-rm@lists.oasis-open.org
>>Subject: Re: [soa-rm] Definition of "Service Consumer"
>>
>>There is a distinction between the software *entity* 
>>(agent/component/J2EE bean/.../) that interacts with a 
>>service in order 
>>to achieve some goal, and the person or persons for whom that 
>>interaction is taking place.
>>
>>The reason that this distinction is important is similar to the 
>>distinction between a service interface and the service itself: 
>>accessing your bank account from an ATM or on-line will use different 
>>interfaces but ultimately all use the same service.
>>
>>Here is an example of why its important: the appropriate 
>>business logic 
>>to apply to a service request will depend on many factors: 
>>the means by 
>>which the request was delivered, the request itself and the 
>>person (or 
>>persons) for whom the request was made. This last aspect is 
>>completely 
>>independent of mode of requesting and is purely business/application 
>>specific.
>>
>>Incidentally, the above definition: "an agent that interacts with a 
>>service in order to achieve a goal" seems to be a reasonable 
>>definition 
>>of a service requester.
>>
>>
>>On Apr 7, 2005, at 7:23 AM, Gregory A. Kohring wrote:
>>
>>    
>>
>>>Matthew,
>>>
>>>OK, here a fewer other choices which might be deemed more
>>>"respectful"...
>>>
>>>Service Consumer:
>>>
>>>1) End-user of a service.
>>>
>>>2) An agent which, acting on behalf of its owner, uses a service.
>>>
>>>3) An entity which utilizes a service
>>>
>>>4) An entity which consumes the product or information produced by a
>>>   service.
>>>
>>>
>>>Note all of these definitions depend upon the definition of the
>>>term "service".  Have we agreed on this already? Perhaps we should
>>>start there first...
>>>
>>>
>>>-- Greg
>>>
>>>
>>>
>>>Matthew MacKenzie wrote:
>>>      
>>>
>>>>I think services deserve respect, lets try not to exploit them :-)
>>>>Gregory A. Kohring wrote:
>>>>        
>>>>
>>>>>Thomas,
>>>>>
>>>>>Perhaps one should use a somewhat broader definition 
>>>>>          
>>>>>
>>which captures
>>    
>>
>>>>>the human user as well:
>>>>>
>>>>>Service Consumer: An entity which exploits a service.
>>>>>
>>>>>
>>>>>-- Greg
>>>>>
>>>>>
>>>>>Thomas Erl wrote:
>>>>>
>>>>>          
>>>>>
>>>>>>Now that we've decided on the term "service consumer" it may be 
>>>>>>useful to formally define it. The term "consumer" is used by the 
>>>>>>WS-I Basic Profile wherein it is simply defined as 
>>>>>>            
>>>>>>
>>"Software that 
>>    
>>
>>>>>>invokes an instance."
>>>>>>
>>>>>>Thomas
>>>>>>
>>>>>>            
>>>>>>
>>>>>          
>>>>>
>>>-- 
>>>
>>>      
>>>
>>======================================================================
>>    
>>
>>>G.A. Kohring
>>>C&C Research Laboratories, NEC Europe Ltd.
>>>
>>>      
>>>
>>======================================================================
>>    
>>
>>
>>
>>
>>    
>>
>
>  
>

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