...
| 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 |
MIT |
|
|
|
|
|
|
|
UW |
| Some projects like myPlan are very contract based | Business capability maps are used in several domains | yes | 1,3 | Intended use, Glossaries | SOAP/REST |
UW-M | 2 | It is beginning to change our application architecture. We are beginning to partition responsibilities more cleanly with well defined interfaces. | The beginnings of enterprise ontologies -- especially as regards curricular data. | Yes | 1 | Assumptions, glossaries | SOAP |