...
| 7.1 Is SOA part of SDLC? | 7.2 If so, explain how | 7.3 SOA architectural artifacts? | 7.4 Version contracts during design? | 7.5 How do you publish contracts? | 7.6 What kinds of meta-data | 7.7 What message structures? |
---|---|---|---|---|---|---|---|
UBC | 1 |
|
| no | 1,3 | none | SOAP/REST/POX/RMI |
Michigan | 1 |
|
| n/a | 2,3 | none | SOAP/REST/POX |
Cornell | 1 |
|
| n/a | 1 | intended use | SOAP/REST |
Georgetown | 3 | Developers/implementers are aware of SOA technologies and encouraged to think in terms of re-usable services. There is no formal training or management of this however. | An enterprise ontology | yes | 2 | intended use | SOAP/REST |
UMUC | 2 | We have a stated design intent to build and identify re-usable services in our projects. We intend to implement an architectural review in our project design phase to catalog these services going forward. | We aspire to do service and functional decompositions in line with TOGAF architectural layers. | yes | 1, 2 | intended use | SOAP/REST/POX |
UofT | 2 | The developers are being initiated into Service Oriented Modelling and Architecture (SOMA). This is proving to be more difficult than we expected but progress is being made. | We don't have these as yet but we are developing architectural components that will address these concerns. | yes | Published in WSRR | Intended use, Glossaries | SOAP/POX |