The original Powerpoint Slides - Karl Wilcox

TUTORIAL

STARTS

7PM

“IF
MY CALCULATIONS ARE CORRECT, WHEN THIS
BABY HITS EIGHTY
-
EIGHT MILES PER HOUR,
YOU'RE GOING TO SEE SOME SERIOUS
SHIT…”

1

START RECORDING!

•
Recordings in various formats will be available in a few
days

•
Check out the Tutor Group Forums for:

•
Recording links

•
Copies of slides

•
Any follow up questions and answers



•
Please use the chat box for chat!




(Note to moderator: Check max. simultaneous talkers)


2

T320

TUTORIAL

THREE

WEB SERVICES, TMA03

3

PROPOSED AGENDA

•
Where are we?

•
Web Services

•
Why?

•
Why not?

•
TMA03 Tips, Q & A

•
Block 4 Preview

•
Important dates

4

Any questions,
please click the
“raise your hand”
icon

Then type
question in chat
box

Or use
microphone!

PROPOSED UN
-
AGENDA(?)

•
The practical work

•
Thoroughly described in Block material

•
Excellent support from the appropriate national forums

•
Best worked through at your own pace (IMHO)

5

WHERE ARE
WE?

“I'M
SURE THAT IN 1985 PLUTONIUM IS
AVAILABLE IN EVERY CORNER DRUG STORE,
BUT IN 1955 IT'S A LITTLE HARD TO COME
BY”

6

OVERVIEW


7

Block 1
–

E
-
Business in context

Block 2
–

Protocols and Data

Block 3
–

Web Services

Block 4
–

Business Processes

TMA01

TMA02

TMA03

E

M

A


pt

2

EMA
pt

1

You

Are

Here

BLOCK 3

You need to have completed all the
practicals

before

starting
TMA02 Part 1

You need to have
read most of
the
material
before

starting
TMA02 Part
2

(Possibly leave Part 7 until later, but very short anyway!)


You have 2 ½ weeks remaining

Do not panic!


Contact your tutor if you have any questions or problems

(More on the TMA later…)

8

WEB
SERVICES
–

WHY?

“LAST NIGHT, DARTH VADER CAME DOWN FROM
PLANET VULCAN AND TOLD ME THAT IF I DIDN’T
TAKE LORRAINE OUT, THAT HE’D MELT MY BRAIN.”

9

APPROACH

•
I Will talk about a single application on 3 architectures

•
A single computer

•
A distributed system (client / server, N
-
tier )

•
A Service Orientated Architecture (SOA)


•
And consider them from several points of view

•
Functional decomposition (“what gets done where”)

•
Communication protocols (“how stuff gets passed around”)

•
Sharing & Discovery (“re
-
using stuff from elsewhere”)

•
Maintainability (“Keeping it all going”)

10

THE SINGLE COMPUTER
-

FUNCTIONAL DECOMPOSITION

•
Everything is under developer control

•
Problem typically broken down into

discrete functional blocks

•
Typical design concerns:

•
Maintainability

•
Performance

11

THE SINGLE COMPUTER
-

COMMUNICATION PROTOCOLS

•
Typically a single programming

language is used

•
So data representation is consistent

•
Data passed in function calls

•
Or shared memory

•
Everything is “internal“

•
Little or no conversion required

12

THE SINGLE COMPUTER
-

SHARING & DISCOVERY

•
Probably use “library” functions

•
Typically part of the programming language

•
But may also be “bought in”

•
“Discovered” through printed documentation

•
Description of what the function does

•
Definition of “arguments” (data passed in/out)

•
Everything is still mostly “internal“

•
Maybe a little conversion required

•
E.g. floats to double

13

THE SINGLE COMPUTER
-

MAINTAINABILITY

•
Quite hard to change things

•
Switching libraries?

•
Probably different functions / arguments

•
In general, system is rigid / inflexible

•
But also mostly under the developer’s complete

control

14

DISTRIBUTED SYSTEM
–

FUNCTIONAL DECOMPOSITION

•
Most things under developer control

•
Except libraries & database

•
Design emphasises “division of labour”

•
Typically presentation / logic / database

•
Typical design concerns

•
Minimising latency (communication delay)

•
Maintainability

15

DISTRIBUTED SYSTEM
–

COMMUNICATION PROTOCOLS

•
Probably very low level

•
E.g. “sockets”
-

a simple pipe for binary

data

•
Data representation issues

•
Different processor architectures (e.g. 16 / 32 bit)

•
How to define strings? Floats? Dates? Currency?

•
Recall Block 2 Part 1 “Exchanging Data”

•
Some low level standards available

•
Remote procedure calls (RPC)

•
Object Request Brokers (ORBs)

16

DISTRIBUTED SYSTEM
–

SHARING AND DISCOVERY

•
Typically, each layer is “fixed” in relation

each of the others

•
Similar situation to single computer

•
Just spread around different boxes

•
No real “sharing” of much except database engine

•
Object Request Brokers tried to address some of this

•
(In theory) included dynamic linking

•
Some “late binding” of function calls

•
i.e. argument types defined as late as possible

•
Didn’t really catch on

17

DISTRIBUTED SYSTEM
–

MAINTAINABILITY

•
More scalable in terms of performance

•
Add more clients, more database servers

•
But still rigid / inflexible in components

•
Hard to change libraries / databases

•
Inflexible interfaces / rigid design

18

(Movie quotes clue!)

SERVICE ORIENTATED
ARCHITECTURE
–

FUNCTIONAL DECOMPOSITION

•
System broken down into discrete,

re
-
usable “services”

•
With scalability benefits

•
High level design of system in terms

of these lower level services

•
BPEL executable description of a business process

•
More of this in block 4

19

SERVICE ORIENTATED
ARCHITECTURE
–

COMMUNICATION PROTOCOLS

•
Standard way of invoking services

•
WSDL describes this

•
Standard ways to transfer data

•
XML
-
RPC, SOAP

•
High level, network independent communication protocols

•
HTTP / SSL

•
Very late binding of function (service) calls

•
Arguments defined at the time of use

•
WSDL describes this also

20

SERVICE ORIENTATED
ARCHITECTURE
–

SHARING & DISCOVERY

•
Any service available to anyone

•
UDDI + WSDL all you need

•
Dynamic service end point discovery

•
UDDI

•
(Theoretically) dynamic choice

•
Based on cost / response time / quality

•
Automatic load balancing / failover

21

SERVICE ORIENTATED
ARCHITECTURE
–

MAINTAINABILITY

•
Flexibility through “late binding”

•
Services chosen dynamically at time of need

•
All necessary information to use service

defined by WSDL

•
Adherence to standards provable

•
WSI
-
Compliance

•
BPEL easy to modify to reflect business changes

•
Nice, graphical diagrammatic interface (block 4)

•
Network independent communication

•
Because of high level protocols (e.g. HTTP)

•
And standardised data formats (e.g. SOAP)

22

SOA COMPARED TO REST

•
Services less flexible / not dynamic

•
Effectively “point to point” links

•
Data formats not dynamic

•
Look them in the documentation

•
Network independent communication

•
Because of high level protocols (e.g. HTTP GET / POST)

•
Can use standardised data formats (e.g. SOAP / JSON)

23

WHY

HASN’T SOA CAUGHT ON?

•
SOA appears to have lots of advantages

•
Discovery, scalability, flexibility, resilience…

•
However, the discovery process benefits from “network”
effects

•
The more services that can be “discovered” the more likely
it is that someone will use the process

•
But preparing a service for discovery incurs costs

•
Defining the WSDL, UDDI entries etc.

•
There is a “first mover disadvantage”

•
Extra costs, no immediate benefits

•
“No one else uses it, why should I?”

24

WHY

HASN’T SOA CAUGHT ON?

•
If we decide not to use UDDI, then:

•
“Discovery” becomes part of the design process, not
operation

•
Chose a service provider, “hard
-
code” that service address

•
If the service address is “hard coded” then:

•
There is less incentive to dynamically define the service
interface (e.g. WSDL entries)

•
If you can’t dynamically chose another service, you might
as well “hard code” the function arguments

•
But we still have the data format compatibility issues

•
So SOAP / XML / JSON widely used


25

TMA03 TIPS
Q & A

“WHY
ARE THINGS SO HEAVY IN THE FUTURE?
IS THERE A PROBLEM WITH THE EARTH'S
GRAVITATIONAL PULL
?”

26

TMA03 PART 1

•
(1) List of Steps
–

10 marks

•
Include “why”
–

or discuss problems & attempted solutions

•
(2) Suggest two applications
–

5 marks

•
Explain what data used, & why

•
(3) WSI
-
Conformance Report
–

5 marks

•
Include and (briefly) explain its
signficance

•
(4) Working web service
–
10 marks

•
Will be tested in a
RESTful

fashion by browser

•
UDDI Entries and Description
–

10 marks

•
Cut & Paste + description of how to locate


Look carefully at the mark breakdown!

27

TMA03 PART 2

•
(1) Contrasting Architectures
–

10 marks

•
Background information / comparison

•
(2) Web Services for the Company
–

20 marks

•
Specific to the business, NOT generic

•
(3) Tools and Standards
–

10 marks

•
Make justified recommendations, with alternatives

•
(4) Recommendations
–

15 marks

•
Summary and justification (your opinion
-

can disagree)

•
References & Sources
–

5 marks

•
Referencing (as per TMA01)


Look carefully at the mark breakdown!

28

TMA03 TIPS

•
There are no tricks or traps!

•
So don’t look for them…

•
Largely straight forward

•
But don’t leave it too late to start…

•
Word count limits

•
But not too challenging (500 + 1500)

•
Organise your report to help your marker!

•
Follow suggested headings / mark breakdown

•
Carefully read (and follow) “What to submit”

•
Block 3 companion, P.9

29

ANY
QUESTIONS?

“AND
SOON I SHALL HAVE UNDERSTANDING OF
VIDEO CASSETTE RECORDERS AND CAR
TELEPHONES. AND WHEN I HAVE UNDERSTANDING
OF THEM, I SHALL HAVE UNDERSTANDING OF
COMPUTERS. AND WHEN I HAVE UNDERSTANDING
OF COMPUTERS,

I

SHALL BE THE SUPREME
BEING!
”

30

BLOCK 4

PREVIEW

“TELL
ME, FUTURE BOY, WHO'S PRESIDENT OF
THE UNITED STATES IN 1985
?”

“RONALD REAGAN” “
THE ACTOR?
”

31

THE STORY SO FAR

•
By the end of block you will understand “web services”

•
A discrete, re
-
usable “chunk” of functionality with a
dynamically defined interface

•
We can (and people do) use web services in a
conventional programming language

(Java,
Javascript

etc.)

•
Treat it like a “library function”

•
But given its flexible, self defining nature

•
And useful “granularity” (if well designed!)

•
Can we do things at a “higher” level?

•
Less “abstract”, closer to reality (i.e. business)

32

BPMN
–


BUSINESS PROCESS
MODELLING NOTATION

•
Rather than describing what we want to do in a
programming language…

33

Can we draw a helpful

diagram of our business
process?

With BPMN we can!

BPEL
–

BUSINESS PROCESS

EXECUTION LANGUAGE

•
Even better than describing it, can we make it happen?

•
With BPEL we can!

34

And it understands web services!

BLOCK 4 ACTIVITIES

•
We will learn to understand BPMN diagrams

•
And how to turn these into BPEL “programs”

•
Using a nice diagramming tool in Eclipse

•
We will be provided with some example web services

•
Including their WSDL definitions

•
And a simulation engine that allows us to “execute” our
business process, using these web services

•
Also running in Eclipse

•
Watch SOAP messages fly back and forth!

•
See web services invoked on the fly!

•
Test your business logic in operation!

35

BLOCK 4 TMA

•
Hah! Fooled you
–

there isn’t one!


•
BUT


•
Your knowledge of BPEL
WILL

be tested in

the EMA project

•
You
WILL

need to complete this to gain anything more
than a pass grade

•
But there will be nothing required for the project that is not
already covered in the
practicals

•
Although you can take it further if you want to…

36

WHAT
NEXT?

“WHAT
ABOUT ALL THAT TALK ABOUT SCREWING
UP FUTURE EVENTS? THE SPACE
-
TIME
CONTINUUM
?
”

“
WELL
, I FIGURED, WHAT THE HELL
?”

37

THANK YOU FOR
WATCHING!

•
TMA03 Submission date 13
th

June

•
Block 4 Material available 28
th

May

•
EMA Work Plan Submission Date
25
th

July
–

NO EXTENSIONS!

•
Next tutorial: 27
th

August (long break for summer
!)


•
Any
questions or problems email
k.r.wilcox@open.ac.uk

•
Please note: limited tutor availability 29
th

May to 4
th

June

•
If no response, please use global forums!


•
Check the Tutor Group Forum for slides & recordings



38