WSDL / Business Process Stuff Breakout
Outline “Service description” –WSDL next steps –WSDL issues Choreographing Web services
WSDL Relation to ebXML CPP/CPA tpaML –“interface definition” –Binding –Security / QoS –“orchestration” tpaML is in the same space as WSDL + “WSEL” + business processs stuff + agreements CPP/CPA = evolution of tpaML CPP = Collaborating Protocol Profile, CPA = Coll. Protocol Agreement
Issues Boundary from top-down and bottom-up w.r.t. service descriptions –What’s horizontal vs. vertical –“Atoms” vs “molecules” Overlap of CPP/CPA with UDDI Are service descriptions queriable? How do service descriptions relate to other W3C work items?
Service Description: Moving Forward Start with ebXML TP vs start with WSDL –ebXML TP has had a lot of work done on it –Bottom up approach is more likely to get adoption in the “Web” community –Need to identify high level approach and then look at options –Consensus on need for a service description WG
Service Description & Sequencing Service descriptions need to include information about proper usage of the service (w.r.t. sequencing) –Separate service interface descriptions from service usage
Service Descriptions Requirements What is core and what is an extension? What extensions are “standard” extensions vs private extensions? Description of a feature does not mean anything about how it will be supported by a specific service implementation
“Service Description” Scoping “Interface” definition Sequencing –Does not indicate what happens; only possible usage of a set of operations of a service Orchestration of services (both “local” and remote) –Defines a specific sequence or flow of activities
Orchestration Issues: –How do we get this to work without locking into QoS problems Need flexible business transaction models for service orchestration to work How do the various business transactions activities relate to transactional properties of business processes
Orchstration Scoping Scoping: –Static processes to dynamic processes –Who’s going to deal with transaction stuff
Compositions as new services What do services need to provide so that they can be composed? Can behavior of compositions be described in an extensible way (not special case on failures for example)