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
– 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.
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 …
• 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)
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.
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:
– WS-* where * refers to names of one of many
Standards in the grid computing
• Open Grid Services Architecture (OGSA)
• First announced at GGF4 in Feb 2002
• OGSA does not give details of
Grid computing software
• Started before standards became accepted.
Gone through several development cycles:
Originally own protocols were developed (e.g. GT2)
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.
2005 -
Now relies more directly upon developing web service
standards (GT 4)
Grid computing standards
Open Grid Services Architecture
• Defines standard mechanisms for creating,
naming, and discovering service instances.
• Addresses architectural issues relating to
interoperable services for grid computing
Web Services
• Introduced in the 2000
• Web services build upon earlier distributed computing
• One of the underlying concepts is the client-server model
• Software components designed to provide specific
operations (“services”) accessible using standard Internet
• 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
Basic client-server model
Client/Server Model
•Starts first
•Starts second
•Waits for contact
from a client
•Contacts a server
with a request
•Responds to
•Waits for response
from server
Types of Servers
A server can be:
Stateful Server
• Maintains some information between
• 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
Stateless Server
• Requires larger messages. That is, the
message must contain all information about
the request since no state information is
• Example: HTTP
Iterative Server
while (1) {
accept a connection (or request)
from a client
service the client
close the connection (if necessary)
Concurrent Server
while (1) {
accept a connection/request from client
start a new thread to handle this client
/* the thread must close the connection! */
Internet Addressing
Find the home page of user aapon
Contact the HTTP server on the computer named
• Same as IP address
• A Domain Name Server (DNS) may be called to
find the IP address of
• Each IP machine is usually configured with the
name of a DNS server.
• Some IP names and addresses can also be stored in
Internet Addressing
“http” says: send the message to port 80
• An IP address includes both a host address and a port
• 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.
• 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
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 ServiceOriented Architecture.
Service-Oriented Architecture
• 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.
Service-Oriented Architecture
Service registry
(Service requester)
(Service provider)
Service-Oriented Architecture
• Services “published” in a Service registry.
• Service requestor asks Service Registry to locate
• Service requestor “binds” with service provider to
invoke service.
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
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.
HTTP envelop
SOAP message
XML document
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
– Can be found via a simple ‘find’ mechansim
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.
Service discovery
Service description
Service invocation
Service message transport
Simple Object Access Protocol (SOAP)
Provides mechanisms for:
Defining communication unit - a SOAP message
Error handling
Data representation
Remote Procedure Calls (RPC’s)
Document-centric approach for business transactions
Binding to HTTP
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
Address of a Web Service
• URIs
Example (URL)
This does not exist, and if did, would only be
meaningful to software.
• 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
Web Service Application
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
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.
• 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.
Web Service Application
Request service
Result returned
Client receives result
Call client stub
• 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
• 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
– 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.
• 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
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)
Web Services Architecture
The Web Services
Architecture is specified
and standardized by the
World Wide Web
Consortium, the same
organization responsible
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
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
Port Type
Operation A
Messages (input, output)
Operation B
Messages (input, output)
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
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
Describes “how” the elements in abstract
interface (portType) are converted in actual
data representations and protocols e.g.
Could be more than one binding associated
with a portType.
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.
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
• 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
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
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.
Web Service Resource Framework
Web Service
Resource properties
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
Stateless web service + stateful
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
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.
WS-* Standards
Principal web service standards adopted for grid
• 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
WS-* Standards
• WS-Notification
– Collection of specifications that specifies how
configure services as notification producers or
• WS-Addressing
– Specifies how to address web services.
– Provides a way to address a web service/resource pair
• 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.