|
8.1 Is SOA part of SDLC? |
8.2 If so, explain how |
8.3 SOA architectural artifacts? |
8.4 Version contracts during design? |
8.5 How do you publish contracts? |
8.6 What kinds of meta-data |
8.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 |
1 |
n/a |
n/a |
n/a |
n/a |
n/a |
SOAP/REST |
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 |
UC-Irvine |
2 |
Applied if it hits the ARB. Some projects don't get to the ARB. |
Primarily for UCPATH. |
n/a |
Nothing formal |
|
|