Michael Gettes, MIT – Approaching SOA as Service Oriented Applications. MAP (the MIT Application Platform) includes language stacks for both Java, looking at PHP, nothing to prevent others. WEb services so far: MIT ID (query / create), PersonLookup, Geo (look up zip codes), Roles, Groups, Textbook, Course Catalog, Who’s Teaching What, Events Calendar, COEUS
ESB: Threat or Menace? Apps can now blame the ESB provider when things break – are we just moving the blame?
Parvis Dousti, Carnegie Mellon – Student Services at Cernegie Mellon
– Tried writing it in J2EE, then heard about Kuali Student and fell in love with that, but before that looked at ERP choices – decided that wouldn’t do it.
– Phase 1, worked with IBM who helped with Business Process Modeling. About 500 service candidates came out of that. Asked the question of “Is the world ready for us? (are the pieces out there if you don’t have to write it all yourselves). Answer is not really, so slowed down project, defining six tracks: 1. Build a solution for only 2 business processes; 2. Migration strategies; 3. Build a governance modela nd insfrastructure; 4. Re-engage with Kuali Student; 5. Ongoing
2 Processes – Student Billing & Account Aging
Are we ready for SOA? Skills, and Organization (relationship of IT and Business domains).
Elazar Harel – UCSD
SOA Framework at UCSD
Drivers – Agility and growth, faster development and deployment, product consistency, performance, integration, technology independence and neutrality.
Been about 8 years since they started SOA development. Moved to Java in year 2000, but had five years of legacy web code. Built a JLink framework, starting with common look and feel across central apps. Wanted to have a SSO environment. Also have legacy mainframe apps and wanted a lightweight bus to that. In 2003 started working with SOAP and building web services to mainframe. Also built a graphical tool to allow developers to create web services. Implemented SHib for SSO, and a simple workflow product called My Approvals, and in 2005 a lightweight service bus, and last year introduced roles.
Identity management – Authentication, People, and Roles.
Future – want to get away from building their own things. Joined the Kuali Rice initiative without commitment to any of the applications. Goals – use the same framework that other people use, sharing apps within the UC community, and being ready to use Kuali apps if / when the campus decides to do that.
Food for thought – Governance – increase organizational discipline, process oriented; Way of working – build to change, may not reduce costs, requires vision, organization and management, not for everything.
JR Schulden – UC Berkeley –
About 8 years of writing web services, but weren’t structured, documented, inventoried, reviewed, or widely shared. Got out of control quickly.
SOA is next step – Software Goal – Quality, Speed, Flexibility.
Trends – increasingly complex and changing business processes. Increasingly tech savvy business partners, an increase in dept/unit development of mission critical systems. A decrease in resources while increase in IT demands.
Became a founder of Kuali Student – gave 2 architects and 2 developers to project.
Looking for more developers, less architects.
Finding that it’s hard for functional people to think abstractly – so they’re getting better with practice.
Using RICE in many cases, but not all, in Kuali Student. How to keep infrastructure upgraded while many apps rely on it is a challenge.
Challenges: Semantic Interoperability (we don’t speak the same language); Culture (not invented here, not under my control), Business Processes, Resources and funding models, Staffing (new skill sets, a fresh look, back-filling key positions, business analysts are rarer than we thought, to succeed is not about “central resources”, but about “campus resources”).
There are many immature technologies – e.g. BPEL.
“In theory there is no difference between theory and practice. Bu, in practice there is.” – Yogi Berra
In the discussion Elazar brings up the issue of functionality running in the cloud, like their new procurement system (SyQuest), which offers web services functionality and integrates with their SSO.
There’s a lively discussion in the backchannel chat room about REST vs. SOAP, specifically around the issues of whether programatically generated WSDLs for SOAP are usable in multiple interfaces from different lnaguages – there seems to be some agreement that hand-designed and coded WSDL is what works, so if you have to hand code it anyway, why not just do REST? Paul Hill points out that well-designed WSDL can be easy to consume with automated tools.
Oren Sreebny 