OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [soa-rm-ra] service, capability, and concise description

Nice!  If we can set this as a context for description, this might tie everything together and make the point that description is not just documentation to put away on some shelf.

But this is likely to take some work :-(


On May 22, 2008, at 11:50 AM, Don Flinn wrote:

It seems to me that this thread closely parallels the views/viewpoint aspect of an architectural description as defined by IEEE 1471 and TOGAF.   Namely, that there are participants, which they call stakeholders, who have concerns and that similar concerns from potentially different stakeholders are grouped into a view.  An architectural description is then composed of the set of descriptions of each of these different views.  Our idea of capability can be looked at as a solution to a single, coherent set of concerns, i.e. the solution to a single view.

The above specs go on to say that a given stakeholder may have different concerns which are satisfied by different views.  Another point they make is that the different views must be checked for consistency and completeness when addressing the complete architectural description.


Frank picked up a very important point: "different stakeholders will have different  understanding of the capabilities on offer".

For example, retrieving certain data from a database - is it a capability? What if I need to retrieve another data - is this another capability? Or a capability is just a set of operations on the database?

Yes, it is too late for one service = one capability. Plus, I think we may not decide this - SOA mirrors business world which may have several cohesive capabilities and consider them together as one business service.

Moreover, one capability does not mean one policy. In my previous message I gave an example where one capability expressed as one  operation(just for the sake of explanation) may still have a lot of message namespaces each of which may have an association with separate policy.

- Michael   

Don Flinn
Mansurus LLC
Tel: 781-856-7230

To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS


Ken Laskey

MITRE Corporation, M/S H305     phone:  703-983-7934

7515 Colshire Drive                        fax:        703-983-1379

McLean VA 22102-7508

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]