1

TUTORIALSTARTS7PM

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

2

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)

3

T320TUTORIALTHREEWEB SERVICES, TMA03

4

PROPOSED AGENDA• Where are we?

• 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!

5

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)

6

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”

7

OVERVIEW

Block 1 – E-Business in context

Block 2 – Protocols and Data

Block 3 – Web Services

Block 4 – Business Processes

TMA01

TMA02

TMA03

EMA

pt2

EMA pt 1

YouAre

Here

8

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

(More on the TMA later…)

9

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.”

10

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”)

11

THE SINGLE COMPUTER -FUNCTIONAL DECOMPOSITION• Everything is under developer control

• Problem typically broken down intodiscrete functional blocks

• Typical design concerns:

• Maintainability• Performance

12

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

13

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

14

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 completecontrol

15

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

16

DISTRIBUTED SYSTEM –COMMUNICATION PROTOCOLS• Probably very low level

• E.g. “sockets” - a simple pipe for binarydata

• 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)

17

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

18

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

(Movie quotes clue!)

19

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

20

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

21

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

22

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)

23

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)

24

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?”

25

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

26

TMA03 TIPS Q & A

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

27

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!

28

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!

29

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

30

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!”

31

BLOCK 4PREVIEW

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

32

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)

33

BPMN – BUSINESS PROCESS MODELLING NOTATION

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

Can we draw a helpfuldiagram of our business process?

With BPMN we can!

34

BPEL –BUSINESS PROCESSEXECUTION LANGUAGE

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

• With BPEL we can!

And it understands web services!

35

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!

36

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…

37

WHAT NEXT?

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

“WELL, I FIGURED, WHAT THE HELL?”

38

THANK YOU FOR WATCHING!

• 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!

• Check the Tutor Group Forum for slides & recordings