Week01 Annotated

37
02267: Software Development of Web Services Week 1 Hubert Baumeister [email protected] Department of Applied Mathematics and Computer Science Technical University of Denmark Fall 2013

Transcript of Week01 Annotated

02267: Software Development of WebServices

Week 1

Hubert [email protected]

Department of Applied Mathematics and Computer ScienceTechnical University of Denmark

Fall 2013

Contents

Course IntroductionCourse GoalPractical InformationDistributed ITService Oriented ArchitectureWeb Services

What is this Course About?

I Web Services & Service Oriented ArchitectureI 5 ECTS pointsI Complementary courses

I 02221/02222 on distributed systems

Goals of this course

I Knowledge aboutI What are Web services and Service-Oriented Architecture

(SOA)I Technologies and standards for Web services

I e.g. XML, SOAP, WSDL, . . .I Web service extensions

I Able to evaluateI When to use Web services and SOAI What are the problems when using Web services and what

are possible solutionsI Able to do

I Implementation of Web services (simple and composite)I including writing of XML Schema documents (XSD), WSDL,

BPEL

Topics not addressed in this course

I Web services are basically a computer to computertechnology

I using technologies also used with Web applicationsI Therefore, the following topics won’t be addressed in this

courseI HTML, Content Management Systems, JSON, Javascript,

JSP, ASP, Python, Perl, How servelets work,MS-Sharepoint, API’s for social networking (i.e.OpenSocial) or location aware services, OAuth

I Other topics not addressed in the courseI Connection to databases (e.g. JDBC), Programming

languages like Java or C#

Course Prerequisites

I Programming language: JavaI Operating system knowledge

I Examples and exercises use Unix (Linux / FreeBSD) orWindows

I Software needs to be installedI Shell commands; Shell-scripts need to be written or

adaptedI Basic knowledge of Internet technologies: XML, HTML,

Sockets, TCP, ...

Practical Information I

I Workload: 5ECTS = 9 hours / weekI 90min lecture (2 * 45min + 10min break)I 90min tutoring sessionsI 5 hours self study→ Additional reading tasks→ You need to work on the exercises outside of the tutoring

sessionsI Lectures 8:30—10:15 on MondayI Tutoring sessions 10:15–12:00 in E-Databar: Rooms 003

and 015 in Building 341I Exercises are not mandatory

I but help prepare for the exam project

Practical Information II

I How to reach meI E-Mail: [email protected] Room: 303B/058

I Course Web PageI http://www.imm.dtu.dk/courses/02267

I SoftwareI Java 6/7 (JDK), OpenESB 2.3 (Netbeans (IDE) and

Glassfish (Application Server))I http://www.open-esb.org

Grading

1. Project workI 5 weeks (week 44—49)I Teams of 4—6 (Team building week 44 (participation is

mandatory))I Implementing Web services (simple and composite)I Writing a report

2. Project presentation by the project teamsI Project presentation (≈ 10min) + questions: total 45 minI Dates Monday—Wednesday week 51 (16— 18.12)

Literature

I Michael P. Papazoglou, Web services: Principles andTechnolgoy, Pearson Education Limited, 2008

I plus additional literature throughout the course

Example: Purchase Order

The customer wants to purchase some goods (via the Internet)1. Customer contacts the supplier and orders the goods2. Sales department check with credit card department if

credit is okay3. Sales department check with inventory department if the

goods are on stock4. Sales department informs the billing department to bill the

customer5. Sales department informs the shipment department to

send out the goods6. Shipment department sends the goods to customer7. Shipment department informs the billing department to

send the invoice8. Billing department sends the invoice to the customer

Classical distributed IT (I)

I Purchase order is a business process involving different ITsystems

I Components in an IT infrastructureI Legacy systemsI Application serverI Database serverI Web serverI Clients: Web browser, thin client, fat client

I GoalI Automation of business processesI Business processes span all of these systemsI Different IT system use different technologiesI How to connect all these parts in a uniform way technically

and semantically?

Classical distributed IT (II)

I ProblemsI Different technologies CORBA, EJB, .NET, COM/DCOMI No well defined interfacesI Ad-hoc combination

Classical distributed IT (III)

I SolutionI Unifying view representing IT to the outside IT world→

Service-Oriented Architecture (SOA)I Use Internet standards→Web service

Example: Purchase Order II

The customer wants to purchase some goods (via the Internet)1. Customer contacts the supplier’s Web site and orders the

goods2. The Web site uses the process sales service to actually

order the goods3. The process sales service contacts the credit card service

to check the customer’s credit4. The process sales service calls the check inventory

service to check if the goods are on stockI . . .

Example: Purchase Order III

I The IT systems of each department offer services→ simple (Web) services

I The purchase order business process is itself a serviceoffered to the customer which uses the services of theother IT systems→ composite (Web) service

Global Computing Challenge (I)

I IT integration between IT systems of different companiesI Business to BusinessI Loose coupling

I In addition to the problems of a distributed IT infrastructure:

I Firewalls: block most of TCP/IP ports for security reasons

SOA (Service Oriented Architecture)

I Automate business processesI within a companyI across companies

→ Services (SOA)→ Web standards (e.g. XML, HTTP, . . . )

Service-Oriented Architecture (SOA)

I A set of principles for organising the softwareI Not restricted to the use of Web services

I Web servicesI OSGi servicesI Grid servicesI Cloud servicesI . . .

SOA Principles (I)

I Loose couplingI Services represent self contained units of logic (one

function or a set of functions) which are relativelyindependent

→ ResusabilityI Discoverablity

:Service Registry

:Service Provider:Client

SOA Principles (II)

I Abstract service description (independent ofimplementation)

I Encapsulation (autonomy and abstraction)I CompositionalityI And additional for Web services

I Based on open standardsI Vendor neutral / vendor diversity

Service invocation vs. function call

Function callI Within the same processI Function is always

availableI Takes almost no timeI Focus on single calls

Service invocationI Across processes,

computers, networksI Takes time (several

magnitudes more than afunction call)

I May failI Several service invocation

may form a dialog

Service invocation vs. function call

Function callI Within the same processI Function is always

availableI Takes almost no timeI Focus on single calls→ Fine grained→ Tight coupling→ Simple data as parameters

Service invocationI Across processes,

computers, networksI Takes time (several

magnitudes more than afunction call)

I May failI Several service invocation

may form a dialog→ Coarse grained→ Loosely coupled→ Complex data, documents,

as parameters

Web Services

Solutions for the global computing problemI Firewalls→ Communication via HTTP using XML messages→ SOAP

I Different technologiesI n interfaces (x , y ↔Web services)I instead of n2 for x ↔ y .→ Use of Internet standards

Integration Scenario

Basic idea of Web services

I Exchange of messagesI Messages are encoded using XML

→ SOAPI Using standard protocols to transport messages

→ HTTP, SMTP, . . .I Message can be sent:

I One-way: Call the service, but don’t expect an immediateanswer→ asynchronous messaging

I Request / response: Call the service and wait for theresponse

I most common styleI synchronous messaging

The history of Web services

I Internet (70’s, 80’s)I Web (90’s)I Extensible Markup Language (XML) (98)I Simple Object Access Protocol (SOAP) (2000)I Description of the REST architecture principle behind the

HTTP protocol (Roy Fielding) (2000)I Web Service Description Language (WSDL) (2001)

Success of Web services . . .

I SOAP is based on XMLI SOAP messages have a simple structure:

<soapenv:Envelope><soapenv:Body>

<ns1:srrequest><ns1:action>register</ns1:action><ns1:student>

<ns1:name>Søren Helmersen</ns1:name></ns1:student>

</ns1:srrequest></soapenv:Body>

</soapenv:Envelope>

I SOAP messages are transported by HTTP or SMTP

. . . Consequences . . .

→ It is easy to generate SOAP messages→ Only a XML parser is needed for parsing the messages→ Web server technology can be reused for Web services

(e.g. cgi-bins and servlets)→ Easy to provide Web services in any programming

language→ Easy to use Web services in any programming language

and operating system

. . . But

I Message contents / data encoding is not standardisedI WSDL and XML Schema help with that

I Simple messageing model: Support needed, e.g., forI SecurityI Meta information (Authorization, Authentification, Dialogs,

. . . )I . . .

Demo: A simple Web service

1. Creating a simple HelloWorld Web service in Javaprepending Hello to its input

2. Deploying the Web service on a Web server (GlassFish)3. Calling the Web service from Java4. Calling the Web service from Ruby

What we are going to study in this course

I Message structure: SOAPI Description of Web services: WSDL (Web Service

Description Language)I http://www2.imm.dtu.dk/courses/02267/examples/

week01/WSDL.wsdl

I Discovery of Web services: UDDI (Universial Description,Discovery, and Integration), WSIL (Web Service InspectionLanguage)

Web service composition and . . .

I How is a Web service constructed from others

I IssuesI Long running business processesI Transaction: What to do when something goes wrong→

Compensation Handler

. . . Web service coordination

I How do different Web services play together

I Planned→ Orchestration→Web service CompositionI Ad-hoc: Each participant has to follow rules→

Choreography

Security

I Problem: In principle SOAP messages can be read byanybody and modified by anyone

I One possibility is that the transport layer ensures privacyand authenticy→ HTTPS

I Other possibility: SOAP message itself contains securityfeatures→ WS-SecurityI Message parts can be encryptedI Message parts can be signedI http://www2.imm.dtu.dk/courses/02267/examples/

week01/security.xmlI What parts need to be encrypted and signed?

I Other security properties: Trust, . . .

WS-* Standards: Addressing, ReliableMessaging,Policy, . . .

I There are hundreds of standards addressing shortcomingsof the simple WS model

I AddressingI SOAP messages itself do not contain information about to

whom the message is addressed or from whom themessage is sent

I Reliable MessagingI Reliability depends partly on the transport protocol (e.g.

HTTP partly reliable, SMTP not reliable: messages can belost)

I PolicyI What properties has a Web service: Performance, Cost,

support for WS-security, WS-Addressing, e.t.c.

Contents of the course1. Introduction to Web services and SOA2. Basic technologies: XML, XML Schema, . . .3. Basic Web service technology: SOAP, . . .4. Describing Web services: WSDL5. Development of Web Services: Bottom up, top down

development, generating compositions from coordinations,. . .

6. Finding Web services: UDDI, WSIL, . . .7. RESTful Web services8. Composing Web services: BPEL9. Coordinating Web services: WS-Coordination, WS-CDL,

. . .I Long running transactions: WS-AtomicTransaction,

Compensation, . . .

10. Security: WS-Security, . . .. . .