100 likes | 225 Views
Asynchronous Activities in SOAP services. Guy Rixon IVOA Interoperability Meeting Cambridge MA, May 2004. What are Async. Activities?. When a service does something between WSDL operations Client starts activity by calling an operation Operation returns when service accepts the job
E N D
Asynchronous Activities in SOAP services Guy Rixon IVOA Interoperability Meeting Cambridge MA, May 2004
What are Async. Activities? • When a service does something between WSDL operations • Client starts activity by calling an operation • Operation returns when service accepts the job • Activity not subject to HTTP timeout • When client can check progress/final status without staying connected to service • Service publishes progress metadata • Client can poll metadata or get notification message • When the activity can restart after service interruption <<title>>
Client Back again. Did I miss much? Client Start query (…) All done now OK Client Keep me posted! Client Oops, gotta close! OK 33% done 66% done Client Client Example with client restart Service <<title>>
Service Service Start query (…) OK All done 33% done. Checkpoint. Service 66% done. Checkpoint. Back again…restart jobs from checkpoints Service Oops, gotta restart! Service Service Example with service checkpointing Client <<title>>
Benefits • Flexibility • Robustness • We already have services that do this • Proven useful • Better with a standard! • Documented protocol • Code reuse • More facilities <<title>>
Proposal • Use WS-ResourceFramework (WS-RF) • It’s what WS-RF is for • Grid (GGF) compatible • Industry support promised • Many OSS implementations in progress • Lightweight standards; own implementation? • Make our own profile where WS-RF is vague • E.g. Define standard metadata for progress notification <<title>>
Factory pattern • Any operation can start an activity • WS-RF doesn’t specify messages to set up context. • No separate “factory service”. • “Resource ID” for activity returned in SOAP header. • Client quotes resource ID in subsequent messages (in SOAP header). <<title>>
WS-ResourceLifetime • Service keeps state metadata of activity + cached results (e.g. MyDB keeps DB tables) • Need to free up resource when job is done • Client controls the resource using ops spec’d in WS-ResourceLifetime: • Delete resource when done • Negotiate timeout • Resource can time out if client abandons it • Deleted by service after timeout. <<title>>
WS-ResourceProperties • Each WSDL port-type can have “resource properties” declared in WSDL • XML metadata structures, schema controlled • Client can poll these with operations spec’d in WS-ResourceProperties. • Suggest defining an IVOA-standard “state of activity” metadata-structure. • Suggest associating “state of activity” structure + polling operations with an “Activity” port-type • Drop-in implementation of this port-type? <<title>>
WS-BaseNotification • Service can send messages to client for significant events in activity • (Provided that client is also a SOAP service) • Protocol defined by WS-BaseNotification • Pushes state data (WS-ResourceProperties) to client • IVOA can define standard notifications • E.g. always notify when job complete or failed. <<title>>