The original Powerpoint Slides - Karl Wilcox

joeneetscompetitiveSecurity

Nov 3, 2013 (4 years and 4 days ago)

83 views

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