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

2. Copyright © 2004 Keith D Swenson, All Rights Reserved. 2 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

3. Copyright © 2004 Keith D Swenson, All Rights Reserved. 3 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.

4. Copyright © 2004 Keith D Swenson, All Rights Reserved. 4 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.

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

6. Copyright © 2004 Keith D Swenson, All Rights Reserved. 6 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

7. Copyright © 2004 Keith D Swenson, All Rights Reserved. 7 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”.

8. Copyright © 2004 Keith D Swenson, All Rights Reserved. 8 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.

9. Copyright © 2004 Keith D Swenson, All Rights Reserved. 9 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.

10. Copyright © 2004 Keith D Swenson, All Rights Reserved. 10 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.

11. Copyright © 2004 Keith D Swenson, All Rights Reserved. 11 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.

12. Copyright © 2004 Keith D Swenson, All Rights Reserved. 12 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.

13. Copyright © 2004 Keith D Swenson, All Rights Reserved. 13 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

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