Interoperability standards, soa and the e-framework

2

Overview

Your project, soa and interoperability standards Interoperability revisited Focusing on services rather than applications

How to find relevant technology and make it available; the e-framework Hands on with the eframework

A development dialog: the development table Pulling all the leads together

3

Introduction

A software system doesn't live in isolation, it needs to work with other systems

How to find useful technology, and make your own available to others: e-framework and development table

4

No interoperability

5

Custom interoperability

6

Interoperability data standards

7

Interoperable services

8

Services and your project

Which systems (inside and outside the firewall) does your tool need to interoperate with?

Which systems could it interoperate with in order to delegate functionality?

What services (from inside and outside the firewall) are already there?

Which service components can I beg, borrow and steal?

9

Services and the e-framework

For JISC: Aims to put service standards and solutions in a common

framework for education and research International partnership A way to coordinate approaches across development

programmes

For you: A way of finding service components and soa solutions A way of making your developments available

10

e-framework hands-on

Consider all the service components your projects uses or makes available

tag them with the e-framework vocabulary give them two sentence descriptions

11

Development table

• Records pointers to relevant services, standards, tools and existing project work

• Establishes a dialog about a project's development:• ‘Strand Support Teams’ looks at project plans• Strand Support Teams have a first go at completing a

‘Development Table’ for each project• Development table is sent back to projects for comment and

completion• Wrap-up by support team and project

12

Development table

Interoperability standardsPotentially relevant services and standards Reasons for/ against use Agreed

Service Genre Service Expression or specificationProgramme team Project

Existing workReasons for / against use Agreed

Programme team Project

Potentially relevant tools Reasons for/ against use Agreed

Type of tool Tool Programme team Project

IDE

test tool

code repository

issue tracker

Relevant existing projects and SUMs (including JISC and non-JISC open source projects)

Development tools for technically oriented projects (e.g. toolkits)

website/blog/wiki

Relevant SIGs