Chris,
This is why I suggested looking at the MEPs that derive from the WSDL 2.0
work. They've already spent a lot of time looking at this.
Ken
At 10:27 AM 4/11/2005, 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:
<?flushboth><?fontfamily><?param Times New
Roman><?x-tad-smaller>A
<?/x-tad-smaller><?x-tad-smaller>data
resource<?/x-tad-smaller><?x-tad-smaller> 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 <?/x-tad-smaller><?x-tad-smaller>processing
resource<?/x-tad-smaller><?x-tad-smaller> 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.
<?/x-tad-smaller><?/fontfamily><?/flushboth>
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
--
---------------------------------------------------------------------------------
/ Ken
Laskey
\
| MITRE Corporation, M/S H305
phone: 703-883-7934 |
| 7515 Colshire
Drive
fax: 703-883-1379 |
\ McLean VA
22102-7508
/
----------------------------------------------------------------------------------
