563.4 Web Services

1
563.4 Web Services

• Presented by Carl A. Gunter
• University of Illinois
• Spring 2006

2
Todays Web

• Designed for applications involving human
  interactions
• Intended purpose
• Information sharing a distributed content
  library
• Enabled B2C e-commerce
• Non-automated B2B interactions
• How did it happen?
• Built on very few standards http html
• Simple interaction model very few assumptions
• Result was ubiquity

3
Whats Next?

• Improve machine-to-machine protocols to enable
  more automation.
• Use a readily-extensible foundation.
• Build in security from the start.
• Overcome limits to widespread web deployment of
  Corba, DCOM, etc.

4
Web Services

• Strategy use XML as a foundation for both
  infrastructure and application formats.
• Build a stack of XML-based processing layers.
• Create XML-based security mechanisms that
  integrate with existing approaches (e.g. X.509).

5
Typical Web Service Components
6
Web Services Architecture
UDDI Universal Description, Discovery, and
Integration

• Provide a Directory of Services on the Internet

WSDL Web Services Description Language

• Web Services are defined in terms of the formats
  and ordering of messages

SOAP

• Web Services consumers send and receive SOAP
  messages

XML HTTP

• Built using open Internet protocols

7
XML

• Extensible Markup Language
• Meta language that
• Allows to create and format own document markups
• A method for putting structured data into a text
  file
• - easy to read
• - unambiguous
• - extensible
• - platform-independent

8
Sample XML Example

• lt?xml version1.0 encoding?gt
• ltmsgmessage fromid toid xmlnsmsgURI
  xmlnspoURIgt
• ltmsgtextgt
• Hi please bill to the following address
• lt/msgtextgt
• ltmsgitemgt
• ltpopo id123gt
• ltpobilltogt
• ltpocompanygt Skateboard lt/pocompanygt
• ltpostreetgt One Warehouse Park
  lt/postreetgt
• ltpocitygt Boston lt/pocitygt
• lt/pobilltogt
• lt/popogt
• lt/msgitemgt
• lt/msgmessagegt

9
XML Declaration

• lt?xml version1.0 encoding?gt
• lt?xml ?gt the XML declaration
• Not required, but typically used
• Attributes include
• Version
• Encoding the character encoding

10
XML Element

• ltmsgmessage fromid toid
  xmlnsmsgURI xmlnspoURIgt
• ltmsgtextgt
• Hi please bill the following
• lt/msgtextgt
• ltmsgitemgt
• ltpopo id123gt
• lt/popogt
• lt/msgitemgt
• lt/msgmessagegt

11
XML Attribute

• ltmsgmessage fromid toid xmlnsmsgURI
  xmlnspoURIgt
• ltpopo id123gt
• lt/popogt
• lt/msgmessagegt
• XML Attribute
• Describes additional information about an element
• lttag keyvaluegt textlt/taggt

12
XML Namespaces

• ltmsgmessage fromid toid
  xmlnsmsgURI xmlnspoURIgt
• lt/msgmessagegt
• Namespaces
• Not mandatory, but useful in giving uniqueness to
  an element
• Declared using the xmlnsname value

13
SOAP

• An XML envelope for XML messaging
• Headers body
• SOAP is transport independent
• Supports both messaging and RPC

SOAP Envelope
SOAP Header encoding, authentication,
transaction information, etc.
SOAP Body
SOAP Body Block parameters, return values, etc
SOAP Fault
14
SOAP Message Example

• lt?xml ?gt
• ltSOAP-ENVEnvelope xmlnsSOAP-ENVURI gt
• ltSOAP-ENVHeadergt
• lttTransaction xmlnstURI
• SOAP-ENVmustUnderstand1 gt
• 12345
• lt/tTransactiongt
• ltpPriority xmlnspURIgt
• Very High
• lt/pPrioritygt
• lt/SOAP-ENVHeadergt
• ltSOAP-ENVBodygt
• XML Document
• lt/SOAP-ENVBodygt
• lt/SOAP-ENVEnvelopegt

15
AMPol Project

• Adaptive Messaging Policy Project concerns
  next-generation messaging systems with improved
  security, flexibility, and integration.
• Principal activities
• WSEmail
• Dynamic policy adaptation
• Attribute-Based Messaging (ABM)

16
AMPol Principal Activities

• WSEmail
• Dynamic policy adaptation
• Attribute-based messaging

17
Internet Email

• Based on a collection of protocols
• SMTP, POP, IMAP, S/MIME
• Evolved over a vast installed base
• Shortcomings
• Flexibility
• Security
• Integration

18
Approaches to Improvement

• Make incremental changes and overlays for the
  existing protocols
• Redesign the system from a low level
• Example instant messaging
• Create a design from another high-level
  foundation
• Example use HTTP and SSL

19
WSEmail Project

• Began at Penn with support from Microsoft
• Aim use web services as a new foundation for
  email as a way to improve security, flexibility,
  and integration
• Ongoing project at both UIUC and Penn

• Applications
• Instant messaging
• Routed forms
• On-demand attachments
• Theory
• Using Proverif and TuleFale
• Performance
• .NET implementation on a small testbed

Lux May Bhattad Gunter 05
20
Application Integrated IM
21
Application Routed Forms
22
Implementation

• WSEmail implemented over .NET framework with Web
  Services Enhancement (WSE)
• Messages stored on SQL Server 2000
• Version 1.0 has
• 68 interfaces
• 343 classes
• 30 projects
• C .NET-managed code created with MS Visual
  Studio
• DNS SRV records used for routing.

23
WSEmail Test-bed
Machines Pentium4 Network 100Mb switched
Ethernet Client Machines 2.8GHz, 512MB
RAM Server (Si) 2.8GHz, 1GB RAM Database (Sdb)
2.4GHz, 1GB RAM Internet Emulator (Se) 2.8GHz,
512MB RAM
24
Parameters

• Each client will send 2000 requests to Si
• Operations send message, list headers, retrieve
  message, delete message (each with equal chance)
• Sent messages include local recipient (a user on
  Si) and an external recipient (a user on Se).

• Test coordinator holds test parameters that
  clients receive and parse
• Message database is pre-populated with a few
  entries
• Test coordinator signals test start
• Clients non-deterministically pick an action to
  perform, based on upon test parameters

25
Results

• Average latency .274 sec / msg
• Rate of 1786 msg / min
• Client machines sent 36.4MB and received 369.4MB
• Test took 1824 sec to execute

• Benchmark comparison to SMTP on our machines
  showed .170 sec / msg with messages of similar
  size
• Benchmark UW Parkside peak usage figures were
  1716 msg / min

26
Performance Results

• Average latency .274 sec / msg
• Rate of 1786 msg / min
• Client machines sent 36.4MB and received 369.4MB
• Test took 1824 sec to execute

• Benchmark comparison to SMTP on our machines
  showed .170 sec / msg with messages of similar
  size
• Benchmark UW Parkside peak usage figures were
  1716 msg / min

27
Theory

• On Demand Attachments Protocol
• Nine messages, four parties
• Complex messages
• Want to prove that receiving an attachment means
  it was sent by the sender in the from field

28
AMPol Principal Activities

• WSEmail
• Dynamic policy adaptation
• Attribute-based messaging

Afandi Zhang Hafiz Gunter 06
29
Policy Adaptation

• Large-scale systems often cannot operate under a
  uniform policy
• Scalability can be aided by allowing parties to
  express policies that must be satisfied in
  interactions
• Apply this idea to messaging systems to achieve
  adaptive messaging policy
• Case study for email based on WSEmail

30
Architectural Components

• Policy Model
• What policies can be expressed
• Our instantiation AMPL and APES (Attachments,
  Payment, Encryption, Signature)
• Policy Discovery
• Policy merging
• Policy Query Protocol (PQP)
• Extension and Enforcement
• Conformance
• Extension
• Enforcement

31
Policy Architecture
RMTA
SMTA
Egress Policies
Merged Policies
Ingress Policies
Client Policies
Recipient
Sender
32
Policy Architecture
RMTA
SMTA
Merged Policies
Recipient
Sender
33
Policy Architecture
RMTA
SMTA
Egress Policies
Ingress Policies
Client Policies
Recipient
Sender
Plug in Server
34
Demo

• A message from Afandisandy1 to Afandigary1
• Two MTAs
• Afandisandy1s egress policy is HashCash (cycle
  exhaustion)
• Afandigary1s ingress policy includes RTT
  (Reverse Turing Test) and Identity-Based
  Encryption (IBE)
• Run demo

35
AMPol Principal Activities

• WSEmail
• Dynamic policy adaptation
• Attribute-based messaging

Bobba Fatemieh Kahn Gunter Khurana 06
36
Problem and Approach

• Problem
• Limited scope for targeted messaging
• Unwanted messages

• Approach
• Target messages based on recipient attributes
• Create recipient lists dynamically

37
Scenarios and Challenges

• Scenarios
• Address all faculty going on sabbatical next term
• Address all the people working on security
  related projects in an organization
• Address all TeraGrid system administrators
• Address doctors in the tri-state area who have
  expertise in a specific kind of operation

• Challenges
• User attribute assimilation and query
• User privacy
• Access rights
• Inter-domain messaging
• Attribute mapping
• Privacy policy
• AAA

38
Architecture
Domain A
39
Phase 1 Architecture
PDP
XACML
Engine
Policy
.
Policy Specialization Path
xml
Web Server
WEB Interface
ABM Host
XML DB
Address Resolution Path
MUA
Send Mail
Run Demo
40
Phase I

• Attribute assimilation and query
• Native XML attribute database
• XQuery
• Privacy and privileges
• Restricted access to attributes
• Policy specification and enforcement using XACML
• Performance evaluation
• 60,000 users and 100 attributes

41
Policy Specialization Time
42
Address Resolution Time RDB
Relational DB
43
Address Resolution Time XMLDB
XML DB
44
Conclusions

• Crossroads for important technology advances
• Adaptive policies
• Web services (Service Oriented Architectures)
• Formal models and verification for security
  protocols
• Messaging systems
• Critical in their own right
• Good domain for developing and applying core
  advances