1. From Services to SOA at Berkeley
CSG - Sept 25, 2008
Berkeley has been writing web services for the last 8 years, but they were not structured, not documented, not inventoried, not reviewed, and limitedly shared. They were done on demand, not part of a bigger plan.
SOA is the next step for us. Our hope is SOA along with building a “Campus IT Community” and Campus Developer Support will enable
a) FLEXIBILITY by allowing IT-by-composition,
b) Composition over reinvention enabling SPEED,
c) Thoughtful methodology, tool, and platform selection enable QUALITY.

2. From Services to SOA at Berkeley
CSG - Sept 25, 2008
THE SOFTWARE GOAL: Quality, Speed, Flexibility.
THE TRENDS:
Increasingly complex and changing business processes.
Increasingly tech savvy business partners.
Increase dept/unit development of mission critical systems.
Decrease in resources while increase in IT demands.
THE CHALLENGE :
How to get UC Berkeley from a set of unorganized, unstructured web services to SOA?
We need help. We don’t have the right experience or enough of the right resources.
Berkeley became Kuali Student Founder July, 2007.

3. We Got FIRST RATE Help
CSG - Sept 25, 2008
UCB gave 2 of 4 Central App architects to Kuali ...
We benefit from the effort of 12 architects & several senior java developers.
Of special note:
Leo Fermin, UBC
Scot Gibson, UMd
Wil Johnson, FSU
For the next phase we are looking for developers:
At least 3 years Java experience (Sun Java certification an asset).
Familiarity with Spring IOC and AOP.
Familiarity with ORM concepts and JPA in particular
(preferably the hibernate implementation).
Advantageous if they have worked with Eclipse and SVN.
Knowledge of  XML, XSD, WSDL, SOAP.

4. From Services to SOA By Leveraging Kuali
KS - July, 2007
Kuali Student is...
Being developed through a community source process over 5 years.
Will deliver through a Standards-based (open, widely accepted, adopted), Service-oriented architecture utilizing web services.
Leverages Open Source Technology (Open source software stack & java).
Modular and relies on Component Abstraction of Business Processes & Rules and Presentation & Data layers.
Rules & logic will not be in code (use rules/workflow engines).
Tier 1 Apps (first 5 years) include: Learning Unit Management, Enrollment, Person Identity, Student Financials, Program Audit & Evaluation, Limited Concierge, Application connectors, Configuration application
Tier 2 Apps include: Admissions, Scheduling, Financial Aid, Concierge

5. KS Services – Release 1 LUM
KS - Jan 1, 2008
*Authentication Service Learning Result Catalog Service
*Authorization Service LUI Person Relation Service
AZ Group Service LU Service
*Business Rules Management Service Organization Service
Communication Service Person Service
Contact Service Resource Service
Deprecated Service Descriptions Rule Repository Service
*Dictionary Service *Search Service
Fact Finder Service *Workflow Service
Learning Objective Service
* Business Agnostic Services, service contracts close to final, coding started. “Developers got anxious”.
** Service performance a concern so QA team has been working on enrollment service for Enrollment Module that has not be officially started.

6. Technical Architecture Web Services Stack Recommendations
Kuali Student Technical Architecture Web Services Stack Recommendations
KS - Jan 1, 2008
- uPortal
- KRice ?
- KS BRMS
- Apache CXF/Sun Metro
- CAS, Acegi
- Kuali Id Mgmt (KIM)‏
- JBoss Drools
We’re going to switch tracks a bit and talk about our technical architecture.
We started with 10 guiding principles that are fundamental to our vision.
The first 4 are about Service Orientation:
A Service Oriented Architecture using Web Services – because the services are autonomous, re-usable and loosely coupled, they’re easier to implement and maintain.
Published Service Contracts & Standards – to allow the community to easily contribute to the product development while still ensuring the quality of the result.
The next 3 are about Component Abstraction:
Abstraction of the presentation layer from the application logic give us a Flexible User Interface which enables each institution to customize the presentation of the system through their user portal.
Abstraction of the Data Model, along with Rules-based Business & Process Logic – enables the system to support a wide range of learners and learning activities in a variety of institutions. It can be configured at implementation time to satisfy the specific business processes and requirements of each institution.
As a result of this abstraction, we will deliver Kuali Student with a Reference Implementation. Kuali Student will be distributed with standard data models and business processes pre-configured. A ‘copy and modify’ approach will speed the implementation process.
And lastly, we will leverage open source technology:
Kuali Student will be built entirely on open source software infrastructure stack so the reference implementation can be downloaded without any licensing fees. All licenses will be compatible with the Educational Community License issued through the Kuali Foundation.
- Apache ServiceMix
- Sun OpenESB
- Kuali Enterprise Workflow (KEW)‏
- Apache Derby
*Certified MySQL & Oracle
Phase I Recommendations found at: 6

7. KS & Rice Planned Alignment
KS - Jan 1, 2008
KS & Rice Planned Alignment
Google Web Toolkit
uPortal 3.0 UI
Id Mgmt:
KIM
Workflow:
KEW
Rules:
BRMS
Dictionary, Search:
KNS
Middleware
Code Mgmt:
Subversion
Build:
Maven
Unit Test:
JUnit
Eclipse
Workbench
JPA:
Hibernate
JAXB
JAX-WS
Mapping
Frameworks
DB:
Derby
Service Eng:
CXF/Metro
Servlet:
Tomcat
ESB:
ServiceMix
Rules Eng:
Drools
Technology
Stack

8. SOA Challenges at Berkeley
CSG - Sept 25, 2008
Semantic Interoperability – We don’t speak the same language (GPA, Student Registered/Enrolled, Chart String)
Culture NIH (NOT INVENTED HERE)/NUMC (NOT UNDER MY CONTROL), Architecture/Technical Religious wars (.net/java, REST/SOAP).
Business Processes Non-standard or Non-alignment (examples-UG & Grad Adm applic, grade submission)
Funding and Resourcing Models
Staffing
New Skill Sets (BusAnalyst, SOA, UI experts, )‏
A fresh look
Back Filling Key Positions
BUSINESS ANALYSTS are rarer than we thought
To succeed it is not about “central resources”,
it is about “campus resources”.

9. Campus Developer’s Community & Support
CSG - Sept 25, 2008
Process and methodology
Toolsets
Technology Stacks
Components & Services
Automated Test Frameworks
Automated Deployment Scripts
Training (“How to” Websites, Book Club, Recommended Readings, Online courses, Pilot Projects, Mentors, Internships, ITAC)
Prototypes
Code review
Security audit

10. SOA Challenges at Berkeley
CSG - Sept 25, 2008
Immature Technologies - (Or did not live up to the vision). BPEL
SOA is not about a Particular Technology - Processes
SOA has a lot of pieces, development is in pieces -
What will bring this all together?
SOA is a different way to design systems - Loose coupling
Loose coupling vs Performance – Example Enrollment
- Communication Synchronous (Tight) vs Asynchronous (Loose)
- Transactionality Two phase commit (Tight) vs Compensation (Loose)
Implementation Readiness
Governance
Resources (Where are all the Business Analysts???)
Interfaces New and Old
Will the vendors get there? (Parviz Dousti– CMU)

11. Getting out of our rut – Taking several steps back
Biggest Challenge
CSG - Sept 25, 2008
Getting out of our rut – Taking several steps back
How we do our business.
What are we really trying to achieve?
How we develop our systems.
How is a SOA system design different?
Our new roles. Who does what?

12. SOA Closing Thought…. Your Thoughts?
CSG - Sept 25, 2008
"In theory there is no difference between
theory and practice.
But, in practice, there is.“
Yogi Berra