Published on November 15, 2007
Time Well Spent:Web Services Standards Mature More: Time Well Spent: Web Services Standards Mature More Charles Abrams Daryl Plummer Web Service Standards: Building TowardMission-Critical Implementations: Used for first-generation integration projects and composite application development High-value scenarios limited by volume and code complexity Usage for collaborative commerce minimal Predominantly SOAP-based WSDL and UDDI are only beginning to make inroads Security limited to existing technologies: Kerberos, PKI, SSL Competency is only beginning to emerge at enterprises Emerge as core architectural building blocks for SOAs, SOBAs and other applications Standards development expands high-value scenarios exponentially Widespread usage across supply chains and value networks Other standards for business processes, events, security, transactions and management WS-Security and SAML expand secure deployment frameworks Competency becomes a core competency for enterprise survival Usage in 2004: First-Generation and Embryonic Usage in 2009: Mission-Critical Core Competencies Web Service Standards: Building Toward Mission-Critical Implementations Client Issues: Client Issues 1. How will standards affect the development of Web services through 2009? 2. Which dynamics will affect the development of Web services standards through 2009? 3. What is the state of development of key Web services standards and specifications, and which roles will they play? Web Services Standards and SpecificationsAre at the Core of SOAs and SOBAs : Web Services Standards and Specifications Are at the Core of SOAs and SOBAs Incorporation Prevalent in SOA and SOBA Increasing Complexity Complex Business Process Utility WSDL: Formal interface description reduces integration effort UDDI: Web services directory can source SOBA components WS-RM: Collab. commerce needs reliable messaging WS-Security/transactions: for mix of uses BPEL: Orchestrating business processes Future: Web services management Future: Addressing SOAP: Core messaging, unification of XML data, SOBA must have this Future: Events Standards/Specifications Usage in Global 2000 New Development and Deployment: 0 20 40 60 80 100 YE04 YE07 YE10 Percent SOAP WSDL WS-Security BPEL WS-R/RM UDDI WS-TX WS- Addressing Standards/Specifications Usage in Global 2000 New Development and Deployment SODA in 2004: Incomplete Standards Dictate Approach: Expedient Enablement Start with a large pile of application code Expose selected methods as WS via megavendor’s monolithic IDE Wait to get bitten by faulty assumptions about a nondistributed architecture Low Road Eschew transparency Stick to fully-baked basics: SOAP, WSDL, UDDI Expose high-value mass of code and/or data via narrow, loosely coupled interface High Road Aggressively track new WS specifications, including BPEL, WS-Security and WS-RM Design to most recent version Test all implementations Rework details when specification is final In All Cases Plan for payback within, at most, two years SODA in 2004: Incomplete Standards Dictate Approach 2007: Standards Power B2B Commerce: 2007: Standards Power B2B Commerce 2000 2010 2007 Development and testing remaining on core Web services standards stack: SOAP, WSDL, UDDI, BPEL. WS-Events, others Growth of semantic B2B standards ebXML vertical initiatives, UBL, OWL, RDF, UCC/Rosettanet, Accord, others 2007 Sweet Spot The semantic Web emphasizes XML and machine-readable content Boom in B2B Trading Efficiencies Why Is It Taking so Long?Case Study: Rolling Out WSRP: 2002 2003 2004 2005 2006 Vendors Ship WSRP committee works on Version 1 WSRP committee works on Version 2 Vendors implement in the lab Vendors ship first version Users deploy pilots internally Users deploy pilots externally Service providers start to emerge Service providers proliferate Vendors ship service packs Vendors ship Version 2 support Why Is It Taking so Long? Case Study: Rolling Out WSRP It’s Not a Stack, It’s a Web of Dependencies: It’s Not a Stack, It’s a Web of Dependencies WS-Coordination WS-Transaction WS-Addressing WSDL 1.1 WS-SecureConversation Xpath 1.0 XML Schema 1.0 XML 1.0 XML Infoset XML Namespaces XML Encryption X.509 WS-Trust WS-Policy WS-Routing A Partial View BPEL 1.1 WS-ReliableMessaging WS-Security XML Signature SOAP 1.2 WS-PolicyAssertions WS-SecurityAddendum WS-SecurityPolicy WS-PolicyAttachments Organizations Drive Standards Development: http://oasis-open.org Founded: 1993 Support: 5/5 Rating: Strong Positive UDDI, BPEL, WS-Reliability WSRP, WS-Security, SAML, WSDM other WS*, ebXML, UBL http://w3c.org Founded: 1994 Support: 5/5 Rating: Strong Positive XML, SOAP, WSDL WS-Addressing, OWL, RDF Major Sponsors: BEA, Computer Associates, Fujitsu, HP,IBM, Intel, Microsoft, Novell, Nokia, Oracle, SAP, SeeBeyond, Sun, Tibco, WebMethods Organizations Drive Standards Development WS-I: Ensuring Standards Interoperability: Basic Profile Basic Profile 1.0 and 1.1 More than 200 interoperability issues resolved in Basic Profile Conventions around messaging, description and discovery Simple SOAP Binding Profile 1.0 Sample Applications and Testing Tools Attachments Profile 1.0 Basic Security Profile Security Scenarios Document security risks in interoperable Web services, along with potential countermeasures Basic Security Profile 1.0 (Working Group Draft) Source: Web Services Interoperability Organization Delivered through September 2004 www.ws-i.org Founded: 2002 Rating: Positive WS-I: Ensuring Standards Interoperability The State of the Core Standards : SOAP Introduced: 1999 Current Version: 1.2 W3C Recommendation. 6/03 Support: 5/5 Rating: Strong Positive Strengths: Broad Vendor Support Relative Simplicity Tool Support Weaknesses: Concern About Speed Scalability WSDL Introduced: 2001 Current Spec.: 2.0 W3C Reccomen. Pending Support: 5/5 Rating: Strong Positive Issued June 2003: Part 1 Core Language Part 2 Message Patterns Part 3 Bindings Strengths: Broad Vendor Support Weakness: Complexity UDDI Introduced: 1999 Current Version: 2.0 Vers. 3.0 approved, 3.1 under development OASIS Recommendation 7/03 Support: 3/5 Rating: Positive Strengths: Growing Vendor Support Growing Private Imp. Weaknesses: Limited Utility Limited Tool Support The State of the Core Standards Advanced StandardsDevelopment: WS-Asynchronous Web Services Established 11/03 Support 1/05 Rating: Caution Estimated Recommendation: ? Challenges: Lack of major player involvement Reconciliation with WS-Events Complexity WS-Distributed Mgt. Established 3/03, Initial Specification 1/04 Support 3/05 Rating: Promising Estimated Recommendation: 2007 Challenges: Has strong support, but Microsoft not listed as initial member Web Service management processes under development WS-Composite Application Framework Established 10/03 Support: 2/05 Rating: Caution Estimated Recommendation: 2008 Challenges: Potential competition with WS-Choreography and WS-Transactions Microsoft involvement potentially limited due to development priorities Other WS Initiatives Are Under Development at OASIS. Advanced Standards Development Vendor-Driven Specifications AddressKey Activities: WS-Policy Introduced: 5/03 Support: 3/5 Rating: Positive Sets performance requirements for specifications WS-Discovery Introduced: 2/04 Support: 2/5 Rating: Promising Deals with devices and systems not always connected WS-Eventing Introduced: 1/04 Support: 2/5 Rating: Promising Receives messages (notifications) in events (event sink) WS-Transactions Introduced 7/02 Support 3/5 Rating: Positive Coordinates multiple clients and services Vendor-Driven Specifications Address Key Activities WS-RM vs. WS-Reliability:Reconciliation Is Needed: WS-RM and WS-Reliability Status: WS-Reliability: OASIS Technical Committee (note name: WSRM) WS-RM: Vendor-driven effort Introduced: WS-Reliability January 2003 (ebXML heritage) WS-RM March 2003 Version: Both are initial versions Support WS-Reliability (2/5) WS-RM (3/5) Rating WS-Reliability and WS-RM if reconciliation does not occur: caution/promising, but WS-RM has support of more megavendors (IBM, Microsoft and SAP) if reconciliation does occur in standards body, positive Strengths Well-understood concepts Weaknesses Name similarity is confusing Vendors need to reconcile efforts WS-RM vs. WS-Reliability: Reconciliation Is Needed WS-S: Safe and Secure? : WS-Security Status: OASIS Standard: April 2004 Support: 4/5 Rating: Positive Strengths Broad vendor support Enables secure SOAP messaging Standard extensions to SOAP Opportunities Comprehensive security and authentication/authorization support when used in conjunction and other associated “tokens,” including SAML Weaknesses Management of relationships to interrelated specs, including SAML, WS-Trust and Liberty Alliance, may be complex Threats Vendor rivalries Limited industry for extensions WS-S: Safe and Secure? WS-Addressing: Overcoming Current Web Services Transport Restrictions: WS-Addressing Status: Originally a vendor-driven initiative, moved to W3C August 2004 Support: 3/5 Rating: Positive Strengths Major vendor support (BEA, Microsoft, IBM, SAP and Sun) Overcomes current SOAP/HTTP transport restrictions Underpins important protocols under development, including WS-RM, WS-Federation and WS-Atomic Transaction Opportunities Become a W3C recommendation established first half of 2006 Next Step: work through the W3C process Weaknesses Complexity, standardized implementations be restricted by growing SOAP complexity Threats Major vendors may not agree on standardized implementations WS-Addressing: Overcoming Current Web Services Transport Restrictions WS-BPEL: Process Orchestration, but Choreography Is Needed : WS: Business Process Execution Language Status: OASIS Technical Committee Joint IBM/Microsoft/ BEA/SAP proposal Support: 3/5 Rating: Positive Introduced: August 2002 Version 1.1: May 2003 Estimated recommendation: 2H05 Next Step: OASIS Committee is revising Opportunities Become a core standard Bring in process definitions from SOBA vendors now emerging Strengths Subsumes XLANG and WSFL work Specifies process logic and interaction Major application player Oracle and SAP involvement BPELJ and UML to XML work pending Weaknesses Development work becoming very complex Reconciliation with WS-Choreography (W3C), BPMN and WS-Transactions WS-BPEL: Process Orchestration, but Choreography Is Needed Recommendations: Recommendations Understand the limitations of Web services standards and specifications and the high-value scenarios that are possible. If you use standards and specifications to increase the capabilities and efficiencies of your SOAs and SOBAs, be prepared to re-factor and re-architect to gain performance, reliability and security. When writing a new SOBA that requires advanced Web services, design in layers of abstraction that can map to possible standards. Do not consider basic Web services support as a significant differentiator among vendors. Consider vendors that participate in the standards process and help shape new standards as being significantly more credible. Participate in standards development activities at OASIS and W3C where you have a vested interest in the outcome. You don’t have to be a formal member to track discussions, read minutes and listen in on conference calls. Do not expect Web services standards to transform your business; use Web services standards to transform your architectures, processes and applications.