120 likes | 144 Views
BEA position on W3C ‘Web Services’ Standards. Jags Ramnarayan jagsr@bea.com 11th April 2001. Overview. Process considerations Broad “Web services” W3C focus recommendations. Identify key technical requirements for standards Categorize areas w.r.t importance Summary.
E N D
BEA position on W3C ‘Web Services’ Standards Jags Ramnarayan jagsr@bea.com 11th April 2001
Overview • Process considerations • Broad “Web services” W3C focus recommendations. • Identify key technical requirements for standards • Categorize areas w.r.t importance • Summary
Process considerations • Standards process should continue in a accelerated manner • Take into account ‘Technology life’ • Should be based on industry adoption rate • e.g SOAP is already in use or planned to be in several products • Imperfect technology sooner better than perfect technology later • Consider ( with proper precaution) • Majority votes over consensus • Appropriate target dates based on Industry requirements
Laying the Foundation • Clearly define “web services” • Definition and scope for W3C • Stay low level • Provide basic “web services enabling” standards • Refrain from standards on business protocols • Continue managing scope of individual specifications • Do layered architecture of standards • Consider a specification that describes “Core” web services • e.g. Architecture specification
Simple Web Services • Standards: SOAP 1.1 w/Attachments, WSDL, HTTP • Security: Authentication, trust, authorization • Simple services use cases: • Invoking service through a synchronous call • “RPC” style semantics; Request/Response thru single channel • SOAP 1.1 protocol sufficient ? • Invoking service asynchronously • semantics provided by messaging services; • Loosely coupled, across business boundaries, • Interoperability issues to be addressed • SOAP encodings, transport issues
Complex Web Services • Collaboration and workflow • e.g. ebXML business process and collaboration protocol • Long duration transactions • Business Transaction Protocol - a submission to OASIS • Support for advanced QoS functions • Priority, auditing, etc • Smart Services • Protocol extensions to support Context info.
Messaging requirements • SOAP 1.1 is not sufficient • Some basic needs ( Based on ebXML ; XMLP requirements spec doesn’t seem to cover these? ): • Reliable message delivery options • “Once And Only Once” • “Best Effort” • Identifying messages • Message ID; • Message type: Normal, Acknowledgement, Exception • Message envelope versioning • Message routing information • Sender URI, Receiver URI, Error URI, Creation timestamp • Sequencing of messages • Sequence number
Messaging requirements • Basic QoS requirements • Guaranteed delivery/response, Max. time to respond • Acknowledgement, retry count • What about Business conversation info., TPA Info., From/To ( Business identification) ? • These B2B protocol requirements are complex • Packaging should include arbitrary data(images) • MIME MultiPart content type (SOAP 1.1 w/ Attachments) • SOAP spec. should address SMTP binding
Securing Web services • Need support for authentication, establishing trust, “on-the-wire” data protection and authorization • Authentication • Basic/digest HTTP authentication is not sufficient • Enterprise class security requirements should be addressed • Several standards exist: • SOAP security extensions, XML-SIG, XKMS, S2ML, SAML • Unclear how these specifications relate (Some overlap) • Consider a security architecture specification for web services • Important to support third party authentication services • PKI and digital certificate management is not cheap • Need support for single sign-on in B2B scenarios • XML Encryption, a anticipated W3C standard; Why ?
Support for transactions • Long running transactions for web services • Loosely coupled; XML protocol extensions desired • Transactions span businesses • Transactions may involve human involvement • Notion of compensating transactions • Higher level functions build on this • Business level conversations && Choreography of business transactions ?
Service definition and discovery • Need to standardize Service definition language • Currently BEA supports and has adopted WSDL 1.0 • There is still need for semantic description • ( Probably in a layered specification ) • Standards for registering services is important • Service discovery standard: UDDI ? • It appears that UDDI would expand beyond service discovery • e.g. ability to locate products, manage hierarchical business organizations, trade groups, etc. • Focus should remain enabling service discovery
Summary • Core standards • Establish a security architecture • SOAP with Digital signature, XML encryption and authentication techniques • Address interoperability concerns • SOAP implementations today do not interoperate • Standardize service definition • The next higher layer • Messaging standards for : • Reliable messaging, routing, sequencing, QoS, etc • Support long running transactions • Focus on what W3C is known for: Core standards