CS 4720

Web Services and Service Oriented Architecture

CS 4720 – Web & Mobile Systems

CS 4720

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

CS 4720

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

CS 4720

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

CS 4720

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

CS 4720

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

CS 4720

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

CS 4720

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

CS 4720

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

CS 4720

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

CS 4720

Architecture

11

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

CS 4720

What are we actually trying to do?

12

Receive PO

Get Items from InventoryUpdate Customer Profile

Compute Subtotal

Compute Shipping Cost

Compute Export Tax

Compute International Shipping

Compute Total

[ship within US] [ship outside US]

Ship Order

Fork

Join

Branch

Merge

CS 4720

OSI Model

13

CS 4720

OSI Model

14

CS 4720

The Stack

15

CS 4720

The Stack

16

BPEL4WSOWL-S ServiceModel

ebXMLCPA

Process and workfloworchestrations

QoS: Servicedescriptions and bindings

Contracts andagreements

XLANGWSCL

WSDL ebXMLCPP

ebXMLBPSS

XML, DTD, and XML Schema

HTTP, FTP, SMTP, SIP, etc.

SOAP ebXMLmessaging

OWL

UDDI ebXMLRegistries

WSCLWSCI

WS-Coordination

WS-AtomicTransaction and WS-BusinessActivity

OWL-S ServiceGrounding

OWL-S ServiceProfile

BTP

BPML

Discovery

Messaging

Transport

QoS: Conversations

QoS: Choreography

QoS: Transactions

Encoding

WS-Policy

WS-Security

WS-ReliableMessaging

PSL

RDF

CS 4720

The Stack

17

CS 4720

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

CS 4720

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

CS 4720

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

CS 4720

SOAP Model

21

CS 4720

SOAP Model

22

CS 4720

SOAP RequestPOST /InStock HTTP/1.1Host: www.example.orgContent-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:GetStockPrice>    <m:StockName>IBM</m:StockName>  </m:GetStockPrice></soap:Body>

</soap:Envelope>

23

CS 4720

SOAP Response• HTTP/1.1 200 OK

Content-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

CS 4720

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

CS 4720

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'll call it! POX!”

26

CS 4720

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

CS 4720

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

CS 4720

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

CS 4720

Thoughts• If you want a great experience for .NET/Java devs,

you'll typically publish schemas and support SOAP. • If you want a great experience for LAMP folks, you'll

support POX messages (or JSON) and will provide a non-XSD description of your formats.

• If you want to reach both audiences, you'll do both #1 and #2.

• If you want to reach both audiences before your competition does, you'll avoid indulging in religious debates and ship something.

30

CS 4720

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

CS 4720

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

CS 4720

Enter WSDL

33

CS 4720

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

/ch06.html

34

CS 4720

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

CS 4720

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

CS 4720

The Original Idea

37

CS 4720

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

CS 4720

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

39

CS 4720

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

CS 4720

The Basic Idea

41

CS 4720

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

k

42

CS 4720

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

CS 4720

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

44

BPEL4WSOWL-S ServiceModel

ebXMLCPA

Process and workfloworchestrations

QoS: Servicedescriptions and bindings

Contracts andagreements

XLANGWSCL

WSDL ebXMLCPP

ebXMLBPSS

XML, DTD, and XML Schema

HTTP, FTP, SMTP, SIP, etc.

SOAP ebXMLmessaging

OWL

UDDI ebXMLRegistries

WSCLWSCI

WS-Coordination

WS-AtomicTransaction and WS-BusinessActivity

OWL-S ServiceGrounding

OWL-S ServiceProfile

BTP

BPML

Discovery

Messaging

Transport

QoS: Conversations

QoS: Choreography

QoS: Transactions

Encoding

WS-Policy

WS-Security

WS-ReliableMessaging

PSL

RDF

CS 4720

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

CS 4720

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

CS 4720

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

CS 4720

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

CS 4720

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

CS 4720

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

CS 4720

Thanks• Many thanks to Ken Anderson @ Colorodo for

some of this information• Some info also from the fine folks at Wikipedia• http://www.pluralsight.com/community/

blogs/dbox/archive/2006/02/17/18869.aspx• This slide deck brought to you by the letter “∫”

and the number “awesome.”

51