Date: Fri, 29 Mar 2024 12:06:36 +0000 (UTC) Message-ID: <719394659.7931.1711713996057@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_7930_109373036.1711713996056" ------=_Part_7930_109373036.1711713996056 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
|
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 tech= nologies and encouraged to think in terms of re-usable services. There is n= o 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 i= dentify re-usable services in our projects. We intend to implement an archi= tectural review in our project design phase to catalog these services going= forward. |
We aspire to do service and functional decomp= ositions in line with TOGAF architectural layers. |
yes |
1, 2 | intended use |
SOAP/REST/POX |
UofT | 2 |
The developers are being initiated into Servi= ce 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 develop= ing 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 |
Washington |
3 |
Some projects like myPlan are very contract b=
ased |
Business capability maps are used in several =
domains |
yes |
1,3 |
Intended use, Glossaries |
SOAP/REST |
UW-Madison |
2 |
It is beginning to change our application arc= hitecture. We are beginning to partition responsibilities more cleanl= y with well defined interfaces. |
The beginnings of enterprise ontologies -- es= pecially as regards curricular data. |
Yes |
1 |
Assumptions, glossaries |
SOAP |
UC-Irvine |
2 |
Applied if it hits the ARB. Some projec= ts don't get to the ARB. |
Primarily for UCPATH. |
n/a |
Nothing formal |
|
|
Colorado |
2 |
SOA components utilize the same issue/bug tra= cking and change management processes as other software components |
Not yet |
yes |
XML Schema |
Intended use |
SOAP/REST |
Indiana |
4 |
Many of our systems take advantage of service= s that are provided by the enterprise. So part of the SDLC is to integrate = and test with services which are needed by the applications. |
Not really |
yes |
XML Schema, |
|
SOAP/REST/POX |