You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »

1=Never
5=Consistently or well-established

 

5.1 Architectural reviews?

5.2 SOA included in reviews?

5.3 Processes for publishing contracts?

5.4 Change management process for contracts?

5.5 A central repository for service contracts?

5.6 Additional information on the management of service contracts

5.7 Has SOA changed your IT governance?

UBC

2

2

1

1

N

 

 

Michigan

2

2

1

1

N

 

 

Cornell

2

1

2

1

N

 

 

Georgetown

2

1

1

1

N

 

 

Ohio State

2

 

2

2

N

 

 


5.6

Michigan: We are currently working on a Directory of API project that will create a repository of web services and their meta data, which will include service level expectations.

Cornell: There is a Confluence wiki listing some of the service contracts. As we start up Oracle SOA Suite, Oracle Enterprise Repository and Oracle Service Registry, we will attempt to leverage the more-or-less automated features of these tools to improve the situation.

Ohio State
Currently maintaining spreadsheet/DB table. Also researching/evaluating Service Registry/Repository software

Cardiff
Characteristics of the interface to the Service. There may be more than one of these for any given Service.

  • Version
    • The version number of the interface, used to ensure the stability of the interface.
  • Endpoint(s)
    • Where the Service is exposed, e.g. the URL of the Service endpoint.
    • The protocol used by the endpoint, e.g. SOAP or REST.
    • The data-interchange format used by the endpoint, e.g. XML or JSON.
    • Any Service Level Agreements for this endpoint, for example:
      • Availability - any uptime guarantee or outage window
      • Timeliness - how "fresh" the data available via this endpoint is
  • Stability - this is a general control on whether the interface should be considered reliable or not; developers should undertake a Contract with the Service provider before consuming an interface that is not Committed. Categories likely to be:
    • Committed - the interface will not change across system developments or upgrades
    • Uncommitted/External - the interface is under internal development or is controlled by third parties (for example, an out-of-the-box Blackboard Service)
    • Not an Interface - this interface should not be used.
  • Data Classification - a general control on what level of protection the data available via this Service is subject to. The target way to do this may be to have this enforced by an ESB, but this may not be achievable in the short term. Categories may be:
    • Public
    • Mixed
    • Private
  • No labels