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: NCOIC Services Interface Capability Patterns and the RAF [was "Comments on HL7 ArB SAIF-CD document"]


Mike,

Your reply threw me completely at first, and I was struggling to see the link with SAIF.

 

Now I realise that it was a completely new thread, talking about NCOIC.

 

I agree that there many references that make sense and I’d be interested to through the whole work in more detail. On the specific issue of identity of stakeholders, I think that there are two considerations:

-          from a modelling perspective: if we consider that a “Stakeholder” is a role played by a “Person” in the “Ecosystem”, and consider that “Person” is a class of “Entity”, then we have a simple and elegant solution. I do however take issue with the W3C mentality that insists that everything with identity is a resource and anything without identity is not a resource. Hopefully we can avoid that fruitless debate.

-          From a textual perspective: this is a little more delicate. The importance of identity, in the sense that you refer to, is relevant at the System level and not necessarily within the Ecosystem. We would probably then need to talk up the importance of identity of Actors more generally and specifically, in your scenario, of Participants: we must remember that Consumer and Provider are different roles rather than Participant types. It is not the identity of a “Participant-as-Stakeholder-in-Ecosystem” (such as Consumer, etc., especially as the role played may change) but the identity of a “Participant-as-Actor-in-System” that is important.

Does that make sense?

 

Bottom line is: do we want/need to address this in the RAF?

 

Regards,

Peter

 

Peter F Brown

Independent Consultant

www.peterfbrown.com

P.O. Box 49719, Los Angeles, CA 90049, USA

Tel: +1.310.694.2278

 

From: soa-rm-ra@lists.oasis-open.org [mailto:soa-rm-ra@lists.oasis-open.org] On Behalf Of Mike Poulin
Sent: Tuesday, 04 October, 2011 16:37
To: soa-rm-ra@lists.oasis-open.org
Subject: Re: [soa-rm-ra] Comments on HL7 ArB SAIF-CD document

 

Hi All,
in hte last week meeting of NCOIC, where Rex promoted my presentation, I heard about NCOIC SOA Governance Pattern and was interested in their practice of patterns. I have learned the one named 
Net-Centric Services Interface Capability Pattern, which references frequently to SOA RM but still has some conceptual deviations from that standard. 

I have found an interesting (IMO) element in this pattern that we, if incorporate into SOA RAF, might benefit as well. It is a unique Consumer ID in the net, i.e. in the SOA Ecosystem. Below, I have provided a few extracts from that Pattern though with no context.

Obviously, it is impossible to establish a unique Consumer ID for totally independent services in the SOA Ecosystem. However, there may be certain domains, like in Internet, with unique IDs. These domains may be set into a federation with no particular limitation on the number of participants. Thus, the Consumer ID may be a relatively unique like an address on a Main Street in American cities for particular city (or a High Street in Britans  cities). 

I propose to think abbout such ID, which brings benefits enumerated by NCOIC.


<Extracts:>

1.2.3 Consumer Identity 

Consumer identities often are not known in a SOA. Poor Provider visibility of the Consumer 

makes change impact difficult or impossible  to gauge. A frequent problem with service 

versioning is service “creep.” Superfluous and redundant versions may evolve. One of the central governance issues that must be addressed is who is using the service interface. Without knowing who is using a service, it is difficult to know if a service can be deprecated. 

 

In those cases, where a service interface may need to be changed significantly, it may be difficult to estimate which Consumers may be affected and the extent of the effect of a change when the Consumer base is unknown. This problem will compound as Consumer use of service increases.  

 

 

2.4.3 Consumer Identity {NC} 

This solution element provides for a tracking, auditing, or logging mechanism clearly visible 

to actors with the right credentials so they have visibility of each others actions, although there 

should be a balance between loose coupling (as typically promoted by SOA) and strict Consumer identification. 

 

For example, a new Consumer should be able to use the service without an initial 

need for a Provider to know Consumer identities ahead of time. A corollary problem described in 

Section 1.2.3 is the expense of multiple version monitoring and control. To minimize this 

expense, requirements include tying change requests to cost as described in item c Requirements are the following: 

a. Provider shall include an interface element containing Consumer identity. 

b. The interface element containing interface Consumer identity shall be described in each 

SLA 

c. A cost mechanism shall exist to charge a Consumer for a change request.  

 

 

2.5.3 Consumer Identity {SOA and NC} 

A tracking, auditing or logging process will allow actors with the right credentials to have 

visibility of each others actions. Requirements are the following:  

a. Interface use shall be available to Provider and Consumers so that if an interface needs 

to be changed, deprecated, or otherwise abandoned, an orderly process amongst all 

parties concerned can be established and carried out. 

b. Consumers shall have interface visibility of changes including content, date and time of 

change, and schedule. 

c. The deprecation process shall have a finite time length.  

d. Once an interface is scheduled for deprecation, the interface shall be deprecated per the 

schedule. 

 

 

21  Consumer Identity  2.4.3 a  Provider shall include an interface element containing 

22  Consumer Identity  2.4.3 b  The Interface element containing interface Consumer identity shall be described in each SLA. 

23  Consumer Identity  2.4.3 c  A cost mechanism shall exist to charge a Consumer for a change request. 

24  Consumer Identity  2.5.3 a  Interface Consumers shall be available to Providers, Integrators, or System Integrators so that if an interface needs to be changed remarkably, deprecated, or otherwise abandoned, an orderly process among all parties concerned can be established readily and carried out. 

25  Consumer Identity  2.5.3 b  Consumers shall have interface visibility changes including content, data, and time of change, and schedule. 

26  Consumer Identity  2.5.3 c  Deprecation process shall have a finite time length.  

27  Consumer Identity  2.5.3 d  Once an interface is scheduled for deprecation, the interface is deprecated per the schedule. 



Thanks,
- Michael

 

----- Original Message -----

From: Peter F Brown

Sent: 10/03/11 10:48 PM

To: 'Ken Laskey', rex.brooks@ncoic.org

Subject: [soa-rm-ra] Comments on HL7 ArB SAIF-CD document

 

Ken,

 

 

As promised a few off-the-cuff comments to the SAIF-CD document.

 

 

 

 

 

Introduction is excellent and well structured;

 

 

SAIF definition and use of “cross-boundary” is good and clear (maybe less clumsy than our own);

 

 

Concise introduction to semiotic concepts of sign, meaning and code (possibly too simplistic – Saussure model rather than Jakobsen – as it skips over role of context in communication);

 

 

Interesting separation between technical interoperability language and “governance language” to express formal linkages between definitions of shared purpose;

 

 

Basic notion of “shared purpose” resulting in “defined value for the various parties involved…” – presumably leads to an intended RWE, in our terms? Am I reading that correctly?;

 

 

Role-based perspectives – “critical to predictable and tractable success” – good link back to ISO 10746-3 (RM-ODP);

 

 

Interesting that they reference Thomas Erl’s latest SOA Governance work – impressive (only been out a few weeks!)

 

 

Contrast between dynamic (behavioural) and static (informational) semantics – I like this: we sort of bumped into this when we were focussed on (static) information models rather than looking at the more dynamic aspects – we might have gotten to conclusion on some of the service execution work quicker if we had seen/known some of this earlier, but what the heck…

 

 

Their distinction between the canonical model and the implementation guidelines deals, elegantly IMO, with the same distinction we struggled with between an RA and the RAF…

 

 

 

 

 

Governance Framework – again familiar material (cf our Section 3) and very welcome.

 

 

 

 

 

“Politically”, I think it also underlines our contention that the Open Group Reference Architecture and SOA ontology are troublesome – SAID seems to be much closer to us and I would be happy to see further cooperation with these guys in hammering home our (common) perspective …

 

 

 

 

 

If I had the bandwidth and/or a research student at hand, it would make for a great comparative analysis but that’s just not going to happen. Instead, and in summary, I would say: without wanting to pin down and map this, I have a sense of a very high level of similarity in concepts and approaches. The fact that there isn’t 100% correspondence I think is less relevant than the fact that a different community has come to very similar conclusions as we have and through very similar processes, is a validation for both communities of the work that has been done.

 

 

 

 

 

HTH, regards,

 

 

Peter

 

 

 

 

 

 

 

 

Peter F Brown

 

 

Independent Consultant

 

 

www.peterfbrown.com

 

 

P.O. Box 49719, Los Angeles, CA 90049, USA

 

 

Tel: +1.310.694.2278

 

 

 

 

 

 

 

 

-----Original Message-----
From: soa-rm-ra@lists.oasis-open.org [mailto:soa-rm-ra@lists.oasis-open.org] On Behalf Of Ken Laskey
Sent: Wednesday, 28 September, 2011 08:08
To: rex.brooks@ncoic.org; soa-rm-ra@lists.oasis-open.org
Subject: RE: [soa-rm-ra] Can we skip Today's Meeting in favor of working on reviews?

 

 

 

 

 

We are likely not to be quorate with you folks otherwise productively

 

 

engaged.

 

 

 

 

 

However, I propose not skipping entirely because Jeff and I need to see if

 

 

we can set up my remotely controlling the audio.  This assumes Jeff is

 

 

available.

 

 

 

 

 

Also, I did a quick read through the HL7 SAIF CD and wanted to see if there

 

 

were others who had a chance.  I do need to get back to Charlie Mead.  Rex -

 

 

you were the likely suspect on this.  If you (or anyone else) did get a

 

 

chance, I'd appreciate you calling in for a few minutes so we could chat.  I

 

 

expect a few minutes real time will be more efficient that a string of

 

 

emails.

 

 

 

 

 

Other items to consider?

 

 

 

 

 

Ken

 

 

 

 

 

---------------------------------------------------------------------------

 

 

Dr. Kenneth Laskey

 

 

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

 

 

7515 Colshire Drive                                    fax:

 

 

703-983-1379

 

 

McLean VA 22102-7508

 

 

 

 

 

 

 

 

-----Original Message-----

 

 

From: soa-rm-ra@lists.oasis-open.org [mailto:soa-rm-ra@lists.oasis-open.org]

 

 

On Behalf Of Rex Brooks

 

 

Sent: Wednesday, September 28, 2011 10:56 AM

 

 

To: soa-rm-ra@lists.oasis-open.org RA

 

 

Subject: [soa-rm-ra] Can we skip Today's Meeting in favor of working on

 

 

reviews?

 

 

 

 

 

Hi Folks,

 

 

 

 

 

Since both Michael and I have presentations to make tomorrow and I am

 

 

hip deep in my review of our spec and making the single model of it in

 

 

Enterprise Architect, as well as getting another important specification

 

 

into the TC Administrator, I propose we skip today's meeting unless

 

 

there's a big reason to have it. I'll show up, and help make quorum, but

 

 

I need to dig into work.

 

 

 

 

 

Cheers,

 

 

Rex

 

 

 

 

 

---------------------------------------------------------------------

 

 

To unsubscribe, e-mail: soa-rm-ra-unsubscribe@lists.oasis-open.org

 

 

For additional commands, e-mail: soa-rm-ra-help@lists.oasis-open.org

 

 

 

 

 

 



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