Your SlideShare is downloading. ×
  • Like
NextGRID: Presentation on Topic
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

NextGRID: Presentation on Topic

  • 782 views
Published

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
782
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
5
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • The key aspects of the Minimal Grid Infrastructure are the following: Communication – protocols and languages through which NextGRID communicates. Behaviour – interfaces implemented by all NextGRID entities. Services – those services that are always available to users and other services. Models – underpinning models of NextGRID. The OGSA WSRF Basic Profile 1.0 provides a widely accepted set of minimal specifications that have been found to enable interoperability. The specifications considered in the OGSA Base Profile primarily address Lifecycle Management, Producer/Consumer Notification, and State access based on WSRF.
  • Presentation of SOA is Fraught Very many small pieces The interactions are not (statically) defined Encapsulation rather than layering
  • Messages can be synchronous or asynchronous. This system is loosely coupled (i.e. Services should not be dependent on each other). But not the “Object Orientated Architecture”.
  • SOAP = message format HTTP = transport protocol TCP/IP = network protocol The SOAP envelope is analogous to a business letter with an address within a distant organisation. This gives the information needed to get it from the sender’s building to the recipient’s building. The transport protocol is analogous to the carrier used for transport between buildings. (e.g. FedEx.) The web server and container act like the local services for the recipient which place the message in his/her pigeon-hole.
  • Simple Object Access Protocol? Or Service Orientated Access Protocol? “ Originally the acronym stood for Simple Object Access Protocol, but that name is now considered to be outdated, so it no longer stands for anything ” [OGSA Glossary] Before SOAP came XML-RPC. XML-RPC is a web services protocol that implements remote procedure calls over HTTP. XML-RPC a uses simple XML application to express function calls (requests) and returned values (responses) between clients and servers.
  • Web Services Addressing 1.0 - Core W3C Candidate Recommendation 17 August 2005
  • SOAP does not provide a standard way to specify where a message is going, how to return a response, or where to report an error. Those details have historically been left up to the transport layer. For example, when a standard SOAP request is sent over HTTP, the URI of the HTTP request serves as the message's destination. The message response is packaged in the HTTP response and received by the client over the HTTP connection. When a SOAP request message is sent asynchronously through JMS, a destination for responses might be specified in the JMS message headers, incorporated into the message body, or left up to the service implementation. Addressing at the transport level is sufficient for many existing services, but it has been a limiting factor in the development of others. WS-Addressing defines standard ways to route a message over multiple transports or direct a response to a third party. For example, a client application might send a request over JMS and ask to receive the response through e-mail or SMS.
  • /wsa:EndpointReference This represents some element of type wsa:EndpointReferenceType. This example uses the predefined <wsa:EndpointReference> element, but any element of type wsa:EndpointReferenceType may be used. /wsa:EndpointReference/wsa:ReferenceParameters This OPTIONAL element may contain elements from any namespace. Such elements form the [reference parameters] of the reference. /wsa:EndpointReference/wsa:Metadata This OPTIONAL element may contain elements from any namespace. Such elements form the metadata that is relevant to the interaction with the endpoint.
  • NB: “widgetReference” is of type wsa:EndpointReferenceType. It doesn’t have to be called the predefined <wsa:EndpointReference>.
  • From - If the message's receiver needs to send a message back to the endpoint that sent the message, then it should use this EPR. Note that there's also a ReplyTo header, which indicates to where the response message should go. The working group is considering removing the wsa:From element due to lack of use-cases and seeks feedback on this decision.
  • Since the reference parameter mechanism does not restrict the content of the generated headers, EPR suppliers should exercise appropriate caution to ensure their reference parameters do not cause unintended or erroneous semantics in the resultant SOAP message. For example, using a reference parameter to send a WS-Security header would be ill-advised (since other parts of the SOAP infrastructure will often control this header, and there must be at most one of them per message). Note: Integrity validation of [reference parameters] needs to take into account the addition of wsa:IsReferenceParameter attributes and the corresponding introduction of the WS-Addressing namespace to the [in-scope namespaces]
  • If shopping basket were carried forward from session, this would be persistent state. Stateless – implements message exchanges for which there is no access or use of information not contained in the input message. E.g. document compression / de-compression Out-of-band persistent state – response is affected by information that changes by some non-WS means. E.g. weather forecast service Transient State ( conversational ) – to co-ordinate a collection of related message exchanges E.g. : shopping-basket; Booking holiday - book hotel, flights and car-hire via different services with two-phase commit – confirm a reservation when all are held. Proposed standards for this – WS-TransactionFramework Persistent state ( stateful resource ) – one message exchange produces a long-lived change in state which affects other message exchanges if shopping basket were carried forward from session, this would be persistent state Combination – Booking holiday is conversational involving several persistent state services WSRF is for Persistent State, not Conversational
  • A resource has a resource properties document Gives values for those aspects of the resource’s state which can be retrieved and possibly modified by service consumer through a Web Services interface That document has a type Fixed for all instances of the resource type Defined by a Schema Each resource property is a global element within that schema The properties document as a whole is a global element with all the resource properties as children (not attributes) The actual order is immaterial
  • The declaration of the WS Resource’s properties represents a projection of or a view on the WS-Resource’s state. This projection is defined in terms of a resource properties document. This resource properties document serves to define a basis for access to the resource properties through Web service interfaces. A WS-Resource is the composition of a resource and a Web service through which the resource can be accessed. A WS-Resource is further defined as follows: • A reference to a WS-Resource is represented by an endpoint reference (EPR), or more precisely an XML element whose type is, or is derived (by extension), from the complexType named EndpointReferenceType defined by the [WS-Addressing] specification. Such EPRs MUST reference exactly one WS-Resource. • The set of properties of the resource MUST be expressed using an XML Infoset described by XML schema. The WS-Resource MUST support accessing resource properties through message exchanges defined by the WS-Resource Properties specification [WS-ResourceProperties]. • A WS-Resource MAY support the message exchanges defined by the WS-Resource Lifetime specification [WS-ResourceLifetime]. For a given WS-Resource there may be many references. The way two references are compared for equality is implementation-specific and not defined by this specification.
  • A resource identifier is Managed by the associated service(s) Unique within each associated service Service-name :: resource-id is universally unique Service-name :: resource-id can be passed around and is guaranteed to identify that resource whoever uses it Opaque No-one other than an associated service should attempt to interpret it or de-compose it – no semantics outside an associated service Can’t even compare two to see if they identify the same resource Identity of a resource is some non-opaque identifier E.g. a person’s e-mail address; an ISBN Allows resources in independent services to be X-referred Not covered by the WSRF standards Would be a property of the resource Would be namespace scoped ISBN:123-64-27694 ISBN = www.ISBNs.org
  • Red is mandated by the standard; bold is significant information Returns all elements with the specified element name Faults – ResourceUnknownFault – X7 does not exist InvalidResourcePropertyQName – tns:seat is not a property … (allowed read access is an authorisation issue, not a WSRF issue ???)
  • The receipt of the DestroyResponse message serves as a confirmation of the destruction of the WS-Resource.
  • If a WS-Resource accepts the request to set the WS-Resource’s termination time, it MUST 382 update the TerminationTime resource property of the WS-Resource to the value specified in the 383 message or to a value “in the future” relative to the requested time. If the SetTerminationTime 384 request message is accepted, the WS-Resource MUST respond with the following message: 385 <wsrf-rl:SetTerminationTimeResponse> 386 <wsrf-rl:NewTerminationTime xsi:nil=”xsd:boolean”?> 387 xsd:dateTime 388 </wsrf-rl:NewTerminationTime> 389 <wsrf-rl:CurrentTime> 390 xsd:dateTime 391 </wsrf-rl:CurrentTime> 392 <wsrf-rl:SetTerminationTimeResponse>
  • The requestor MUST NOT depend on the destruction of the WS-Resource occurring at termination time expiration but SHOULD assume that the WS-Resource is no longer accessible after termination time has expired.
  • SubscriptionManager Renew, Create, Pause, Resume
  • Doesn’t allow multiple !!! – an oversight
  • Red = required Timestamp = time at which the error occurred. /wsrf-bf:BaseFault/ErrorCode This OPTIONAL element provides convenient support for legacy fault reporting systems (e.g., POSIX errno). The dialect attribute on ErrorCode MUST be a URI that defines the context in which the ErrorCode MUST be interpreted.
  • TYPE and MESSAGETTPE are not actual components START FROM Middle – PortTYPE – the central notion – then message; then type Finally service
  • One service location for all RPC services http://www.company.org/WebServices/ws-RPC One service location for all e-mail services mailto:WS-EM@www.company.org Published WSDLs for the four service views: http://www.company.org/WSDLS/GenRPC.wsdl http://www.company.org/WSDLS/GenEM.wsdl http://www.company.org/WSDLS/CustRPC.wsdl http://www.company.org/WSDLS/CustEM.wsdl
  • In and Out relative to the service.
  • Why is transport optional? The style attribute indicates whether the operation is RPC-oriented (messages containing parameters and return values) or document-oriented (message containing document(s)). This information may be used to select an appropriate programming model. The value of this attribute also affects the way in which the Body of the SOAP message is constructed, as explained in Section 3.5 below. If the attribute is not specified, it defaults to the value specified in the soap:binding element. If the soap:binding element does not specify a style, it is assumed to be "document". RPC Hint that this is best dealt with as a procedure call (/return) Message parts are parameters which are wrapped as one component of Body As in the SOAP RPC standard Document This is a document to be processed – message parts are directly in body Wrapped convention – single message part – looks like RPC style <soap:binding ..> says SOAP structure – envelope, header body style – how message parts are mapped into the body Can: specify it for each operation, provide a default for all operations If not specified at all, default is “document” transport – a SOAP transport binding, e.g. http://schemas.xmlsoap.org/soap/http soapAction – only for SOAP HTTP binding and there mandatory – specifies the value for the SOAPAction header (at HTTP level) e.g. http://www.company.org/soapActions/PO for document style this is what says what “operation”
  • The soap:body binding element provides information on how to assemble the different message parts inside the Body element of the SOAP message. The soap:body element is used in both RPC-oriented and document-oriented messages, but the style of the enclosing operation has important effects on how the Body section is structured: If the operation style is rpc each part is a parameter or a return value and appears inside a wrapper element within the body (following Section 7.1 of the SOAP specification). The wrapper element is named identically to the operation name and its namespace is the value of the namespace attribute. Each message part (parameter) appears under the wrapper, represented by an accessor named identically to the corresponding parameter of the call. Parts are arranged in the same order as the parameters of the call. If the operation style is document there are no additional wrappers, and the message parts appear directly under the SOAP Body element. The same mechanisms are used to define the content of the Body and parameter accessor elements. Allows a lot of flexibility --> complexity. Mostly will be simple!!
  • The OGSA work on naming recognises three levels of name; human-oriented names such as paths or attributes are mapped to abstract names, which are then mapped to some form of address. In fact, nearly all abstract names are easily read and interpreted by humans, but not always very user-friendly. So perhaps a better definition of a human-oriented name is one that is short, user-friendly and easy to generate by a human (rather than by a machine, as in the case of UUIDs for example).
  • Additional Desirable Properties Persistent – the name may need to reference an object well beyond the lifetime of the object it identifies or of any naming authority involved in the assignment of its name. Compact and fast to allocate. Fast to resolve and efficient - if the scheme is too slow, it will not be used. Provide legacy support - the scheme should permit the support of existing legacy naming systems. Extensible - must permit future extensions to the scheme. Comparable - it should be possible to determine equality of two different names. Internationalisable – names should be language independent. A naming scheme that is not practical to use and does not include these desirable properties is less likely to gain widespread use, and not being widely adopted diminishes the usefulness of a naming scheme. Certain names should also be human readable and ideally self-describing, whilst others may need to be cheap to allocate.
  • It is usual to represent UUIDs with hexadecimal digits with a hyphen separating the different fields within the 16-octet UUID. Can provide a guarantee of uniqueness across space and time. IRI (Internationalized Resource Identifier) - specifications from W3C. URIs introduced a standard means of identifying resources across distributed networks that in only 15 years has become the most successful identifier scheme in history. IRIs subsequently extended the generic URI scheme, which supports only the ASCII character set, to include the full UCS (Unicode Character Set). XRIs take a third step by adding additional syntax and resolution features that enable XRIs to solve problems of abstract identification that are not easily addressed by conventional URI or IRI syntax or resolution. One of these problems—persistence—has been addressed by other URI schemes for abstract identifiers, such as the URN scheme. XRIs also go on to address a much wider range of issues in abstract identification.
  • Naming Schemes – 3 categories: 1. Ways to construct a name. 2. Specs for moving / transmitting names between services. 3. Mechanisms for storing and retrieving (resolving) names. RNS addresses the need to access resources within a grid environment by way of a universal name that ultimately resolves to a meaningful address.
  • A pure name service, such as the Handle System, can be designed solely around efficient resolution of known items without addressing functions and data structures required for discovery of unknown items based on incomplete criteria. Every handle consists of two parts: its naming authority, otherwise known as its prefix, and a unique local name under the naming authority, otherwise known as its suffix . A handle has a set of values assigned to it and may be thought of as a record that consists of a group of fields. Each handle value must have a data type specified in its <type> field, that defines the syntax and semantics of its data, and a unique <index> value that distinguishes it from the other values of the set. A set of handle data types has been pre-defined for administrative use.
  • Filenames for dialectics, experiment reports etc. <type>_<originatingWP>_<yyyymmdd>_<unique-addition-and-description> http://www.nextgrid.org/bscw/bscw.cgi/d29209/expplan_wp5_20050527_discovery-perf-1.doc Handle name: 2131.wp1/urn:nextgrid.wp1:<type>:<originatingWP>:<yyyymmdd>:<dname> 2131.wp1/urn:nextgrid:wp1:usecase:wp3:20050427:FinancialScenario

Transcript

  • 1. Minimal Infrastructure: SOA, WS-Addressing, WSRF, WSDL & Naming Stephen Davey, NeSC
      • 1st NextGRID Training Course
      • National e-Science Centre (NeSC), Edinburgh, 7 th March 2006
  • 2. Contributors & Acknowledgments
    • This presentation is based on work by
      • Richard Hopkins, “Web Services Resource Framework - WSRF.” http://www.egee.nesc.ac.uk/trgmat/events/otherNA3/05-02-23-IntroWSRF-Edinburgh-UK/talks/WSRF.ppt.
      • With additional information from
      • “ The Joy of Web Services”. http://vermont.mvc.mcc.ac.uk/JoyOfWebServices.ppt. Author: M. McKeown.
      • “ Foundation Grid Services using WSRF and OGSA base profile.” http://www.egee.nesc.ac.uk/trgmat/events/otherNA3/05-07-10-SummerSchool-Naples-Italy/talks/Tues_7_19.ppt. Author: D. Snelling.
      • “ Web Services, WSRF and GT4”. http://gks05.fzk.de/upload/lectures/Mineter_WS_WSRF_GT4_v1.pdf. Author: M. Mineter.
    • These slides have been compiled / edited by
      • Stephen Davey
  • 3. Introduction - Aim & Scope
    • These slides intend to cover the following:
    • NextGRID Minimal Infrastructure
      • Service-Oriented Architecture
      • OGSA WSRF Base Profile 1.0
      • WSDL 1.1
      • Naming
    • They are at an Introductory level, aimed at people with some knowledge in this area.
  • 4. Introduction - Contents
    • What is a Service-Oriented Architecture?
      • Web services stack.
      • SOAP.
    • OGSA WSRF Basic Profile 1.0
      • WS-Addressing
      • WS-ResourceProperties
      • WS-ResourceLifetime
      • WS-BaseNotification
      • WS-BaseFaults
    • WSDL 1.1
    • Naming
  • 5. What is a Service-Oriented Architecture?
    • Service-Oriented Architecture (SOA)
      • This term is increasingly used to refer to an architectural style of building reliable distributed systems that deliver functionality as services , with the additional emphasis on loose coupling between interacting services.
    • Service
      • A software component participating in a service-oriented architecture that provides functionality and/or participates in realizing one or more capabilities .
    • [OGSA Glossary v1.0]
  • 6. What is a Service?
    • In computing terms, a ‘service’ is simply a function that can be invoked via a well-defined remote interface.
    • [OGSI primer]
    • Systems interact with a Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.
    • [W3C – Web Services Architecture]
  • 7. Benefits of Web Services & SOA
    • Benefits
      • Allows us to hide the details of how a service is implemented; only URL and data types are required
      • It is largely irrelevant to the client whether the service is developed with Java or ASP.NET or if it is running on Windows, Linux or any other platform
    • Key Service Oriented Principles
      • Composable
      • Simple parts
      • Intended for distributed systems
      • Acknowledgement of boundaries
  • 8. SOA Triangle Service Registry Service Requestor Service Provider Find (Discover) Publish Bind (Interact) Service Description
  • 9. Web services stack Application rpcrouter SOAP HTTP TCP/IP Infrastructure (Data link) Application (servlet) Web server SOAP HTTP TCP/IP Infrastructure (Data link)
  • 10. SOAP
    • “ SOAP provides a simple lightweight mechanism for exchanging structured and typed information between peers in a decentralized, distributed environment using XML” [Microsoft]
  • 11. SOAP over HTTP HTTP Headers <soap:Envelope> <soap:Header> XML… </soap:Header> <soap:Body> XML payload… </soap:Body> </soap:Envelope> SOAP Envelope Header Body Message Pay Load
  • 12. SOAP Structure
    • Envelope – contains the entire SOAP message.
    • Header – (optional) contains header information.
    • Body – contains the application pay load.
    • Message Payload – the part of the message that is intended for the application.
  • 13. Sample SOAP
    • < SOAP-ENV:Envelope
    • xmlns:SOAP-ENV=“http://schema.xmlsoap.org/soap/envelope/”
    • xmlns:SOAP-ENC=“http://schema.xmlsoap.org/soap/encoding/”
    • SOAP-ENV:encodingStyle=“http://schema.xmlsoap.org/soap/encoding”>
    • < SOAP-ENV:Body >
    • < getHostname />
    • </ SOAP-ENV:Body >
    • </ SOAP-ENV:Envelope >
    • Invokes the “getHostname” operation on the Web service.
  • 14. OGSA WSRF Base Profile 1.0
    • Key parts mandated in the profile:
      • Addressing:
        • WS-Addressing endpoint references and places some constraints on their structure, thus enabling interoperable addressing.
      • Resource Properties:
        • resource must support certain resource properties,
        • support for certain operations that are optional in the WS-ResourceProperties specifications.
      • Resource Lifetime:
        • ImmediateResourceTermination portType, and
        • ScheduledResourceTermination portType (and their associated operations and properties).
      • Base Notification:
        • NotificationProducer portType (and its associated operations and properties to provide notification using a publish/subscribe pattern).
      • Base Faults:
        • WS-BaseFaults (and extends the fault structure).
  • 15. WS-Addressing
    • Before WS-Addressing
    • WS-Addressing specification
      • Endpoint References
        • EPRs and SOAP
      • Message Addressing Properties (headers)
        • To, From, ReplyTo, FaultTo, Action, MessageID, RelatesTo.
        • Reference parameters.
        • Anonymous & None URI s.
  • 16. Before WS-Addressing
    • To locate a web service had to ask for the URL of the endpoint or the WSDL .
    • Plus might need to identify the web services instance.
      • Could use a URL with a session identifier (e.g. appending ?resourceID=123).
      • Could add extra information in SOAP headers, but now no longer bound to one specific transport protocol.
  • 17. Endpoint References (EPRs)
    • Web service endpoint is a entity to which Web service messages can be addressed.
    • Endpoint references convey the information needed to address a Web service endpoint.
    • EPR is basically a URL wrapped by some XML elements.
    • <wsa:EndpointReference>
      • <wsa:Address> xs:anyURI </wsa:Address> (1..1)
      • <wsa:ReferenceParameters> xs:any *</wsa:ReferenceParameters> ?
      • <wsa:Metadata> xs:any *</wsa:Metadata>?
    • </wsa:EndpointReference>
  • 18. EPRs and SOAP
    • How does a Service return a reference to a new entity?
      • Does so by returning an EPR:
    • E.g. An EPR with an added ReferenceParameters element.
    • <soap:Envelope ...>
    • <soap:Body>
    • <widget:createWidgetResponse>
    • <widget:widgetReference>
    • <wsa:Address>http://host/WidgetService</wsa:Address>
    • <wsa:Reference Parameters >
    • <widget:resourceID>123</widget:resourceID>
    • </wsa:Reference Parameters >
    • </widget:widgetReference>
    • </widget:createWidgetResponse>
    • </soap:Body>
    • </soap:Envelope>
  • 19. Message Addressing Properties
    • To
    • Target Web service's URI. Typically same as the HTTP request's URL, but it is not required to be.
    • <wsa:To> http://host/WidgetService </wsa:To>
    • The To header should be the same value as the <wsa:Address> element when using an EPR.
    • From
    • EPR of the message's (source) sender.
      • Used in cases where an acknowledgement needs to be sent back to the sender (WS-ReliableMessage).
    • <wsa:From>
    • <wsa:Address> http://client/myClient </wsa:Address>
    • </wsa:From>
  • 20. Message Addressing (cont.)
    • ReplyTo
    • Any response from the Web service should be sent to the ReplyTo EPR.
      • From and ReplyTo can be two distinct EPRs, the message's sender might not be the endpoint that is meant to receive the response.
    • <wsa:ReplyTo>
    • <wsa:Address> http://client/myReceiver </wsa:Address>
    • </wsa:ReplyTo>
    • FaultTo
    • If the response to a message is a SOAP fault, the fault should be sent to the EPR in the FaultTo header.
    • <wsa:FaultTo>
    • <wsa:Address> http://client/FaultCatcher </wsa:Address>
    • </wsa:FaultTo>
  • 21. Message Addressing (cont. 2)
    • MessageID
    • The MessageID is a URI that uniquely identifies a message.
    • <wsa:MessageID>urn:uuid:12-34-56-78</wsa:MessageID>
    • Action
    • The Action header is the in-envelope version of the SOAP HTTP Action header. REQUIRED .
    • <wsa:Action> http://host/widgetOp </wsa:Action>
    • RelatesTo
    • Typically used on response messages to indicate that it is related to a previously-known message and to define that relationship.
      • <wsa:RelatesTo RelationshipType=&quot;wsa:Response&quot;>
      • urn:uuid:12-34-56-78
      • </wsa:RelatesTo>
  • 22. Constructing SOAP Messages
    • <wsa:Address> value is copied into the <wsa:To> header block.
    • Reference parameters.
      • Each element in <wsa:ReferenceParameters> (including all of that elements children, attributes and namespaces) is copied literally as header blocks in the SOAP message.
      • Each header block added as a result of the above rule is annotated with wsa:IsReferenceParameter = ‘true’.
  • 23. Anonymous & None URI s
    • http://www.w3.org/2005/08/addressing/anonymous
    • In all of the headers can use a special anonymous URI.
    • When you use this URI, you are indicating that there is no real endpoint available for this address.
    • http://www.w3.org/2005/08/addressing/none
    • Messages sent to EPRs whose address is this value MUST be discarded.
    • Typically used to designate that no reply or fault message should be sent.
  • 24. WS-Addressing
    • WS-Addressing specification –
      • requires the Address element,
      • but resourceID is specific to the WidgetService.
    • SOAP envelope of future requests to this EPR would take the form:
      • <soap:Envelope...>
      • <soap:Header>
      • <wsa:To> http://host/WidgetService </wsa:To>
      • <widget:resourceID wsa:IsReferenceParameter=true >
      • 123
      • </widget:resourceID>
      • </soap:Header>
      • <soap:Body>
      • ...
      • </soap:Body>
      • </soap:Envelope>
  • 25. Introduction - Contents
    • What is a Service-Oriented Architecture?
      • Web services stack.
      • SOAP.
    • OGSA WSRF Basic Profile 1.0
      • WS-Addressing
      • WS-ResourceProperties
      • WS-ResourceLifetime
      • WS-BaseNotification
      • WS-BaseFaults
    • WSDL 1.1
    • Naming
  • 26. Web Services Resource Framework
    • Stateful Resources
      • Web service itself (front end) is stateless.
      • Maintains state in a back-end.
      • Service request identifies the specific resource.
    • WSRF is for Persistent State (stateful resource)
      • One message exchange produces a long-lived change in state which affects other message exchanges.
  • 27. WSRF Architecture
    • A stateful (WS) resource
      • Is a repository for persistent state
        • Like an object in an object-oriented architecture.
      • Has state that comprises a set of state data
        • Each item of state data is a resource property.
        • A resource property is expressible as an XML document, which can in principle be retrieved and updated.
      • E.g. Bank Account has properties:
        • Balance owed, Credit limit, Latest statement, …
    • Differences from Object-Oriented Architecture
      • O-O object has just one interface, and is defined by the operations on it.
      • The type of a WS-resource is
        • The type of its resource properties document
        • Not the signatures of its operations
  • 28. WSRF Architecture
    • A stateful (WS) resource
      • … .
      • Has a well-defined life-cycle – creation and destruction
        • Destruction can be explicit or scheduled
      • Can be known and acted upon by one or more Web Services
        • Has a globally unique identifier –
          • http://www.company/CreditCard#Ac7
          • Can be passed between services to identify the resource
      • Is associated with one or more web services, providing interfaces for manipulating it.
      • A WS-Resource comprises: its service; the resource itself
    • http://docs.oasis-open.org/wsrf/wsrf-ws_resource-1.2-spec-cs-01.pdf
  • 29. Running Example
    • Seat Booking System for a Specific Event
    • Resource – Event6
      • Properties
        • Places – number of seats in total
        • Held – number of seats with provisional bookings
        • Booked – number of seats with confirmed bookings
      • Service
        • End-point – www.events.org/E6
        • Operations
          • Get – returns the resource properties
          • Reserve – creates a reservation resource
        • … .
  • 30. Running Example
    • Resource – Reservation (i.e. a booking)
      • Properties –
        • RNo – reservation number Identifier, not an actual property
        • Firm - number of seats with confirmed booking
        • Hold – number of seats with provisional booking
        • Seats – list of seat numbers allocated
        • Arrival – expected time of arrival
      • Service
        • End-point - www.events.org/E6res
        • Operations
          • Get – retrieve the properties
          • SetArrival – change/set the Arrival property
          • Change – reset reservation properties (firm=n; hold=m)
        • … .
  • 31. Referencing
    • Resource-qualified endpoint reference – the service address and specific resource identifier – part of WS-Addressing Standard.
    • If service has only one resource instance (1:1) don’t need to include resource identifier in address.
    www.events.org/E6 places: 120 held: 6 booked: 8 1:* reserve(3, “hold”) firm:0 hold:3 seats: K1, K2, K3 arrival: nil www.events.org/E6res create (www.events.org/E6 :: X3) Resource qualified End-point reference 1:1 Change(Firm=2, Hold=0)
    • RNo: X3
    www.events.org/E6 www.events.org/E6res :: X3
  • 32. Multiply-serviced Resource
    • Two end-point references
      • www.events.org/E6res
      • www.events.org/E6admin
    • Each providing a different interface to the same set of resource instances
    firm:0 hold:3 seats: K1, K2, K3 arrival: nil www.events.org/E6res Change(Firm=2, Hold=0)
    • RNo: X3
    www.events.org/E6res :: X3 www.events.org/E6admin clearHolds(1) www.events.org/E6admin :: X3 - Get - SetArrival - Change - ClearHolds - ChangeSeats - Get
  • 33. Operations on Resource Properties
    • WS-ResourceProperties
    • http://docs.oasis-open.org/wsrf/wsrf-ws_resource_properties-1.2-spec-pr-01.pdf
    • GetResourcePropertyDocument - retrieve the values of all resource properties of the WS-Resource.
    • GetResourceProperty – get single property. Mandatory.
    • GetMultipleResourceProperties – get multiple properties.
    • QueryResourceProperties - query resource properties document using a query expression such as XPath.
    • PutResourcePropertyDocument – replace all properties.
    • SetResourceProperties - modify the values of multiple resource properties – Insert, Update, Delete .
    • InsertResourceProperties - insert new values of a single resource property.
    • UpdateResourceProperties - replace the existing values of a single resource property.
    • DeleteResourceProperties - removal of all values of a single resource property.
  • 34. GetResourceProperty
    • Returns all elements with the specified element name
    <env:envelope ….namespace definitions ..> <env:Header> <wsa:Action> http://...wsrf.../ GetResourceProperty </> <wsa:To env:mustUnderstand=“1”> www.events.org/E6res </> <m:ResId> X7 </> </> <env:Body> < wsrp:GetResourceProperty> tns:seat </> </></> <env:envelope ….namespace definitions ..> <env:Header> <wsa:Action> http://...wsrf.../ GetResourcePropertyResponse </> <wsa:To env:mustUnderstand=“1”> www. … requestor … </> <m:ResId> X7 </> </> <env:Body> <wsrpl:GetResourcePropertyResponse> <seat> K1 </> <seat> K2 </> <seat> K3 </> </></>
  • 35. Get Multiple Resource Properties
    • Must specify at least one
    • Order in response should follow order in request
    <env:envelope ….namespace definitions ..> <env:Header> <wsa:Action> http://...wsrf.../ GetMultipleResourceProperties </> <wsa:To env:mustUnderstand=“1”> www.events.org/E6res </> <m:ResId> X7 </> </> <env:Body> < wsrp:GetMultipleResourceProperties> <wsrp:ResourceProperty> tns:firm </> <wsrp:ResourceProperty> tns:seat </> </></> <env:envelope ….namespace definitions ..> <env:Header> <wsa:Action> http://...wsrf.../ GetResourcePropertyResponse </> <wsa:To env:mustUnderstand=“1”> www. … requestor … </> <m:ResId> X7 </> </> <env:Body> <wsrpl:GetResourcePropertyResponse> <firm> 3 </> <seat> K1 </> <seat> K2 </> <seat> K3 </> </></>
  • 36. SetResourceProperties
    • A number of SetRequestComponents, each – insert, update, delete
    • Must be done in given order – could have several for same element name
    • If failure on one:
      • Must not do any subsequent ones
      • Final result may reflect the partial processing
      • Final result may be the original
    <env:envelope ….namespace definitions ..> <env:Header> <wsa:Action> http://...wsrf.../ SetResourceProperties </> <wsa:To env:mustUnderstand=“1”> www.events.org/E6res .</> <m:ResId> X7 </> </> <env:Body> < wsrp:SetResourceProperties> <wsrp: Update ><tns: hold > 0 </> <tns :firm > 4 </></> <wsrp: Delete resourceProperty=“tns: arrival ”> <wsrp: Insert > ><tns: seat > J9 </> </></></> <env:envelope> ….<env:Body> <wsrpl:GetResourcePropertyResponse></> </></>
  • 37. SetResourceProperties
    • Faults
      • ResourceUnknownFault
      • InvalidResourcePropertiesRequestContent
        • The result would be a properties document which is invalid, e.g. too many seats if maxoccurrs=3
      • UnableToModifyResourceProperty – a read-only resource
      • InvalidResourcePropertyQName
      • SetResourcePropertyRequestFailed – one or more components failed
      • … to be defined
      • Fault message must indicate whether effects of processing non-failed components were restored
    firm:0 hold:3 seats: K1, K2, K3 arrival: 15:00:00
    • RNo: X3
    firm:4 hold:0 seats: K1, K2, K3, J9 RNo: X3 <wsrp: Update ><tns: hold > 0 </> <tns :firm > 4 </></> <wsrp: Delete resourceProperty=“tns: arrival ”> <wsrp: Insert > ><tns: seat > J9 </> </></></>
  • 38. Introduction - Contents
    • What is a Service-Oriented Architecture?
      • Web services stack.
      • SOAP.
    • OGSA WSRF Basic Profile 1.0
      • WS-Addressing
      • WS-ResourceProperties
      • WS-ResourceLifetime
      • WS-BaseNotification
      • WS-BaseFaults
    • WSDL 1.1
    • Naming
  • 39. WS-ResourceLifetime
    • Lifetime of a WS-Resource is defined as the period between its instantiation and its destruction.
    • Specification defines standard by which:
      • WS-Resource can be destroyed.
      • Lifetime can be monitored.
    • Specification does not prescribe the means by which a WS-Resource is created.
  • 40. Immediate Destruction
    • Destroy
      • <s11:Envelope . . .>
      • <s11:Header>
      • . . .
      • <wsa:Action>
      • http://docs.oasis-open.org/wsrf/rlw-1/ImmediateResourceTermination/DestroyRequest
      • </wsa:Action>
      • . . .
      • </s11:Header>
      • <s11:Body>
      • <wsrf-rl:Destroy/>
      • </s11:Body>
      • </s11:Envelope>
  • 41. Scheduled Destruction
    • SetTerminationTime
      • RequestedTerminationTime
      • RequestedLifetimeDuration
    • Querying Current Time
      • Clock synchronization between the service requestor and the service provider.
      • Resource properties:
        • <wsrf-rl:CurrentTime>
        • <wsrf-rl:TerminationTime>
  • 42. Termination Time Expiration
    • If service requestor fails to successfully update the termination time of a WS-Resource before the termination time expires, the WS-Resource MAY be destroyed and therefore no longer be accessible.
    • An implementation MAY delay destruction of the WS-Resource at its own discretion.
  • 43. Resource Destruction
    • Immediate Destruction
      • Send a destroy message to the resource-qualified endpoint
      • Thereafter any attempt to access it must result in a Unknown Resource fault message – this is a synchronisation point – the reply to the destroy
      • The consumer could decide to destroy the reservation resource – cancelling the reservation
    • Scheduled Destruction
      • Can request a modification in the termination time
        • Extend the provisional booking for another 2 days
        • If termination time is in the past this may be interpreted as an immediate asynchronous destroy
    • A resourced service should have a destruction policy which does not depend on action by the consumer service
      • Consumer may disappear at any time
      • Consumer may be impolite
    • Risk of having the physical resources never recovered, and performance consequences of large number of useless resource instances.
  • 44. Introduction - Contents
    • What is a Service-Oriented Architecture?
      • Web services stack.
      • SOAP.
    • OGSA WSRF Basic Profile 1.0
      • WS-Addressing
      • WS-ResourceProperties
      • WS-ResourceLifetime
      • WS-BaseNotification
      • WS-BaseFaults
    • WSDL 1.1
    • Naming
  • 45. WS-Notification
    • WS – BaseNotification
    • WS – Topics
    • WS – BrokeredNotification
  • 46. Notification
    • WS-Notification is draft standards dealing with the
      • The Notification-based Interaction pattern – Event Driven
    • Model - Subscribing to a Notification service on some topics
      • E.g. My boss ( Subscriber ) informs a press-cutting service ( Publisher ) that it is to notify me ( Consumer ) of articles on WebServices ( Topic ) appearing in the popular press ( Producer )
      • Topic Space - a forest of topic Trees
      • Publisher – distributes notification messages according to subscriptions
      • Producer – generates notification messages for Consumers
      • Can combine Producer and publisher - same service generates the event and sends it to the subscribers; otherwise Publisher is a Broker
      • Can separate them – producer generates the notification and sends it to a broker who distributes it according to subscriptions
      • Subscriber creates a subscription for a consumer in a Publisher
      • Consumer receives notification messages (may combine with subscriber)
    webServices WSRF WSDL travel USA EU
  • 47. Notification and WSRF
    • NotificationProducer Interface
      • Notify
      • Subscribe
      • GetCurrentMessage
    • PullPoint Interface
    • SubscriptionManager Interface
    • Relation to WSRF
      • A subscription is a resource
      • A resourced service can be producer/publisher:
        • To notify consumers of changes in state of the resource
          • Value change
          • Destruction
  • 48. Destruction Notification Pattern
    • WS-Notification standard deals with this
    • Subscribe to the resource
    • Resource notifies subscriber
    www.events.org/E6 places: 120 held: 6 booked: 8 reserve(3, firm) firm:3 hold:0 … www.events.org/E6res Subscribe(topic=ResourceTermination)
    • RNo: X3
    www.events.org/E6res :: X3 (www.events.org/E6 :: X3) EventCancelled www.events.org/E6res : X3 Notify(“Event Cancelled”, dateTime)
  • 49. Destruction Notification
    • If Resource chooses to support the pattern of notifying interested parties when it is destroyed
    • And to use the WS-Notification standard,
    • Then must follow this standard
    • The TopicSpace = “ResourceLifetime”
    • The Topic name=“ResourceTermination”
    • The notification message must include the following element
    <wsrl:TerminationNotificaton> <wsrl:TerminationTime> xsd:dateTime </> <wsrl:TerminationReason> xsd:any </> ? </>
  • 50. Value Change Notification
    • Can similarly subscribe to being notified of value changes for the resource.
    • If the resource supports the property value-change notification pattern, and it uses WS-Notification then it must follow these standards
      • Subscription can be a sub-set of the resource properties
        • E.g. wanting notification of changes in seat numbers
      • The notification message must contain an element of the form
    <wsrp:ResourcePropertyValueChangeNotification> <wsrp:OldValue> <seat> K1 </> <seat> K2 </> <seat> K3 </></> <wsrp:NewValue> <seat> K1 </> <seat> K2 </> <seat> J4 </></></>
    • One such notification for every value change
    • OldValue – if nil, there was no value; if absent the old value was not recorded
    • NewValue – can be nil
    • !!!Standard does not actually allow multiple components!!!
  • 51. Introduction - Contents
    • What is a Service-Oriented Architecture?
      • Web services stack.
      • SOAP.
    • OGSA WSRF Basic Profile 1.0
      • WS-Addressing
      • WS-ResourceProperties
      • WS-ResourceLifetime
      • WS-BaseNotification
      • WS-BaseFaults
    • WSDL 1.1
    • Naming
  • 52. WS-BaseFaults
    • Difficult when interfaces use different conventions for representing common information in fault messages.
    • So specify Web Service fault messages in a common way.
    • WS-BaseFaults defines an XML Schema type for a base fault, along with rules for how this fault type is used by Web Services.
  • 53. Base Fault Type
    • Base fault has the following syntax:
    • <BaseFault>
    • <Timestamp>xsd:dateTime</Timestamp>
    • <OriginatorReference>
    • wsa:EndpointReferenceType
    • </OriginatorReference> ?
    • <ErrorCode dialect=&quot;anyURI&quot;>
    • xsd:anyType
    • </ErrorCode> ?
    • <Description> xsd:string </Description> *
    • <FaultCause>{any}</FaultCause> ?
    • {any}*
    • </BaseFault>
  • 54. Introduction - Contents
    • What is a Service-Oriented Architecture?
      • Web services stack.
      • SOAP.
    • OGSA WSRF Basic Profile 1.0
      • WS-Addressing
      • WS-ResourceProperties
      • WS-ResourceLifetime
      • WS-BaseNotification
      • WS-BaseFaults
    • WSDL 1.1
    • Naming
  • 55. What is WSDL?
    • In XML format
    • For describing network services
      • Which operate either on
        • Documents
        • Procedure calls
      • Describes the exposed interface – i.e. What the consumer sees of the service
      • Constitutes a contract with the client
        • Provides a specification of what is offered by the service provider which can be relied on by the service consumer.
  • 56. What is WSDL?
    • Supports separation of concerns
        • logical structure of messages
        • binding to a specific underlying protocol
        • definition of a particular deployed service
      • To allow common definition and re-combination
    • Does not describe what the service does, how it does it or how you should use the service – i.e. does not provide semantic information about the service.
    • Here using WSDL 1.1 – a W3C submission (March 2001).
    • WSDL 2.0 – is a W3C Candidate Recommendation (6 January 2006) – many differences.
  • 57. Structure <import> incorporate external definitions * <types> logic structure of data being transmitted ? <message> transmittable messages * <portType> interface – operations and assoc. messages * <binding> how messages will be transmitted * <service> how a service is accessed * <schema> * <part> * <port> web-address ref * <operation> * <MESSAGETYPE> * <TYPE> * Abstract Physical
  • 58. Contents of a WSDL document
    • Types – a container for data type definitions using some type system (such as XSD).
    • Message – an abstract, typed definition of the data being communicated.
    • Operation – an abstract description of an action supported by the service.
    • Port Type –an abstract set of operations supported by one or more endpoints.
    • Binding – a concrete protocol and data format specification for a particular port type.
    • Port – a single endpoint defined as a combination of a binding and a network address.
    • Service – a collection of related endpoints.
  • 59. Services Structure Example
    • Company Provides two types of service (PortTypes)
      • General Service
        • Get general information
        • Open an account
      • Customers Service (being a “Customer” = having an account)
        • Purchase Order
        • Invoice
        • Payment Advice
        • Get Statement
    • Both over two kinds of binding
      • RPC
      • Email
  • 60. Services Structure Example Binding : Service : Location= www. …/WS-RPC www…/GenRPC www…/CustRPC www…/GenEM www…/CustEM Binding : Service : Location= www. …/WS-RPC Binding : Service : Location= www. …/WS-EM Binding : Service : Location= www. …/WS-EM PortType :General Op : GenInfo Op: OpenAcc PortType :Customer Op : PurchOrder Op: Inv Op: PayAdv Op: GetStmt Op : Overdue Message: Mess1 … . Schema … .
  • 61. Services Structure Example Binding : Service : Location= www. …/WS-RPC www…/GenRPC www…/CustRPC www…/GenEM www…/GenEM Binding : Service : Location= www. …/WS-RPC Binding : Service : Location= www. …/WS-RPC Binding : Service : Location= www. …/WS-RPC PortType :General Op : GenInfo  Op: OpenAcc  PortType :Customer Op : PurchOrder  Op: Inv  Op: PayAdv  Op: GetStmt  Op : Overdue  Message: Mess1 … . Schema … . Four message patterns  IN One-way  OUT Notify *  IN then OUT Request/Response  OUT then IN Solicit/Response * * Reversed roles Provider proactive = client Consumer reactive = server
  • 62. Request - Response
    • Most Common Pattern
      • Message to service provider; reply to service consumer
    • A logical pattern, Binding might be either
      • An HTTP request/response
      • Two HTTP requests
    <wsdl:message name=POinM> <part name=accInfo type=m:accInfoT> <part name=order element=m:accInfoT> </> <wsdl:portType name=CustomerPort> <wsdl:operation name=PurchOrder> <wsdl:input name=PurchOrderRequest message=POinM> <wsdl:output name=PurchOrderResponse message=DeliveryScheduleM> <wsdl:fault name=PurchOrderDuffAccFM message=DuffAccFM> … .. </> <wsdl:operation …> </> …</> Default message name – operation + request/response
  • 63. Solicit - Response
    • Backwards two-way Pattern
      • Message from service provider to consumer; reply from consumer to provider
    • Example – “overdue payment”
      • Company sends this notification to the customer and expects a response
    <wsdl:portType name=CustomerPort> … <wsdl:operation name=Overdue> <wsdl:output name=OverdueSolicit message=OverdueOutM> <wsdl:input name=OverdueResponse message=ExcuseInM> <wsdl:fault name=OverdueThreatOutFM message=ThreatOutFM> … .. </> <wsdl:operation …> </> …</> Default message name – operation + solicit/response Opposite order!
  • 64. Single Message
    • Notify
      • Message from service provider to consumer, with no reply
      • Example – “Invoice”
        • Send an invoice
    • One-way -- Request with no reply
      • Message from service consumer to provider
      • Example – “payment advice”
        • Company gets notification from customer that a payment has been made
    <wsdl:portType name=CustomerPort> … .. <wsdl:operation name=Inv> <wsdl:output name=Inv message=InvoiceOutM> </> <wsdl:operation name=PayAdv> <wsdl:input name=PayAdv message=PaymentAdviceInM> </> </> Default message name – operation Can’t have fault message
  • 65. Binding - General
    • A Binding defines
      • For a particular PortType – named as its “type”
      • Particular message format and communication protocol details
        • By extensibility point
        • A standard extension is SOAP binding
    • Can have multiple bindings for one PortType
      • Different modes in which it can be accessed
    Binding : Service : Location= www…/GenRPC www…/CustRPC www…/GenEM www…/GenEM Binding : Service : Location= Binding : Service : Location= Binding : Service : Location= PortType :General Op : GenInfo  … . PortType :Customer Op : PurchOrder  … . Message: Mess Schema
  • 66. Binding Extensions
    • There are a number of defined bindings
      • SOAP – identify the SOAP standards
        • Transport
          • Over HTTP
          • … .
        • Style
          • RPC
          • Document
        • Use
          • Literal
          • Encoded
      • HTTP
      • MIME
    • SOAP over HTTP, Literal is most commonly used
      • all we will deal with here
  • 67. RPC vs Document < wsdl:message name=POinM> <part name=accInfo type=…> <part name=order element=…> </> <wsdl:operation name= PurchOrder > <wsdl:input name= PurchOrderRequest message=POinM> <wsdl:output name= PurchOrderResponse message=POoutM> ….. </> < wsdl:message name=POoutM> <part name=Result type=…> <part name=delivSched type=…> </> <env:Body> <m:PurchOrderRequest> <accInfo> … </> <order> … </></></> <env:Body> <accInfo> … </> <order> … </></></> <env:Body> <m:PurchOrderResponse> <Result> … </> <delivSched> … </></></> <env:Body> <Result> … </> <delivSched> … </></></> RPC Actual messages Document Actual messages
  • 68. Introduction - Contents
    • What is a Service-Oriented Architecture?
      • Web services stack.
      • SOAP.
    • OGSA WSRF Basic Profile 1.0
      • WS-Addressing
      • WS-ResourceProperties
      • WS-ResourceLifetime
      • WS-BaseNotification
      • WS-BaseFaults
    • WSDL 1.1
    • Naming
  • 69. Naming
    • Naming definitions
    • Requirements on names
    • Existing naming schemes
    • Overview of the Handle syntax
    • NextGRID Experiment in WP1
    • Summary
  • 70. Naming definitions
    • “ Name” - attribute used to identify an entity. In OGSA-naming, 3 types: human-oriented names, abstract names, and addresses.
    • “ Human-oriented name” - a naming scheme designed to be easily interpreted by humans (e.g. human-readable and human-parsable).
    • “ Abstract name” - persistent name suitable for machine processing that does not necessarily contain location information. Abstract names are bound to addresses.
    • “ Address” - specifies the location of an entity.
    • Additionally,
    • “ Resolution” – Name resolution is the mapping of human names to abstract names, which are then mapped to some form of address.
      • E.g. A name resolution function could be: Address Resolve(AbstractName);
  • 71. Requirements on names
    • Names and naming schemes need to:
    • Be transmitted and resolved in a new context.
    • Name all entities in the universe of discourse that need naming.
    • Allow autonomous allocation of names - it is solely the responsibility of a name issuing authority to determine conditions under which it will issue a name.
    • Allow scalable distributed name resolution.
    • Be secure and reliable – there must be no spoofing of the naming service and no impersonating of names. It must support digital signatures, encryption and non-repudiation.
    • Be robust and trusted - data confidentiality and privacy need to be included.
    • Have global scope - it needs to have the same meaning everywhere, extensible & internationalisable.
    • Globally unique – the same name will never (to best probability affordable) be assigned to two different objects.
  • 72. Existing naming schemes
    • Uniform Resource Identifier (URI) - a string used for identifying an abstract or physical resource in a web application.
    • Uniform Resource Locator (URL) - the address of an Internet resource named as a combination of a DNS name and local name.
    • Uniform Resource Name (URN) - a subset of URI that defines a namespace registration mechanism for persistent namespaces under URI. E.g. urn:nextgrid:wp1:usecase:wp3:20050427:FinancialScenario
    • Universally-unique identifier (UUID) / Globally Unique Identifier (GUID) - 128 bits long, and can provide a guarantee of uniqueness. E.g. f81d4fae-7dec-11d0-a765-00a0c91e6bf6 .
    • Life Science Identifiers (LSIDs) - persistent, location-independent, resource identifiers for uniquely naming biologically significant resources. E.g. URN:LSID:rcsb.org:PDB:1D4X:22 .
    • Extensible Resource Identifier (XRI) - built directly on top of URI & IRI specifications. Examples:
      • xri://@example.org*agency*department/!(urn:ISBN:0-395-36341-1)
      • xri://@!9990!A58F!1C3D/!(urn:ISBN:0-395-36341-1)
  • 73. Existing naming schemes
    • Endpoint reference (EPR) – a WS-Addressing construct that identifies a message destination. In WSRF an EPR conveys the information needed to identify or reference a stateful resource.
    • WS-Naming – a profile on top of the WS-Addressing specification, where additional elements AbstractName and ReferenceResolver are included in the MetaData element of a WS-Addressing Endpoint Reference.
    • Resource Namespace Service (RNS) - RNS primarily addresses the human-readable level rather than the abstract level. Intended to facilitate namespace services for a wide variety of Grid applications.
    • Domain Name Service (DNS) – primarily designed for mapping domain names into IP Addresses for network routing purposes.
    • X.500 / LDAP - X.500 defines a hierarchical data and information model with a set of protocols to allow global name lookup and search. LDAP (Lightweight Directory Access Protocol) is a simpler protocol aimed at being easier to implement.
    • Handle.net - a general-purpose global name service that allows secured name resolution and administration over networks such as the Internet. It manages handles, which are unique names for digital objects and other Internet resources.
  • 74. Overview of the Handle syntax
    • Handle System architecture defines a hierarchical service model.
      • Single top level service, known as the Global Handle Registry (GHR).
      • Lower levels known as Local Handle Services (LHS).
    • Syntax:
    • <Handle> ::= <Handle Naming Authority> &quot;/&quot; <Handle Local Name>
    • Handle.net meets all of the requirements for allowing scalable distributed name resolution, autonomous allocation of names, be secure, extensible, and guarantee global uniqueness.
    • Server and client software is available through its website, http://www.handle.net/download.html.
    • Handle Proxy Sever is http://hdl.handle.net/
  • 75. NextGRID Experiment in WP1
    • NextGRID project Naming Authority Handle:
      • 0.NA/2131
    • Also have sub-prefixes for workpackages.
      • 0.NA/2131/WP1
    NextGRID BSCW Server Other NextGRID Server Other NextGRID Service Naming webpage Handle System Proxy Server http://hdl.handle.net/ webpage Resolve name. (Read-only) Create, delete, modify & list names. Create, delete, modify & list names. Interfaces ?? Security model ?? Client PC Handle Admin Tool dev.nextgrid.org (EPCC Server) Handle Names DB Handle Server Software NextGRID Naming Service
  • 76. The End
    • What is a Service-Oriented Architecture?
      • Web services stack.
      • SOAP.
    • OGSA WSRF Basic Profile 1.0
      • WS-Addressing
      • WS-ResourceProperties
      • WS-ResourceLifetime
      • WS-BaseNotification
      • WS-BaseFaults
    • WSDL 1.1
    • Naming
    Questions?