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] about NCOIC Service Interface Pattern


Michael, Ken, Everyone,

The NCOIC Interface Pattern is intended to be implemented at the solution level, so this particular pattern is aimed at the operational level, e.g. about 95% concrete, and 100% NCOIC-specific because the next most concrete step in the process is developing and testing a NCOIC "Building Block" such as an interface to an app for a smart phone. So this crosses over into the entirely concrete level of abstraction.  From our point of view, it is a solution architecture component.

Everyone, I decided not to share this with everyone because the next version will be the approved version, which I can share without adding the "work in progress" disclaimer. This is interesting because it is so "management" and "governance"oriented. Note we were still making significant changes from the very last batch of change requests last week.

Cheers,
Rex

On 3/27/11 9:46 AM, Ken Laskey wrote:
058001cbec9e$755df1b0$6019d510$@org" type="cite">

+1

 

An example of a stable interface is one we specified for a Deliver component: inputs are the package to deliver, the address where to deliver, and a properties set that can convey the required conditions for delivery.  The property set could (details still being worked) conform to an XML schema (or other formalism) and would begin with something identifying the schema, etc. being used.  If new conditions are required over time, you update the schema.  It is up to the receiver to adequately understand and comply with the properties or return appropriate faults if that is not possible.

 

Note, this is completely independent of SLAs, governance policy, etc.  Such things may have bearing on how a conformant service is designed and operated, but this is separate from the design and implementation of the stable interface.

 

Ken

 

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

Dr. Kenneth Laskey

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

7515 Colshire Drive                                    fax:        703-983-1379

McLean VA 22102-7508

 

From: mpoulin@usa.com [mailto:mpoulin@usa.com]
Sent: Sunday, March 27, 2011 12:12 PM
To: rexb@starbourne.com; soa-rm-ra@lists.oasis-open.org
Subject: [soa-rm-ra] about NCOIC Service Interface Pattern

 

Rex,

this is so hot topic that I could not resist looking into it briefly. I read, probably 1% of the material but it's happened that Interface Stability  just jumped into my eyes:

 

2.4.9    Interface Stability {SOA}[1]

To achieve interface stability through design, the following SOA structure requirements apply:

a.   Service Level Agreements (SLA)s or equivalently named contractual instruments shall contain Explicit Operational Agreements.

b.   Explicit Operational Agreements shall contain interface definitions.

c.   Explicit Operational Agreements should contain a governance policy

d.   The authentication and authoritization process for who can examine published contracts shall be standards based..

e.   Interface artifacts shall be published in a registry/repository or other object, e.g., ESB.

f.    Interface Definitions shall be standards based, e.g., WSDL, XSD, etc.

g.   The SLA shall contain performance characteristics associated with each interface.

h.   SLAs shall be maintained between the Provider and individual Consumers or classes of Consumer

i.    Versioning processes may be contained in a separately defined governance process.  Governance principles are described in the NCSF.  A NCOIC governance pattern is under consideration.

 

To my taste, copied content has almost nothing to do with "Interface Stability". I think that stability of service interface is about how the interface can work in the changing environment, changing behaviour model and related messages. For example, Interface Definitions shall be standards based, e.g., WSDL, XSD, etc" does not contribute into the stability, IMO, because someone may (should not be restricted from) publish (ing) a non-standardised but immutable (100% stable) interface. Moreover, common (not thought through) use of WSDL leads to constant changes if the interface, i.e. minimal stability. In the essence, it is not a standardisation that important, but the usability pattern is important. And the latter has escaped aforementioned list.

 

An example of interface stability: 'adding or removing data elements of the exchange messages should not result in the change of interface'. I can say the same thing regarding the operations and use WSDL (in a smart way) to implement this.

 

Anyway, thank you very much for such interesting material.

 

- Michael

 

 

 

-----Original Message-----
From: Rex Brooks <rexb@starbourne.com>
To: mpoulin@usa.com; 'Ken Laskey' <klaskey@mitre.org>
Sent: Wed, Mar 23, 2011 3:30 pm
Subject: Re: [soa-rm-ra] meeting time conflict

Hi Guys,

I didn't send the redline version and waited for this latest clean version of the NCOIC Service Interface Pattern. I'm not suggesting you go through this in detail to ensure that the principles espoused in Sections 4 and 5 are actually taken up in this document, but you could if you wanted to do that. However, I think this provides a fairly good example of what can be expected of "Testing" with "Management" in mind. Please do not redistribute despite the fact that it is not strictly disallowed. I send it to you two because I think it bears on finishing up your work. Sorry if it's a bit late. Reminder: This is still a work in progress and this is not yet approved, but it is likely to be approved.

Cheers,
Rex

On 3/23/11 4:05 AM, mpoulin@usa.com wrote:

Hi Folks,

 

I will have a conflict of meetings today: I will be able (now) to participate in the first and the last 30 min time-windows only. Please, plan my presentation on the Management Model accordingly.

Sorry,

- Michael



-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670


[1] SOA (Service Oriented Architecture), NC(net centric),  & SW(software) are solution categories.  They are used  here to map  the solutions in sections 2.4 and 2.5 to these categories.  See Appendix C, section 5.3 for a summary of this mapping.



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