The Ohio State University – OCIO Enterprise Architecture
Architecture Decision Document
DRAFT – Web Services Implementation
Document creation date:
Revision
Number
1
2
3
03/25/2011
Revision
Date
Summary of changes:
03/25/11 Initial Draft – Glenn E. Donaldson Jr.
03/30/11 Minor edits; added supporting information via attachment (Capabilities summary;
Pros/Cons…)
Architectural
Decision
Issue or
Problem
Alternatives
Decision
Integration Architecture: Implement Web
Services w/ SOAP, REST, or Both
AD ID <<A unique identifier>>
The primary ways to implement web services: Simple Object Access Protocol (SOAP)/WS-
* based implementations and/or Representational State Transfer (REST)-based implementations. We need to determine if we support one way or both when developing web services.
Note: The Simple Object Access Protocol name has been dropped. It is simply SOAP. SOAP 1.2 was the adopted as a standard by W3C in 2003. WS-* represent the multiple web service specifications
1. Only support SOAP-based web services
2. Only support REST-based web services
3. Support SOAP and REST –based Web Services along with implementation/usage guidelines
Alternative #3 – Support SOAP and/or REST based web services along with implementation/usage guidelines
Glenn E. Donaldson Jr. Page 1

Justification
Assumptions
The Ohio State University – OCIO Enterprise Architecture
Architecture Decision Document
DRAFT – Web Services Implementation
A key issue is technologists misunderstanding the difference between SOAP and REST.
SOAP is a messaging framework while REST is an architectural style. Other standard web technologies and methods (HTTP/S , AJAX, JSON ...) are used to implement REST-based
(web) services. Because of this, both implementations should be supported and the decision of which one should be based on the use case(s), source(s), and target(s).
For further justification read below:
 Both SOAP w/ WS-* and REST have value
 PeopleSoft ERPs (HR/SIS, FIN) only supports SOAP/WS-*-based web services.
 Both SOAP/WS-* and REST-based web services are used by major IT companies
(Amazon, Google…).
 The regular and mobile web applications do not only consume secure and/or transactional services. They also consume RSS feeds and other public/open data services. (i.e. Find people, maps, or sports information)
 SOAP is about exposing named operations; REST is for exposing named resources
 SOAP is good for transactional (Support for distributed ACID transactions) or logicbased web services, using SOAP for read-only data web services could be overkill.
REST may be the optimal choice.
 RESTful web services are based standard HTTP/S and URI specifications, and the HTTP
Verbs (GET, PUT, DELETE, and POST).
 RESTful web services are simple to implement and can be cached ( this can help with performance and scalability)
 SOAP is not only possible over HTTP transport. SOAP can be used the SMTP and JMS transport protocols.
 There is good support for both SOAP/WS-* and REST in Java EE, .NET, other frameworks
 Future State: the prominent Enterprise Services Buses (ESBs) supports both SOAP and
REST
 The solution for a web service (SOAP or REST) depends on the use case, source(s), and target(s)
 There is a need for guidance around developing web services
 There are needs for multiple types of web services (public/private, data/logic, browser clients/systems…)
 While the first sprint of the Integration Architecture initiative will focus on OCIO, our future state will involve our partners across the university community.
 PeopleSoft ERP environments only supports SOAP/WS-*-based web services, there are other systems/environments providing REST-based web services
Glenn E. Donaldson Jr. Page 2

Motivation
The Ohio State University – OCIO Enterprise Architecture
Architecture Decision Document
DRAFT – Web Services Implementation
 Knowing what options are available and what will be supported will help in making solution decisions
 OCIO and partners are embarking on Integration Architecture and specifically web services
 There are no OCIO guidelines in place to help development or infrastructure
 Guidelines and standards will promote consistency across the decentralized development groups especially for integration activities.
Implications  The capabilities of the producer and consumer
 The security protocols used
 The amount of development needed
Ensure business alignment is an
imperative.
Information is an
enterprise asset.
Does the investment and capability align with the university needs or requirements and strategies? Does it align with similar functions across the institution?
None of these alternatives directly impacts Business alignment
Does the data support accelerating decision making? Does the information asset allow appropriate university wide access? Is the information asset a critical institutional asset?
None of these alternatives directly impacts use of data in the enterprise.
Manage enterprise assets through the entire
life cycle.
What is the total cost of ownership
(implementation, ongoing maintenance and support, refresh)? What is life of the product? What is the current and projected demand over the next 5 years?
The cost comes from designing, developing, and managing web services and any additional software/hardware needed for support. SOAP and REST by themselves do not add costs directly.
Standardize, rationalize, componentize, encapsulate, and
interoperate .
Does the product replace or eliminate other products? Are there similar products in use or planned for use elsewhere on campus? Does the product fill a gap? Does the product duplicate all or part the functionality of another product? Does the product seamlessly
Both SOAP and REST based web services are either developed or delivered. Therefore, they do not replace or eliminate other products.
The gap being filled is the need for
Glenn E. Donaldson Jr. Page 3

Ensure effective
compliance.
The Ohio State University – OCIO Enterprise Architecture
Architecture Decision Document
DRAFT – Web Services Implementation integrate with other components? Does the product meet open systems standards? more web/data services. Web
Services, which are based on SOAP and/or REST, are to help the goal of providing improved methods of application and system integration.
SOAP 1.2 is a standard supported by W3C. REST is not a standard, but the technologies used to provide REST are based on open system standards (i.e. HTTP/S….)
Is the product compliant with legal and regulatory requirements? How will the product affect internal or external auditability of the business unit? Is the product compliant with the OSU IT security framework?
None of these alternatives directly impacts compliance
Glenn E. Donaldson Jr. Page 4