Grid Service Specification
Steve Tuecke
Mathematics and Computer Science Division
Argonne National Laboratory
tuecke@mcs.anl.gov
www.globus.org/ogsa
OGSA Early Adopters Workshop, Argonne, May 29, 2002
Transient Service Instances
z
“Web services” address discovery & invocation
of persistent services
– Interface to persistent state of entire enterprise
z
In Grids, must also support transient service
instances, created/destroyed dynamically
– Interfaces to the states of distributed activities
– E.g. workflow, video conf., dist. data analysis
z
Significant implications for how services are
managed, named, discovered, and used
– In fact, much of our work is concerned with the
management of service instances
Grid Services
www.globus.org/ogsa
Specification of Protocols
z
The “Grid Service Specification” is a protocol
specification
– Only concerned with issues of how clients
interact with a service
– Promotes interoperable implementations
> E.g. J2EE, .NET, Python, C, etc.
z
Hosting environment issues are out of scope
– Will be addressed in other specifications
> E.g. How to write a Grid service as an EJB.
Grid Services
www.globus.org/ogsa
Open Grid Services Architecture:
Fundamental Structure
1) WSDL conventions and extensions for
describing and structuring services
– Useful independent of “Grid” computing
2) Standard WSDL interfaces & behaviors for
core service activities
– portTypes and operations => protocols
– Define common patterns that occur
repeatedly in Grid settings
Grid Services
www.globus.org/ogsa
WSDL Conventions & Extensions
z
portType (standard WSDL)
– Define an interface: a set of related operations
z
serviceType (extensibility element)
– List of port types: enables aggregation
z
serviceImplementation (extensibility element)
– Represents actual code
z
service (standard WSDL)
– instanceOf extension: map descr.->instance
z
compatibilityAssertion (extensibility element)
– portType, serviceType, serviceImplementation
Grid Services
www.globus.org/ogsa
Service Description
z
z
Describes how a client interacts with a
service, independent of any particular service
instance
Primary purposes:
– Discovery: find services of interest
– Tooling: generate client proxies & server code
z
Any number of service instances may bind to
a particular service description
Grid Services
www.globus.org/ogsa
Discovery
z
Discovery drove many details of the GS Spec
z
Examples: Find me a service that…
– supports a particular set of operations.
– can create a service that supports operations.
– will respond as I expect to an op request.
– I can use.
– is currently suspended waiting for input.
– has 10MB bandwidth tomy machine.
– has 5ms latency to any copy of my database.
– has various combinations of these…
Grid Services
www.globus.org/ogsa
Tooling
z
Standard WSDL has most of what is
needed for code generation
– Client proxies in various languages
– Server skeletons
z
One missing bit: serviceType
– WSDL <service> element is ambiguous
about the relationship of its ports
> Do you generate one class that is a union of the
operations from all portTypes, or separate classes for
each port
Grid Services
www.globus.org/ogsa
Capturing Semantics
z
z
Service description obviously captures
interface syntax
But capturing semantic meaning is critical for
discovery
– Not only does the service accept an operation
request with a particular signature
– But it should also respond as expected
> “As expected” is usually defined offline in specifications
z
Approach: name everything
– Use names as basis for reasoning about
semantics
Grid Services
www.globus.org/ogsa
Compatibility Assertions
z
One type of semantic reasoning is about
compatibility between services
– Just because two services implement the same
operations, does not necessarily imply that
they can be used interchangeably by a client
z
z
Current approach: define compatibility
relations between named parts of the service
description
But who is making the assertion?
– Probably will move this out of WSDL, and into
service data of compatibility services
Grid Services
www.globus.org/ogsa
Structure of a Grid Service
service
…
Service
Instantiation instanceOf
service
service
instanceOf
Service
Description serviceImplementation
instanceOf
cA
serviceType
=Standard WSDL
PortType
cA = compatibilityAssertion
Grid Services
…
…
service
instanceOf
serviceImplementation
cA
PortType
serviceType
cA
…
…
PortType
www.globus.org/ogsa
serviceType Definition
<gsdl:serviceType name=“nmtoken”>
<wsdl:documentation .... />?
<gsdl:portTypeList>
<gsdl:documentation .... />?
<gsdl:portTypeRef="qname"/>*
</gsdl:portTypeList>
<gsdl:compatibility statementName="qname"/>*
<-- extensibility element --> *
</gsdl:serviceType>
Grid Services
www.globus.org/ogsa
serviceImplementation Definition
<gsdl:serviceImplementation
name=“nmtoken”
serviceType=“qname”>
<wsdl:documentation .... />?
<gsdl:compatibility
statementName="qname"/>*
<-- extensibility element --> *
</gsdl:serviceType>
Grid Services
www.globus.org/ogsa
Standard Interfaces & Behaviors:
Four Interrelated Concepts
z
Naming and bindings
– Every service instance has a unique name,
from which can discover supported bindings
z
Information model
– Service data associated with Grid service
instances, operations for accessing this info
z
Notification
– Interfaces for registering interest and
delivering notifications
z
Lifecycle
– Service instances created by factories
– Destroyed explicitly or via soft state
Grid Services
www.globus.org/ogsa
OGSA Interfaces and Operations
Defined to Date
z
GridService
Required
z
Factory
– FindServiceData
– Destroy
– CreateService
z
PrimaryKey
– SetTerminationTime
z
– FindByPrimaryKey
– DestroyByPrimaryKey
NotificationSource
– SubscribeToNotificationTopic
z
Registry
– UnsubscribeToNotificationTopic
z
– RegisterService
NotificationSink
– DeliverNotification
– UnregisterService
z
HandleMap
Authentication, reliability are binding properties
Manageability, concurrency, etc., to be defined
Grid Services
– FindByHandle
www.globus.org/ogsa
Composition of portTypes
z
z
We are trying to define basic patterns of
interaction, which can be combined with
each other with custom patterns in a
myriad of ways
GS Spec focuses on:
– Atomic, composable patterns in the form of
portTypes and service data element types
– A model for how these are composed
z
Actual serviceType definitions are left to
other groups that are defining real services
– More on this later…
Grid Services
www.globus.org/ogsa
Naming and Bindings
z
Every service instance has a unique and immutable
name: Grid Service Handle (GSH)
– Basically just a URL
z
Handle must be converted to a Grid Service
Reference (GSR) to use service
– Includes binding information; may expire
– Separation of name from implementation facilitates
service evolution
z
The HandleMap interface allows a client to map from
a GSH to a GSR
– Each service instance has home HandleMap
Grid Services
www.globus.org/ogsa
Observations on Handles
z
Names vs references vs handles
– Handle is a special name that is known to
the service
z
Perhaps not as special as we first thought
– Maybe just another form of reference,
which requires a particular type of resolver
– Originally thought handle could be used for
policy assertions about the service
> But this only works if handle is an authenticated name
z
Should generalize the specification to allow
for other handle/resolver techniques
Grid Services
www.globus.org/ogsa
Service Data
z
A Grid service instance maintains a set of service
data elements
– XML fragments encapsulated in standard <name, type,
TTL-info> containers
– Includes basic introspection information, interfacespecific data, and application data
z
FindServiceData operation (GridService interface)
queries this information
– Extensible query language support
z
See also notification interfaces
– Allows notification of service existence and changes in
service data
Grid Services
www.globus.org/ogsa
Why Service Data?
z
z
Discovery often requires instance-specific,
perhaps dynamic information
Service data offers a general solution
– Every service must support some common
service data, and may support any additional
service data desired
– Not just meta-data, but also instance state
z
Part of the MDS-2 model contained in OGSA
– Defines standard data model, and query op
– Complements soft-state registration and
notification
Grid Services
www.globus.org/ogsa
ServiceData Elements (new)
<gsdl:serviceData
name=“nmtoken”?
globalName=”qname”?
type=”qname”
goodFrom="xsd:dateTime"?
goodUntil="xsd:dateTime"?
availableUntil=”xsd:dateTime”?>
<-- extensibility element --> *
</gsdl:serviceData>
Grid Services
www.globus.org/ogsa
ServiceData Attributes
z
z
z
z
z
z
name: local name for this Grid service data element.
globalName: A global name (i.e. QName) for this Grid service
data element.
type: The XML schema type of the element contained in the
extensibility element
goodFrom: Declares the time from which the value of the SDE
carried in its extensibility element is said to be valid. This is
typically the time at which the contained element was created or
aggregated.
goodUntil: Declares the time until which the value of the SDE
carried in its extensibility elements is said to be valid. This value
MUST be greater than the goodFrom time.
availableUntil: Declares the time until which this named SDE is
expected to be available. Prior to this time, a client SHOULD be
able to query for an updated value of this SDE. This value MUST
be greater than the goodFrom time.
Grid Services
www.globus.org/ogsa
ServiceData Example
<gsdl:serviceData name=“foo” type=”n1:sometype”
goodFrom="200204271020" goodUntil=”200204271120”
availableUntil=”200204281020”>
<n1:e1>
<n1:e2>
abc
</n1:e2>
<n1:e3 gsdl:goodUntil=”200204271030”>
def
</n1:e3>
<n1:e4 gsdl:availableUntil=”200203272020”>
ghi
</n1:e4>
</n1:e1>
</gsdl:serviceData>
Grid Services
www.globus.org/ogsa
FindServiceData
z
Standard query operation against a
service’s service data elements
– Simple “by name” query language required
– Can support Xpath, Xquery, etc.
z
Simple, extensible query operation
– Not meant to be the end-all, be-all of query
interfaces
– Expect other groups to define query
interfaces designed to handle other data
types (e.g. relational), large responses (e.g.
iterater-based interface), etc.
Grid Services
www.globus.org/ogsa
Static Service Data
z
In order to support rich discovery, we
often want to annotate a WSDL
serviceType with additional information
– Meta-data and policies about service
– What service data the service supports
z
Maybe support service data in WSDL
– A serviceType can reference a set of service
data elements
– All static service data also available from
instance via FindServiceData
Grid Services
www.globus.org/ogsa
Notification Interfaces
z
NotificationSource for client subscription
– Persistent query against service data
> Generates notification message, whose type is determined by
the query
> Filters, topics, etc. can be represented in query language
> Supports messaging services, 3rd party filter services, …
– Soft state subscription to a generator
z
z
NotificationSink for asynchronous delivery of
notification messages
A wide variety of uses are possible
– E.g. Dynamic discovery/registry services, monitoring,
application error notification, …
Grid Services
www.globus.org/ogsa
Notification & FindServiceData
z
In current spec they are somewhat separate
z
They are being unified in new spec
– Both are simply forms of query against the
service data of an instance
– FindServiceData is a simple query (pull)
– Notification subscription is a persistent query,
with asynchronous response (push)
z
Interesting open questions on what the
subscription language should look like
– How to define temporal aspects of query?
Grid Services
www.globus.org/ogsa
Notification Subscription Lifetime
z
Another planned change is to use normal
service lifetime management approach to
manage subscription lifetime
– A subscription is just a factory operation,
which creates a new services that
represents the subscription state
– SetTerminationTime & Destroy can be used
to manage lifetime of that subscription
– The service data of the subscription service
contains information about the subscriptio
Grid Services
www.globus.org/ogsa
Lifetime Management
z
GS instances created by factory or manually;
destroyed explicitly or via soft state
– Negotiation of initial lifetime with a factory
z
GridService interface supports
– Destroy operation for explicit destruction
– SetTerminationTime operation for keepalive
z
Soft state lifetime management avoids
– Explicit client teardown of complex state
– Resource “leaks” in hosting environments
Grid Services
www.globus.org/ogsa
Lifetime Management Questions
z
z
Should Destroy and SetTerminationTime be
required operations?
What are semantics of SetTerminationTime?
– Contract between client and service, related to
accounting?
> Client is willing to keep paying for service until time X
> Service will not charge for service after time Y
Grid Services
www.globus.org/ogsa
Factory
z
Factory interface’s CreateService operation creates
a new Grid service instance
– Reliable creation (once-and-only-once)
> Is reliability part of service interface, or at binding level?
z
z
z
“Reliable messaging” vs “reliable invocation”
CreateService operation can be extended to accept
service-specific creation parameters
Returns a Grid Service Handle (GSH)
– A globally unique URL
– Uniquely identifies the instance for all time
– Based on name of a home handleMap service
Grid Services
www.globus.org/ogsa
Factories as Templates
z
Factories are under-specified in current spec
– There is an extensibility argument that hides all
the interesting input/output parameters
> Good because it allow for generic clients
> Bad because it hinders discovery
z
Two options:
– Move to differently-named, fully-typed factory
creation operations
> Factories are just a concept (e.g. consider subscription)
– Use service data to describe what a particular
factory supports in its extensibility arguments
> Single Factory portType which is basically a template
Grid Services
www.globus.org/ogsa
Factories and Virtualization
z
Consider a factory to create a given service
– CreateService expects particular input args
z
GS interfaces permit various implementations,
translucent to the client
– Simple factory might create service within its own hosting
environment
– Factory might discover an appropriate resource to host
the service, and delegate request to another factory
– Factory may decompose request into multiple service
creations, & create aggregating service
Grid Services
www.globus.org/ogsa
Registry
z
The Registry interface may be used to
register Grid service instances with a registry
– A set of Grid services can periodically register
their GSHs into a registry service, to allow for
discovery of services in that set
– Just registration of existence, not of information
z
Registrations maintained in the service data of
the registry service
– Standard discovery mechanisms can then be
used to discover registered services
Grid Services
www.globus.org/ogsa
Observations on Registry
z
Perhaps “Registration” is a better name
than “Registry”
– Not concerned with registry query
– Just notification of existence
z
z
Debating if registration should just fold
into a notification subscription
More on this later…
Grid Services
www.globus.org/ogsa
Example: Building Registries
z
Options for building registries…
– Need for radically different query capabilities
– Topology of services used for discovery
> E.g hierarchical, p2p
z
Can illuminate important aspects of OGSA…
– Composition of interfaces
– Service data
– Multiple protocol bindings
Grid Services
www.globus.org/ogsa
Architecting Registries
z
There is no single registry that can serve all
purposes
– A Virtual Organization (community) must
architect registries that are appropriate to
their needs
z
But there are common primitives that can be
used to architect many different registries
– Service data
– Notification
– Soft-state registration
Grid Services
www.globus.org/ogsa
Need for Different Queries
z
Need registries that can answer radically
different queries
– “Find me all Redhat Linux 7.2 machines which
are available for my use with a load < 0.3.”
> Requires a registry that can deal with dynamic information
– “Find me both an available cluster and a one
my project database servers with good
network connectivity between them.”
> Requires a registry that can join information from multiple
services
Grid Services
www.globus.org/ogsa
Use of Service Data
z
A registry’s service data should be
architected to support query requirements
– Customized service data XML types
– More powerful (e.g. Xpath, Xquery) or
custom query languages
z
A registry is defined largely by its service
data and query language
Grid Services
www.globus.org/ogsa
WS-Inspection
z
z
Standard format for a list of services
May be appropriate service data format for
some registries
<?xml version="1.0"?>
<inspection
xmlns="http://schemas.xmlsoap.org/ws/2001/10/inspection/">
<service>
<description
referencedNamespace="http://schemas.xmlsoap.org/wsdl/"
location="http://example.com/stockquote.wsdl" />
</service>
</inspection>
Grid Services
www.globus.org/ogsa
Discovery Topologies
z
GS patterns can be applied in various ways
to build discovery topologies
– Hierarchical with caching
– Hierarchical with forwarding
– Peer-to-peer mesh
– Multicast/broadcast
Grid Services
www.globus.org/ogsa
Hierarchical with Caching
z
Soft-state registration up the tree
– Various services in a VO are configured to send softstate registrations to registries
– Registry services may be configured to send soft-state
registrations to higher-level registries
z
FindServiceData & Subscription down the tree
– Registry gathers information that it cares about from
each registered service
– Registry caches that information as its service data, with
some refresh policy
Grid Services
www.globus.org/ogsa
Hierarchical with Forwarding
z
z
Soft-state registration up the tree
Forwards query & subscription down the
tree
– When registry receives query from client, it:
> Queries lower level registries & services
> Collects results, formats them appropriately
> Replies to client query
Grid Services
www.globus.org/ogsa
Peer-to-peer Mesh
z
Each service also acts as a “registry”
– It supports queries against service data that
is appropriate for discovery
z
z
Each service soft-state registers with a set
of peers, to establish the mesh
When queries, the service forwards the
query to any services that are registered
with it
– Perhaps caches any subsequent responses
Grid Services
www.globus.org/ogsa
Multicast Discovery
z
Use a custom protocol binding for WSDL
– E.g. SOAP over IP multicast
z
Option 1
– Registries subscribe to IP multicast channel
– Clients send queries to IP multicast channel
– Soft-state registration not used
z
Option 2
– Services send information via IP multicast
channel to any listening registries
> Does not use registration of existence, but of information
– Client queries a registry using normal approach
Grid Services
www.globus.org/ogsa
The End