Web Services and Service Oriented Architecture

1. Web Services and Service Oriented Architecture CS 4720 – Web & Mobile Systems

2. The traditional software model • Organizations build it all from scratch • “We can't trust anyone! Our competitors will sabotage us!” • “We must own everything! Hardware and software!” • Companies that build software need components that do X or Y… • … so they buy COTS components • Service contracts, new releases, regression testing… 2

3. The traditional software model • How well does this work? • Some project data from the DOD: • 47% of software delivered could not be used • Usually didn't meet requirements • 29% of funded software never delivered • Usually canceled due to cost/schedule overruns • 19% of software useful after extensive rework • Costs 36 times more to fix problems after release 3

4. A push to distribution • “We're really good at __________, how can we get our __________ out for people to use?” • The idea of distributed computing • “We're good at X, but not so good a Y…” • “What if we got someone to help us with Y… but in a way that we didn’t have to include any fancy libraries… • … and we could use them in web apps! And mobile devices! And even desktop apps!” 4

5. A Web Service • From W3C: “a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards” 5

6. A Web Service? • Huh? • A bit more simply: A program, accessible via the Internet, that can do some function (either for free or a fee) and can be dynamically discovered and used. • So… I use web apps all the time… are those web services? 6

7. Web Service as RPC • The earliest form of a true “web services” was an RPC – remote procedure call. • Exactly what it sounds like – there is an exposed function/method that is accessed via the web where you pass the parameters and the method name and you get back a return value. • Notice how this is very different from the RESTful model (verbs vs. nouns) 7

8. Web Service as SOA • RPC was okay… but it turned out to be a bit more language specific than we'd like • What if we just a structured message (like an XML document) that described what we wanted, as opposed to knowing the exact function call? • This is the basis of the Service-Oriented Architecture 8

9. Word By Word • What is a service? • "A service is a discoverable resource that executes a repeatable task, and is described by an externalized service specification.” • Business alignment – business requirements • Specifications – self-contained, well specified • Reusability – general enough to be reused • Agreements – based on function, not platform • Hosting and discoverability – available • Aggregation – can be combined to make bigger services 9

10. Word By Word • What is an architecture? • "A formal description of a system, or a detailed plan of the system at component level to guide its implementation.” • “The structure of components, their interrelationships, and the principles and guidelines governing their design and evolution over time." 10

11. Architecture • Architecture is: • A high-enough level of abstraction that the system can be viewed as a whole and yet still provides enough information to make decisions. • Supports the functionality of the system. • All implementation details are hidden. • Service orientation is a way of integrating a business as a set of linked services. 11

12. What are we actually trying to do? 12

13. OSI Model 13

14. OSI Model 14

15. The Stack 15

16. The Stack 16

17. The Stack 17

18. SOA – The Quick Version • Right now, you probably think of a software system as being a collection of classes / objects • But users don't think of systems like that… they think of systems as sets of functionality that help them do something • So… why do we use objects? • Easier to model • Easier to program • Easier to explain to other programmers 18

19. Or is it actually easier? • Turn our idea of a system 90 degrees • Functionality objects (procedural abstraction) is the key idea, not world objects (data abstraction) • This is the key in SOA • An SOA system has the functionalities as the main players, not the objects themselves • But more so, these services are provided by many different players 19

20. But what language do we speak? • SOAP - Simple Object Access Protocol • A communication protocol • A format for sending messages • Platform independent • XML based • Follows the rules that allow for transmission easily over HTTP, SMTP, etc. • Not really much more than an HTTP request that follows XML/SOAP standards 20

21. SOAP Model 21

22. SOAP Model 22

23. SOAP Request POST /InStock HTTP/1.1 Host: www.example.org Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn<?xml version="1.0"?><soap:Envelopexmlns:soap="http://www.w3.org/2001/12/soap-envelope"soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"><soap:Body xmlns:m="http://www.example.org/stock">  <m:GetStockPrice>    <m:StockName>IBM</m:StockName>  </m:GetStockPrice></soap:Body></soap:Envelope> 23

24. SOAP Response • HTTP/1.1 200 OKContent-Type: application/soap+xml; charset=utf-8Content-Length: nnn<?xml version="1.0"?><soap:Envelopexmlns:soap="http://www.w3.org/2001/12/soap-envelope"soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"><soap:Body xmlns:m="http://www.example.org/stock">  <m:GetStockPriceResponse>    <m:Price>34.5</m:Price>  </m:GetStockPriceResponse></soap:Body></soap:Envelope> 24

25. Parts of SOAP • The Envelope – required root element defining the document as being a SOAP request • The Header – not required, but contains authentication and/or payment info for the request • The Body – the actual message being sent 25

26. But I like to be dirty! • …. • Bad title aside, some didn't like to be “tied down” by such “conservative talk” of having to follow the SOAP rules! • “It's just XML!” they said. “I don't need of this extra stuff! Just good Plain Old XML…!” • “And that's what we'llcall it! POX!” 26

27. What's the difference? • Following the agreed upon rules… • Validating POX can be hard; SOAP is comparably easy • SOAP services are better at being dynamically bound • How we do this is Thursday's lecture 27

28. After all this… What about REST? • REST is an architectural style that is independent, but compatible, with XML • POX/HTTP means exchanging plain old XML documents over HTTP; can be RESTful • SOAP is a standard document format for building high-level protocols. Anything that uses SOAP is (by definition) not just using plain old XML, and thus not POX; it can also be RESTful 28

29. So… • So there can be RESTful SOAP applications, and RESTful POX applications, and non-RESTful SOAP applications, and non-RESTful POX applications, but no POX/SOAP combination… sort of 29

30. Thoughts • If you want a great experience for .NET/Java devs, you'lltypically publish schemas and support SOAP. • If you want a great experience for LAMP folks, you'llsupport POX messages (or JSON) and will provide a non-XSD description of your formats. • If you want to reach both audiences, you'lldo both #1 and #2. • If you want to reach both audiences before your competition does, you'llavoid indulging in religious debates and ship something. 30

31. Using a Web Service • If you took the time to create a service, then you probably want people to use it • In order to use a service, users need to know what information they can send the service and what information is going to be sent back • What would be even better is if the software could do all this automatically… 31

32. Enter WSDL • WSDL: Web Services Description Language • An XML document used to give the specifics of a service • Location • Methods • Allowed messages • Potential error messages 32

33. Enter WSDL 33

34. The HelloService Example • http://oreilly.com/catalog/webservess/chapter/ch06.html 34

35. Quick Sidestep: UDDI • UDDI: Universal Description, Discovery and Integration • A solution in search of a problem • The idea is okay: a language and schema for allowing people to publish their WSDL schemas so that others can discover their services • IBM, Microsoft, and SAP announced they were closing their public UDDI nodes in January 2006 • No one used it! 35

36. Quick Sidestep: UDDI • Where might it work decently? • Perhaps inside a single organization for internal code • The public sides were either: • Empty • Overrun with junk • Whichever it was UDDI, isn't really used • Quote Marty Humphrey: “It was a good problem to solve, but a terrible solution.” 36

37. The Original Idea 37

38. Back to WSDL • We DO use WSDL though • It is how a web service is bound to an application • It's more XML… which kinda sucks… • But… the best part is… 38

39. The Best Part about WSDL • No one ever writes the stuff themselves! • It's auto-generated! 39

40. BPEL • Business Process Execution Language • Standard executable language for specifying interactions with Web Services • Basic goal: an “execution language” to write “systems” by tying available web services together 40

41. The Basic Idea 41

42. Video • http://www.youtube.com/watch?v=XRzTySj-aak 42

43. Okay… so… • In a SOA… • Every function is a service • Every service is independent • Each service can talk to other services through a specified protocol (SOAP) • Each service defines what messages it can deal with through a specified protocol (WSDL) • Services can announce themselves to everyone else (UDDI or some other publishing scheme) • And services can be bundled into processes (BPEL) 43

44. That was exhausting… • Oh, it gets better. Look at all the QoS stuff… 44

45. What could possibly go wrong? • QoS: Quality of Service • Availability (MTTR): is it up? • Accessibility: if it's up, can I get to it? • Conformance to Standards: play by the rules? • Integrity: actually does what the WSDL says? • Performance: how fast does it come back? • Reliability: how does it handle failures? • Scalability: how does it handle lots of requests? • Security: what about all my data flying around? • Transactions: if one part fails, does it all fail? 45

46. Bring in the lawyers • Service Level Agreements • Web services can come with contracts between the provider and the consumer that specify the requirements of the previous slide • Basically will boil down to how it will handle: • Performance and capacity • Availability • Security/Privacy • There are protocols for this too! 46

47. BAH! Is it worth it? • Verizon thinks so: • Rebuilt fraud detection system into BPEL from J2EE • Used Oracle's BPEL Process Manager system • Original system: • Three large DBs consisting of 2.5 billion records • Team of 100 47

48. BPEL-arific • Tossed all the Java • Now it's one Shockwave (Flash) and one JSP page on top of the BPEL • Flash makes web services calls into the BPEL processes • All business rules written into the BPEL language • Web 2.0 UI 48

49. BPEL-arific • New code base is 0.5% of original size • 192 processor cores down to a single 8-core server • Energy consumption down 99% • 20 terabytes of DB to 64 gigabytes 49

50. According to Verizon • Based on event-driven architecture, data on cell phone usage coming from the Verizon switches is analyzed and checked for business exceptions, Chappell explains. He site examples of possible fraud including business exceptions such as the detection of excessive data thresholds. This might indicate that someone is doing "phone cloning" to make calls by stealing a customer's account information. When this sort of exception is detected, an event starts a BPEL process. • With the SOA implementation, Chappell explains "the BPEL process invokes a number of services, which includes going out directly to the source of the call detail records to get the information necessary to enrich the event data. It is then fed into a rules engine to check for violations, make decisions based on policy, and then on to generate more detailed reports." • Using this services approach rather than data warehousing to retrieve and process the required information reduces the storage requirements. 50