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
Enter the password to open this PDF file:
File name:
-
File size:
-
Title:
-
Author:
-
Subject:
-
Keywords:
-
Creation Date:
-
Modification Date:
-
Creator:
-
PDF Producer:
-
PDF Version:
-
Page Count:
-
Preparing document for printing…
0%
Σχόλια 0
Συνδεθείτε για να κοινοποιήσετε σχόλιο