Part of the ftf discussion covered to what extent a role is a convenient collection of attributes, and the role becomes a composite attribute.
From what I recall from my reading of the facet classification literature, there is less in the way of extensive attribute taxonomies and more a collection of smaller taxonomies that describe a given attribute group, such as size. You can use any facet you think is useful in describing your thing in your context.
Ken
On Aug 24, 2006, at 11:42 AM, Ellinger, Robert wrote:
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
------------------------------------------------------------------------------------------
Ken Laskey
MITRE Corporation, M/S H305 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-1379
McLean VA 22102-7508
smime.p7s
