1 / 12

BEA position on W3C ‘Web Services’ Standards

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.

Download Presentation

BEA position on W3C ‘Web Services’ Standards

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. BEA position on W3C ‘Web Services’ Standards Jags Ramnarayan jagsr@bea.com 11th April 2001

  2. Overview • Process considerations • Broad “Web services” W3C focus recommendations. • Identify key technical requirements for standards • Categorize areas w.r.t importance • Summary

  3. 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

  4. 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

  5. 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

  6. 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.

  7. 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

  8. 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

  9. 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 ?

  10. 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 ?

  11. 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

  12. 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

More Related