Transcript •••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• BEA position on W3C ‘Web Services’ Standards Jags Ramnarayan [email protected] 11th April 2001 Overview •••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• • Process considerations • Broad “Web services” W3C focus recommendations. • Identify key technical requirements for.

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••
BEA position on W3C
‘Web Services’ Standards
Jags Ramnarayan
[email protected]
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