Architecture of Web Service Grids

1. Architecture ofWeb Service Grids IIT Computer Science Colloquium October 25 2004 Geoffrey Fox Community Grids Lab Indiana University gcf@indiana.edu

2. e-Infrastructure • e-Infrastructure builds on the inevitable increasing performance of networks and computers linking them together to support new flexible linkages between computers, data systems and people • Grids and peer-to-peer networks are the technologies that build e-Infrastructure • e-Infrastructure called CyberInfrastructure in USA • We imagine a sea of conventional local or global connections supported by the “ordinary Internet” • Phones, web page accesses, plane trips, hallway conversations • Conventional Internet technology manages billions of broadcast or low (one client to Server) or broadcast links • On this we superimpose high value multi-way organizations (linkages) supported by Grids with optimized resources and system support and supporting virtual (electronic) enterprises • Low multiplicity fully interactive real-time sessions • Resources such as databases supporting (larger) communities

3. Philosophy of Web Service Grids • Much of Distributed Computing was built by natural extensions of computing models developed for sequential machines • This leads to the distributed object (DO) model represented by Java and CORBA • RPC (Remote Procedure Call) or RMI (Remote Method Invocation) for Java • Key people think this is not a good idea as it scales badly and ties distributed entities together too tightly • Distributed Objects Replaced by Services • Note CORBA was considered too complicated in both organization and proposed infrastructure • and Java was considered as “tightly coupled to Sun” • So there were other reasons to discard • Thus replace distributed objects by services connected by “one-way” messages and not by request-response messages

4. Web services • Web Services build loosely-coupled, distributed applications, (wrapping existing codes and databases) based on the SOA (service oriented architecture) principles. • Web Services interact by exchanging messages in SOAP format • The contracts for the message exchanges that implement those interactions are described via WSDL interfaces.

5. What is a Grid? • You won’t find a clear description of what is Grid and how does differ from a collection of Web Services • I see no essential reason that Grid Services have different requirements than Web Services • Geoffrey Fox, David Walker, e-Science Gap Analysis, June 30 2003. Report UKeS-2003-01, http://www.nesc.ac.uk/technical_papers/UKeS-2003-01/index.html. • Notice “service-building model” is like programming language – very personal! • Grids were once defined as “Internet Scale Distributed Computing” but this isn’t good as Grids depend as much if not more on data as well as simulations • So Grids can be termed “Internet Scale Distributed Services” and represent a way of collecting services together to solve problems where special features and quality of service needed.

6. Community Resources • Grid Community databases have analogy to Television and the News Web that allow individuals to communicate instantly with each other via Web Pages and Headline News acting as proxies • N resources deposit information and N can view – Complexity O(N)

7. Large and Small Grids • N resources in a community (N is billions for the world and 1000-10000 for many scientific fields) • Communities are arranged hierarchically with real work being done in “groups” of M resources – M could be 10-100 in e-Science • Metcalfe’s law: value of network grows like square of number of nodes M – we call Grids where this true Metcalfe or M2 Grids • Nature of Interaction depends on size of M or N • Shared Information O(N) Complexity Grids for largish N • Complexity M2 Metcalfe Grids for smaller M < N • Grids must merge with peer-to-peer networks to support both Complexity O(N) and M2 Systems

8. M2Interactions • Superimpose M2 “Grids” on the sea (heatbath) of O(N) “ordinary” interactions

9. Architecture of (Web Service) Grids • Grids built from Web Services communicating through an overlay network built in SOFTWARE on the “ordinary internet” at the application level • Grids provide the special quality of service (security, performance, fault-tolerance) and customized services needed for “distributed complex enterprises” • We need to work with Web Service community as they debate the 60 or so proposed Web Service specifications • Use Web Service Interoperability WS-I as “best practice” • Must add further specifications to support high performance • Database “Grid Services” for O(N) Community case • Streaming support for M2case

10. Web Services WS-* • Java is very powerful partly due to its many “frameworks” that generalize libraries e.g. • Java Media Framework • Java Database Connectivity JDBC • Web Services have a correspondingly collections of specifications that represent critical features of the distributed operating systems for “Grids of Simple Services” • Some 60 active WS-* specifications for areas such as • a. Core Infrastructure Specifications • b. Service Discovery • c. Security • d. Messaging • e. Notification • f. Workflow and Coordination • g. Characteristics • h. Metadata and State • i. User Interfaces

11. A List of Web Services I • a) Core Service Architecture • XSD XML Schema (W3C Recommendation) V1.0 February 1998, V1.1 February 2004 • WSDL 1.1 Web Services Description Language Version 1.1, (W3C note) March 2001 • WSDL 2.0 Web Services Description Language Version 2.0, (W3C under development) March 2004 • SOAP 1.1 (W3C Note) V1.1 Note May 2000 • SOAP 1.2 (W3C Recommendation) June 24 2003 • b) Service Discovery • UDDI(Broadly Supported OASIS Standard) V3 August 2003 • WS-Discovery Web services Dynamic Discovery (Microsoft, BEA, Intel …) February 2004 • WS-ILWeb Services Inspection Language, (IBM, Microsoft) November 2001

12. A List of Web Services II • c) Security • SAMLSecurity Assertion Markup Language (OASIS) V1.1 May 2004 • XACML eXtensible Access Control Markup Language (OASIS) V1.0 February 2003 • WS-Security 2004 Web Services Security: SOAP Message Security (OASIS) Standard March 2004 • WS-SecurityPolicy Web Services Security Policy (IBM, Microsoft, RSA, Verisign) Draft December 2002 • WS-TrustWeb Services Trust Language (BEA, IBM, Microsoft, RSA, Verisign …) May 2004 • WS-SecureConversation Web Services Secure Conversation Language (BEA, IBM, Microsoft, RSA, Verisign …) May 2004 • WS-FederationWeb Services Federation Language (BEA, IBM, Microsoft, RSA, Verisign) July 2003

13. A List of Web Services III • d) Messaging • WS-Addressing Web Services Addressing (BEA, IBM, Microsoft) March 2004 • WS-MessageDelivery Web Services Message Delivery (W3C Submission by Oracle, Sun ..) April 2004 • WS-Routing and Referral SOAP Routing Protocol (Microsoft) October 2001 • WS-RM Web Services Reliable Messaging (BEA, IBM, Microsoft, Tibco) v0.992 March 2004 • WS-Reliability Web Services Reliable Messaging (OASIS Web Services Reliable Messaging TC) March 2004 • SOAP MOTM SOAP Message Transmission Optimization Mechanism (W3C) June 2004 • e) Notification • WS-Eventing Web Services Eventing (BEA, Microsoft, TIBCO) January 2004 • WS-Notification Framework for Web Services Notification with WS-Topics, WS-BaseNotification, andWS-BrokeredNotification (OASIS) OASIS Web Services Notification TC Set up March 2004 • JMSJava Message Service V1.1 March 2002

14. A List of Web Services IV • f) Coordination and Workflow, Transactions and Contextualization • WS-CAFWeb Services Composite Application Framework including WS-CTX, WS-CFandWS-TXM below (OASIS Web Services Composite Application Framework TC) July 2003 • WS-CTXWeb Services Context (OASIS Web Services Composite Application Framework TC) V1.0 July 2003 • WS-CF Web Services Coordination Framework (OASIS Web Services Composite Application Framework TC) V1.0 July 2003 • WS-TXM Web Services Transaction Management (OASIS Web Services Composite Application Framework TC) V1.0 July 2003 • WS-Coordination Web Services Coordination (BEA, IBM, Microsoft) September 2003 • WS-AtomicTransaction Web Services Atomic Transaction (BEA, IBM, Microsoft) September 2003 • WS-BusinessActivity Web Services Business Activity Framework (BEA, IBM, Microsoft) January 2004 • BTP Business Transaction Protocol (OASIS) May 2002 with V1.0.9.1 May 2004 • BPEL Business Process Execution Language for Web Services (OASIS) V1.1 May 2003 • WS-Choreography (W3C) V1.0 Working Draft April 2004 • WSCI (W3C) Web Service Choreography Interface V1.0 (W3C Note from BEA, Intalio, SAP, Sun, Yahoo) • WSCLWeb Services Conversation Language (W3C Note) HP March 2002

15. A List of Web Services V • h) Metadata and State • RDFResource Description Framework (W3C) Set of recommendations expanded from original February 1999 standard • DAML+OIL combining DAML (Darpa Agent Markup Language) and OIL (Ontology Inference Layer) (W3C) Note December 2001 • OWLWeb Ontology Language (W3C) Recommendation February 2004 • WS-DistributedManagement Web Services Distributed Management Framework with MUWS and MOWS below (OASIS) • WSDM-MUWS Web Services Distributed Management: Management Using Web Services (OASIS) V0.5 Committee Draft April 2004 • WSDM-MOWS Web Services Distributed Management: Management of Web Services (OASIS) V0.5 Committee Draft April 2004 • WS-MetadataExchange Web Services Metadata Exchange (BEA,IBM, Microsoft, SAP) March 2004 • WS-RFWeb Services Resource Framework including WS-ResourceProperties, WS-ResourceLifetime, WS-RenewableReferences, WS-ServiceGroup, and WS-BaseFaults(OASIS) Oasis TC set up April 2004 and V1.1 Framework March 2004 • ASAP Asynchronous Service Access Protocol (OASIS) with V1.0 working draft G June 2004 • WS-GAFWeb Service Grid Application Framework (Arjuna, Newcastle University) August 2003

16. A List of Web Services VI • g) General Service Characteristics • WS-Policy Web Services Policy Framework (BEA, IBM, Microsoft, SAP) May 2003 • WS-PolicyAssertionsWeb Services Policy Assertions Language (BEA, IBM, Microsoft, SAP) May 2003 • WS-Agreement Web Services Agreement Specification (GGF under development) May2004 • i) User Interfaces • WSRP Web Services for Remote Portlets (OASIS) OASIS Standard August 2003 • JSR168: JSR-000168 Portlet Specification for Java binding (Java Community Process) October 2003

17. A List of Web Services VII • j) Recent Updates ………………… • WS-Eventing important update of this notification specification with IBM, Sun and others joining Microsoft et al. as authors • WS-Enumeration supporting the splitting of a single entity (file or stream) into multiple messages • WS-Transfer supporting the creation, update (by get or put) or deletion of a resource • WS-Management competes with WS-DM to provide a Web Service to manage resources • WS-PolicyAttachment describes how to associate policies with UDDI and Endpoints and how to integrate with WSDL • WS-DAI is a Web Service of the OGSA-DAI Grid linkage with databases • WS-CIM is a Web Service rendering from DMTF (Distributed Management Task Force) of the industry standard CIM (Common Information Model) of metadata for computer devices • The WS-* implicitly define an architecture

18. Importance of SOAP • SOAP defines a very obvious message structure with a header and a body • The header contains information used by the “Internet operating system” • Destination, Source, Routing, Context, Sequence Number … • The message body is partly further information used by the operating system and partly information for application when it is not looked at by “operating system” except to encrypt, compress it etc. • Note WS-Security supports separate encryption for different parts of a document • Much discussion in field revolves around what is referenced in header! • e.g. WSRF adds a lot to header

19. WS-……..Handler WS-RMHandler Deployment Issues for “System Services” • “System Services” are ones that act before the real application logic of a service • They gobble up part of the SOAP header identified by the namespace they care about and possibly part or all of the SOAP body • e.g. the XML elements in header from the WS-RM namespace • They return a modified SOAP header and body to next handler in chain Header Body e.g. ……. Could be WS-Eventing WS-Transfer ….

20. Messaging Process SOAPBody Header Process SOAPHeader Body Messaging Structure • Communication Services are messaging (transport protocol, routing) using SOAP protocol Service itself Serviceitself Customizable HandlerChain processesSOAP Header Invoke Other Services from Header or Body

21. Legacy Service WS-RMService WS-RM removed from SOAP Header WS-RM enabledSOAP Proxy Distributed Processing • A handler is like an in memory “service” so one can build handlers that can alternatively be deployed “outside” application service and look like a service. • Natural for some cases like Reliable Messaging but always possible • Support and architecture of handlers/servicesthat can be inside or outside containers is not clear? • Build virtual (distributed) containers

22. WS-I Interoperability • Critical underpinning of Grids and Web Services is the gradually growing set of specifications in the Web Service Interoperability Profiles • Web Services Interoperability (WS-I) Interoperability Profile 1.0a." http://www.ws-i.org. gives us XSD, WSDL1.1, SOAP1.1, UDDI in basic profile and parts of WS-Security in their first security profile. • We imagine the “60 Specifications” being checked out and evolved in the cauldron of the real world and occasionally best practice identifies a new specification to be added to WS-I which gradually increases in scope • Note only 4.5 out of 60 specifications have “made it” in this definition

23. Web Services Grids and WS-I+ • WS-I Interoperability doesn’t cover all the capabilities need to support Grids • WS-I+ is designed to minimal extension of WS-I to support “most current” Grids: it adds support for • Enhanced SOAP Addressing (WS-Addressing) • Fault tolerant (reliable) messaging • Workflow as in IBM-Microsoft standard BPEL • Security and Notification best practice and support will probably get added soon • There are Web Service frameworks here but various IBM v Microsoft v Globus differences to be resolved • Portlet-based User Interfaces could be added • UK OMII Open Middleware Infrastructure Institute is adopting this approach to support UK e-Science program • Currently UK e-Science largely either uses GT2 (as in EDG) or Simple Web Services for “database Grids” • http://www.omii.ac.uk/

24. Application Specific Grids Generally Useful Services and Grids Workflow WSFL/BPEL Service Management (“Context etc.”) Service Discovery (UDDI) / Information Service Internet Transport  Protocol Service Interfaces WSDL Higher Level Services ServiceContext ServiceInternet Base Hosting Environment Protocol HTTP FTP DNS … Presentation XDR … Session SSH … Transport TCP UDP … Network IP … Data Link / Physical Bit level Internet (OSI Stack) Layered Architecture for Web Services and Grids

25. Working up from the Bottom • We have the classic (CISCO, Juniper ….) Internet routing the flood of ordinary packets in OSI stack architecture • Web Services build the “Service Internet” or IOI (Internet on Internet) with • Routing via WS-Addressing not IP header • Fault Tolerance (WS-RM not TCP) • Security (WS-Security/SecureConversation not IPSec/SSL) • Data Transmission by WS-Transfer not HTTP • Information Services (UDDI/WS-Context not DNS/Configuration files) • At message/web service level and not packet/IP address level • Software-based Service Internet possible as computers “fast” • Familiar from Peer-to-peer networks and built as a software overlay network defining Grid (analogy is VPN) • SOAP Header contains all information needed for the “Service Internet” (Grid Operating System) with SOAP Body containing information for Grid application service

26. Consequences of Rule of the Millisecond • Useful to remember critical time scales • 1) 0.000001 ms – CPU does a calculation • 2a) 0.001 to 0.01 ms – Parallel Computing MPI latency • 2b) 0.001 to 0.01 ms – Overhead of a Method Call • 3) 1 ms – wake-up a thread or process • 4) 10 to 1000 ms – Internet delay • 2a), 4) implies geographically distributed metacomputing can’t in general compete with parallel systems • 3) << 4) implies a software overlay network is possible without significant overhead • We need to explain why it adds value of course! • 2b) versus 3) and 4) describes regions where method and message based programming paradigms important

27. Closely coupled Java/Python … Coarse Grain Service Model Service B Service A Module B Module A Messages Service B Service A 0.1 to 1000 millisecond latency Method Calls.001 to 1 millisecond Linking Modules • From method based to RPC to message based to event-based publish-subscribe Message Oriented Middleware “Listener”Subscribe to Events Publisher Post Events Message Queue in the Sky

28. What is a Simple Service? • Take any system – it has multiple functionalities • We can implement each functionality as an independent distributed service • Or we can bundle multiple functionalities in a single service • Whether functionality is an independent service or one of many method calls into a “glob of software”, we can always make them as Web services by converting interface to WSDL • Simple services are gotten by taking functionalities and making as small as possible subject to “rule of millisecond” • Distributed services incur messaging overhead of one (local) to 100’s (far apart) of milliseconds to use message rather than method call • Use scripting or compiled integration of functionalities ONLY when require <1 millisecond interaction latency • Apache web site has many projects that are multiple functionalities presented as (Java) globs and NOT (Java) Simple Services • Makes it hard to integrate sharing common security, user profile, file access .. services

29. CPUs Clusters Compute Resource Grids Overlay and Compose Grids of Grids MPPs Methods Services Component Grids Federated Databases Databases Data Resource Grids Sensor Sensor Nets Grids of Grids of Simple Services • Link via methods  messages  streams • Services and Grids are linked by messages • Internally to service, functionalities are linked by methods • A simple service is the smallest Grid • We are familiar with method-linked hierarchyLines of Code  Methods  Objects  Programs  Packages

30. Component Grids? • So we build collections of Web Services which we package as component Grids • Visualization Grid • Sensor Grid • Utility Computing Grid • Person (Community) Grid • Earthquake Simulation Grid • Control Room Grid • Crisis Management Grid • We build bigger Grids by composing component Grids using the Service Internet

31. Gas CIGrid Flood CIGrid … … Gas Servicesand Filters Flood Servicesand Filters Electricity CIGrid Portals Collaboration Grid Visualization Grid Sensor Grid GIS Grid Compute Grid Data Access/Storage Registry Metadata Core Grid Services Physical Network Security Notification Workflow Messaging Critical Infrastructure (CI) Grids built as Grids of Grids

32. Field Trip Data ? GISGrid Discovery Services RepositoriesFederated Databases Streaming Data Sensors Database Database Sensor Grid Database Grid Research Education SERVOGrid Compute Grid Customization Services From Researchto Education Data FilterServices ResearchSimulations Analysis and VisualizationPortal EducationGrid Computer Farm Geoscience Research and Education Grids

33. IOI and CIE • Let us study the two layers IOI (Service Internet On the Bit Internet) and CIE (Service Context and Information Environment) • IOI is most “straightforward” as it is providing reasonably well understood capabilities at a new “level” • CIE is roughly the inter-service “shared memory” used to manage and control them at “distributed operating system level • Critical is “shared” (a database service) versus message based CIE Higher Level Services Application Specific Grids Generally Useful Services and Grids Workflow WSFL/BPEL Service Management (“Context etc.”) Service Discovery (UDDI) / Information Service Internet Transport  Protocol Service Interfaces WSDL CIE IOI

34. NaradaBrokering Audio/Video Conferencing Client Computer Modem Server Peers NaradaBrokering Broker Network Minicomputer Firewall Laptop computer Workstation Peers Audio/Video Conferencing Client PDA Web Service B Queues Stream Server-enhanced Messaging NB supports messages and streams

35. “GridMPI” v. “Service Internet” • In parallel computing, MPI and PVM provided “all the features one needed’ for inter-node messaging • Service Internet implemented by NB aims to play same role for the Grid but the requirements and constraints are very different • NB is not MPI ported to a Grid/Globus environment • Typically MPI aiming at microsecond latency but for Grid, time scales are different • 100 millisecond quite normal network latency • 30 millisecond typical packet time sensitivity (this is one audio or video frame) but even here can buffer 10-100 frames on client (conferencing to streaming) • 1 millisecond is time for a Java server to “think” • Jitter in latency (transit time through broker) due to routing, processing (in NB) or packet loss recovery is important property • Grids need and can use software supported message functions and trade-offs between hardware and software routing different from parallel computing

36. Current NaradaBrokering Features

37. Forthcoming Features • Production implementations of WS-Eventing, WS-Notification, WS-RM and WS-Reliability. • Time Differential Services: Preserve time spacing between events, that are time-stamped using high-resolution timers. • Active replay support: Pause and Replay live streams. • Replicated storage support for fault tolerance and resiliency to storage failures.

38. NaradaBrokering and IOI • “Software Overlay Network” features • Support for Multiple Transport protocols • Support for multiple delivery mechanisms • Reliable Delivery • Exactly-once Delivery • Ordered Delivery • Optional Delivery optimization modules for different modes • Compression/Decompression of payloads with optional module • Coalescing/Fragmentation of payloads with optional module • NTP Time Service • Security Service • Performance Monitoring • Performance optimized routing with optional module • Support for WS-Reliability, WS-ReliableMessaging and their Federation

39. Virtualizing Communication • Communication specified in terms of user goal and Quality of Service – not in choice of port number and protocol • Bit Internet Protocols have become overloaded e.g. MUST use UDP for A/V latency requirements but CAN’t use UDP as firewall will not support ……… • A given “Service Internet” communication can involve multiple transport protocols and multiple destinations – the latter possibly determined dynamically NB Brokers FastLink FirewallHTTP B1 SatelliteUDP A Hand-HeldProtocol B2 Software Multicast Dial-upFilter NB Broker B3 Client Filtering

40. Performance Monitoring • Every broker incorporates a Monitoring service that monitors links originating from the node. • Every link measures and exposes a set of metrics • Average delays, jitters, loss rates, throughput. • Individual links can disable measurements for individual or the entire set of metrics. • Measurement intervals can also be varied • Monitoring Service, returns measured metrics to Performance Aggregator.

41. Mean transit delay for message samples in NaradaBrokering: Different communication hops 9 hop-2 hop-3 8 hop-5 7 hop-7 6 5 Transit Delay (Milliseconds) 4 3 2 1 0 100 1000 Message Payload Size (Bytes) Pentium-3, 1GHz, 256 MB RAM 100 Mbps LAN JRE 1.3 Linux

44. Custom Message Reliability Filter 2 NaradaBroker Filter 1 2 second PDA reply latency! Different endpoints may well need different reliability schemes. Another reason to use application layer. Need to define easy touse “standard reliabilityprofiles Wireless Optimized WS-RM WS-RM WS-Reliability

45. NaradaBrokering and Fault Tolerance GridFTP plus NaradaBrokering • As well as reliable messaging, NaradaBrokering supports performance based dynamic routing • Choose both route and protocol (UDP, Parallel TCP ..) • It will also support automatic fail-over among replicated services subscribing to same message stream • Provides scriptable control of streams for custom management schemes • Saves ALL messages in faulttolerant storage for eithersession replay or recovery • Will support reliable BitTorrentP2P file swapping model (better than GridFTP?)

46. Pure SOAP SOAP over UDP Binary over UDP Fast Web Service Communication I • IOI Application level Internet allows one to optimize message streams at the cost of “startup time”, Web Services can deliver the fastest possible interconnections with or without reliable messaging • Typical results from Grossman (UIC) comparing Slow SOAP over TCP with binary and UDP transport (latter gains a factor of 1000) 7020 5.60

47. Fast Web Service Communication II • Mechanism only works for streams – sets of related messages • SOAP header in streams is constant except for sequence number (Message ID), time-stamp .. • One needs two types of new Web Service Specification • “WS-StreamNegotiation” to define how one can use WS-Policy to send messages at start of a stream to define the methodology for treating remaining messages in stream • “WS-FlexibleRepresentation” to define new encodings of messages

48. Fast Web Service Communication III • Then use “WS-StreamNegotiation” to negotiate stream in Tortoise SOAP – ASCII XML over HTTP and TCP – • Deposit basic SOAP header through connection – it is part of context for stream (linking of 2 services) • Agree on firewall penetration, reliability mechanism, binary representation and fast transport protocol • Naturally transport UDP plus WS-RM • Use “WS-FlexibleRepresentation” to define encoding of a Fast transport (On a different port) with messages just having “FlexibleRepresentationContextToken”, Sequence Number, Time stamp if needed • RTP packets have essentially this structure • Could add stream termination status • Can monitor and control with original negotiation stream • Can generate different streams optimized for different end-points

49. Grids and e-globalcommunity • Peer-to-peer networks already are a good example of value of Information Technology supporting broad global communities • File sharing, text chats, bulletin boards • Grids must include these capabilities and extend in terms of increased functionality and quality of service • This will support business and cultural interactions between nations • Several interesting applications can be supported by • Replacing files by multi-media streams so can collaborate in real-time • Adding traditional tools like audio-video conferencing and shared applications to P2P set • This integration of P2P and Grid to give M2 Grids impacts e-Business as well as e-globalcommunity

50. Streaming M2 Grids • e-Textilemanufacturing involves Clothes designers in USA and manufacturers in Hong Kongexchanging designswhich arestreams of images • e-Sports is a possible collaboration between Indiana University and Beijing Sport University • Basket ball coaches (teacher) interact with aspiring NBA players in China • Martial Arts masters in China train neophytes in Indiana • Faculty recreational sports adviser works from university with faculty exercising at home • Hope to have working incredibly well by the 2008 Olympics • Interactive TV Grid: allows anybody to discuss professional or home video (of sports or other events) within a custom Grid • Multi-player distributed games which should be supported with exactly the same overlay Grid • Video Game Production Grid links artistic direction (design) in one country with digital animation (manufacturing) in another • e-Science: Physics and Environmental Science Sensors • Surveillance Grid enables security personnel to annotate and discuss suspicious remote camera images/streams