OASIS Asynchronous Service Access Protocol ASAP Tutorial Overview

OASIS Asynchronous Service Access Protocol (ASAP) Tutorial Overview, OASIS ASAP TC May 4, 2004 Keith D Swenson Fujitsu Software Corporation Copyright © 2004, Keith D Swenson, All Rights Reserved.

Motivation § Entities exist in most systems which: § Take a long time to execute – longer than you want to hold a connection for – anywhere from minutes to months. § Retain state for that duration § Ultimately need to notify the client that the task has been completed § The standards for dealing with such long running processes are not consistent with the most recent web services standards § Updating those standards to make use of standardization at lower protocol levels would be a benefit to all implementations Copyright © 2004 Keith D Swenson, All Rights Reserved. 2

How Long is “Long Running”? § Anything longer than you want to wait for. § Operations that can always be completed in a few seconds or less will be called synchronously by most non-specialized systems. § Operations that might take longer, anywhere from a few minutes to a few months, need to be handled asynchronously. § An operation that is running necessarily has state. § Because the operation is asynchronous, the requester may wish to check on the state, and possibly even terminate the operation early. Copyright © 2004 Keith D Swenson, All Rights Reserved. 3

Real World § Not everyone is a programmer § Many proposals assume that systems are built uniformly and exclusively by programmers. § Instead real enterprises have a mixture of skill levels that work together to make the complete solution. § Programmers make low level “services” § People with business domain expertise compose solutions from the “services” § What is needed is a “component model” that allows easy assemble of the component services. Copyright © 2004 Keith D Swenson, All Rights Reserved. 4

Asynchronous Service Components Solution Framework Service Components “plug compatible” Copyright © 2004 Keith D Swenson, All Rights Reserved. 5

Scope of ASAP § How to represent state of a long running operation (asynchronous service) as a resource. § How to start an asynchronous service § How to monitor it; how to fetch resource values. § A set of well defined, extensible state values that can be understood by the requester. § How to control it; e. g. how to terminate the service before it is finished. § How to register to receive, and how to send, notification messages. § How to communicate exception values Copyright © 2004 Keith D Swenson, All Rights Reserved. 6

What is a Web Service? § An operation, that can be: § invoked from another location; § describe as an exchange of XML messages conforming to the SOAP structure; § described using WSDL § A standard web service is typically stateless. § Analogy: in the standard programming world is that of a “function” or “subroutine”. Copyright © 2004 Keith D Swenson, All Rights Reserved. 7

What is an Asynchronous Service Instance? § The entire service takes longer than is comfortable in one web service call, so multiple calls (operations) are allowed. § It maintains state of its current operation, and can provide XML representation to caller § Many instances of the service may exist at the same time. § Analogy: in the standard programming world is that of an “object” -- it holds state and a collection of operations. Copyright © 2004 Keith D Swenson, All Rights Reserved. 8

The service instance is logically a resource. § Service instance acts like a resource because properties can be retrieved from it. § Each service instance has an address. § From the caller’s perspective, the operations are called on directly on the instances. § The implementation, of course, will most likely share executable code (operations) among instances of a class of service, but the caller is not able to distinguish this. The implementation details are purposefully hidden from the caller, in order to allow greatest flexibility. § This encapsulation is a well known design principle that aids modularity and reuse. Explicitly separating the operations from state unnecessarily exposes internal workings of the service. Copyright © 2004 Keith D Swenson, All Rights Reserved. 9

A common question about scalability: § “If every service instance has it’s own operations, then won’t the server become overloaded once you have thousands of instances? ” § No, it only appears to have its own operations. The logical model is purposefully different from the implementation. § An object oriented programming language makes it appear that each object instance has its own operations, but actual code is shared between all instances of the same class § A web server gives a different address to every document that it serves up, but those addresses do not consume space in the web server runtime structure. § Instances are entirely virtual. Often there will be one web service handler, which uses a query parameter in the address to retrieve service state from persistent store. Copyright © 2004 Keith D Swenson, All Rights Reserved. 10

What is a Asynchronous Service Factory? § The Factory works in a way very similar to a “class” in an object oriented language. § It is itself logically a resource with properties that provide meta-information about the class of service. § It has standard web service operations that allow a service instance to be create § It provides query operations across the instances of that class of service. Copyright © 2004 Keith D Swenson, All Rights Reserved. 11

Why is Encapsulation Important? § A service instance appears as a resource. § The internal state is projected as an XML document, but this does not mean that the state is represented internally as an XML document. § The service may not expose all its internal state into the external XML projection. The service may have private data values. § If the operation is logically separated from the resource, then private values are exposed to any other operation that can access the resource. Copyright © 2004 Keith D Swenson, All Rights Reserved. 12

Addressing § Every resource has an address: § Each service instance § Each factory § The address is opaque to the requestor § The requestor should not examine or attempt to interpret the contents of the address. § The address parts are meaningful only to the service § Many implementation will compose an address from a machine address, a handler name on the machine, an instance id, etc. but there is complete flexibility on how this is composed. § The address must conform to RFC 1738 syntax rules Copyright © 2004 Keith D Swenson, All Rights Reserved. 13

Copyright © 2004 Keith D Swenson, All Rights Reserved. 14