SOA-14: Web Services Standards Update

1
SOA-14 Web Services Standards Update

• Dave Chappell
• Vice President Chief Technology Evangelist,
  Sonic Software

2
Our Goals Today

• Understand whats so hip about standards
• ...and also their limitations
• Summarize whats up in the Web Services standards
  space
• ...and why WS standards are interesting
• Adopt a hopeful but realistic picture of WS
  interoperability and evolution

3
Some Familiar Standards

• Power
• Phone lines
• Railroads
• Currency
• etc...

4
Standards Why the Big Deal?

• Standards allow for independently developed (over
  time and space) components to interoperate
• Open standards discourage monopolization
• Anyone can implement (and even affect) the
  standard
• Standards bodies (govts, IETF, W3C, etc)
  shared control
• Standards reduce costs of development
  maintenance
• Shared skills, commoditized tools

5
Benefits of Using Software Standards

• Categories
• API standards (Java, .NET, open-source)
• Protocols (TCP, HTTP, SOAP)
• Data Formats (XML, ASN.1, WSDL, UBL)
• Benefits
• Leveraging common developer skills
• Interoperability with more partners
• Insulation from implementation changes
• Pluggability (vendor independence evolution)
• Validation / tool support

6
Whats So Special About Web Services

• Web Services Application Interoperability
• Havent we been here before? DCE, CORBA....
• Everyone actually seems to support the bottom
  layers!
• SOAP / WSDL interop is real today
• Soapbuilders, WS-I de jure standardization
• Dont need the whole stack in order to go ahead
• An orthogonally developed set of composable specs
• Extensibility built in at each layer (protocol,
  metadata)
• This hasnt really been tried before!
• There are tradeoffs....

7
Composability

• Composition is the Elephant in the Room for WS
• Encryption Compression ???
• For composability to work, we need a common
  language
• Forays into this area
• SOAP Extensibility Model
• WSDL Features and Properties
• WS-Policy

8
A Whirlwind Tour of the WS Stack

• Goal is to understand what each spec means and
  where its at in its development
• Not deep technical details!

9
The Four Pillars of Web Services

• SOAP
• WSDL
• Policy
• Addressing

10
XML The Zeroth Pillar

• Common data representation (Infoset
  Serialization)
• Fairly simple (simpler than SGML)
• Human readable
• Lots of tool support
• XML Schema
• Validation and typing
• Related XPath, XSLT, XQuery, XLink, XInclude
• XML 1.0 and Schema 1.0 are W3C Recommendations

11
SOAP

• Messaging Envelope
• Extensibility framework
• Vertical headers
• Horizontal intermediaries

ltEnvelopegt
ltHeadergt
ltEncrypted MustUnderstandtrue/gt
Partner
Notary
ltBodygt
Encrypted Purchase Order
Purchase Order
SOAP Message
12
SOAP, cont.

• Faults, Versioning, RPC, Encoding
• SOAP 1.1 is a W3C Note
• SOAP 1.2 is a W3C Recommendation
• Binding Framework
• Features Properties
• Modules
• Processing model clarifications
• Infoset-based
• Cleaner fault model
• NotUnderstood header

13
WSDL

• Web Service Description Language
• IDL for Web Services
• WSDL 1.1 is a W3C Note
• WSDL 2.0 is in Last Call at W3C
• Simpler (no ltpartgts)
• Interface inheritance/extension
• Single Interface per Service
• SOAP 1.2 / MTOM support
• Flexible MEPs

14
policy More Metadata, Please!

• policy allows expressions of assertions
• You MUST...
• I SUPPORT...
• Rules for composition, comparison
• WSDL Features Properties / SOAP Modules
• WS-Policy (MS/IBM/BEA/SAP/Sonic/Verisign)
• XAML
• WS-Policy will eventually be submitted to a
  standards body (likely W3C)
• No timeline yet

15
WS-Addressing

• WSA is the machinery behind asynchronous SOAP
• Building blocks for complex MEPs (callback,
  routing)
• Defines Endpoint References, Addressing Headers
• ltTogt, ltFromgt, ltMessageIDgt, ltReplyTogt, ltFaultTogt
• Abstract spec, binding to SOAP
• WS-Addressing is in the W3C, accelerated schedule
• Last Call in March?

16
The Four Pillars

• SOAP
• WSDL
• Policy
• Addressing
• When these foundational pieces are standard, the
  WS extensibility/agreement mechanisms kick in and
  allow us to either interoperate or fail
  gracefully.
• On the wire, and at design/metadata time

17
MTOM XOP

• Unified, infoset-based approach to binary
  attachments
• Helps with programming model
• Eases security/encryption
• Abstract Transmission Optimization Feature
• XML-binary Optimized Packaging
• Not tied to SOAP
• HTTP Transmission Optimization Feature
• Lots of support
• MTOM XOP are W3C Recommendations (Jan 2005)

18
WS-Security

• Rules for putting security principals,
  certificates, and encryption info into SOAP
  messages
• End-to-end security
• Token Profiles
• Username/password, X.509, SAML, REL
• WS-Security is an OASIS Standard
• but WS-SecurityPolicy is not...
• so theres no standard way to do this in WSDL yet!

19
WS-Reliab

• Reliable messaging comes in two flavors,
  WS-Reliability (OASIS) and WS-ReliableMessaging
  (MS/IBM)
• WS-Reliability is an OASIS Standard
• WS-ReliableMessaging has been submitted to OASIS
  as WS-RX TC
• Will MS/IBM implement WSReliability? Doubtful.
• OK to have two? (Sonic a member of both)

20
WS-Eventing / WS-Notification

• Patterns for asynchronous pub/sub WS interactions
• Subscribe this EPR to receive future events
• Notification includes hierarchical Topic Spaces
• Both make heavy use of WS-Addressing
• Eventing is an MS/TIBCO/BEA spec
• Notification is in OASIS Technical Committee
• Merging base specs seems obvious
• but WSNs dependence on WSRF makes that a bit
  challenging

21
Working up the stack Process Models

• Process modeling linked series of WSDL
  operations and logic
• Faults / compensation
• BPEL Based around a single nodes viewpoint
• Choreography Omniscient Observer viewpoint.

22
Other Specs

• UDDI (OASIS)
• WS-Context / CAF (OASIS)
• WS-Coordination / Transactions (MS/IBM)
• WS-ResourceFramework (OASIS)
• WS-Distributed Management (OASIS)
• etc... (too many to discuss here)

23
So How are we Doing?

• Basic interop is there now
• Yee ha!!
• Important specs coming togetherbut
• Composability story isnt there yet
• We need to be writing extensions with hooks /
  abstraction
• Wheres Policy?
• What about competing specs?
• We should be OK with two or more of some layers

24
Closing Thoughts

• Adopt SOAP/WSDL now
• Really means adopt SOA now modular,
  message-based interfaces
• Useful no matter what else happens
• More stuff will settle while you start
• GET INVOLVED if you hope to use this stuff
• Push on your vendors to ensure theyre on top of
  it
• Join groups yourself
• Platforms (.NET, Java, Axis, etc) support
  composibility extensions
• pick a good model, and ask questions
• Standards arent a panacea
• but they make some great platforms interoperable

25
?
Q A
26
Thank you for your time!
27
(No Transcript)