Time Well Spent: Web Services Standards Mature More

1
Time Well SpentWeb Services Standards Mature
More

• Charles Abrams
• Daryl Plummer

2
Web Service Standards Building
TowardMission-Critical Implementations
Usage in 2004 First-Generation and Embryonic
Usage in 2009 Mission-Critical Core Competencies

• Used for first-generation integration projects
  and composite application development
• High-value scenarios limited by volume and code
  complexity
• Usage for collaborativecommerce 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

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

4
Web Services Standards and SpecificationsAre at
the Core of SOAs and SOBAs
Future Events
Increasing Complexity
Future Addressing
Future Web services management
ComplexBusiness Process Utility
BPEL Orchestrating business processes
WS-Security/transactions for mix of uses
WS-RM Collab. commerce needs reliable messaging
UDDI Web services directory can source SOBA
components
WSDL Formal interface description reduces
integration effort
SOAP Core messaging, unification of XML data,
SOBA must have this
Incorporation Prevalent in SOA and SOBA
5
Standards/Specifications Usage in Global 2000 New
Development and Deployment
Percent
100
80
WS-Security
SOAP
WS-Addressing
60
BPEL
UDDI
40
WSDL
WS-R/RM
WS-TX
20
0
YE04
YE07
YE10
6
SODA in 2004 Incomplete Standards Dictate
Approach

• Expedient Enablement
• Start with a large pile of application code
• Expose selected methods as WS via megavendors
  monolithic IDE
• Wait to get bitten by faulty assumptionsabout a
  nondistributed architecture

• Low Road
• Eschew transparency
• Stick to fully-baked basics SOAP, WSDL, UDDI
• Expose high-value mass of code and/or datavia
  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

7
2007 Standards Power B2B Commerce
Development and testing remaining on core Web
services standards stack SOAP, WSDL, UDDI,
BPEL.WS-Events, others
Boom in B2B Trading Efficiencies
Growth of semantic B2B standards
2007 Sweet Spot
ebXML vertical initiatives, UBL, OWL, RDF,
UCC/Rosettanet, Accord, others
2000
2010
2007
The semantic Web emphasizes XML and
machine-readable content
8
Why Is It Taking so Long?Case Study Rolling Out
WSRP
Serviceproviders start to emerge
Serviceproviders proliferate
Users deploy pilots externally
Users deploy pilots internally
Vendors implementin the lab
Vendors ship firstversion
Vendors ship service packs
Vendors ship Version 2support
Vendors Ship
WSRP committee works on Version 1
WSRP committee works on Version 2
2002
2003
2004
2005
2006
9
Its Not a Stack, Its a Web of Dependencies
A Partial View
BPEL 1.1
WS-ReliableMessaging
WS-Coordination
WS-Transaction
WS-Addressing
Xpath 1.0
WS-Security
WS-Trust
WSDL 1.1
WS-Policy
WS-SecurityAddendum
SOAP 1.2
WS-PolicyAssertions
WS-SecurityPolicy
WS-Routing
WS-PolicyAttachments
XML Schema 1.0
WS-SecureConversation
XML Signature
XML Encryption
XML Infoset
X.509
XML 1.0
XML Namespaces
10
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
11
WS-I Ensuring Standards Interoperability
Delivered through September 2004

• 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)

www.ws-i.org Founded 2002 Rating Positive
Source Web Services Interoperability Organization
12
The State of the Core Standards
SOAP Introduced 1999 Current Version 1.2
W3C Recommendation. 6/03 Support 5/5 Rating
Strong Positive StrengthsBroad Vendor Support
Relative SimplicityTool Support WeaknessesConce
rn About Speed Scalability
WSDL Introduced 2001 Current Spec. 2.0 W3C
Reccomen. Pending Support 5/5 Rating Strong
Positive Issued June 2003Part 1 Core
LanguagePart 2 Message PatternsPart 3
Bindings StrengthsBroad 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 StrengthsGrowing Vendor Support
Growing Private Imp. WeaknessesLimited
UtilityLimited Tool Support
13
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.
14
Vendor-Driven Specifications AddressKey
Activities
WS-Policy Introduced 5/03 Support 3/5 Rating
Positive Sets performance requirements for
specifications
WS-Transactions Introduced 7/02 Support
3/5 Rating Positive Coordinates multiple clients
and services
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)
15
WS-RM vs. WS-ReliabilityReconciliation Is Needed

• WS-RM and WS-Reliability
• StatusWS-Reliability OASIS Technical Committee
  (note name WSRM)
• WS-RM Vendor-driven effort
• IntroducedWS-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

16
WS-S Safe and Secure?

• WS-Security
• Status OASIS Standard April 2004
• Support 4/5
• Rating Positive
• Strengths
• Broad vendor support
• Enables secureSOAP messaging
• Standard extensions to SOAP

• Opportunities
• Comprehensive security and authentication/authoriz
  ation 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

17
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 recommendationestablished 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

18
WS-BPEL Process Orchestration, but Choreography
Is Needed

• WS Business Process
• Execution Language
• Status OASIS TechnicalCommittee 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

19
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
  significantdifferentiator among vendors.
  Consider vendors that participatein 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 dont 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 businessuse Web services standards to
  transform your architectures,processes and
  applications.