|
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 |