[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")
It is possible to request a service once and consume it multiple times thereafter. Duane Nickull. Christopher Bashioum wrote: > Ken and Joe, > > do all services have a 2-way communication mechanism, or is it > possible to have a service that just consumes messages (or just sends > messages)? The reason I am asking, is that it looks like all the > interactions mentioned so far involve a request and a response, but I > am wondering about the idea of events or broadcasts. > > > > ------------------------------------------------------------------------ > From: Ken Laskey [mailto:klaskey@mitre.org] > Sent: Monday, April 11, 2005 12:34 AM > To: Chiusano Joseph > Cc: Christopher Bashioum; soa-rm@lists.oasis-open.org > Subject: Re: [soa-rm] Types of Services (RE: [soa-rm] Definition > of "Service Consumer") > > Let me suggest the following: > > A data resource is a source of content. It accepts a request and > returns a value or set of values in response. The return can be an > entity (such as a particular schema), an attribute of an entity > (such as when the schema was last modified), or any numerical or > textual value or set of values. The content can be static objects > stored in some repository or dynamically generated through the use > of a processing resource. Data about a missile that is stored in a > database is content. The weather forecast for tomorrow is content > generated from a weather simulation. In a net-centric environment, > the requester does not know the format from which the response is > retrieved or how it is generated. > > A processing resource is one that accepts a task and return a > status indicating the extent to which the task was completed and > information on how the state of entities changed as a result of > the processing. One or more processing resources may be invoked as > part of a process of submitting a query and being returned a > response. From the standpoint of a user (either human or machine), > it is unimportant what combination of data and processing > resources are invoked as long as the request is satisfied. > > Services interact with (i.e. use, invoke, access, ...) these > resources. > > Ken > > On Apr 10, 2005, at 2:00 PM, 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. > > ====================================================================== > > > > > > > > > > ------------------------------------------------------------------------------------------ > Ken Laskey > MITRE Corporation, M/S H305 phone: 703-883-7934 > 7515 Colshire Drive fax: 703-883-1379 > McLean VA 22102-7508 > -- *********** 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]