planning & delivering service oriented architecture (soa) university of california, san diego...
TRANSCRIPT
Planning & Delivering Service Oriented Architecture (SOA)
University of California, San Diego
October 30, 2006
2
Topics
About UCSD
What is SOA?
Why Implement SOA?
Planning for SOA
UCSD Examples Experiences and Case Studies
Implementation Challenges
The UCSD SOA Framework
3
About UCSD
26,100 Students
23,500 Employees (Including Medical Center)
$1.9 Billion Annual Budget
$728 Million Annual Research Funding_______________________________________________________________________________________
IBM Mainframe and Sun Solaris Servers
Java (J2EE)
DB2
4
About UCSD
Ease of Use and Access
Common Look & Feel
Web-Based Systems
Interoperability and Open Architecture
Single Signon
Evolution v. Revolution
Cost-Effectiveness
Administrative Computing Goals:
5
Driving Factors for UCSD
Application life-cycles continue to shrink – demand increases
Systems constantly changing for business needs
Regardless of platform, DB, technology – all systems need to: Interoperate, Communicate & Integrate
Leverage departmental IT staff in development
6
Architecture Needs
Loosely-coupled with reusable components
Promote productivity - reduce the time-to-market
Greater business agility
To drive business processes closer to end users
Technology independent
Leverage and integrate existing applications
Provide standard connections between systems
Abstract the complexity for the developers
7
What is Service-Oriented Architecture?
What is SOA?SOA (service-oriented architecture) is a broad framework within which enterprises build, deploy, and manage services; these services are application components that can be called upon by other applications using standard protocols. The primary objective is a more agile application infrastructure that responds swiftly to shifting business demands.
8
What is a Service?
Services are application components that are available to other applications using standard protocols (typically XML)
Examples: Create a PO inside a mainframe application Retrieving & updating student info Reviewing & changing HR benefits
9
What is a Service
Campus Users
IBM Mainframe
PDA
Server
COBOL Application
1989Middleware
Service for retrieving & updating
Travel Information
Example of a “Service” that incorporates Mainframe code
XML
XHTML
10
What is SOA?
Analogy to A/V Components
Years ago electronic systems were self-contained monolithic systems
Today’s electronics are pluggable and independent
Standardized connections.
Today's interchangeable components
1952-57 TV 1918-45 Radio1962 Telephone
11
Key Components of a SOA
A service oriented architecture is a software architecture that is based on the following key concepts:
A service consists of a contract, one or more interfaces and an implementation
SOA
Service BusService
RepositoryService
Application Frontend
Contract Implementation Interface
Business Logic Data
12
Using a Service
Development time discovery imposes a fairly simple model. The developer is responsible for locating all required information from the service repository in order to create a client that interacts correctly with the service instance.
Developer
Service Repository
Service Contract
ServiceClient
(Application frontend or services)
Service Stub
Contains
CreatesSearches in
Based on
Invokes
Uses
Fulfills
Describes
13
A Service Example
Message Server
Campus Application
Service
Department Application
VendorApplication
Service
Java Interface
Java/.NET/Other
Interface
Java/.NET/Other
Interface
Student Information
servicesService Contract
ResponseName : Mary SmithDOB : 10/11/1982College : MuirOther Info...
Lookup By Student ID A123456
Mainframe
SOAP XML Request
SOAP XML Response
14
Benefits of SOA
Independence from Technology
Adequate Business Infrastructure
Agility
Reuse
Risk Mitigation
Evolutionary Approach
Cost Savings
More Efficient Development Process
Feedback at Different Levels
15
Planning for SOA @ UCSD
Approach: Think strategically and plan tactically
Evolutionary not revolutionary
“Leave & layer vs. rip & replace” Gartner Group
Make it easy for developers to adopt
Natural progression of original OO Architecture and Approach
Not going to happen overnight- It takes time: “the true
adoption is about two years behind the hype”. Gartner Group
16
Planning for SOA @ UCSD
Process Experiment with Web Services
Small project high degree of success Helpful not vital
Adapt some existing systems to use Services
Remove Intersystem dependencies
Establish an Internal SOA
Expand Internal SOA to include external services.
17
Single Sign-On
Uses Shibboleth for Authentication http://shibboleth.internet2.edu/
Supported on different platforms (based on SAML)
Uses UCSD Roles & Affiliates as the data repository for authentication and authorization
Part of the UC-Trust Collaboration project for cross-campus identity management.
18
Case Study - MyRecords Portlets
Student portlets are provided through the MyRecords tab.
Each portlet is populated from a web service.
Information comes from either the mainframe or data warehouse.
Portlet content is cached and managed through event driven messages which implement the cache policy.
19
ElementK Integration
UCSD supplies the Portal top banner navigation, page footer and right sidebar
Single Sign-On provides user pass through from UCSD portal to KnowledgeHub.
Web Services create user account at the time of login.
UCSD Portal KnowledgeHub Integration
20
UCSD Server Environment
Mainframe
Database Server
Portal Server
Load Balancer
Partner Applications Various Web Technologies
Authentication Server A^4
Web Farm App Servers SunFire 280r
Web Farm App ServersSunFire 280r
Portal Application Integration DiagramProduction Environment
SunFire 280r
Sunfire 4800
SUN V100
Cisco CSS 11503
21
Implementation Challenges
Technical Challenges
Creating object-like services using: Legacy Procedural Mainframe (CICS) Applications Legacy Web-Applications (Perl/CGI)
Monitoring process Trouble shooting Dealing with failures
Managing the environment
22
Implementation Challenges
Technical Challenges (cont)
Security challenges - loosely coupled environment
Performance - XML brings robustness not speed
Optimization
Organizing the services – Registry & Repository
23
Implementation Challenges
Organizational and Cultural Challenges
Paradigm shift for developers Specialists vs. Generalist
Paradigm shift for IT Managers
More organizational discipline
Governance
24
Implementing SOA @ UCSD
Organizational Structure Portal Services: Web Content Analysts, Writers, UI & Usability
Enterprise Architecture & Middleware Team
Security Team
DBA & Data Warehouse Team
System & Tech Support (Unix & Mainframe)
Legacy Mainframe Application Programmers
Web Application Developers
UI Developers
Services developers
Process Centric Developers
25
Implementation Challenges
Staffing Challenges Recruitment
Retention
Compensation
Adoption - Buy-in
Keeping staff motivated and excited
26
Implementing SOA @ UCSD
Staffing Transition
Wiki Training
Framework Bootcamp
UCSD Toolbox
Conferences & classes
Bi-weekly staff meeting
Student Interns
27
Implementing SOA @ UCSD
Gartner Conferences – 2002-2006 Things we did:
Take stock of what you already have Build on existing technology Train staff Design Services for Re-use Move in incremental adoption
Things we avoided: Avoid guidance from vendors SOA is NOT a technology, not a single solution, buy the technology
that compliments your goals and environment Don’t do the “Big Bang” approach Avoid thinking of an SOA projects any differently that other project Plethora of products in the SOA space - Common myth that you
have to start with buying products
28
UCSD Toolbox
29
UCSD Toolbox
Title
Double Click to Build ...
Webapp Name admissionssoService Name CityOfBirthPackage edu.ucsd.act.admissionsso.servicesVirtual Name adminssoDate 11/15/2005Diagram ID 1DBAlias db2
ADV_APPL_DATA_VA_V
ADC_SET_TS
LAST_ACTIVITY_DATE
APPLICATN_DATACODE
FK_APP_INTRL_REFID
USER_CODE
FK_APP_APLCN_REFNM
APPLICATN_DATA_VAL
Model Name: cityOfBirth [main]
ApplicantInfoDBO
ISIS
Model uses ISIS Mainframe DB/2
(Student Services)
PRS_PERSON_V
PERSON_FULL_NAME
INTRL_REF_ID
NAME_SUFFIX_DESC
ARCHIVED_DATE
BIRTH_DATE
Student Lookup & Create Service
PID_PERSON_ID_V
PERSON_ID
FK_PCH_INTRL_REFID
cityofbirth
dob
name
DOBDateHandler
DOBHandler2
Deploy to ... jlinkservices_db
firstname
FirstnameFormatHandler
lastname
middlename
LastnameFormatHandler
MiddlenameFormatHandler
dob_month
dob_day
dob_year
DOBMonthFormatHandler
DOBYearFormatHandler
DOBDayFormatHandler
DateValidator
DateValidator
ApplicantInfoDBO
ApplicantInfoDBO
Drag Table Icons from stencil to create under lying data model for service
Creates Service on the Mainframe
Add business rules component to field. Validation and Filtering
Creates individual service stubs
Add formatting component to field.
Click Icon to build and deploy service
Add a customized attribute to service
30
UCSD Application Infrastructure
What did we build?
We had an application infrastructure which supported the concept of services. It could be extended and runs in a J2EE container
We already had support for and interoperability with open source technology What did we buy?
Adobe eForms Vignette Portal & Content Management ElementK (hosted) InfiNET (hosted) SciQuest (hosted) WebSphere Z/OS IBM WD4Z
We currently have over 50+ services in production and over 400+ services developed for our applications. There has been a high percentage of reuse over the last year. These will be the building blocks of our campus wide services planned for the next 12 months.
31
Marty Backer [email protected]
Christopher De Rosa [email protected]
Elazar Harel [email protected]
Thank You