1 / 16

SOA in Higher Education Workshop

SOA in Higher Education Workshop. Service-Oriented Architecture with Thomas Erl, SOA Systems Inc. University of British Columbia Vancouver BC Canada | 20-24 March 2006. Publisher’s Note. This is the first version of a Workshop summary prepared for review and discussion.

rtanaka
Download Presentation

SOA in Higher Education Workshop

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SOA in Higher EducationWorkshop Service-Oriented Architecture with Thomas Erl, SOA Systems Inc. University of British Columbia Vancouver BC Canada | 20-24 March 2006

  2. Publisher’s Note This is the first version of a Workshop summary prepared for review and discussion.

  3. An emerging consensus

  4. Service-Oriented Architecture • Service-oriented architecture (SOA) better supports the diversity and complexity of colleges and universities than the architecture of current academic and administrative systems. • SOA implemented using Open Standards and Web Services offers improved services for students and faculty, primarily by supporting changed and new business processes.

  5. SOA analysis and design • (Workshop facilitator) Thomas Erl recommended “top down” enterprise SOA analysis and design; participants agreed the results would offer improved benefits, but believe this is not now feasible because of institutional priorities and limited resources. • Erl suggested collaborative analysis and design should be explored with contributions from several institutions. • To achieve broader use of any analysis and design, diverse institutions should participate. The text was substantially changed by Mr. Erl.

  6. Business agility and IT flexibility • To achieve flexibility, effective SOA requires composable “layered” services, event and time-certain triggered workflow, and a “rules engine.” • Interoperability and its benefits require strict compliance with open standards for data representations.

  7. Business processes and analysts • The use of service-oriented architecture and the associated technologies—workflow, rules engines, and Internet messaging—encourages real-time processes supported by real-time exchanges of information, and changing business processes based on service composition, workflow and rules. • Many of these changes will be made by business analysts in business and academic units rather system analysts and computer programmers.

  8. Software development and support • Open standards SOA better supports shared development and reduces the development and maintenance costs of any localization. • Using open standards of Web Services, SOA can support .NET and Java environments and increasingly other programming languages.

  9. Risk: Maturity of specifications • Based on current trends, Erl believes the specifications for Web Services, including the WS-* “Extensions” are maturing and will be fully and broadly supported by commercial software suppliers within the next 12 or 18 months. • The risk of using Web Services technology is acceptable. There have been sufficient implementations of Web Services specifications to validate the technology, though some changes are expected. The text was substantially changed by Mr. Erl.

  10. OKI OSIDs • MIT’s OKI OSIDs (OKI Service Interface Definitions), as presented by Tom Coppeto and Scott Thorne, can complement Web Services as well as provide an alternative integration point. • Using widely adopted OSIDs in the design may improve interoperability.

  11. Sharing • Sufficient commonality of business processes, the flexibility permitted by workflow and rules and composition of services and the improved ability of localization permits sharing any software developed using SOA architecture. • Disciplined development following SOA analysis and design and the use of open standards increases the number of colleges and universities that could benefit from shared software development.

  12. Sources of software • Software developments such as learning systems—Bodington, Moodle, Olat, and Sakai—and finance—Kuali—demonstrate the willingness to collaborate and the potential to develop and sustain open source software • Unless commercial firms offer SOA open specifications software with new and agile business processes, higher education will have to development software supporting higher education.

  13. A student services system • Learning and research systems and the student system support “core” functions of higher education; “all else is context.” • Developing a new open source student system to meet the emerging requirements of transformation should be a high priority. • Private for-profit and commercial software firms should be included in any collaboration.

  14. Toward a new future

  15. Priorities • Technology demonstration projects to confirm the benefits and costs of service-oriented architecture. • Cross-institutional SOA analysis and design. • Collaborative development of an open-source student services system. • Concurrent development of specifications relevant only to higher education to supplement existing specifications and standards.

  16. Next steps • Identify potential partners • Coordinate with other organizations representing standards-development, related software development, and users. • Begin collaborative analysis and design with broad community and industry review.

More Related