View Presentation
Upcoming SlideShare
Loading in...5
×
 

View Presentation

on

  • 339 views

 

Statistics

Views

Total Views
339
Views on SlideShare
339
Embed Views
0

Actions

Likes
0
Downloads
4
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Humble in that this is not glamorous work. We are simply running the business of the institution. “Community source” – looking for like-minded partners for collaboration. Leveraging our resources while meeting our specific needs that may not be getting addressed by off-the-shelf software. Great thing about working in higher ed. We all have similar problems. Let’s work together to solve them. Do the math.
  • Proposed architecture
  • Loosely coupled allows flexibility – unlike CORBA which is a more tightly coupled interface Not such a fine level of granularity An application doesn't have to know the details of another application to talk to it. SOA is a higher level of application development (coarse granularity). By Focusing on business processes and using standard APIs, SOA masks the complexity and leverages IT assets.
  • Presentation Layer Handles request/response actions and UI rendering Formatting and non-business related validation logic Handles exceptions Web access via HTTP (Struts/JSTL or possibly Java Server Faces (JSF)?) Rich client possibilities: Eclipse RCP, Java WebStart, Laszlo, Spring remoting connects local objects with remote objects over HTTP, etc Apache2 Webservers, load balanced, MOD-JK2 communication between Tomcat and Apache Tomcat Web App servers, serve dynamic web requests, serve dynamic spring remoting requests Struts/JSF Action Classes and Beans DEFAULT Spring Object Remoting (JAVA) Business Layer Contains business objects that are used across persistence and presentation layers Relationships between Domain Objects Independent Business Logic components and services Use Spring as appropriate Leverage existing business logic assets Business module interfaces (Spring/JSF (?) Action Classes and Beans or Spring Object Remoting) Persistence Layer Communicates consistently with persistence store (relational database, ldap, etc) Data Access Object (DAO) implementations. Default DAO implementation: Spring/OJB J2EE Connector Architecture (JCA) allowing multiple databases/multiple platforms DAO interfaces (Java) hide the data source implementations from the clients
  • Creates a reusable set of “assets” for future projects as well as leveraging existing “assets” Focus on long-term benefits!
  • Less complexity in the code. Easier to achieve true Enterprise Application Integration (EAI) It has always been sort of the “ideal goal” or “holy grail” to be able to build applications by reusing a number of previously built components. It is much easier said than done. Communication across all development areas is key. In addition, reusing a service must be easier than building from scratch. Developers must learn to trust the code of others or fix it themselves. We have learned from previous attempts at this
  • Proposed methodology
  • A lot of people have had success with these kinds of formal methodologies. We haven’t seen it work at IU. What is our real goal here? We are trying to build and deliver functional software that does what it is supposed to do, is reliable, and is easy to maintain.
  • Documentation is nice. All sorts of deliverables with diagrams, spreadsheets, etc are good too. However, are these more important than the software itself?
  • Show the users prototypes, mockups, or early versions of how the software will work. This works and allows you to make progress on the software development.
  • Keeps our REAL goal in mind but with a more practical approach.
  • Developer focuses on what code is supposed to do
  • A growing set of tests that allow you to know when you break code written 6 mos. Ago
  • Key points – flexibility for dealing with change, focusing on our REAL objectives, iterative approach dealing with smaller “chunks” of code and functionality. It may take more time to develop this way but the long term benefits with regard to future release, production support, and maintenance are the payoff. Difficult to see this when we are often driven by short-term deliverables.
  • Other considerations? Hibernate instead of OJB? We know OJB and are experienced with it. So, we need to evaluate the benefits of Hibernate versus the cost of switching all of our developers over. JSF? Does JSF give us enough benefit to move away from Struts? Same type of cost/benefit evaluation needs to take place. Spring facilitates good programming practices which is ideal in a framework. Spring can provide a nice alternative to EJB. Spring provides a consistent framework for data access.
  • What sticks out in this slide? Oracle. All current core Kuali schools are Oracle schools and want to use Oracle as their backend database. That said, we are going to avoid things like triggers, stored procedures, and particular data types that are dependent on a specific proprietary technology. The idea is that any database should be able to be plugged in. It is hoped that future versions of MySQL will be just as robust as Oracle.
  • Currently, we have our own homegrown portal called OneStart. We are looking at migrating to uPortal 3.0. Ideally, would be portal independent so that Kuali can work in any standards-based portal.
  • for approval, completion, FYI, or acknowledgement Provide consistency across applications for applying business rules of our institution.
  • Currently processing eDocs for HRMS ERA – pre/post award administration Purchasing Future eDocs Travel authorizations and reimbursements Enterprise data access permissions K uali applications
  • Some people want themselves in the loop until they get bombarded by documents. May decide it isn’t necessary. No one wants to be “Bottleneck Bill”. We still route a lot of paper and many of the routing paths are very inefficient. We may pave the cowpaths at first. However, once it is in place, you can begin to see the inefficiencies in the process.

View Presentation View Presentation Presentation Transcript

  • Kuali Project Architecture JA-SIG December 7, 2004 James Thomas Manager, Systems Integration Indiana University
  • Session Agenda
    • Kuali Project Overview (brief)
    • Service Oriented Architecture
    • Kuali Development Methodology
    • Standard Tools and Frameworks
    • Key Infrastructure: Portal & Workflow
  • Kuali Project Overview
  • Overview
    • Kuali – kitchen wok; humble utensil
    • Community Source Project
    See www.kualiproject.org for details
  • Overview
    • Develop a comprehensive suite of financial software to serve the needs of higher education . Modules include:
    • Chart of Accounts Purchasing
    • General Ledger Accounts Payable
    • General Accounting Cash Receipting/Disbursement
    • Accounts Receivable Travel Req/Reimbursement
    • Capital Asset Mgmnt E-Commerce
    • Pre/Post-Award Admin Budget Construction
    • Auxiliary Accounting Workflow (infrastructure)
  • Overview
    • Project Status
    • Work has already begun
    • “Official” kickoff in January 2005
    • Two-year development plan
  • Kuali Project Architecture
  • Architecture
    • Key Objectives
    • Design highly functional and flexible software
    • Technology choices based on industry standard, open source, and “proven” solutions
    • Deliver applications via loosely-coupled components and services with clearly defined APIs
    • Leverage core “IT assets”
    • Emphasize code re-use/reduce redundancy
  • Architecture
    • Service Oriented Architecture (SOA)
    • Services are loosely coupled .
    • Services have well-defined interfaces and are reusable .
    • Focus on business processes
  •  
  • Architecture
    • Benefits of SOA
    • Improved ROI – some reusable components will outlive applications
    • Easier to maintain code base
    • Code Mobility
  • Architecture
    • Benefits of SOA (continued)
    • Can support multiple clients - browser or
    • “ rich client”
    • Services can be assembled to build new applications faster
    • Independent layers make development by different groups easier using standard APIs
  • Kuali Development Methodology
  • Methodology
    • Problems with previous methodologies
    • Process driven
    • Difficult to keep up with changes
    • Time consuming
    • Inefficient
    • Sometimes less than satisfactory results
    • Inflexible – requirements do change
  • Methodology
    • What’s wrong with this picture?
    • Where is our focus?
    • Our goal is to develop software that works for our customers
  • Methodology
    • Development Methodology for delivering working software
    • Flexible (b/c the only certainty is change )
    • Efficient
    • Results-Oriented
    • People-Centered
    • Feedback Driven
    • Sustainable
  • Methodology
    • Strategy
    • Plan for shorter development cycles
    • Embrace change
    • Developers and functional experts should work together continuously
    • Open communication
    • Quality software builds trust and faith
    • Keep it simple/avoid over-engineering
  • Methodology
    • One Possibility: Test-Driven Development (TDD)
    • TDD is a lightweight methodology emphasizing fast, incremental development and writing tests before writing code
    • Start with small pieces of functionality and then build the app little-by-little (red/green/refactor)
  • Methodology
    • Benefits of TDD
    • Code that works!
    • Immediate feedback on design decisions
    • Flexibility
    • Users provide input “as you go”
    • Confident programmers
    • Fully testable code base
    • Clean and maintainable code
  • Methodology
    • Exploring other concepts from
    • Agile Processes
    • Extreme Programming (XP)
    • Learning and adapting as we go
    • Like the results thus far
  • Kuali Standard Tools and Frameworks
  • Tools/Frameworks
    • Standards
    • Java 2 Enterprise Edition (J2EE)
    • XML/XSLT
    • Tools/Frameworks
    • Struts/JSTL
    • Spring
    • Object Relational Bridge (OJB)
    • jUnit and jMeter
    • Log4J
  • Platforms
    • Web Server: Linux, Apache
    • Application Server: Linux, Tomcat 5
    • DBMS: Oracle
    * *avoiding triggers, stored procedures, proprietary data types, etc. in order to achieve database independence
  • Key Kuali Infrastructure Portal & Workflow
  • Enterprise Portal
    • Kuali services will be designed to be delivered via a standard enterprise portal framework
    • Access to “Action List” service for managing electronic transactions (eDocs) via enterprise workflow
  • Power of Workflow
    • A general-purpose infrastructure for conducting mediated transactions with electronic documents (eDocs)
    • Quick, easy, and accurate routing
    • Automate University business rules
    • Complete Audit Trail
  • OneStart Workflow
    • EXAMPLE:
    • OneStart Workflow is currently routing over 1,800 eDocs/day and 55,000/mo
    • Human Resources eDocs previously requiring 1 to 2 weeks to process have been approved in < 1 hour
    • 38 different types of eDocs from 3 diff apps
  • Workflow Lessons
    • Causes re-evaluation of current business processes. Are they efficient?
    • No more “Bottleneck Bills”. 
    • We see Workflow…
    • … everywhere!
  • Conclusions
  • Conclusions
    • Kuali Partners are committed to:
    • Community Source Software
    • Service Oriented Architecture
    • Iterative and Flexible Methodology
    • Open Standards
    • Enterprise Application Integration
  • Conclusion
    • We are genuinely excited about the challenges and the possibilities!!!
  • Want technical details?
    • Attend this session TODAY (12/7/04):
    • “ Pragmatic Application Building: Step-By-Step”
    • Build IT Track
    • 2:00 to 3:00PM
    • Presenter: Jay Sissom
    • Indiana University
  • Questions?
    • James Thomas
    • Manager, Systems Integration
    • University Information Systems
    • Indiana University
    • [email_address]