[CSG Fall 2008] SOA Panel

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: … Continue reading “[CSG Fall 2008] SOA Panel”

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.

[CSG Fall 2008] Non-Enterprise Initiatives of SOA

Services that are reliable, specific, small, secure, stable, standards-based and reusable.

SOA slated at Stanford –

Remedy – Stanford uses it heavily in the central IT office for order fulfillment and billing, and tracking some labor hours. They want to expose it as a service to replace brittle current integrations. Will allow new functionality. They’re building a Remedy-Zimbra integration

Tom Barton is talking about SOA at Chicago.

No bigg app yet, but the want to be prepared. They thingk web services seems like a good approach to solving some problems. Their early experience is that even with a single simple service, there are lots of issues.

WS & ID management – Identifier translation – translate among ChicagoID, SSN, NEtID, hospital ID, alumID, studentID, etc. Also did an account management integration project with the hospital.

Net of early experience – concentrate on functionality, not underlying data stores. Loose coupling allows nice divisions of labor.

Data services – might provide good technology for providing data across the institution. A combination of reporting & WS capabilities.

Steps toward first SOA – look for cowpaths in institutional data – a relatively small set of objects that reflect the way we think about our businesses. Choose web services to reinforce a common data model across systems. Facing infrastructure choices, like servlet platform, esb, etc and development framework.

Designing Grouper’s WS Interfaces –

It takes 4 WS interface styles to please enough adopters – SOAP vs. REST, and heavy capabilities vs. lightweight ones.

[CSG Fall 2008] SOA Architecture workshop – Jim Phelps (Wisconsin)

Jim Phelps (Wisconsin) is introducting Service Oriented Architecture. 4 years ago they went to their board and stated that SOA was their direction, and since then they spent a lot of time spinning wheels – it’s like a thousand pound stone that you push and push and push and it moves an inch, then you … Continue reading “[CSG Fall 2008] SOA Architecture workshop – Jim Phelps (Wisconsin)”

Jim Phelps (Wisconsin) is introducting Service Oriented Architecture.

4 years ago they went to their board and stated that SOA was their direction, and since then they spent a lot of time spinning wheels – it’s like a thousand pound stone that you push and push and push and it moves an inch, then you move away and realize you have five miles to go.

SOA is a maturity state you need to reach, not a technology roll-out.

Using their Course Guide as a case study. http://www.registrar.wisc.edu/courseguide/

What is the course guide? Changes in official course descriptions take lots of bureacracy, curriculum committees, etc. Departments have lots more detailed description, and the instructors have even more detail. Want to bring that in, plus syllabi and textbooks into one spot. Want to give students ability to put those into favorites list (like an Amazon Wish List), and give departments and advisors the ability to gather and publish lists (e.g. good courses for non-majors). Also want the ability to add notes (remember to take this next spring). Then give depts the ability to send notices to students who have a given course as a favorite. Can send courses to a scheduler that can suggest schedules, or to degree audit system, etc.

Architecture – course guide sits at the center of lots of things, don’t want to build a silo with lots of flat file feeds. Want to avoid building a service that nobody uses. Enter once, use many times, leverage “Selfish Altruism” (if I’m already building it for my own web site, allow it to be leveraged). Can build it “right” or build it “fast”. Decided to build it “right”.

SOA – A style of application design, not a technology. Not an application stack. Based on shared, reusable services – not point-to-point web services. Services represent some business or technical function. Not a buy/build decision, but something you grow into.

Sources – Student Info System (peoplesoft), on top of which sits an operational data store called Curricular Hub (CHUB). Bringing up a content management system, in which people will build departmental descriptions. There’s a schedule system, and then other systems like library, etc.

There’s an enterprise service bus.

UI is the university portal.

There’s an orchestration engine, a portlet app engine and a database that stores local state info.

Lots of orchestration that has to be written, but less application writing.

Need to have lots of infrastructure to build an app.

Klara notes that the ERP systems don’t store the data in ways that are meaningful outside their own apps, so need to be reflected in operational data stores. Jim agrees and says that the additional layer of abstraction allows for load management. Wisconsin keeps the CHUB updated every few minutes, and would like to get it to near-real-time, but they can back off updates if the student system is under heavy load (like during registration).

Maturity states (from Enterprise Architecture As Strategy book) – 1. Business Silos 2. Standardized Technology 3. Optimized Core (an important step in moving towards SOA – agreement on what processes you work on and agree on data models) and 4. Business Modularity.

Enterprise Maturity – what’s important processes to fix, what should the data look like, etc. You would think that an institution would know what a course roster should be, but it’s taken many discussions.

Issues –

Skills – lots of people in the organization have built applications, but this looks very different – especially the orchestration portion. A lot has to do with Business Process Analysis and Improvement – not necessarily a skill of coders. There are some standards, BPML, BPMN, BPEL. These are new skills.

Building these apps is a lot more orchestration and assembly, not top-down coding.

There are also a lot of issues around scope and trust in managing these projects – control of the dependent layers are not under the control of a single manager. Hard to get people to focus on the service requirements and trusting the providers to do their work, rather than getting lost in the weeds of pieces that aren’t in your control.

Funding – A lot of what we do is product-focused funding, but SOA is about funding infrastructure. Who pays to build out web services? The first project to use it? Central funding? Gather everybody who might use the services and get community funding? People say “not me first”. In this case they funded it themselves with support from the budget and registrar offices, who bore part of the cost because they see the value in the process. Shel points out the difficulty in creating cost models that properly allocate the parts of the infrastructure to the uses of the applications. Jack Duwe notes that the funding model is important, and that there’s no sane way to fund the infrastructure other than centrally. Tom Barton says that this problem is not unique to SOA, but is common to many modern technologies that require lots of infrastructure, like virtualized servers. Shel asks whether central funding will allow for enough funding to really support this, and wonders how we create a shared sense of ownership for that integration layer.

In response to a question, Jim says that he things there needs to be an “Integration Competency Center” where the expertise and responsibility for the services layer lives.

Klara says that this model also breaks our notion of who the functional “owner” of an application is. Greg notes that it’s the institution that owns the services, not any functional group. Ron Kraemer says that it’s important that the funding model have different components that get treated separately, including having some funds for the CIO able to allocate for unforeseen eventualities. Bob says that in order to justify funding you have to have adoption with enthusiasts who actually gain something early from using the service.

Requires some organizational maturity among the players at the institution to agree on shared requirements to avoid the “Me first now!” syndrome. The motto is Design for the Enterprise.

Governance – do we need some levels of governance that are not about individual stewards? Wisconsin hasn’t dealt with that yet.

Change management – how do you decide when you can change services? You need to track who’s using services, but what happens when they don’t agree on changes?

Why do this?

Transparency – think about being able to know who is consuming which pieces of data – a great advantage.

Agility – allows you to cope with changes quickly and roll out new services that knit together composite applications.