1 / 63

From last time

From last time. Grid computing concept started in mid-90’s Fosters 3 point checklist of a grid system: coordinate shared resources standard, open, general-purpose protocols and interfaces deliver nontrivial qualities of service Grid definitions focus on: distributed computing

perrin
Download Presentation

From last time

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. From last time • Grid computing concept started in mid-90’s • Fosters 3 point checklist of a grid system: • coordinate shared resources • standard, open, general-purpose protocols and interfaces • deliver nontrivial qualities of service • Grid definitions focus on: • distributed computing • common set of interfaces, tools and APIs • inter-institutional Virtual Organizations • virtualization of resources, services, people, orgs, etc.

  2. Standards Bodies The primary standards-setting body is1: • Global Grid Forum (GGF) • Started in 1998 • Meets three times a year, GGF1, GGF2, GGF3 … • More than 40 organizations involved and growing … Others: • W3C consortium (Worlds Wide Web Consortium) • Working on standardization of web-related technologies such as XML • See http://www.w3.org • OASIS (Organization for the Advancement of Structured Information Standards) • IETF, DMTF

  3. Grid computing • With the use of the Internet interconnection technology, implementation now based upon Internet technologies. • Now uses a form of web services. • Enables using existing protocols, security mechanisms, etc.

  4. Standards in the Web Services World • XML introduced (ratified) in 1998 • SOAP ratified in 2000 • Web services developed • Subsequently, standards have been are continuing to be developed: • WSDL • WS-* where * refers to names of one of many standards

  5. Standards in the grid computing world • Open Grid Services Architecture (OGSA) • First announced at GGF4 in Feb 2002 • OGSA does not give details of implementation.

  6. Grid computing software • Started before standards became accepted.Gone through several development cycles: • Originally own protocols were developed (e.g. GT2) • Then • OGSA (Open Grid Services architecture) standard and a specification called OGSI (Open Grid Service Infrastructure) was developed. Extended web service was invented called a grid service to embody state and transience. (GGF) Implemented in GT3. • And • Now relies more directly upon developing web service standards (GT 4) 1996-2002 2002-2004 2005 -

  7. Grid computing standards

  8. Open Grid Services Architecture(OGSA) • Defines standard mechanisms for creating, naming, and discovering service instances. • Addresses architectural issues relating to interoperable services for grid computing

  9. Web Services • Introduced in the 2000 • Web services build upon earlier distributed computing concepts • One of the underlying concepts is the client-server model • Software components designed to provide specific operations (“services”) accessible using standard Internet technology. • For machine interaction over a network. • Concept similar to Remote Procedure Call (RPC), Remote Method Invocation (RMI), only applied over HTTP • Usually through SOAP (simple Object Access Protocol) messages carrying XML documents, and a HTTP transport protocol.

  10. Basic client-server model

  11. Client/Server Model Server Client • Starts first • Waits for contact from a client • Responds to requests • Starts second • Contacts a server with a request • Waits for response from server

  12. Types of Servers A server can be: Iterative Concurrent iterative stateful concurrent stateful Stateful iterative stateless concurrent stateless Stateless

  13. Stateful Server • Maintains some information between requests • Requires smaller messages, since some information is kept between contacts • May become confused if a connection terminates abnormally (if the design is not fault tolerant) • Example: FTP

  14. Stateless Server • Requires larger messages. That is, the message must contain all information about the request since no state information is kept. • Example: HTTP

  15. Iterative Server while (1) { accept a connection (or request) from a client service the client close the connection (if necessary) }

  16. Concurrent Server while (1) { accept a connection/request from client start a new thread to handle this client /* the thread must close the connection! */ }

  17. Internet Addressing Find the home page of user aapon http://web.info.uvt.ro/~petcu/ • Same as IP address 194.102.62.5 • A Domain Name Server (DNS) may be called to find the IP address of comp.uark.edu • Each IP machine is usually configured with the name of a DNS server. • Some IP names and addresses can also be stored in /etc/hostfile Contact the HTTP server on the computer named web.info.uvt.ro

  18. Internet Addressing “http” says: send the message to port 80 • An IP address includes both a host address and a port number! • The HTTP server listens to port 80 • The HTTP server responds when a client contacts it • You can write a server that listens to any port not already in use! • A port number is a 16-bit integer. Ports below 1024 are reserved for system use. • Well-known ports include FTP, Telnet, SMTP, etc.

  19. RPC and RMI • Remote Procedure Call (RPC) • Extends the client/server concept by making the definition of an interface more formal, clarifying rules for parameter passing, adding capabilities for locating services, etc. • RMI (Remote Method Invocation) is RPC applied to object. We will study Java RMI

  20. Remote Procedure Call Early distributed computing system introduced in the 1980’s. Allows a local program to execute a procedure on a remote computer and get back results from the procedure. Basis of certain remote operations such as mounting remote files in a shared file system. We need to know how and where to make the call. The basic RPC requires the calling program to know details about how to make the call (meaning and types augments and return value) The calling program also needs to know where to send the request. RPC introduced the concept a service registry a third party used to identify location of “service” (procedure). Using a service registry is now part of what is now called a Service-Oriented Architecture.

  21. Service-Oriented Architecture (SOA) • Client needs to: • Identify location of the required service • Know how to communicate with the service to get it to provide the actions required. • Uses service registry - a third party.

  22. Service-Oriented Architecture Service registry Publish Find Bind Client Server (Service requester) (Service provider)

  23. Service-Oriented Architecture Steps: • Services “published” in a Service registry. • Service requestor asks Service Registry to locate service. • Service requestor “binds” with service provider to invoke service.

  24. Later systems • Later forms of remote procedure calls in 1990’s introduced distributed objects: • CORBA (Common Request Broker Architecture) • Java RMI (Remote Method Invocation) • Universally agreed standardized interfaces • Inter-operability • The need to provide flexibility • Using the Internet as the network communication (Internet standards)

  25. Key aspects of Web services Has similarities with RMI and other distributed object technologies (CORBA etc.) but:: • Web Services are platform independent • They use XML within a SOAP message). • Most use HTTP to transmit message. SOAP message HTTP envelop XML document

  26. Key aspects of Web services • Should be self-describing: • publish a public interface to the services • Should be discoverable: • Mechanism for publishing WS’s you have created • Can be found via a simple ‘find’ mechansim

  27. Web Services “Stack” • HTTP transport • SOAP message carrying XML documents • WSDL (Web Services Description Language used to describe message syntax for invoking a service and its response. • UDDI (Universal Description, Discovery and Integration) used as web service discovery mechanism. Activity Protocol/language Service discovery UDDI WSDL Service description Service invocation SOAP + XML Service message transport HTTP

  28. Simple Object Access Protocol (SOAP) Provides mechanisms for: • Defining communication unit - a SOAP message • Error handling • Extensions • Data representation • Remote Procedure Calls (RPC’s) • Document-centric approach for business transactions • Binding to HTTP

  29. XML Tags • Must define your own tags using names as names in a programming languages • As in programming languages, restrictions. Case sensitive. Start with a letter. • “Elements” have start and end tags. • Start tags can have attributes as in HTML • XML on-line materialsW3C consortium home page: http://www.w3.org/XML W3Schools XML Tutorial http://www.w3schools.com/xml/

  30. Address of a Web Service • URIs Example (URL) http://www.info.uvt.ro/webservices/math1 This does not exist, and if did, would only be meaningful to software.

  31. Note • The term “Web Service” is a little misleading as the web service need not be on the web. • It could be on the same computer as the client, or another computer in a local cluster.

  32. Web Service Application

  33. Client Stub • Between client code and the network is a client stub, sometimes called client proxy. • The client stub is responsible for taking a request from the client and converting the request into a SOAP request on the network - marshalling. • Also responsible for receiving SOAP responses on network and converting to a suitable form for client.

  34. Server Stub • Between the service and the network is a server stub, sometimes called a skeleton. • Responsible for receiving a SOAP request from the client stub and converting it into a suitable form for the service -unmarshalling. • Also converts the response from the service into a SOAP message for the client stub.

  35. Steps • Client calls client stub. • SOAP request sent across network • Server stub receives request and sends request to service • Service send result to serve stub • Server stub sends result across network to client stub. • Client stub sends result to client.

  36. Web Service Application SOAP request Call client stub Request service SOAP response Client receives result Result returned

  37. SOA • SOA is more than a group of web services or any other specific set of technologies: it's an architecture. • all functions are aggregated as reusable services, each defined by a service interface. • SOA is the contract to identify the services, • it contains rules to access them. • All request and response data, exception conditions, and functionality must be listed as part of this interface. • Service contracts are designed to be coarse-grained • interactions package several function calls and responses into fewer, but larger, messages. • Service-oriented architectures are not a new thing: • first SOA for many people was DCOM or Object Request Brokers (ORBs) based on the CORBA specification

  38. SOA • All services are abstracted from the internal design that achieves the results for the services. • interface should have sufficient information for a service to be identified and used without needing to know about its internal design, language, or platform implementation. • A loosely-coupled design also means that services are designed for no particular service consumer. • The information carried by the service should be agnostic to the purpose and technical objectives of the service consumer.

  39. SOA • Location of the service(s) should be transparent to the consumer: • registry could serve as the discovery mechanism for consumers to locate services being offered in a transparent way. • Irrelevant whether the services are local or remote • responsibility of the system, not the calling application, to effect and manage the invocation of the service. • Allows for services to be truly independent and managed.

  40. SOA Characteristics • Provides logical, abstracted view: • programs, dbs, business processes, etc • Message orientation defines service: • exchanged between provider agents and requester agents • one does not need to know a service is constructed • Legacy code can be "wrapped" in message handling code that allows it to adhere to the formal service definition. • Description orientation: • A service is described by machine-processable meta data. • details exposed important for use of service are included • semantics of a service should be documented by its description • Granularity: • Services use a small number of ops; large, complex messages. • Network orientation • Platform neutral exchange of messages (XML)

  41. Web Services Architecture The Web Services Architecture is specified and standardized by the World Wide Web Consortium, the same organization responsible for XML, HTML, CSS, etc.

  42. Web Service Definition Language (WSDL) A W3C standard XML document that describes three fundamental properties of a service: • What it is - operations (methods) it provides. • How it is accessed - data format, protocols. • Where it is located - protocol specific network address.

  43. Parts of a WSDL Document Parts of an WSDL document:: • Root definitions - namespaces • portType definitions - abstract definition of service • Message definitions - parameters in method signature • Type definitions - data types • Binding definitions - to protocols I.e. SOAP over HTTP • Service definitions - where service is, ports

  44. Service Port Port Type Operation A Messages (input, output) Operation B Messages (input, output) Bindings

  45. port and service Describe “where” service is. • port - describes how a binding is deployed at the endpoint of a network • service - a named collection of ports

  46. portType Describes “What” - an abstract definition of service operation. Compare to a Java interface. Uses the elements: • message definitions - a set of parameters referred to by method signature, decomposed into parts • type definitions - defines all data types used

  47. Binding Describes “how” the elements in abstract interface (portType) are converted in actual data representations and protocols e.g. SOAP over HTTP. Could be more than one binding associated with a portType.

  48. Grid service The Global Grid Forum (GGF) developed standard interfaces, behaviors, core semantics, etc. for grid applications based upon web services. GGF introduced the term Grid Service as an extended web service that conforms to the GGF OGSI standard. • Key aspect is the separation of the (web) service and a resource – conceptually if not actually. • Provides the ability to have “state” without altering the statelessness of a web service.

  49. Grid Services • Common interface specification supports the interoperability of discrete, independently developed services • Based on extensions of Web Services • OGSA – Open Grid Services Architecture • OGSI – Open Grid Services Infrastructure

More Related