[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm-ra] about NCOIC Service Interface Pattern
+-1 Interface stability is more about design than anything else (technology,
implementation, etc). And by the way there are certain architectural approaches
for implementing stable interfaces. For example – adding optional parameter to the interface
does not change it, while switching parameter from optional to mandatory does.
Removing parameter (even optional) from the interface changes it. So, the list that Michael pointing does not ensure stable
interface – proper interface design approaches do. From: Ken Laskey
[mailto:klaskey@mitre.org] +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] 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----- Hi Guys, 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. The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it from your computer or paper files. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]