Ken, good questions and ones
that I've wrestled with for awhile.
I think there are
good reasons for each depending on whether they are business
functions (role-based) or IT functions
(attribute-based), and all IT infrastructures, independent of the type
of architecture has both.
The buckets that
Joe is describing are IT buckets. They include: Interaction services,
process services, Information services, access services, business application
services, and partnering services. Other than partnering services
and potentially business application services, all of these are IT
functions, while partnering services and business application
services may be treated as IT functions. The assembly of these create
composite applications; these are business
functions.
The issue that I
think you are dealing with is the famous granularity/recursive
assembly issue; a composite application at one level may be treated as a
Service Component at another level of composition.
I think it boils
down to this, both RBAC and ABAC are taxonomic views into a single Service
Component repository. Which view is used is dependent on the role of the
person needing the information. The business process engineer requires the
RBAC to model the process, while the composite application assembler and the
developer need the ABAC to implement the Composite Application to support the
business process.
That is my two
cents, though I may be one cent off base.
Thoughts?
Bob
From: Ken Laskey [mailto:]
Sent: Thursday, August 24, 2006 10:36 AM
To: Chiusano
Joseph
Cc: Michael Stiefel;
Subject: Re: [soa-rm-ra] random
question
In line with my previous response, look at the complication of the taxonomy
you are considering while you are just thinking out loud! Will it really
help to bucket things in this way?
Years ago I became fascinated with what I read on facet
classification. Now that I think about it, it is the more general ideas
that describe RBAC (role-based) vs. ABAC (attribute-based), i.e. forget about
the bins and just describe things. Let the consumer decide which
collection of attributes are relevant to the job at hand.
Ken
On Aug 24, 2006, at 10:08 AM, Chiusano Joseph wrote:
Other potential types of services are Infrastructure Services, Utility
Services, Function Services (still fuzzy on the name - meaning fine-grained
bits of functionality such as a single calculation), and Presentation
Services. Application Services can also cover those types of services that are
"in between" Function Services and Process Services - i.e. more coarse-grained
than Function Services, but not as complex as Process Services (and also not
business process definitions, as Process Services are). An example of an
Application Service could be a service that provides a loan amortization
schedule for a loan, invoking one or more Function Services for
fine-grained units of functionality.
Just thinking out loud...
Joe
Joseph Chiusano
Associate
Booz Allen Hamilton
700 13th St. NW,
Suite 1100
Washington, DC 20005
O: 202-508-6514
C: 202-251-0731
Visit us online@ http://www.boozallen.com
From: Chiusano Joseph [mailto:]
Sent: Thursday, August 24, 2006 9:29 AM
To: Ken
Laskey
Cc: Michael Stiefel;
Subject:
RE: [soa-rm-ra] random question
Not types of service providers; service providers that provide certain
types of services (e.g. data service provider = service provider of data
services).
Joe
Joseph Chiusano
Associate
Booz Allen Hamilton
700 13th St. NW,
Suite 1100
Washington, DC 20005
O: 202-508-6514
C: 202-251-0731
Visit us online@ http://www.boozallen.com
From: Ken Laskey [mailto:]
Sent:
Thursday, August 24, 2006 8:49 AM
To: Chiusano Joseph
Cc:
Michael Stiefel;
Subject:
Re: [soa-rm-ra] random question
Joe,
But I'm not sure "types" of service providers is relevant. I look
at a service description, decide if the real world effects are what I want
(and whether the rest of the execution context stuff can be aligned), and then
I proceed with the interaction. If I ask for information, I don't know
(unless I have a business reason for this to be part of my rationale for which
service to use) if it is "data" from a database, results from a simulation, or
Mechanical Turk.
Ken
On Aug 24, 2006, at 6:33 AM, Chiusano Joseph wrote:
I think it's a question
of service providers, but more specifically of what *types* of services. So
there can be data service providers, perhaps process service providers (e.g.
BPEL-based processes), and perhaps even application service providers in a
different sense than the traditional ASP (perhaps service-based
applications).
Joe
From: Ken Laskey [mailto:]
Sent:
Wed 8/23/2006 10:19 PM
To: Michael Stiefel
Cc:
Subject:
Re: [soa-rm-ra] random question
Michael,
My question is whether there are providers in the SOA sense for
something other than services. For example, one could say there are
data providers but wouldn't they have their data sources accessed using
services? Does that apply to all providing stakeholders?
Ken
On Aug 23, 2006, at 6:58 PM, Michael Stiefel wrote:
Aren't users of the services stakeholders?
Aren't manufacturers of equipment
stakeholders?
Is the government that collects a tax or
regulates a stakeholder?
Aren't the "victims" we discussed at the F2F
stakeholders as well?
Michael
At 05:57 PM 8/23/2006, Ken Laskey wrote:
Can we have stakeholders who are providers or
maintainers of something other than services? Or, do we assume by the nature
of SOA that if you provide something other than a service, that
something is a capability that must have a service access, so you always
end up a service provider?
Ken
--
---------------------------------------------------------------------------------
/ Ken Laskey
\
| MITRE Corporation, M/S
H305 phone: 703-983-7934 |
| 7515 Colshire
Drive
fax: 703-983-1379
|
\ McLean VA
22102-7508
/
----------------------------------------------------------------------------------
---
Ken Laskey
MITRE Corporation, M/S H305 phone:
703-983-7934
7515 Colshire Drive
fax:
703-983-1379
McLean VA 22102-7508
---
Ken Laskey
MITRE Corporation, M/S H305 phone:
703-983-7934
7515 Colshire Drive
fax:
703-983-1379
McLean VA 22102-7508
------------------------------------------------------------------------------------------
Ken Laskey
MITRE Corporation, M/S H305
phone:
703-983-7934
7515 Colshire Drive
fax:
703-983-1379
McLean VA 22102-7508
