BEA position on W3C ‘Web Services’ Standards Jags Ramnarayan 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