It is definitely possible to
have a service that just consumes messages, or just sends messages. Broadcast
messages are an excellent example of a type of service that just sends messages.
Perhaps this can be considered a 4th type of service (i.e. added to the 3 I
originally mentioned below).
Joe
Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.com
From: Christopher Bashioum
[mailto:]
Sent: Mon 4/11/2005 10:27
AM
To:
Subject: RE: [soa-rm]
Types of Services (RE: [soa-rm] Definition of "Service
Consumer")
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
