563.4 web services
DESCRIPTION
563.4 Web Services. Presented by: Carl A. Gunter University of Illinois Spring 2006. Today’s Web. Designed for applications involving human interactions Intended purpose Information sharing: a distributed content library Enabled B2C e-commerce Non-automated B2B interactions - PowerPoint PPT PresentationTRANSCRIPT
2
Today’s 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
What’s 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).
6
SOAPSOAP Web Services consumers send and Web Services consumers send and
receive SOAP messages receive SOAP messages
WSDLWeb Services
Description Language
WSDLWeb Services
Description Language
Web Services are defined in terms of the Web Services are defined in terms of the formats and ordering of messagesformats and ordering of messages
Built using open Internet protocols Built using open Internet protocols XML & HTTP
Web Services Architecture
UDDIUniversal Description,
Discovery, and Integration
UDDIUniversal Description,
Discovery, and Integration
Provide a Directory of Services on the Provide a Directory of Services on the InternetInternet
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
<?xml version=“1.0” encoding=“…”?><msg:message from=“id” to=“id” xmlns:msg=“URI”
xmlns:po=“URI”><msg:text>
Hi please bill to the following address</msg:text><msg:item>
<po:po id=“123”> <po:billto>
<po:company> Skateboard </po:company> <po:street> One Warehouse Park </po:street> <po:city> Boston </po:city>
</po:billto> </po:po>
</msg:item></msg:message>
9
XML Declaration
<?xml version=“1.0” encoding=“…”?>
• <?xml ?> the XML declaration – Not required, but typically used– Attributes include:
• Version
• Encoding – the character encoding
10
XML Element
<msg:message from=“id” to=“id” xmlns:msg=“URI” xmlns:po=“URI”><msg:text>
Hi please bill the following</msg:text><msg:item> <po:po id=“123”>
… </po:po></msg:item>
</msg:message>
11
XML Attribute
<msg:message from=“id” to=“id” xmlns:msg=“URI” xmlns:po=“URI”>
… <po:po id=“123”>
… </po:po>
</msg:message>
• XML Attribute – Describes additional information about an element– <tag key=”value”> text</tag>
12
XML Namespaces
<msg:message from=“id” to=“id” xmlns:msg=“URI” xmlns:po=“URI”>…
</msg:message>
• Namespaces– Not mandatory, but useful in giving uniqueness to an
element– Declared using the xmlns:name= “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
<?xml … ?><SOAP-ENV:Envelope xmlns:SOAP-ENV=“URI” >
<SOAP-ENV:Header> <t:Transaction xmlns:t=“URI” SOAP-ENV:mustUnderstand=“1” >
12345 </t:Transaction> <p:Priority xmlns:p=“URI”>
Very High </p:Priority></SOAP-ENV:Header>
<SOAP-ENV:Body>“XML Document”
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
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)
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
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
Stc
TestCoordinator
X.509 Certificate Authentication
Se
Windows 2003 Web Edition
Si
Windows 2003 Web Edition
DNS, User Authentication
DNS, User Authentication,
DB Storage
Windows 2003 Server Standard
Edition
T1
T3
T2
T4
Client MachinesWindows XP Pro
UserNameand
PasswordAuthentication
Sdb SQL Server 2000 Enterprise Edition (SP3a)
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
SMTA RMTA
Sender Recipient
Egress Policies Ingress Policies
ClientPolicies
Merged Policies
33
Policy Architecture
SMTA RMTA
Sender Recipient
Egress Policies Ingress Policies
ClientPolicies
Plug in Server
34
Demo
• A message from Afandisandy1 to Afandigary1
• Two MTAs– Afandisandy1’s egress policy is HashCash
(cycle exhaustion)– Afandigary1’s 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
MTA
ABMServer
DataServices
Legacy Databases
Attr.DB
Domain B
MTA
ABMServer
DataServices
Legacy Databases
Attr.DB
Regular E-mail (SMTP)
Inter Domain ABM over Web Services
To:
Mgr@
DomA
&&
Mgr@
DomB
39
Phase 1 Architecture
WEB Interface
Send Mail
Send mail
B2.
Standard Email Client
Address : [email protected] : xacml.xml;
xquery .xml; sender
.
.
.Send
MTA
ABM
XML DB
Policy.xml
ABM Host
MUA
PDPXACML Engine
C5. Xquery (ABM Address )
C2. User Attribute List
C1. Xquery (User ID )
C3
. X
AC
ML
re
qC
4.
XA
CM
L r
esp
Web Server
A2. User ID
A7. Routable Attribute List
A3. Xquery (User ID )
A4. User Attribute List
A5
. X
AC
ML
re
q
A6
. X
AC
ML
re
spA8
. R
ota
bl e
Att
rib
ute
Li s
t
A1
. U
se
r ID
(A
uth
en
tica
tio
n)
B1. Create Query
C6. Email list
Run Demo
Policy Specialization Path
Address Resolution Path
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