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:]
> Sent: Monday, April 11, 2005 12:34 AM
> To: Chiusano Joseph
> Cc: Christopher Bashioum;
> 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:]
> Sent: Thursday, April 07, 2005 12:49 PM
> To:
> 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:]
> Sent: Thursday, April 07, 2005 12:21 PM
> To: 'Frank McCabe';
> 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:]
> Sent: Thursday, April 07, 2005 9:00 AM
> To:
> 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
***********
