T110 455 Network Application Frameworks and XML Middleware

T-110. 455 Network Application Frameworks and XML Middleware and Mobile Middleware 2. 3. 2005 Sasu Tarkoma

Contents n Middleware u Motivation u Examples n Mobile Middleware u Motivation u Examples n Summary

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

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

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

Applications Middleware provides various Middleware transparencies (HW, OS, location, fault, . . ) for apps. Transport Layer (TCP/UDP) APIs for: RPC, messaging, transactions, session management, storage, directories, trading, etc. Networking Layer (IP) Underlying network (link layer, physical)

Examples n Remote Procedure Call (RPC) u u n Remote Method Invocation (RMI) u u n call of a remote procedure as it were local marshalling / unmarshalling call of a remote method as it were local marshalling / unmarshalling Event-based computing u u entities receive asynchronous notifications a notification causes a state change

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

Network Application Framework n n 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 u u objects (discovery, representation) directories (overlays, . . ) network security

Object Model n n Components: object references, interfaces, actions (methods), exceptions, garbage collection Distributed object model u u u client-server model usually implemented using request-reply marshalling, unmarshalling Example: Java RMI Invocation Semantics F F Exactly-once cannot be guaranteed Typical semantics: at-least-once, at-most-once At-least-once is good for idempotent operations CORBA and RMI use at-most-once

Assignment: Schema Web Services Middleware Objects CORBA SOAP with security XML NAF Security Assignment: Apache Axis J 2 EE SIP Middleware is a fuzzy term. This is one way to look at things. .

Examples n n n CORBA Message-oriented Middleware Event Systems & tuple spaces Java Message Service Java 2 Enterprise Edition (J 2 EE). NET

CORBA I n Common Object Request Broker Architecture (CORBA) u u n Standardized by Object Management Group (OMG) OMG est. 1989, currently over 800 members Distributed object-oriented middleware u u Network abstraction of object location Support for heterogeneous environments F F hardware, networks, OS, languages Interface Definition Language (IDL)

CORBA II n Object Request Broker (ORB) u Broker pattern, transparent object invocation F F n Interoperable Object Reference (IOR) u n n object location, activation, communication CORBA works for both OO and non-OO languages Shareable reference Support for dynamic and static method invocation Many commercial and non-commercial implementations

Client Object Implementation IDL stub IDL Skeleton I. REQUEST II. Invocation returns Object Request Broker (ORB)

Implementation layer - Dynamic Invocation Interface - Alternative to static -stub/skeleton generate andcalls interpret object references - Generic runtime invocation, generic interface - demultiplex requests defined in IDL - Handle method invocations via skeletons - activation policies, thread models - object life cycle - pre/post invocation capabilities Interceptors useful for monitoring and security

CORBA Services n n Services specified by OMG to help using distributed objects Naming Service Event and Notification Service Security Service u n Persistent Object Service u n persistent objects (activation / deactivation) Trading Service u n authentication, access control, nonrepudiation directory service, objects are identified by attributes Transaction and Concurrency Control Service u database transactions

Message-oriented Middleware n Transfers messages between applications u n n Asynchronous communication Direct or queued u n Does not consider the content of messages Queued (buffered) communication supports wireless clients Examples u u u Sun Microsystems JMS Microsoft: MSMQ IBM: Websphere MQ

Event Systems I n n Traditional Mo. M systems are message queue based (one-to-one) Event systems and publish/subscribe are one-to-many u u u n n One object monitors another object Reacts to changes in the object Multiple objects can be notified about changes Events address problems with synchronous operation and polling In distributed environments a logically centralized services mediates events u u anonymous communication expressive semantics using filtering

Event Systems II n n n Push versus Pull May be implemented using RPC, unicast, multicast, broadcast, . . Three main patterns u Observer design pattern F u Notifier architectural pattern F u Used by many research systems Event channel F n Used in Java / Jini Used in CORBA Event/Notification Service Filtering improves scalability / accuracy u Research topic: content-based routing

Tuple Spaces n n n Tuple-based model of coordination The shared tuple space is global and persistent Communication is u u n decoupled in space and time implicit and content-based Examples: Linda, Lime

Java Message Service (JMS) n n Asynchronous messaging support for Java Point-to-point messaging u n Topic-based publish/subscribe u u n Map, Object, Stream, Text, and Bytes Durable subscribers u n SQL for filtering messages at the topic event queue One-to-many Message types: u n One-to-one Event stored at server if not deliverable Transactions with rollback

Source: http: //java. sun. com/j 2 ee/1. 4/docs/tutorial/doc/index. html

Source: http: //java. sun. com/j 2 ee/1. 4/docs/tutorial/doc/index. html

JMS messaging n JMS messaging proceeds in the following fashion: u u u Client obtains a Connection from a Connection. Factory Client uses the Connection to create a Session object The Session is used to create Message. Producer and Message. Consumer objects, which are based on Destinations. Message. Producers are used to produce messages that are delivered to destinations. Message. Consumers are used to either poll or asynchronously consume (using Message. Listeners) messages from producers.

Java 2 Platform Enterprise Edition (J 2 EE) n Specifications and practices for developing, deploying, and managing multi-tier server-centric applications u u n Containers - separation of business logic from resource and lifecycle management u u n Builds on J 2 SE Web Services support Enterprise Java. Beans (EJB) Servlets Java Message Service (JMS) u async. communication supports decoupling

Source: http: //java. sun. com/j 2 ee/1. 4/docs/tutorial/doc/index. html

Java Management Extensions (JMX) J 2 EE Authorization Contract for Containers Java API for XML Registries (JAXR) Java Message Service (JMS) Java Naming and Directory Interface (JNDI) Java Transaction API (JTA) CORBA JDBC data access API. J 2 EE Technologies Java API for XML-Based RPC (JAX-RPC) Java. Server Pages Java Servlets Enterprise Java. Beans components J 2 EE Connector Architecture J 2 EE Management Model J 2 EE Deployment API

. NET n The. NET Framework is Microsoft's the next generation application platform u u n Based on the CLR (Common Language Runtime) u n applications, services, web services, . . Protocol stack and computing model for TCP/IP based distributed computing JIT compiles and executed NET code Components u . NET architecture, . NET Integrated Programming, Common Language Runtime (CLR), . NET System Class Libraries, Data and XML, Web Services / ASP+

. NET Architecture Source: MSDN

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

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

Reflection n In general, middleware provides transparency to the underlying conditions u n In mobile environments this is not always desired u n Location transparency in RPC/RMI Sometimes we need to know about location changes, Qo. S changes, etc. Requirement for reflective middleware u u Should expose APIs for querying / changing important parameters Under development

Secure mobile XML routing Middleware Objects J 2 ME Wireless CORBA Plain IPv 4 IPv 6 mobility, HIP XML NAF Mobility Security

Examples n n WAE J 2 ME Wireless CORBA FUEGO

WAE n Wireless Application Environment (WAE) u n A suite of protocols and specifications for optimizing data transfer for wireless communication WAP stack u u Focus on binary transmission Protocols F F WSP (Wireless Session Protocol) WTP (Wireless Transaction Protocol) WTLS (Wireless Transport Layer Security) • more efficient than TLS, but no end-to-ned security WDP (Wireless Datagram Protocol)

Comparison HTML/JS WAE Other Session Layer (WSP) HTTP TLS - SSL TCP/IP UDP/IP Transaction Layer (WTP) Security Layer (WTSL) Transport Layer (WDP) Bearers: SMS, CDMA, . .

Java 2 Platform Micro Edition (J 2 ME) n n n Java for consumer electronics and embedded devices A virtual machine and a set of APIs Configurations and profiles u Configurations F u two-low level APIs and optimized VMs • CDC, CLDC Profiles F F F API specification on top of a configuration for complete runtime Specify both APIs and Configurations Profiles defined using Java Community Process (JCP)

Source: http: //developers. sun. com/techtopics/mobility/getstart/articles/survey/

Wireless CORBA n CORBA does not support accessing mobile objects or wireless communication u n Three basic requirements u u u n n Wireless CORBA specification Invocations from mobile objects Invocations to mobile objects Wireless communication Home bridge Access bridges Tunnelling over wireless Handoff protocols

Mobile IP vs. WCORBA n n n MIP addresses host mobility, not object mobility MIP does not specifically support wireless protocols MIP hides all handoff events u location-aware services difficult to implement

• Redirects requests for Architecture services on the terminal • Abstract transport-independent • Keeps track of the current • Encapsulates, forwards or ignores tunnel for GIOP messages • Other side end of the Access Bridge access bridge incoming GIOP messages • Concrete tunnels for TCP/IP, • Encapsulate/decapsulates msgs • Decapsulates and. WDP. forwards UDP/IP andevents WAP • Generates mobility messages from reliable the GIOP tunnel • Protocol requires and • Generates mobility events ordered delivery • Lists available services

Handoffs n Network initiated handoff u u n Terminal initiated handoff u u n n started by an external application optional to support make-before-break terminal discovered a new Access Bridge make-before-break is required Access recovery The Home Location Agent is updated Old Access Bridges are informed Mobility events are generated in the visited domain and the terminal domain

Network Initiated Handoff

FUEGO CORE (HIIT) n Mobile and wireless environments have different requirements than desktop systems u n n Vision: A service application is distributed among various application servers, network elements and terminals Three year Tekes project (2002 -2004) u u n User mobility, terminal mobility, connectivity, device characteristics, dynamic environments Industrial partners: Nokia, Telia. Sonera, Elisa, Ericsson, Movial Open source software Demonstration at WMCSA 2004

FUEGO Architecture n The FUEGO middleware service set for mobile computing u Data communication F F u Data synchronization F F u Efficient wireless SOAP Efficient content-based routing (asynchronous events) 3 -way XML document merging XML-aware distributed file system Applications F Presence service, mobile ticker, image-album

Automatic reconciliation of XML documents Optimized storage of XML Expressive async. communication Ad-hoc file sharing Content-based routing using filters Presence service based on events Integrates with existing file systems (NFS) / mobility support Event attribute buffering Control of presence visibility Support for context-aware operation Efficient sync/async messaging Efficient XML serialization Persistent connections across mobility Reliable messaging Multiplexing multiple connections on TCP Prioritization of connections End-to-end authentication of hosts Encryption of network traffic using IPsec Mobility and multihoming support Resilient sockets

FUEGO DEMO

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