380 likes | 533 Views
“If my calculations are correct, when this baby hits eighty-eight miles per hour, you're going to see some serious shit…”. 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
E N D
“If my calculations are correct, when this baby hits eighty-eight miles per hour, you're going to see some serious shit…” TutorialStarts7PM
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)
T320TutorialTHREE Web Services, TMA03
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!
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)
“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” Where Are We?
Overview E M A pt 2 Block 1 – E-Business in context TMA01 Block 2 – Protocols and Data TMA02 You AreHere Block 3 – Web Services TMA03 Block 4 – Business Processes EMA pt 1
Block 3 • You need to have completed all the practicalsbefore starting TMA03 Part 1 • You need to have read most of the material beforestarting 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…)
“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.” 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”)
The Single Computer -Functional Decomposition • Everything is under developer control • Problem typically broken down intodiscrete functional blocks • Typical design concerns: • Maintainability • Performance
The Single Computer -Communication Protocols • Typically a single programminglanguage is used • So data representation is consistent • Data passed in function calls • Or shared memory • Everything is “internal“ • 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“ • 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 • But also mostly under the developer’s completecontrol
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
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)
Distributed System –Sharing and Discovery • Typically, each layer is “fixed” in relationeach 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
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!)
Service Orientated Architecture –Functional decomposition • System broken down into discrete,re-usable “services” • With scalability benefits • High level design of system in termsof these lower level services • 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 • 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 • 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 servicedefined 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)
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)
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?”
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
“Why are things so heavy in the future? Is there a problem with the Earth's gravitational pull?” 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 • Cut & Paste + description of how to locate • Look carefully at the mark breakdown!
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!
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
“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!” Any Questions?
“Tell me, Future Boy, who's President of the United States in 1985?”“Ronald Reagan” “The ACTOR?” Block 4Preview
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)
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? With BPMN we can!
BPEL –Business ProcessExecution Language • Even better than describing it, can we make it happen? • With BPEL we can! 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!
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…
“What about all that talk about screwing up future events? The space-time continuum?” “Well, I figured, what the hell?” What Next?
Thank you for watching! • TMA03 Submission date 19thJune • Block 4 Material available “Early June” • EMA Work Plan Submission Date 31stJuly – 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