Kuali Student Service System: Technical Architecture Phase 1 Recommendations

Total Page:16

File Type:pdf, Size:1020Kb

Kuali Student Service System: Technical Architecture Phase 1 Recommendations Kuali Student Service System Technical Architecture Phase 1 Recommendations Kuali Student Service System Technical Architecture Phase 1 Recommendations December 31 2007 Kuali Student Technical Team Technical Architecture Phase 1 deliverables 2/14/2008 1 Kuali Student Service System Technical Architecture Phase 1 Recommendations Table of Contents 1 OVERVIEW ........................................................................................................................ 4 1.1 REASON FOR THE INVESTIGATION ................................................................................... 4 1.2 SCOPE OF THE INVESTIGATION ....................................................................................... 4 1.3 METHODOLOGY OF THE INVESTIGATION .......................................................................... 4 1.4 CONCLUSIONS ............................................................................................................... 5 1.5 DECISIONS THAT HAVE BEEN DELAYED ............................................................................ 6 2 STANDARDS ..................................................................................................................... 7 2.1 INTRODUCTION .............................................................................................................. 7 2.2 W3C STANDARDS .......................................................................................................... 7 2.3 OASIS STANDARDS ....................................................................................................... 7 2.4 JAVA COMMUNITY STANDARDS ........................................................................................ 8 2.4.1 Java web services: JSR 222 and JSR 224............................................................ 8 2.4.2 JBI: JSR 208......................................................................................................... 8 2.4.3 Rules engine: JSR 94 ........................................................................................... 8 2.4.4 Portlets: JSR 286.................................................................................................. 8 3 THE PORTAL..................................................................................................................... 9 3.1 COMMENTS ON SELECTION ............................................................................................ 9 3.2 SELECTION CRITERIA AND EVALUATION .......................................................................... 9 3.2.1 Widespread adoption............................................................................................ 9 3.2.2 Community of interest........................................................................................... 9 3.2.3 Standards compliance .........................................................................................10 3.3 ISSUES .........................................................................................................................10 4 THE DATABASE...............................................................................................................11 4.1 COMMENTS ON SELECTION ...........................................................................................11 4.2 SELECTION CRITERIA AND EVALUATION .........................................................................11 4.3 ISSUES .........................................................................................................................12 5 SERVLET ENGINES .........................................................................................................13 5.1 COMMENTS ON SELECTION ...........................................................................................13 6 XML-JAVA BINDING.........................................................................................................14 6.1 COMMENTS ON SELECTION ...........................................................................................14 6.2 SELECTION CRITERIA AND EVALUATION .........................................................................14 6.3 ISSUES .........................................................................................................................14 6.3.1 Performance concerns.........................................................................................14 7 WEB-SERVICE ENGINES.................................................................................................16 7.1 REASONS FOR THE SELECTION ......................................................................................16 7.2 ISSUES .........................................................................................................................16 8 RULES ENGINES..............................................................................................................17 8.1 COMMENTS ON SELECTION ...........................................................................................17 Technical Architecture Phase 1 deliverables 2/14/2008 1 Kuali Student Service System Technical Architecture Phase 1 Recommendations 8.2 SELECTION CRITERIA AND EVALUATION .........................................................................17 8.3 ISSUES .........................................................................................................................18 8.4 FIGURE 1 – KS BRMS ..................................................................................................19 9 BPEL .................................................................................................................................20 9.1 SELECTION CRITERIA AND EVALUATION .........................................................................20 9.1.1 Potential Uses......................................................................................................21 9.2 ISSUES .........................................................................................................................21 10 ESB................................................................................................................................22 10.1 SELECTION CRITERIA AND EVALUATION ......................................................................22 10.1.1 Criteria.................................................................................................................22 10.1.2 Product Space .....................................................................................................22 10.1.3 WS-* Compatibility...............................................................................................23 10.2 COMMENTS ON SELECTION ........................................................................................24 10.3 ISSUES .....................................................................................................................24 11 TRANSACTIONS...........................................................................................................25 11.1 COMMENTS ON SELECTION ........................................................................................25 11.2 ISSUES .....................................................................................................................25 11.2.1 Mitigation .............................................................................................................25 11.2.2 Next Steps ...........................................................................................................26 12 WORKFLOW .................................................................................................................27 12.1 POSSIBLE INTEGRATION ISSUES .................................................................................27 12.2 INTEGRATION APPROACH ...........................................................................................27 12.3 POSSIBLE FURTHER ENHANCEMENTS ..........................................................................28 13 SWAPPABLE INFRASTRUCTURE...............................................................................29 13.1 WHAT DO WE MEAN BY “SWAPPABLE INFRASTRUCTURE ”? ............................................29 13.2 WHAT ARE THE MAIN DRIVERS BEHIND THE CONCEPT OF SWAPPABLE INFRASTRUCTURE ? 31 13.3 WHAT ARE THE CONSTRAINTS AROUND SWAPPING OUT DIFFERENT LAYERS OF THE INFRASTRUCTURE ? .................................................................................................................31 13.3.1 Operating system.................................................................................................31 13.3.2 Portal ...................................................................................................................32 13.3.3 Database .............................................................................................................32 13.3.4 Service engine layer ............................................................................................32 13.3.5 ESB .....................................................................................................................32 13.3.6 Workflow..............................................................................................................33 13.3.7 Rules engine........................................................................................................33 13.4 WHERE DOES RESPONSIBILITY LIE FOR TESTING ASSUMPTIONS ABOUT SWAPPABLE INFRASTRUCTURE ? .................................................................................................................34
Recommended publications
  • Apache Cxf Rest Service Example Bruzek
    Apache Cxf Rest Service Example Tad never paved any Akkadian intergrading unknowingly, is Aubrey light and resplendent enough? Knotty Lambert tattles some sigmoidectomy after antiodontalgic Tucker conceived aerobiotically. Nickie remains Sadducean after Iggie personifying inevitably or seek any chump. Running on creating the apache rest example if you run it all edits are capable of its recommended to create your browser go to learn apache cxf as the xml? Most english words and get a sample shows throwing exceptions occurred while the help? Easier than to use when the rest dsl will keep the operation on the spring configuration for connection. Dom elements or a spring or attenuate the default values into the classes. Control will generate a java or checkout with spring xml we mentioned before you progress through the methods. Invoked it is enabled and test but the dzone. Office be using your rest service which sends multiple endpoints. High force than to start with a rest service using the code to know to build the server? Trackers while you from apache cxf service example a rest service engine uses akismet to add user does the above. Easiest way to cxf rest service example a custom configured for tomcat? Zombie that the hostname the parts of all injection points are not going to download ibm liberty for communication. Help icon above json outputted in or conditions of the camel components and i motivate the camel! Diverts it so, cxf rest styled dsl consumes the steps to build the routing? Bean to generate the apache service which listens to be nice if set this option on the routes.
    [Show full text]
  • The State of the Feather
    The State of the Feather An Overview and Year In Review of The Apache Software Foundation The Overview • Not a replacement for “Behind the Scenes...” • To appreciate where we are - • Need to understand how we got here 2 In the beginning... • There was The Apache Group • But we needed a more formal and legal entity • Thus was born: The Apache Software Foundation (April/June 1999) • A non-profit, 501(c)3 Corporation • Governed by members - member based entity 3 “Hierarchies” Development Administrative PMC Members Committers Board Contributors Officers Patchers/Buggers Members Users 4 At the start • There were only 21 members • And 2 “projects”: httpd and Concom • All servers and services were donated 5 Today... • We have 227 members... • ~54 TLPs • ~25 Incubator podlings • Tons of committers (literally) 6 The only constant... • Has been Change (and Growth!) • Over the years, the ASF has adjusted to handle the increasing “administrative” aspects of the foundation • While remaining true to our goals and our beginnings 7 Handling growth • ASF dedicated to providing the infrastructure resources needed • Volunteers supplemented by contracted out SysAdmin • Paperwork handling supplemented by contracted out SecAssist • Accounting services as needed • Using pro-bono legal services 8 Staying true • Policy still firmly in the hands of the ASF • Use outsourced help where needed – Help volunteers, not replace them – Only for administrative efforts • Infrastructure itself is a service provided by the ASF • Board/Infra/etc exists so projects and people
    [Show full text]
  • SOA Using Open ESB, BPEL, and Netbeans” > Focus Is to Explain How WSDL, BPEL, JBI, Open ESB, Java EE Work Together
    SSOOAA uussiinngg OOppeenn EESSBB,, BBPPEELL,, aanndd NNeettBBeeaannss SSaanngg SShhiinn JJaavvaa TTeecchhnnoollooggyy EEvvaannggeelliisstt SSuunn MMiiccrroossyysstteemmss,, IInncc.. 1 Three Talks I Did on SOA Here • NetBeans Day: “Tools for Simplifying SOA” > Focus is to show how to use NetBeans for building a simple Composite application • GlassFish Day: “Open ESB and GlassFish” > Focus is to show more advanced features such as Intelligent Event Processing module for building a composite application • Sun Tech Day: “SOA using Open ESB, BPEL, and NetBeans” > Focus is to explain how WSDL, BPEL, JBI, Open ESB, Java EE work together 2 Agenda • Composite Applications • BPEL • Services • JBI • Java EE Service Engine • Open ESB • Open ESB runtime, tools, and sample apps • Demo 3 CCoommppoossiittee AApppplliiccaattiioonnss Traditional Application Development • Point technologies, products, and APIs > For example: EJB, Spring, Hibernate, JSF, Servlets, Struts, etc. • Lots of glue written by developers > Requires a great deal of expertise & time > Inflexible 5 Composite Applications • A way to compose applications from reusable parts • Composite applications employ SOA principles > Features exposed as Web services > Standards-based interaction between services > Are themselves composable 6 WWSSDDLL TTuuttoorriiaall ((OOppttiioonnaall PPrreesseennttaattiioonn)) Why WSDL? • Enables automation of communication details between communicating partners – Machines can read WSDL – Machines can invoke a service defined in WSDL • Discoverable through registry
    [Show full text]
  • Web Services CXF User Guide
    JBoss Enterprise Application Platform 5 Web Services CXF User Guide for use with JBoss Enterprise Application Platform 5 Edition 5.2.0 Last Updated: 2017-10-13 JBoss Enterprise Application Platform 5 Web Services CXF User Guide for use with JBoss Enterprise Application Platform 5 Edition 5.2.0 Alessio Soldano Edited by Elspeth Thorne Eva Kopalova Petr Penicka Rebecca Newton Russell Dickenson Scott Mumford Legal Notice Copyright © 2012 Red Hat, Inc. This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux ® is the registered trademark of Linus Torvalds in the United States and other countries. Java ® is a registered trademark of Oracle and/or its affiliates. XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. MySQL ® is a registered trademark of MySQL AB in the United States, the European Union and other countries. Node.js ® is an official trademark of Joyent.
    [Show full text]
  • Nimsoft Monitor
    Nimsoft Monitor SOAP Web Services Getting Started Guide Version 2.0 Legal Notices Copyright © 2012 CA. All rights reserved. Warranty The material contained in this document is provided "as is," and is subject to being changed, without notice, in future editions. Further, to the maximum extent permitted by applicable law, Nimsoft LLC disclaims all warranties, either express or implied, with regard to this manual and any information contained herein, including but not limited to the implied warranties of merchantability and fitness for a particular purpose. Nimsoft LLC shall not be liable for errors or for incidental or consequential damages in connection with the furnishing, use, or performance of this document or of any information contained herein. Should Nimsoft LLC and the user have a separate written agreement with warranty terms covering the material in this document that conflict with these terms, the warranty terms in the separate agreement shall control. Technology Licenses The hardware and/or software described in this document are furnished under a license and may be used or copied only in accordance with the terms of such license. No part of this manual may be reproduced in any form or by any means (including electronic storage and retrieval or translation into a foreign language) without prior agreement and written consent from Nimsoft LLC as governed by United States and international copyright laws. Restricted Rights Legend If software is for use in the performance of a U.S. Government prime contract or subcontract, Software is delivered and licensed as "Commercial computer software" as defined in DFAR 252.227-7014 (June 1995), or as a "commercial item" as defined in FAR 2.101(a) or as "Restricted computer software" as defined in FAR 52.227-19 (June 1987) or any equivalent agency regulation or contract clause.
    [Show full text]
  • Action-Based Study and Development of a Web Service Application in Java for METLA
    Prakash Sapkota Action-Based Study and Development of a Web Service Application in Java for METLA Helsinki Metropolia University of Applied Sciences Bachelor of Engineering Information Technology Bachelor’s Thesis 30 January 2014 Abstract Author Prakash Sapkota Title Action-Based Study and Development of a Web Service Appli- cation in Java for METLA Number of Pages 38 pages + 4 appendices Date 30 January 2014 Degree Bachelor of Engineering Degree Programme Information Technology Specialisation option Software Engineering Instructor(s) Mika Galkin, Senior System Analyst Sami Sainio, Lecturer The primary purpose of the thesis project was to carry out an action-based study of web services by developing a forestry related web service application for MetINFO. MetINFO is an information division of the Finnish Forest Research Institute (METLA). It provides various forest-related information services and tools in order to make forest- related information more visible and useful. The goal of the project was to develop a web service application which could be used by Finnish sawmills to upload their roundwood sales data to MetINFO. The uploaded data is used to calculate statistics about roundwood sales in Finland by different forestry centers and price areas. The development of the project involved various steps. Initially, the requirements of the application were analyzed. Based on the requirements, the application was designed and developed using feature-driven development methodology. As the outcome, fully function- ing web services for uploading roundwood sales data and a web based application for ad- ministering uploaded data were created. The developed application was tested in a test environment and all the known bugs were fixed.
    [Show full text]
  • Focus on Apache Camel 23 3.1 Classification
    Institute of Architecture of Application Systems University of Stuttgart Universitätsstraße 38 D–70569 Stuttgart Diploma Thesis No. 3480 Complete Enterprise Topologies with routing information of Enterprise Services Buses to enable Cloud-migration Andre Grund Course of Study: Software Engineering Examiner: Prof. Dr. Frank Leymann Supervisor: Dipl.-Inf. Tobias Binz Commenced: May 01, 2013 Completed: October 28, 2013 CR-Classification: E.1, K.6 Abstract The Enterprise Service Bus is an important part of todays enterprise IT landscape. It offers the integration of applications build on different platforms without adaptation. This is accomplished by offering message transformation and routing capabilities of client requests to the designated endpoint service. However, Enterprise Service Buses also introduce an additional indirection between the client and the called backend application. Enterprise Topology Graphs capture a snapshot of the whole enterprise IT and are used in various use cases for analysis, migration, adaptation, and optimization of IT. The focus of this work is to enhance the ETG model with structural and statistical information about an enterprise. However, due to the decoupled architecture the information is hidden inside the ESB and not directly accessible. Furthermore, the arrangement and semantics of the routing entities are unknown. The existing ETG Framework includes the automated discovery and maintenance of ETGs, but offers no solution for ESB components in the enterprise IT. This thesis provides an in depth analysis of the ESBs Apache Camel and Apache Synapse. It applies information gathering concepts and evaluate them with a prototypical implementation of an ETG Framework plugin. Using tailored information gathering and presentation methods to enhance ETGs with routing information.
    [Show full text]
  • SOA and Open Source
    SOA and Open Source Service Business Ma Consumers Systems Portals Web Apps M nageme onitorin g ance Business Process n nn Management t & Composite Services Gover CEP -CEP B AA SO Core Services Business AM Systems COTS Legacy Inhouse Magnus Larsson Callista Enterprise AB Vendor support of Open Source SOA • Vendors provide services for training, consulting and support on selected Open Source SOA products • MuleSource – Over 1000 mission-critical production installations worldwide! – http:// www.mu lesou rce .co m/custo me rs/casestud ies .p hp •WSO2 – http://wso2.com/about/whitepapers/ • Progress FUSE – http://fusesource.com/resources/collateral/ SOA and Open Source Copyright 2009, Callista Enterprise AB Building a SOA Reference Model… Service Business Portals Web Apps Consumers Systems Business Systems COTS Legacy Inhouse SOA and Open Source Copyright 2009, Callista Enterprise AB Building a SOA Reference Model… • Connectivity Service Business - SOAP, Rest, Messaging, Database, FTP… Portals Web Apps Consumers Systems • Transformation - XML, CSV, Fixed Position… • Routing - Header and/or Content based • Enterprise Integration Patterns - Splitting, Aggregation, Resequencing… Core Services Business Systems COTS Legacy Inhouse SOA and Open Source Copyright 2009, Callista Enterprise AB Building a SOA Reference Model… Composite Services Service Business Portals Web Apps Consumers Systems ‐ Course Grained ‐ Internal Messaging High performance access to other services CitComposite Services Core Services Business Systems COTS Legacy Inhouse SOA
    [Show full text]
  • Return of Organization Exempt from Income
    OMB No. 1545-0047 Return of Organization Exempt From Income Tax Form 990 Under section 501(c), 527, or 4947(a)(1) of the Internal Revenue Code (except black lung benefit trust or private foundation) Open to Public Department of the Treasury Internal Revenue Service The organization may have to use a copy of this return to satisfy state reporting requirements. Inspection A For the 2011 calendar year, or tax year beginning 5/1/2011 , and ending 4/30/2012 B Check if applicable: C Name of organization The Apache Software Foundation D Employer identification number Address change Doing Business As 47-0825376 Name change Number and street (or P.O. box if mail is not delivered to street address) Room/suite E Telephone number Initial return 1901 Munsey Drive (909) 374-9776 Terminated City or town, state or country, and ZIP + 4 Amended return Forest Hill MD 21050-2747 G Gross receipts $ 554,439 Application pending F Name and address of principal officer: H(a) Is this a group return for affiliates? Yes X No Jim Jagielski 1901 Munsey Drive, Forest Hill, MD 21050-2747 H(b) Are all affiliates included? Yes No I Tax-exempt status: X 501(c)(3) 501(c) ( ) (insert no.) 4947(a)(1) or 527 If "No," attach a list. (see instructions) J Website: http://www.apache.org/ H(c) Group exemption number K Form of organization: X Corporation Trust Association Other L Year of formation: 1999 M State of legal domicile: MD Part I Summary 1 Briefly describe the organization's mission or most significant activities: to provide open source software to the public that we sponsor free of charge 2 Check this box if the organization discontinued its operations or disposed of more than 25% of its net assets.
    [Show full text]
  • Architecture of Mule and Servicemix 42 3 ■ Setting up the Mule and Servicemix Environments 72 4 ■ the Foundation of an Integration Solution 111
    Open Source ESBs in Action Open Source ESBs in Action EXAMPLE IMPLEMENTATIONS IN MULE AND SERVICEMIX TIJS RADEMAKERS JOS DIRKSEN MANNING Greenwich (74° w. long.) For online information and ordering of this and other Manning books, please visit www.manning.com. The publisher offers discounts on this book when ordered in quantity. For more information, please contact: Special Sales Department Manning Publications Co. Sound View Court 3B Fax: (609) 877-8256 Greenwich, CT 06830 Email: [email protected] ©2009 by Manning Publications Co. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in the book, and Manning Publications was aware of a trademark claim, the designations have been printed in initial caps or all caps. Recognizing the importance of preserving what has been written, it is Manning’s policy to have the books we publish printed on acid-free paper, and we exert our best efforts to that end. Recognizing also our responsibility to conserve the resources of our planet, Manning books are printed on paper that is at least 15% recycled and processed elemental chlorine-free Development Editor: Jeff Bleil Manning Publications Co. Copyeditors: Liz Welch, Tiffany Taylor Sound View Court 3B Typesetter: Denis
    [Show full text]
  • Maîtriser Apache Jmeter Du Test De Charge À Devops
    Maîtriser Apache JMeter Du test de charge à Devops Antonio Gomes Rodrigues, Bruno Demion (Milamber) et Philippe Mouawad Ce livre est en vente à http://leanpub.com/maitriser-jmeter-du-test-de-charge-a-devops Version publiée le 2018-09-30 ISBN 978-2-9555036-1-4 Ce livre est publié par Leanpub. Leanpub permet aux auteurs et aux éditeurs de bénéficier du Lean Publishing. Lean Publishing consiste à publier à l’aide d’outils très simples de nombreuses itérations d’un livre électronique en cours de rédaction, d’obtenir des retours et commentaires des lecteurs afin d’améliorer le livre. © 2014 - 2018 Antonio Gomes Rodrigues, Bruno Demion (Milamber) et Philippe Mouawad Tweet ce livre ! S’il vous plaît aidez Antonio Gomes Rodrigues, Bruno Demion (Milamber) et Philippe Mouawad en parlant de ce livre sur Twitter ! Le tweet suggéré pour ce livre est : Je viens d’acheter Maîtriser Apache JMeter : Du test de charge à #Devops par @ra0077, @milamberspace, @philmdot sur https ://leanpub.com/maitriser-jmeter-du-test-de-charge-a-devops Le hashtag suggéré pour ce livre est #jmeter. Découvrez ce que les gens disent à propos du livre en cliquant sur ce lien pour rechercher ce hashtag sur Twitter : #jmeter Couverture et quatrième de couverture conçues par Cécile Platteeuw (C’grafic) Table des matières Droits ............................................ 1 Présentation des auteurs ................................ 2 Antonio Gomes Rodrigues ............................. 2 Bruno Demion (Milamber) ............................. 2 Philippe Mouawad (Philippe M.) ......................... 3 L’écosystème d’Apache JMeter ............................ 5 Introduction ...................................... 5 Plugin polyvalent ................................... 5 JMeter Plugins .................................. 5 JMeter dans le cloud ................................. 18 BlazeMeter .................................... 19 Tricentis Flood .................................. 23 Redline 13 ...................................
    [Show full text]
  • Proof of Concept Implementation of an Enterprise Service Bus for Health Information Exchanges
    PHILIPPINE ENGINEERING JOURNAL PC Zuñiga, et al 49 PEJ 2020; Vol. 41, No. 1: 49-66 Proof of Concept Implementation of an Enterprise Service Bus for Health Information Exchanges Philip Christian Zuniga, Joseph Benjamin Del Mundo, Edgardo Felizmenio, Marie Jo-anne Mendoza and Rose Ann Zuniga Computer Security Group, Department of Computer Science, University of the Philippines - Diliman Abstract – Integration of health systems is one of the biggest problem in eHealth today. There are a lot of systems, yet they were developed using different platforms and technologies, making them virtually impossible to connect. In this paper, we discussed how to implement an ESB as the integration platform for health data. We identified use cases and functional requirements. Logical and deployment architecture were developed, and an actual proof of concept of an ESB is developed. Experiments were also done to determine the overhead caused by the ESB. Some of the functionalities of the ESB were examined to determine their individual overheads. Keywords: Enterprise Service Bus, Interoperability, Health Information Exchange, OpenHIE. I. INTRODUCTION During the past few years, the healthcare industry has witnessed a growth in the development of Health Information Systems. Hospitals, both public and private, rural health clinics, and even individual clinics of medical practitioners have been developing or acquiring their own Electronic Medical Records (EMRs), and Hospital Information Systems (HIS). The goal of these systems is to ensure a secure, organized and effective way of collecting and storing patient data [1]. The increase in the number of edge applications leads to the increase of patient data that are stored separately and independently, depending on the application that collected the data.
    [Show full text]