soa, web-services and student systems leo fernig university of british columbia [email protected]
TRANSCRIPT
Overview
• The Community Source Student System initiative– See http://educationcommons.org/projects/display/CSSSS/Home
• Service Oriented Architecture design issues
• Working with XML
• Web service design paradigms
• Web service deployment issues
• Future directions
SOA, Web-Services and Student Systems
SOA, Web-Services and Student Systems
SOAAD issues
• In SOAAD (Service Oriented Architecture Analysis and Design) there is a real tension between traditional top-down approaches and contemporary agile approaches
• The maturity of web service technologies
• The maturity of open source WS components
SOA, Web-Services and Student Systems
A specific example
AcademicRecordService
2.1 Insert transcript2.2 Update transcript2.3 Get transcript2.4 Delete transcript2.5 Add transfer credit2.6 Get transfer credit2.7 Delete transfer credit2.8 Insert test2.9 Get test2.10 Update test2.11 Delete test
AcademicDecisionService
1.1 Evaluate Test Results1.2 Evaluate Transcript
AcademicPlan
Service
3.1 Create plan3.2 Update plan3.3 Get plan3.4 Roll plan3.5 Activate plan3.6 Inactive plan3.7 Delete plan
SOA, Web-Services and Student Systems
Degree Audit and Assessment Application
Audit degree (progress)
Evaluate for promotion
Determine at-risk
The process: end-of term (or session) evaluation forpromotion to the next level (or phase) of an academicprogram
The business agnostic services that support the process:1. Supplying the student’s academic
record2. Applying some evaluation rules3. Plan the next level (or phase)
Working with XML
• Design issues
• Integration with industry schemas
SOA, Web-Services and Student Systems
XML: design issues
• Flexibility of XML schema– Inheritance – Composition– Cardinalities– Ranges of values (eg country codes)
• Verbosity
SOA, Web-Services and Student Systems
XML: design issues
• XML-Java binding– Flexibility– Performance– JiBX binding framework (http://jibx.sourceforge.net/)
• Governance and management– Name spaces– Naming conventions– Versioning
• Doc/lit versus RPC– Coarse grained interfaces– Hiding implementation details– Stateless– Emphasis on design
SOA, Web-Services and Student Systems
XML: design issues
• Design patterns– Russian doll vs Salami vs Venetian blind– http://www.xfront.com/GlobalVersusLocal.html
SOA, Web-Services and Student Systems
CourseType
Grade
Standing
CourseType
Ref = Grade
Ref = Standing
GradeType
StandingType
ResultType
Grade
Standing
CourseType
Ref = Result
Russian doll Salami Venetian blind
XML: Integration with industry standards
• Integrating “local” and “global” commerce– Receiving high-school transcripts– Trading post-secondary transcripts– Receiving test scores (SAT TOEFL etc)
• PESC (Post Secondary Education Standards Council)– http://www.pesc.org/
• IMS global– http://www.imsglobal.org/
• Alignment strategies
SOA, Web-Services and Student Systems
XML: Alignment strategies
• Use the Venetian blind design pattern
• Create a new container object
• Include the learning unit
• Include the PESC types
SOA, Web-Services and Student Systems
CourseType
LearningUnitTypeLearning Unit ID
PESC course type
PESC grade type
XML: design issuesREST and SOAP
• REST: Representational State Transfer– Flexible– Simple
• ExampleREQUEST: http://www.parts-depot.com/parts
RESPONSE:
<p:Parts <Part id="00345" xlink:href="http://www.parts-depot.com/parts/00345"/> <Part id="00346" xlink:href="http://www.parts-depot.com/parts/00346"/> <Part id="00347" xlink:href="http://www.parts-depot.com/parts/00347"/> <Part id="00348" xlink:href="http://www.parts-depot.com/parts/00348"/></p:Parts>
SOA, Web-Services and Student Systems
XML: design issuesREST and WSDL/SOAP
• REST: Representational State Transfer– Flexible– Simple
• Disadvantages– Service contracts are opaque– Flow of control is opaque– Not self-documenting
• If some services are exposed as REST– Will have to be over and above WSDL’s– Useful for simple “one of” implementations
SOA, Web-Services and Student Systems
A process agnostic service• Handlers for processing headers
– Security– Message logging
• XML – java binding – Flexibility and performance– Intelligibility
• Spring AOP (isolate housekeeping)– Caching– Logging
• Object Relational Mappings
• Local services
SOA, Web-Services and Student Systems
A process agnostic service: issues
• The need for a standard template– WS standards are very flexible– Do not want to re-invent
infrastructure– Allow developers to concentrate on
business logic
• Managing XML files – Preponderance of XML
• Global vs local objects– Canonical XML = global objects– Local objects do not need schemas
SOA, Web-Services and Student Systems
A business process service: Orchestration
• The core of agility and flexibility in SOA
• The differences between this and a business agnostic service:
– It contains the logic that expresses a business process
– It consumers other services
SOA, Web-Services and Student Systems
Orchestration
• Hand coding processes
• Using a BPEL (Business Process Execution Language) engine
• Workflow
• Enterprise Service Bus
SOA, Web-Services and Student Systems
Performance
There will be performance problems to solve. But, we can…
1. Optimize deployment configurations. E.g. put services behind http load balancers with SSL accelerators.
2. Package operations in a service with a view to minimizing traffic
3. Use doc/lit to minimizes traffic
And the predictions are that Moore’s law will now hold between 2010 and 2030.
SOA, Web-Services and Student Systems
Putting it all together…
SOA, Web-Services and Student Systems
Get a transcript
Evaluate transcript
Create a newLevel/phase
End of termevaluation
process
SOA, Web-Services and Student Systems
Get a transcript
Evaluate transcript
Create a newLevel/phase
End of termevaluation
process
Viewmanager
FunctionController
Data store Data store Data store
Portal
Business Processes(orchestration)
Bus
Business Agnostic Services
Data
Deployment: managing a service ecology
SOA, Web-Services and Student Systems
Production
Integration
Development
The future
• Process agnostic systems
• Rule agnostic systems
• Highly flexible and robust deployments
• Intelligent systems that modify there own rule base
SOA, Web-Services and Student Systems