“IF MY CALCULATIONS ARE CORRECT, WHEN THIS
BABY HITS EIGHTY-EIGHT MILES PER HOUR,
YOU'RE GOING TO SEE SOME SERIOUS SHIT…”
1
TUTORIAL
STARTS
7PM
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!
2
(Note to moderator: Check max. simultaneous talkers)
T320
TUTORIAL
THREE
3
WEB SERVICES, TMA03
PROPOSED AGENDA
• Web Services
•
•
Why?
Why not?
• TMA03 Tips, Q & A
• Block 4 Preview
• Important dates
Any questions,
please click the
“raise your hand”
icon
Then type
question in chat
box
Or use
microphone!
4
• Where are we?
PROPOSED UN-AGENDA(?)
• The practical work
5
• Thoroughly described in Block material
• Excellent support from the appropriate national forums
• Best worked through at your own pace (IMHO)
“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
WHERE ARE
WE?
OVERVIEW
Block 1 – E-Business in context
TMA01
Block 2 – Protocols and Data
TMA02
Block 3 – Web Services
You
Are
Here
TMA03
E
M
A
pt
2
Block 4 – Business Processes
7
EMA pt 1
BLOCK 3
You need to have completed all the practicals before starting
TMA03 Part 1
You need to have read most of the material before starting
TMA03 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
8
(More on the TMA later…)
“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
WEB
SERVICES –
WHY?
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:
11
• Maintainability
• Performance
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“
12
• Little or no conversion required
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“
13
• Maybe a little conversion required
• E.g. floats to double
THE SINGLE COMPUTER MAINTAINABILITY
• Quite hard to change things
• Switching libraries?
• Probably different functions / arguments
• In general, system is rigid / inflexible
14
• But also mostly under the developer’s complete
control
DISTRIBUTED SYSTEM –
FUNCTIONAL DECOMPOSITION
• Most things under developer control
• Except libraries & database
• Design emphasises “division of labour”
• Typically presentation / logic / database
• Typical design concerns
15
• Minimising latency (communication delay)
• Maintainability
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
16
• Remote procedure calls (RPC)
• Object Request Brokers (ORBs)
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
17
• Didn’t really catch on
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
19
• BPEL executable description of a business process
• More of this in block 4
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
20
• Arguments defined at the time of use
• WSDL describes this also
SERVICE ORIENTATED
ARCHITECTURE –
SHARING & DISCOVERY
• Any service available to anyone
• UDDI + WSDL all you need
• Dynamic service end point discovery
• UDDI
• (Theoretically) dynamic choice
21
• Based on cost / response time / quality
• Automatic load balancing / failover
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
22
• Because of high level protocols (e.g. HTTP)
• And standardised data formats (e.g. SOAP)
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
23
• Because of high level protocols (e.g. HTTP GET / POST)
• Can use standardised data formats (e.g. SOAP / JSON)
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
25
• So SOAP / XML / JSON widely used
“WHY ARE THINGS SO HEAVY IN THE FUTURE?
IS THERE A PROBLEM WITH THE EARTH'S
GRAVITATIONAL PULL?”
26
TMA03 TIPS
Q&A
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
Look carefully at the mark breakdown!
27
• Cut & Paste + description of how to locate
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
Look carefully at the mark breakdown!
28
• Referencing (as per TMA01)
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”
29
• Block 3 companion, P.9
“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
ANY
QUESTIONS?
“TELL ME, FUTURE BOY, WHO'S PRESIDENT OF
THE UNITED STATES IN 1985?”
“RONALD REAGAN” “ THE ACTOR? ”
31
BLOCK 4
PREVIEW
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?
32
• Less “abstract”, closer to reality (i.e. business)
BPMN –
BUSINESS PROCESS
MODELLING NOTATION
• Rather than describing what we want to do in a
programming language…
Can we draw a helpful
diagram of our business
process?
33
With BPMN we can!
BPEL –
BUSINESS PROCESS
EXECUTION LANGUAGE
• Even better than describing it, can we make it happen?
And it understands web services!
34
• With BPEL we can!
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
36
• 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…
“WHAT ABOUT ALL THAT TALK ABOUT SCREWING
UP FUTURE EVENTS? THE SPACE-TIME
CONTINUUM?”
“WELL, I FIGURED, WHAT THE HELL?”
37
WHAT
NEXT?
• TMA03 Submission date 19th June
• Block 4 Material available “Early June”
• EMA Work Plan Submission Date 31st July – NO EXTENSIONS!
• Next tutorial: 15th July (For EMA Part 1 + Q&A)
• Any questions or problems email k.r.wilcox@open.ac.uk
• Expect reply within 48 hours
• If no response, please use global forums!
THANK YOU FOR
WATCHING!
38
• Check the Tutor Group Forum for slides & recordings