T-110.455 Network Application Frameworks and XML Summary and Conclusions 27.04.2005 Sasu Tarkoma

1. T-110.455 Network Application Frameworks and XML Summary and Conclusions27.04.2005Sasu Tarkoma

2. Topics Covered • Distributed systems security • Multi-addressing: Mobility and multi-homing • Building applications with XML • Distributed objects • Role of directory services • Mobile and wireless applications • XML-based presentation and RPC • Scalability and performance issues

3. Lecture Outline Note: starts 16.00

4. Objects Interconnections • Interconnections applicable on many levels • Network-level operation • DNS, overlay lookup, IPsec • Application-level operation • UDDI, SSL, WS-Security Network Security Directories

5. Mobility and Routing

6. Naming, Addressing, and Routing How to identify and name a node? Frequent updates? One or two new name spaces? NAMING unicast: to a specific node broadcast: to all nodes multicast: to a subset of nodes anycast: to any one in some subset (IPv6) ROUTING ADDRESSING How to route information to the node’s address? NAT traversal? Overlay vs. network routing Where is the node located? Differences (IPv4/IPv6) Multi-addressing?

7. TCP/IP Network Stack All applications (FTP, Telnet, HTTP, Overlays) Application Layer host-to-host transport reliability, congestion control, flow control Transport Layer (TCP/UDP) host-to-host connectivity routing, addressing HOST-TO-HOST Link layer: local data transfer, encoding, framing, error correction Physical: transmission of signals Networking Layer (IP) Underlying network (link layer)

8. Routing vs. mobility • Topology data aggregation is necessary • Cannot track all hosts in the world • IP addresses determined by topology • Network gives the routing prefix • Mobile hosts must change their IP addresses • Causes sockets / connections to break • How to communicate address changes? • Goal of a mobility protocol • Transport and applications do not see address changes

9. MH AP NAT GPRS/UMTS Access network Public Switched Data Network NAT Router Router BS BS Backbone LAN MAN Ad hoc MH MH R R R R Router Router Networks: Mobility R

10. Rendezvous • How to find the moving end-point? • Tackling double jump • What if both hosts move at the same time? • Requires a rendezvous point • Mobility management is needed! • Initial rendezvous • Can be based on directories • Requires fast updates to directories • Does not work well for DNS

11. Process Transport IP Layer Link Layer Identity/Locator split • New name space for IDs • Maybe based on DNS • Maybe a separate namespace • Maybe IP addresses are used for location • Good for hiding IP versions • Communication end-points (sockets) bound to identifiers identifier ID Layer locator

12. Host Identity Protocol • New cryptographic namespace • Connection endpoints mapped to 128 bit host identity tags (hashes of public keys) • Mapping at HIP layer • 4-phase Base Exchange with cryptographic puzzle for DoS prevention • IPSec for network-level security

13. Upper layer view • IP connectivity problematic today • Broken by firewalls, NATs, mobility • Two versions of IP: IPv4 and IPv6 • HIP has a potential remedy • Restores end-to-end connectivity (NAT traversal possible but may require changes / tunnelling) • Adds opportunistic security • Handles mobility and multi-homing • Requires DHT based overlay (currently missing) • Where is the network state? • Routers know addresses • Like today • DHT knows HITs / SIDs • Lease based storage • Middleboxes know SPIs • Soft state

14. Lessons to learn • Hierarchical routing likely to stay • Addresses carry topological information • Efficient and well established • Applications face changing connectivity • QoS varies • periods of non-connectivity • Identifiers and locators likely to split • Mobility management is needed • Probably changes in directory services • Overlays have been proposed

15. Summary • Topology based routing is necessary • Mobility causes address changes • Address changes must be signalled end-to-end • Mobility management needed • Initial rendezvous: maybe a directory service • Double jump problem: rendezvous needed • Many engineering trade-offs

16. Distributed Hash Tables and Overlays

17. Layered-model revisited Finding, meta-data, invoking, syncing, mobility. Web Services DNS names Object API XML presentation Presentation Firewall bypass IP addresses Congestion control End-to-end Routing Routing paths

18. Overlay Networks • Origin in Peer-to-Peer (P2P) • Builds upon Distributed Hash Tables (DHTs) • Easy to deploy • No changes to routers or TCP/IP stack • Typically on application layer • Overlay properties • Resilience • Fault-tolerance • Scalability

19. Upper layers DNS names, custom identifiers Overlay Overlay addresses Congestion IP addresses End-to-end Routing Routing paths

20. Some DHT applications • File sharing • Web caching • Censor-resistant data storage • Event notification • Naming systems • Query and indexing • Communication primitives • Backup storage • Web archive

21. Applications for DHTs • DHTs are used as a basic building block for an application-level infrastructure • Internet Indirection Infrastructure (i3) • New forwarding infrastructure based on Chord • DOA (Delegation Oriented Architecture) • New naming and addressing infrastructure based on overlays

22. Summary • Mobility and multi-homing require directories • Scalability, low-latency updates • Overlay networks have been proposed • Searching, storing, routing, notification,.. • Lookup (Chord, Tapestry, Pastry), coordination primitives (i3), middlebox support (DOA) • Logarithmic scalability, decentralised,… • Host/identity split and overlays for directories seem good candidates for solving many of the issues with mobility and multi-homing

23. Middleware

24. Middleware • Widely used and popular term • Fuzzy term • One definition • “A set of service elements above the operating system and the communications stack” • Second definition • “Software that provides a programming model above the basic building blocks of processes and message passing” (Colouris, Dollimore, Kindberg, 2001)

25. Why Middleware? • Application development is complex and time-consuming • Should every developer code their own protocols for directories, transactions, ..? • How to cope with heterogeneous environments? • Networks, operating systems, hardware, programming languages • Middleware is needed • To cut down development time • Rapid application development • Simplify the development of applications • Support heterogeneous environments and mask differences in OS/languages/hardware

26. Middleware cont. • Middleware services include • directory, trading, brokering • remote invocation (RPC) facilities • transactions • persistent repositories • location and failure transparency • messaging • Security • Network stack (transport and below) is not part of middleware

27. Transparencies • Location transparency • RPC and RMI used without knowledge of the location of the invoked procedure / object • transport protocol transparency • RPC may be implemented using any transport protocol • transparency of OS and hardware • RPC/RMI uses external data representation • Presentation is important • XML is becoming increasingly important • transparency of programming languages • language independent definition of procedures: CORBA IDL

28. Network Application Framework • Network Application Framework is middleware • Contains services for distributed applications • Middleware as a term is fuzzier and larger • In this course, we focus on network application frameworks and XML • objects (discovery, representation) • directories (overlays,..) • network • security

29. Examples • Middleware • CORBA • Message-oriented Middleware • Event Systems & tuple spaces • Java Message Service • Java 2 Enterprise Edition (J2EE) • .NET • Mobile middleware • WAE • J2ME • Wireless CORBA • FUEGO

30. Mobile Middleware I • Middleware is typically designed and implemented for fixed-network hosts • High bandwidth, low latency, reliable communication • Persistent storage and sufficient computing power • No mobility • Mobile environment requires new solutions • Existing middleware services do not scale • Previous lectures: mobility is challenging • Small devices / embedded systems pose totally different challenges

31. Mobile Middleware II • Goals for middleware: • fault-tolerance, adaptability, heterogeneity,scalability, resource sharing • Mobile middleware • dynamically changing context • decoupled • events, tuple spaces • Basic solution for wireless • Use a proxy

32. Summary • Middleware • for application development and deployment • for supporting heterogeneous environments • Main communication paradigms: RPC/RMI, asynchronous events (publish/subscribe) • J2EE, CORBA, .. • Mobile middleware • Desktop middleware not usable on small, mobile devices • Special solutions are needed • J2ME, Wireless CORBA, ..

33. Web Services

34. XML XML A Basic Web Service Computer A Language: C++ OS: W2000 Computer B Language: Java OS: Linux Independent of language, OS, network protocols

35. Standardization • W3C Web Services • XML Protocol Working Group • SOAP • Web Services Addressing Working Group • Web Services Choreography Working Group • Web Services Description Working Group • WSDL • OASIS • E-business standards, UDDI • WS-I (Web Service Interoperability Org.) • Binding profiles,..

36. Web Service Architecture • The three major roles in web services • Service provider • Provider of the WS • Service Requestor • Any consumer / client • Service Registry • logically centralized directory of services • A protocol stack is needed to support these roles

37. Web Services Protocol Stack • Message Transport • Responsible for transporting messages • HTTP, BEEP • XML Messaging • Responsible for encoding messages in common XML format • XML-RPC, SOAP • Service Description • Responsible for describing an interface to a specific web service • WSDL • Service discovery • Responsible for service discovery and search • UDDI

38. WS Protocol Stack Discovery: UDDI Description: WSDL XML Messaging: SOAP, XML-RPC, XML Transport: HTTP, FTP, BEEP, SMTP, JMS

39. WS requester Business partner or other system SOAP RQ SOAP RQ Bind Publish Services JAXR SOAP RQ WSDL document WSDL with Java 2. Look up WS UDDI 4. Call WS firewall 1. WSDL is published to UDDI 3. Retrieve WSDL description JAXR=Java API for XML Registries

40. What is WSDL? • WSDL: Web Service Description Language • An XML language used to describe and locate web services • location of web service • methods that are available • data type information and XML messages • Commonly used to describe SOAP-based services • W3C standard (work in progress) • Initial input: WSDL 1.1 as W3C Note • Current version 2.0 (last call) • Some differences between 1.1 and 2.0 • WSDL 1.1 in WS-I Basic Profile 1.0 and 1.1.

41. WSDL Overview <definitions>: ROOT WSDL element <types>: The data types that are used <message>: What messages are transmitted? <portType>: The supported operations <binding>: The binding to concrete protocols <service>: Reference to actual location

42. Mapping SOAP to WSDL

43. Putting it together Source: http://msdn.microsoft.com/

44. SOAP Envelope SOAP Header Header block Header block SOAP Body Message Body SOAP Message Structure Optional header contains blocks of information regarding how to process the message: • Routing and delivery settings • Authentication/authorization assertions • Transaction contexts • Body is a mandatory element and contains the actual message to be delivered and processed (and fault information)

45. What is UDDI? • Universal Description Discovery and Integration • Industry-wide initiative supporting web services • Specifications • Schemas for service description • Schemas for business (service implementers) description • Developed on industry standards • Applies equally to XML and non-XML web services • Implementation • Public web service registry and development resources • SOAP-based programming protocol for registering and discovering Web services • XML schema for SOAP messages • a description of the API • UDDI does not directly specify how pricing, deadlines, etc. are handled/matched • Advanced discovery via portals and marketplaces

46. Web Services Security

47. Need for XML security • XML document can be encrypted using SSL or IPSec • this cannot handle the different parts of the document • documents may be routed hop-by-hop • different entities must process different parts of the document • SSL/TLS/IPSec provide message integrity and privacy only when the message is in transit • We also need to encrypt and authenticate the document in arbitrary sequences and to involve multiple parties

48. High-level view to WS security • Security is as strong as the weakest link • The options for an attacker are: • Attack the Web Service directly • Using ”unexpected” XML • Attack the Web Services platform • Attack a WS security tool • Attack the underlying operating system or network connection

49. Application-layer Security • Identity-based security • Authentication and authorization information shared across security domains • Content-based security • Protecting against buffer overflow and CGI-like attacks • Must have knowledge about the applications to which these messages are directed • Accountability or non-repudation • Need message level security • Maintain integrity, archived audit trails • The standards and specifications mentioned earlier address these issues

50. Standardization landscape • Who are specifying the basic standards? • Who are specifying the higher level standards? • Who is implementing the standards?