1. Models and Languages for Parallel Computation & Modeling Stateful Resources with Web Services v. 1.1 Ramakrishna Varadarajan

2. 2 Models and Languages for Parallel Computation Discusses a RANGE of parallel programming models Discusses a RANGE of parallel programming models Their suitability for realistic portable parallel programming Models categorized based on level of abstraction they provide. Trade off between efficiency and portability Discusses 6 categories of models Abstract Models { easy to build, portable cannot guarantee performance } Concrete Models { hard to build, not very portable, can guarantee performance } Increase in ease of use

3. 3 PARALLELISM BASICS Distributed-memory MIMD (Multi-Computer Systems) Shared-memory MIMD (Multi-Processor Systems) PARALLEL ARCHITECTURES Building blocks – Processor (processing elements) Memory and Interconnection network

4. 4 Parallel Computation Units Processes Processes Have their own Address Space Have their own Address Space Communicate using Message Passing Communicate using Message Passing Context Switch is expensive Context Switch is expensive Threads Threads Threads of a single process share the Address Space Threads of a single process share the Address Space Communicate via Shared Memory Transfers Communicate via Shared Memory Transfers Context Switch is cheap Context Switch is cheap In a parallel program processes get interrupted more often than in sequential program. In a parallel program processes get interrupted more often than in sequential program.

5. 5 Other concepts.. Direct remote-memory access - Another form of communication Direct remote-memory access - Another form of communication A pair of processors are used : A pair of processors are used : Application processor Application processor Messaging processor Messaging processor Types of Parallelism of a Program Types of Parallelism of a Program Virtual Parallelism Virtual Parallelism Physical Parallelism Physical Parallelism

6. 6 Model and its properties A model of parallel computation is an interface separating high-level properties from low-level ones. Higher-level Operations are provided. Simplifies Software Structure. Reduces the difficulty of Software construction. Models exist in different levels of abstraction and efficiency.

7. 7 Properties of a Good Model 1. EASY TO PROGRAM Hide most of the details (from programmers) Hide most of the details (from programmers) As much as possible of the executing program should be inserted by the Translation mechanism (Compiler & run time system) creates most of the executing program. As much as possible of the executing program should be inserted by the Translation mechanism (Compiler & run time system) creates most of the executing program. The model should conceal: Decomposition of Program in to Threads. Decomposition of Program in to Threads. Mapping of Threads to Processors. (Optimal decomposition and mapping are exponentially expensive) Mapping of Threads to Processors. (Optimal decomposition and mapping are exponentially expensive) Communication among threads. Communication among threads. Synchronization among threads. Synchronization among threads.

8. 8 Properties of a Good Model 2. SOFTWARE DEVELOPMENT METHODOLOGY. A Large gap exists between semantic structure of program and the detailed structure for execution. A Large gap exists between semantic structure of program and the detailed structure for execution. A Software Development methodology is needed to bridge the gap. A Software Development methodology is needed to bridge the gap. 3. ARCHITECTURE INDEPENDENT. To make Parallel Software Portable. To make Parallel Software Portable. Model must be abstract from any parallel computer Style. Model must be abstract from any parallel computer Style. Can be easily achieved in isolation. But difficult in conjunction with other requirements. Can be easily achieved in isolation. But difficult in conjunction with other requirements. These requirement conflict with each other. Hence we need to see the tradeoff. These requirement conflict with each other. Hence we need to see the tradeoff.

9. 9 Properties of a Good Model 4. EASY TO UNDERSTAND. Necessary if we intend parallelism to be a part of mainstream computing. Necessary if we intend parallelism to be a part of mainstream computing. Increases the chances of being accepted and used. Increases the chances of being accepted and used. 5. GUARANTEED PERFORMANCE & COST MEASURES. Based on Program Structure (Static or dynamic) and the amount of Communication (bounded or unbounded) Based on Program Structure (Static or dynamic) and the amount of Communication (bounded or unbounded) The primary reason for reduced performance is Congestion (communication overruns). The primary reason for reduced performance is Congestion (communication overruns). We can guarantee performance and can give accurate cost measures only when, Structure of the Program is static & Structure of the Program is static & Amount of Communication is bounded Amount of Communication is bounded

10. 10 GUARANTEED PERFORMANCE & COST MEASURES Closely related to the Extent to which Program Implementations (Final Executing Program) is constrained by Program Text Closely related to the Extent to which Program Implementations (Final Executing Program) is constrained by Program Text Models that allow dynamic process or thread structure (cannot restrict communication). Models that allow dynamic process or thread structure (cannot restrict communication). Models that have a static process or thread structure but do not impose syntactic limits on communication. Models that have a static process or thread structure but do not impose syntactic limits on communication. Models that have a static process or thread structure can guarantee performance by suitably limiting the frequency with which communication actions can be written. Models that have a static process or thread structure can guarantee performance by suitably limiting the frequency with which communication actions can be written.

11. 11 Categorizing Models Primary Basis of categorization Primary Basis of categorization LEVEL OF ABSTRACTION LEVEL OF ABSTRACTION Surrogate (substitute) for simplicity of the model From “nothing explicit” to “everything explicit” From “nothing explicit” to “everything explicit” Secondary Basis of categorization Secondary Basis of categorization LEVEL OF constraint on PROGRAM STRUCTURE LEVEL OF constraint on PROGRAM STRUCTURE From “static structure” to “dynamic structure” From “static structure” to “dynamic structure” By structure we mean the thread or process structure By structure we mean the thread or process structure ABSTRACT MODELS ABSTRACT MODELS Easy to build software : Hard to Compile to efficient Code Easy to build software : Hard to Compile to efficient Code CONCRETE MODELS CONCRETE MODELS Hard to build software : Easy to Compile to efficient Code Hard to build software : Easy to Compile to efficient Code

12. 12 Primary Categorization Models could allow the programmers to specify the following: Models could allow the programmers to specify the following: Decomposition of program to Parts (processes or threads) executable in parallel Decomposition of program to Parts (processes or threads) executable in parallel Mapping of parts to Processors Mapping of parts to Processors Communication among parts Communication among parts Synchronization among parts Synchronization among parts Models in decreasing levels of abstraction Models in decreasing levels of abstraction Nothing Explicit (No Parallelism) Nothing Explicit (No Parallelism) Best Model for Programmers Best Model for Programmers Similar to Sequential Software Similar to Sequential Software Translation is difficult Translation is difficult

13. 13 Primary Categorization Models in decreasing levels of abstraction Models in decreasing levels of abstraction Parallelism Explicit Parallelism Explicit Developers express the programs potential for parallelism Developers express the programs potential for parallelism Implicit : Decomposition, Mapping, Communication Synchronization Implicit : Decomposition, Mapping, Communication Synchronization Decomposition Explicit Decomposition Explicit Models require decisions to break up the program Models require decisions to break up the program Implicit: Mapping, Communication & Synchronization Implicit: Mapping, Communication & Synchronization Mapping Explicit Mapping Explicit Developer must also consider how best to place the pieces Developer must also consider how best to place the pieces Must be aware of processor’s interconnection Must be aware of processor’s interconnection Hard to make software portable Hard to make software portable

14. 14 Primary & Secondary Categorization Models in decreasing levels of abstraction Models in decreasing levels of abstraction Communication Explicit Communication Explicit Synchronization alone is implicit Synchronization alone is implicit Programmer makes almost all implementation decisions Programmer makes almost all implementation decisions Everything Explicit Everything Explicit Extremely difficult to build Software Extremely difficult to build Software Developers specify all implementation details Developers specify all implementation details Secondary Categorization (Sub-Categorization) Secondary Categorization (Sub-Categorization) Based on degree of control over structure & Communication Based on degree of control over structure & Communication Models with dynamic thread structure Models with dynamic thread structure Models with static thread structure but communication is NOT limited Models with static thread structure but communication is NOT limited Models with static thread structure and limited communication Models with static thread structure and limited communication

15. 15 Modeling Stateful Resources with Web Services v. 1.1 Motivation Many ways of representing state in Web services No agreed upon convention that would promote interoperabilityContributions Standardization and explicit representation of the web services state Standardization and explicit representation of the web services state Formalize using WS-Resource approach Formalize using WS-Resource approach Implied Resource Pattern – A set of conventions Implied Resource Pattern – A set of conventions

16. 16 Web Services Background ( http://www.w3.org/TR/2003/WD-ws-arch-20030808/) Service – abstract set of functionality Service – abstract set of functionality Agents – concrete entities implementing the service Agents – concrete entities implementing the service WSD – defines message formats, data types, transport protocols (WSDL) WSD – defines message formats, data types, transport protocols (WSDL) Semantics – defines contract, purpose and consequences of service Semantics – defines contract, purpose and consequences of service

17. 17 Web Service Environments Picture from : Modeling Stateful Resources with Web Services v 1.1 paper 1 – Web service (Software component) that provides some function 2 – Runtime Environment (App. Server) 3 – Web service Interface (WSDL) 4 – Message Processing facility 5 – Messages 6 – Dispatch 7 – Stateful Resources

18. 18 A Brief Taxonomy of State and Services Stateless Service Uses information only from input message Conversational Service Result of one operation depends on previous operation Result of one operation depends on previous operation Affects subsequent operation Affects subsequent operation HTTP sessions and cookies HTTP sessions and cookies Stateful Service Uses stateful resources (Paper’s focus)

19. 19 Stateless Implementations, Stateful Interfaces Service Implementation – Stateless Service Implementation – Stateless Delegates the responsibility of managing state to another component (eg: database or file system) Delegates the responsibility of managing state to another component (eg: database or file system) Enhances reliability & scalability Enhances reliability & scalability As a consequence, State is provided either: Explicitly (directly – by value or indirectly – by reference) Explicitly (directly – by value or indirectly – by reference) Implicitly ( within other components) – static Implicitly ( within other components) – static

20. 20 WS-Resource WS-Resource = Web Service + Stateful Resource WS-Resource = Web Service + Stateful Resource Implied Resource Pattern: Implied Resource Pattern: A stateful resource needs to be associated with a web service A stateful resource needs to be associated with a web service Implied – Resource id is an implicit parameter in message exchange Implied – Resource id is an implicit parameter in message exchange Static way – Association during deployment Static way – Association during deployment Dynamic way – Association during message execution Dynamic way – Association during message execution WS-Resource qualified End Point Reference WS-Resource qualified End Point Reference Returned by either: WS-Resource Factory Service WS-Resource Factory Service Registry Service Registry Service

21. 21 End Point Reference 3 – End Point Reference 5 – Stateful Resource 2 – Web Service

22. 22 Resource Identifier Meaningful only to the Web Service Meaningful only to the Web Service Implementation-specific Implementation-specific Opaque to the client Opaque to the client Client should not examine or interpret it Client should not examine or interpret it Should be unique within Web Service scope Should be unique within Web Service scope Need not be universally unique Need not be universally unique An endpoint reference containing a stateful resource identifier is a WS-Resource qualified endpoint reference.

23. 23 Using a WS-Qualified end point reference 1 – End Point Reference 2 – Soap Message 3 – Web Service identifies resource C Modeling Stateful Resources with Web Services v 1.1

24. 24 WS-Resource Lifecycle 1) WS-Resource Creation Factory Service creates a WS-Resource Factory Service creates a WS-Resource Involves the following steps: Creating a new stateful resource Creating a new stateful resource Assigning an identity Assigning an identity Associating the resource and the web service Associating the resource and the web service Places the Places the WS-Resource-qualified endpoint reference in to the registry for future use Response Message : WS-Resource-qualified endpoint reference

25. 25 WS-Resource Lifecycle 2) WS-Resource Identity From Web service perspective Uniquely identifies the resource within its scope Implementation-specific From Requestor’s (client) perspective Not Meaningful, Opaque Shall not interpret or examine 3) WS-Resource Destruction Requestor sends a destroy message to Web Service Receives a response Thereafter will receive fault/unknown/absent messages for any more request on that WS-Resource

26. 26 AGNOSTIC QUESTIONS Can you explain what is the role played by the reference properties of the endpoint reference? Answer The wsa:ReferenceProperties component may contain an XML serialization of stateful resource identifier, as understood by the Web service addressed by the endpoint reference. The stateful resource identifier represents the stateful resource to be used in the execution of the request message.

27. 27 AGNOSTIC QUESTIONS Can you explain what other patterns for enabling access to stateful resources are possible? Can you explain what other patterns for enabling access to stateful resources are possible?Answer Web service could maintain the resource identity as static service state, thus obviating the need to pass that identity in the WS- state, thus obviating the need to pass that identity in the WS- Addressing endpoint reference. This design choice implies a one- to-one mapping from Web service endpoints to stateful resources and thus a need for a unique Web service endpoint for each and thus a need for a unique Web service endpoint for each stateful resource. stateful resource.

28. 28 AGNOSTIC QUESTIONS If a service requestor has access to several WS-Resource- qualified endpoint references, can it compare the values of these resources and why? If a service requestor has access to several WS-Resource- qualified endpoint references, can it compare the values of these resources and why?Answer An attempt by the service requestor to compare the contents of two stateful resource identifiers is considered invalid. From the perspective of the service requestor, the content of the stateful resource identifier within the endpoint reference is opaque. resource identifier within the endpoint reference is opaque.

29. 29 AGNOSTIC QUESTIONS What is the difference between a stateful resource, and a WS- Resource? What is the difference between a stateful resource, and a WS- Resource?Answer A WS-Resource is a combination of a stateful resource, such as a database or hardware device, and a Web service with which it database or hardware device, and a Web service with which it interacts. interacts. A stateful resource is something that exists even when you're not interacting with it. A database exists, for example, you're not interacting with it. A database exists, for example, even when you're not querying it. even when you're not querying it.

30. 30 AGNOSTIC QUESTIONS The authors envisioned "an operation that would allow the values of resource properties to be inserted, updated, and deleted through the view provided by WS-Resource’s resource property document". Do you know if this can be done using the existing GT4 components and operations? The authors envisioned "an operation that would allow the values of resource properties to be inserted, updated, and deleted through the view provided by WS-Resource’s resource property document". Do you know if this can be done using the existing GT4 components and operations?Answer The state of a WS-Resource, i.e., the values of resource properties exposed in the WS-Resource’s resource properties document, can be read, modified, and queried by using standard Web services messages. The base functionality is to retrieve the value of a single resource property using a simple Web services request/response message exchange. The Web service responds with a message containing the values of the requested WS-Resource properties. The Monitoring and Discovery System (MDS) is the Globus Toolkit's information services component. MDS facilitates the discovery and characterization of resources, and monitors services and computations.

31. 31 AGNOSTIC QUESTIONS In the Introduction, the authors mention that "there are many ways of representing state in Web services". Besides WS- Resources, what are the other feasible ways to keep state? In the Introduction, the authors mention that "there are many ways of representing state in Web services". Besides WS- Resources, what are the other feasible ways to keep state?Answer WS-Resource is a standard for representing state. Many ways include different methods to pass the resource identifier in SOAP include different methods to pass the resource identifier in SOAP Message other than in a standard header. Using stateful Implementations instead of stateless implementations.

32. 32 THANK YOU