cetis E-Learning and Service Orientation Scott Wilson.

http://www.cetis.ac.ukcetis

E-Learning and Service Orientation

Scott Wilson

http://www.jisc.ac.uk/


Interoperability : Our Holy Grail

• New synergies from the combination of tools and functions

• Efficiencies gained from linking together processes and using automation

• Flexibility in the configuration of functions to match strategic objectives and priorities



Experiences So Far…

• Black-box solutions for e-learning are inflexible and difficult to adapt to their context

• What should be basic integration problems have proven intractable and expensive, and often any solutions are unrepeatable

• Duplication and waste in R&D efforts, and difficulty in exploiting R&D outputs outside of incubation projects



JISC Interoperability projects • Lots of projects funded under MLE programmes

aiming for interoperability• Content-oriented projects were generally quite

successful• Integration projects were generally unsuccessful• Where integration projects were successful, they

were not repeatable outside the project



Why unrepeatable?• Various projects along lines of “Integrate System

X with System Y”• Eventually everything talks to everything else?• But actually “Integrate X with Y in environment

Z”• So even replicating a previous pairwise

integration often meant starting from scratch (cf SWaNI)



Desirable outcomes

• Flexible solutions that can be suited to individual institutions without causing interoperability problems

• Integration that is affordable and repeatable

• R&D outcomes that can be shared outside of their incubator projects



Integration Choices

• So how can we achieve integration?

• What does each approach afford us?

• Well, there are some common patterns…



Information Portal• Aggregate information

from multiple sources into a single display

• Display divided into multiple zones each displaying information from different system

• Limited interaction between zones

• Enables ‘shallow’ rather than ‘deep’ integration



Data Replication• Data is replicated

between multiple storage systems

• Business logic and presentation remains independent



Shared Business Function• Multiple applications

share common business functions

• Presentation remains independent

• Data encapsulated by shared function

• E.g. D/COM and RMI



Service Oriented Architecture• Presentation and

workflow constructed from multiple shared services

• Data and business function encapsulated in services

• Also known as “Enterprise service bus” architecture



Distributed Business Process• Business process

coordinates activities across multiple systems

• Business process components manage execution of tasks that span existing applications

• Typical for building web applications over legacy systems



Data Warehouse• Integrate many data

sources to provide enterprise-wide reporting

• Business and presentation remain independent

• Strategic but not operational integration



Mix and match• Using a Service

Oriented Architecture to implement teaching and administration workflows as Distributed Business Processes, presented using an Information Portal



Service Orientation

• A popular way to look at systems integration• Concentrates on contracts between service

Providers and service Consumers• Separates service from implementation• Many functions within an e-learning system can

be ‘exported’ to services offered by the environment to applications



SOA Myths• SOA needs lots of complex WS-* specs

– No it doesn’t. HTTP+XML can be used too, as can various levels of SOAP implementation

• SOA is new and untried– Its an approach that’s been around in some form for a

long time– The technology used to realize SOA is mostly pre-

existing

• SOA is all hype– Well, there is a fair amount of that…



SOA benefits• Platform vendor buy-in, with plenty of

class libraries• Lends itself easily to abstraction• Enables flexibility, even with legacy assets• Neutral with regard to platforms and

languages• Relatively intuitive



The emergence of the e-Learning Framework

• An international effort to figure out SOA in the public education sectors



The e-Learning Framework

• A Service-Oriented analysis of the educational problem space

• Backed up with technical specifications, R&D projects, and toolkits

• A place for us to work together, to identify issues, opportunities, priorities



ELF myths

• ELF is an open-source LMS– The ELF provides a framework that can help

when developing any kind of e-learning application, commercial or open-source

• To use ELF you need to use SOAP– Service orientation is an approach to system

design, and isn’t based on any one technology binding



More ELF myths…• Using ELF means buying all new Web Services-

capable systems– SOA enables existing investments in systems to be

leveraged, regardless of their platform, by exposing functions as services

• ELF will give you everything you need– You still need applications… at least for now(!?)– Workflow? Security? Management?



ELF Today



What are Services?• Functionally discrete patterns

– Scope and definition– Patterns of implementation

• Port definitions– Abstract contract (UML)– API– Service bindings (WSDL, XML-RPC,

HTTP+XML…)



Learning Domain Services

• Functions that at the moment seem unique to the L&T domain

• Each function expressed as a service analysis, with links to specification and R&D activity

• Eventually, each service will have toolkits, specifications and implementation patterns



Learning Domain Services• Activity authoring and management• Course/curriculum management and validation, • Assessment, marking, and grading• Sequencing/flow, tracking and reporting• Personal development, competencies and e-

Portfolios



Common Services• Functions that at this time seem to be

shared by other domains, such as IT services, information environment, and e-science

• Effort may be lead by the e-learning sector, follow efforts lead by other sectors, or investigate in collaboration



Common Services

• Wide range of functions: administrative, collaboration, information management, and some core middleware functions



What are the bricks?

• Each ‘brick’ represents a discrete set of functions that can be exposed within an environment, such that applications such as authoring tools, learning tools etc can make use of them

• Each ‘brick’ defines one or more service ports



Our plans• Identify the most critical services

– And the most ‘doable’ in terms of current knowledge and capability

• Build toolkits• Develop expertise• Demonstrate practical use in proof-of-concept

applications and deployments• Contribute to applicable standards• Work with the developer community - both commercial

vendors and open source



Standards

• Standards already exist for some services

• Standards don’t exist for many services

• Where standards do exist, they aren’t always service-oriented

• Where standards don’t exist, there may be insufficient experience to create one



What isn’t on the ELF diagram?• Applications - there are no applications here.

Just services that support applications• ‘Fabric’ - some things are common to a whole

swathe of services and cannot be easily encapsulated into discrete functions– Workflow– Security– Management



Workflow• How services fit within a flow of activity• How services need to be able to respond to

flows of action (‘workflow-aware’)• Some services need pretty complex workflow

behaviour:– Activation– Closedown– Monitoring– Intervention



Security• Authentication

– Consumer to Provider (agent trust)– Provider to Consumer (service trust)– User to Provider via Consumer (user authn)

• Authorization– Client to Provider (agent access policy)– Provider to implementation (service entitlement)– User to implementation (user entitlement)



Security (contd)• Communication security

– Eavesdropping/Replay attacks– Signing/Tamperproofing

• Non-repudiation– Timing– Sequencing

• Accountability and logging• Privacy



Management • Configuration

– Access– Performance– Feature activation/removal

• Deployment– Packaging– Live redeploy– Clustering, routing and forwarding

• Management– Monitoring– Upgrading



Using ELF services in apps

• As well as the services in SOA, need to realise benefits in developing applications– After all, these services are meant to make

writing/improving/adapting applications easier!

• There are two views of this…



Using ELF Services

ForumGroup

Person Membership

Chat

Resource List

WorkflowPresentation

E-Learning Collaboration Application

Security

Configuration and Deployment



Using ELF Services 2

ForumGroupPerson Membership

ChatResource List

Workflow

Presentation

E-Learning Collaboration Application

Security

Configuration and Deployment



Challenges Ahead

• We’ve made a pretty good start

• There’s a lot of work we could do - but what would be really useful?



Challenges• Get the basic technology right

– Make things simple, but not simplistic– Enable different levels of technical sophistication,

from very easy HTTP+XML to very tricky SOAP+WS-* as needed

• Show some of this stuff really working– Compelling and interesting demonstrators– Persuading vendors and OSS projects to take

advantage of ELF toolkits



Challenges (cont’d)

• Communicate the ideas– Developers mostly get it … some managers

get it… but a lot of people don’t

• Get the factoring of services right

• Start thinking about the hard problems– Security, workflow, management are all issues

that aren’t going away!


cetis E-Learning and Service Orientation Scott Wilson.

Documents

Transcript of cetis E-Learning and Service Orientation Scott Wilson.