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: Others:
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
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)
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 Stateful
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 http://web.info.uvt.ro/~petcu/
Find the home page of user aapon
Same as IP address
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
Find
Publish
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” Activity Protocol/language UDDI WSDL SOAP + XML
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 materials W3C consortium home page:
W3Schools XML Tutorial

30. Address of a Web Service
URIs
Example (URL)
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

38. 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

39. 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.

40. 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.

41. 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)

42. 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.

43. 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.

44. 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

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

46. 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

47. 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

48. 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.

49. 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.

50. 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

51. OGSI
Service Data – a common mechanism to expose a service instance’s state data for query, update, and change notification
Grid Services uses a Factory to manage instances – to allow transient and private instances

53. Changes to Grid Standards
Introduction of Web Services Resource Framework (WSRF), January, 2004
Web services vendors recognized the importance of OGSI concept but would not adopt OGSI as it was defined (summer 2003)
Globus Alliance teamed up with Web services architects and came up with WSRF
Add the ability to create, address, inspect, discover, and manage stateful resources

54. Stateless Web Service
It is generally thought that web services should be stateless – they do not remember or store information themselves from one invocation to the next.
Any state information needed by the web service to complete a client request or maintained should be held separately.

55. Web Service Resource Framework
(WS-RF)
Resource
Web Service
Resource properties
Holds information retained between accesses.
Client

56. First attempt as a stateful service
A now defunct attempt at providing a stateful service was embodied in the OGSI standard which was part of the OGSA grid computing standard
Introduced in 2002
Abandoned in 2004

57. Stateless web service + stateful resource
Web services can be front-ends to stateful resources.
Concept formalized in a standard called
WS-RF framework.
WS-RF also at the center of recent grid computing software (Globus 4.0).
Provides a way of identifying resource through the web service, and other things such as resource lifetime

58. WS-Resource Framework
A specification developed by OASIS, essentially to replace OGSI and make the implementation of a stateful web service acceptable.
Specifies how to make web services stateful and other feature, without drifting from the original web services concept.

61. WS-* Standards
Principal web service standards adopted for grid computing:
WSRF Framework collection of 5 specifications:
WS-ResourceProperties
Specifies how resource properties are defined and accessed
WS-ResourceLifetime
Specifies mechanisms to manage resource lifetimes
WS-ServiceGroup
Specifies how to group services or WS-Resources together
WS-BaseFaults
Specifies how to report faults

62. WS-* Standards WS-Notification WS-Addressing
Collection of specifications that specifies how configure services as notification producers or consumers
WS-Addressing
Specifies how to address web services.
Provides a way to address a web service/resource pair

63. WS-Addressing
WS-Resource Framework introduced a standard for addressing WS-Resources, called WS-Addressing
Introduces an End-Point Reference (EPR) to point to the service, which will provide the URL and possibly additional information about the service.