# Presentation: 125872

## OGSI for Network Measurement

- Keith R. Jackson
- Lawrence Berkeley National Laboratory
- krjackson@lbl.gov

## Overview

- Globus Project / Open Grid Services Architecture (OGSA)
- OGSI Specification
- Service Data Elements
- Service Data Operations
- Notification
- Acknowledgements / Contact Information

## Grid Evolution:Open Grid Services Architecture

- Refactor Globus protocol suite to enable common base and expose key capabilities
- Service orientation to virtualize resources and unify resources/services/information
- Embrace key Web services technologies for standard IDL, leverage commercial efforts
- Result: standard interfaces & behaviors for distributed system management: the _Grid service_

- Courtesy of the Globus ProjectTM

## OGSA Structure

- Courtesy of the Globus ProjectTM

- A standard substrate: the Grid service
- OGSI = Open Grid Service Infrastructure
- Standard interfaces and behaviors that address key distributed system issues
- Much borrowed from GT abstractions
- ... supports standard service specifications
- Resource mgt, dbms, workflow, security, ...
- Target of current & planned GGF efforts
- ... and arbitrary application-specific services based on these & other definitions

## Transient Service Instances

- “Web services” address discovery & invocation of _persistent services_
- Interface to persistent state of entire enterprise
- 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, subscription
- Significant implications for how services are managed, named, discovered, and used
- In fact, much of Grid is concerned with the management of service instances

- Courtesy of the Globus ProjectTM

## Standard Interfaces & Behaviors:Four Interrelated Concepts

- Naming and bindings
- Every service instance has a _unique name_, from which can discover _supported bindings_
- Lifecycle
- Service instances created by _factories_
- Destroyed _explicitly_ or via _soft state_
- Information model
- _Service data_ associated with Grid service instances, operations for accessing this info
- Basis for service introspection, monitoring, discovery
- Notification
- Interfaces for _registering existence_, and _delivering notifications_ of changes to service data

- Standard Interfaces & Behaviors:Four Interrelated Concepts

- Courtesy of the Globus ProjectTM

## Open Grid Services Infrastructure Specification

## OGSI Grid Service Specification

- Defines WSDL conventions and GSDL extensions
- For describing and structuring services
- Working with W3C WSDL working group to drive GSDL extensions into WSDL
- Defines fundamental interfaces (using WSDL) and behaviors that define a Grid Service
- A unifying framework for interoperability & establishment of total system properties

- Courtesy of the Globus ProjectTM

## OGSI Specification

- The Specification Defines how Entities can Create, Discover and Interact with a Grid Service

- Service
- data
- element

- Service
- data
- element

- Service
- data
- element

- Service Implementation

- GridService
- (required)

- ... other interfaces ...
- (optional)

- Optional:
-  Service creation- Notification
-  Registration
-  Service Groups
*+ application-**specific interfaces*

- Required:
-  Introspection  (service data)
-  Explicit destruction
-  Soft-state lifetime

## OGSI Specification (cont.)

- GridService portType
- Defines the fundamental behavior of a Grid Service
- Introspection
- Discovery
- Soft State Lifetime Management
- Mandated by the Spec

## OGSI Specification (cont.)

- Factory portType
- Factories create services
- Factories are typically persistent services
- Factory is an optional OGSI interface
- (Grid Services can also be instantiated by other mechanisms)

## OGSI Specification (cont.)

- Notification portTypes
- A subscription for notification causes the creation of a NotificationSubscription service
- NotificationSinks are not required to implement the GridService portType
- Notification portTypes are optional

## OGSI Specification (cont.)

- Service group portTypes
- A ServiceGroup is a grid service that maintains information about a group of other grid services
- The classic registry model can be implemented with the ServiceGroup portTypes
- A grid service can belong to more than one ServiceGroup
- Members of a ServiceGroup can be heterogenous or homogenous
- Each entry in a service group can be represented as its own service
- Service group portTypes are optional OGSI interfaces

## OGSI Specification (cont.)

- HandleResolver portType
- Defines a means for resolving a GSH (Grid Service Handle) to a GSR (Grid Service Reference)
- A GSH points to a Grid Service
- (GT3 uses a hostname-based GSH scheme)
- A GSR specifies how to communicate with the Grid Service
- (GT3 currently supports SOAP over HTTP, so GSRs are in WSDL format)
- HandleResolver is an optional OGSI interface

## A Service Creation Scenario

-   Client

- A Service Creation Scenario

- Registry

- 1. From a known
- registry, the client
- discovers a factory
- by querying service
- data

## A Service Creation Scenario

- A Service Creation Scenario

- Registry

- 1. From a known
- registry, the client
- discovers a factory
- by querying service
- data

- 2. The client calls the
- createService
- operation on the
- factory

-  Factory

## A Service Creation Scenario

-   Client

- A Service Creation Scenario

- Registry

- 1. From a known
- registry, the client
- discovers a factory
- by querying service
- data

- 2. The client calls the
- createService
- operation on the
- factory

-  Factory

-  Service

- 3. The factory
- creates a
- service

## A Service Creation Scenario

- A Service Creation Scenario

- Registry

- 1. From a known
- registry, the client
- discovers a factory
- by querying service
- data

- 2. The client calls the
- createService
- operation on the
- factory

-  Factory

-  Service

- 3. The factory
- creates a
- service

-                         4. The factory
-               returns a locator

## A Service Creation Scenario

-   Client

- A Service Creation Scenario

- Registry

- 1. From a known
- registry, the client
- discovers a factory
- by querying service
- data

- 2. The client calls the
- createService
- operation on the
- factory

-  Factory

-  Service

- 3. The factory
- creates a
- service

-                         4. The factory
-               returns a locator

- 5. The client and service interact

## A Notification Scenario

- NotificationSink

**1**. NotificationSink calls the
- subscribe operation on
- NotificationSource

- NotificationSource

## A Notification Scenario

- NotificationSink

- 1. NotificationSink calls the
- subscribe operation on
- NotificationSource

- NotificationSource

- NotificationSubscription

- 2.NotificationSource creates
- a subscription
- service

## A Notification Scenario

- NotificationSink

**1**. NotificationSink calls the
- subscribe operation on
- NotificationSource

- NotificationSource

- NotificationSubscription

**2**.NotificationSource creates
- a subscription
- service

-                         **3**. Notification
-                Source  returns a
-      locator to the subscription
- service

## A Notification Scenario

- NotificationSink

**1**. NotificationSink calls the
- subscribe operation on
- NotificationSource

- NotificationSource

- NotificationSubscription

**2**.NotificationSource creates
- a subscription
- service

-                         **3**. Notification
-                Source  returns a
-      locator to the subscription
- service

**4.b** The NotificationSink and
- Subscription service interact
- to perform lifetime management

**4.a** deliverNotification
- stream continues
- for the lifetime of
- NotificationSubscription

## Service Data Elements

## Standard way to expose a service instance’s state data.
No service data specific operations defined.
No getXXX() or setXXX() functions
GridService portType defines base operations for manipulating Service Data by name
A new child element of portType is defined: serviceData.

- No service data specific operations defined.
- No getXXX() or setXXX() functions
- GridService portType defines base operations for manipulating Service Data by name
- A new child element of portType is defined: serviceData.

- Service Data Elements

- <gwsdl:portType name="NCName"> *
- <wsdl:documentation .... /> ?
- <wsdl:operation name="NCName"> *
- ...
**<sd:serviceData name="NCName" ... /> ***
**<sd:staticServiceDataValues>?**
**<some element>***

## SDE Example

- <wsdl:definitions xmlns:tns=”xxx” targetNamespace=”xxx”>
- <gwsdl:portType name="exampleSDUse"> *
- <wsdl:operation name=...>
- ...
- <sd:serviceData name="sd1" type=”xsd:String”
- mutability=”static”/>
- <sd:serviceData name="sd2" type=”tns:SomeComplexType”/>
**...**
- <sd:staticServiceDataValues>
- <tns:sdl>initValue</tns:sd1>
- </sd:staticServiceDataValues>
- </gwsdl:portType>
- ...
- </wsdl:definitions>

## SDE Schema Elements

- maxOccurs = (nonNegativeInteger | unbounded) : default to 1
- This value indicates the maximum number of serviceData element values that can appear in the service instance’s serviceDataValues or the portType staticServiceDataValues.
- minOccurs = nonNegativeInteger : default to 1
- This value indicates the minimum number of serviceData element values that can appear in the service instance’s serviceDataValues or the portType staticServiceDataValues.
- If the value is 0, then the serviceData element is optional

## SDE Schema Elements (cont.)

- name = NCName and {target namespace}
- The name of the serviceData element must be unique amongst all sd:serviceData and xsd:element declarations in the target namespace of the wsdl:definitions element.
- The combination of the name of the serviceData element and the target namespace of the wsdl:definitions element’s targetNamespace attribute forms a QName, allowing a unique reference to this serviceData element.
- nillable = boolean : default to false
- Indicates whether the serviceData element can have a nil value (that is a value that has an attribute xsi:nil with value=“true”).
- For example a serviceData declaration
- <serviceDataElement name=”foo” type=”xsd:string” nillable=true” />
- can have a valid SDE value
- <foo xsi:nil=”true”/>

## SDE Schema Elements (cont.)

- type = QName
- Defines the XML schema type of the serviceData element value
- modifiable = “boolean” : default to false
- If true, it is legal for requestors to directly update the serviceData value through the setServiceData operation (see §9.2.2), subject to constraints on cardinality (minOccurs, maxOccurs) and mutability. If false, the serviceData element should be regarded as “read only” by the requestor, though its values may change as a result of other operations on the service’s interface.
- mutability = “static” | “constant” | “extendable” | “mutable” : default to extendable
- An indication of whether and how the values of a serviceData element can change.

## SDE Schema Elements (cont.)

- {any attributes with non-schema namespace}
- Open content on the attributes of serviceData declaration is allowed.
- Content
- annotation
- This element allows documentation elements to appear as children of a serviceData declaration
- Open content element model, meaning elements from any other namespace (besides XML Schema) may appear as child elements of the serviceData element.
- A serviceData element extends a restricted of xsd:element to allow open element content model,

## Service Data Operations

## findServiceData

**GridService :: findServiceData**
- Query the service data.
**Input**
- • *QueryExpression*: The query to be performed. This extensib le parameter MUST conform to an inputElement declaration denoted by one of the findServiceDataExtensibility SDE values. Note: The service infers what to do based on the tag of the root element of this argument.
**Output**
- • *Result*: The result of the query. The format of this result is dependent upon the QueryExpression.

## findServiceData (cont.)

**Fault(s)**
- • *ExtensibilityNotSupportedFault: *Indicates that the service cannot evaluate the
- QueryExpression because its type is not supported by this service.
- • *ExtensibilityTypeFault*: Indicates that the value passed as the QueryExpression violates
- that value’s type.
- • *TargetInvalidFault*: Indicates that one or more of the SDEs that the QueryExpression
- requires do not exist in this service.
- • *Fault*: Any other fault.

## setServiceData

**GridService :: setServiceData**
- This operation allows for the modification of a service data element’s values, if its service data declaration specifies modifiable=”true”. Changing a modifiable service data element implies changing the corresponding state in the underlying service instance. If no service data elements have a modifiable=”true” attribute then setServiceData is essentially disabled.
**Input**
- • *UpdateExpression*: The update to be performed. This extensible parameter MUST conform to an inputElement declaration denoted by one of the setServiceDataExtensibility SDE values. Note: The service infers what to do based on the tag of the root element of this argument

## setServiceData (cont.)

**Output**
- • *Result*: The result of the update. The format of this result is dependent upon the UpdateExpression.
**Fault(s)**
- • *ExtensibilityNotSupportedFault: *Indicates that the service cannot evaluate the UpdateExpression because its type is not supported by this service.
- • *ExtensibilityTypeFault*: Indicates that the value passed as the UpdateExpression violates that value’s type.
- • *CardinalityViolationFault: *Indicates that operation requested would violate the “minOccurs” and/or “maxOccurs” attributes of the service’s SDE(s).
- • *MutabilityViolationFault: *Indicates that the UpdateExpression was not consistent with the “mutability” attribute of the service’s SDE(s).
- • *ModifiabilityViolationFault: *Indicates that the UpdateExpression was not consistent with the “modifiable” attribute of the services’s SDE(s).

## setServiceData (cont.)

- • *TypeViolationFault: *Indicates that the UpdateExpression contains values that do not
- conform to the XSD type of the service’s SDE(s).
- • *IncorrectValueFault: *Indicates that the UpdateExpression contains values that are XSD type conformant, but are not acceptable to the service for other reasons.
- • *PartialFailureFault: *Indicates that servic e was unable to satisfy all portions of the
- UpdateExpression. This fault extends FaultType with an element that contains a list of qnames of SDEs from the UpdateExpression that could not be updated. This fault MAY have 1 or more “faultcause” elements that describe in more detail the portions that failed, using any of the fault types allowed by setServiceData.
- • *Fault*: Any other fault.

## Notification

## Notification portTypes

- Notification Source
- Source of notification messages. May send to multiple sinks
- Notification Sink
- Receives notification messages from any number of notification sources
- Not required to implement the GridService portType
- NotificationSubscription
- Created from a subscription message and used to manage a subscription

## Notification Source SDE’s

- notifiableServiceDataName
- A set of QNames of service data elements to which a requestor MAY subscribe for notification of changes.
- <sd:serviceData name=”notifiableServiceDataName” type=”xsd:QName” minOccurs=”0” maxOccurs=”unbounded” mutability=”mutable” modifiable=”false” nillable=”false”/>
- subscribeExtensibility
- A set of operation extensibility declarations (§7.8) for the subscribe operation. Any conforming inputElement declared by values of this SDE MAY be used by the client as a SubscriptionExpression parameter to the instance’s subscribe operation, and implies the subscription semantics and notification message that result from the subscription.
- <sd:serviceData name=”subscribeExtensibility” type=”ogsi:OperationExtensibilityType” minOccurs=”1” maxOccurs=”unbounded” mutability=”static” modifiable=”false” nillable=”false”/>

## Notification Source SDE’s (cont.)

- The NotificationSource portType also includes the following initial service data value elements.
- <sd:staticServiceDataValues> <ogsi:subscribeExtensibility 	    inputElement=”ogsi:subscribeByServiceDataNames” />
- </sd:staticServiceDataValues>

## Notification Source Operations

**NotificationSource :: subscribe**
- Subscribe to be notified of subsequent changes to the target instance’s service data. This operation creates a Grid service subscription instance, which MAY subsequently be used to manage the lifetime and discovery properties of the subscription.
**Input:**
- • *SubscriptionExpression*: The subscription to be performed. This extensible parameter MUST conform to an inputElement declaration denoted by one of the
-      subscribeExtensibility SDE values. Note: The service infers what to do based on the tag of the root element of this argument.
- • *Sink *: The locator of the notification sink to which messages will be delivered. This
-      locator MAY be to some other service than the one issuing this subscription request, thus allowing for third-party subscriptions. This locator MAY contain only references, thus allowing it to refer, for example, to a Web service that implements the NotificationSink portType but that does not have a handle.
- • *ExpirationTime*: The initial time at which this subscription instance should terminate, and thus notification delivery to this sink be halted. Normal GridService lifetime management operations MAY be used on the subscription instance to change its lifetime.

## Notification Source Operations (cont.)

**Output:**
- • *SubscriptionInstanceLocator*: A locator to the subscription instance that was created to manage this subscription. This subscription instance MUST implement the NotificationSubscription portType.
- • *CurrentTerminationTime*: An element of type TerminationTimeType (as defined in §7.6) that gives the NotificationSubscription service's currently planned termination time. The timestamp attribute of this CurrentTerminationTime MUST be the time at which the NotificationSubscription service was created.

## Notification Source Operations (cont.)

**Fault(s):**
- • *ExtensibilityNotSupportedFault: *Indicates that the service cannot evaluate the SubscriptionExpression because its type is not supported by this service.
- • *ExtensibilityTypeFault*: Indicates that the value passed as the SubscriptionExpression violates that value’s type.
- • *TargetInvalidFault*: Indicates that one or more of the SDEs that the SubscriptionExpression requires does not exist in this service.
- • *Fault*: Any other fault.

## Notification Subscription SDE’s

- subscriptionExpression
- The current subscription expression managed by this subscription instance.
- 	<sd:serviceData name=”subscriptionExpression” type=”xsd:anyType” minOccurs=”1” maxOccurs=”1” mutability=”mutable” modifiable=”false” nillable=”false”/>
- sinkLocator
- The Grid Service Locator of the Notification sink to which this subscription is delivering messages.
- 	<sd:serviceData name=”sinkLocator” type=”ogsi:LocatorType” minOccurs=”1” maxOccurs=”1” mutability=”mutable” modifiable=”false” nillable=”false”/>

## Notification Sink Operations

**NotificationSink :: deliverNotification**
- Deliver message to this service.
**Input:**
- • *Message*: An XML element containing the notification message. The content of the message is dependent upon the notification subscription.
- This operation is input-only, so it does not return an output or faults.

## Acknowledgement

- Thanks to the Globus project
- More information can be found at
- _[http://www.](http://www-unix.mcs.anl.gov/~gawor/ldap/)__[globus](http://www-unix.mcs.anl.gov/~gawor/ldap/)__[.org/](http://www-unix.mcs.anl.gov/~gawor/ldap/)_
- _[http://www.](http://www-unix.mcs.anl.gov/~gawor/ldap/)__[ggf](http://www-unix.mcs.anl.gov/~gawor/ldap/)__[.org/](http://www-unix.mcs.anl.gov/~gawor/ldap/)_
- Email:
- krjackson@lbl.gov