SOA-14: Web Services Standards Update Dave Chappell Vice President & Chief Technology Evangelist,...

SOA-14: Web Services Standards Update

Dave ChappellVice President & Chief Technology Evangelist, Sonic Software

2 SOA-14:Web Services Standards Update© 2005 Progress Software Corporation

Our Goals Today

Understand what’s so hip about standards– ...and also their limitations

Summarize what’s up in the Web Services standards space– ...and why WS standards are interesting

Adopt a hopeful but realistic picture of WS interoperability and evolution


Some Familiar Standards

Power Phone lines Railroads Currency etc...


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 (gov’ts, IETF, W3C, etc) =

shared control Standards reduce costs of development +

maintenance– Shared skills, commoditized tools


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


What’s So Special About Web Services

Web Services == Application Interoperability Haven’t 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

– Don’t 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 hasn’t really been tried before!– There are tradeoffs....


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


A Whirlwind Tour of the WS Stack

Goal is to understand what each spec means and where it’s at in its development

Not deep technical details!


The “Four Pillars of Web Services”

SOAP WSDL Policy Addressing


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


SOAP Messaging Envelope Extensibility framework

– Vertical – headers

– Horizontal – intermediaries

Purchase Order

<Encrypted MustUnderstand=“true”/>

EncryptedPurchase Order

PartnerNotary

SOAPMessage

<Body>

<Header>

<Envelope>


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


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 <part>s)– Interface inheritance/extension– Single Interface per Service– SOAP 1.2 / MTOM support– Flexible MEPs


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


WS-Addressing

WSA is the machinery behind asynchronous SOAP Building blocks for complex MEPs (callback, routing) Defines Endpoint References, Addressing Headers <To>, <From>, <MessageID>, <ReplyTo>, <FaultTo> Abstract spec, binding to SOAP WS-Addressing is in the W3C, accelerated schedule

– Last Call in… March?


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


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)


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 there’s no standard way to do this in WSDL

yet!


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)


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 WSN’s dependence on WSRF makes that a bit challenging


ChoreographyBPEL

Working up the stack – Process Models

Process modeling – linked series of WSDL operations and logic

Faults / compensation BPEL : Based around a single node’s viewpoint Choreography : “Omniscient Observer” viewpoint.


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)


So How are we Doing?

Basic interop is there now– Yee ha!!

Important specs coming together…but Composability story isn’t there yet

– We need to be writing extensions with hooks / abstraction

Where’s Policy? What about competing specs?

– We should be OK with two or more of some layers


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 they’re on top of it– Join groups yourself

Platforms (.NET, Java, Axis, etc) support composibility + extensions– pick a good model, and ask questions

Standards aren’t a panacea– but they make some great platforms interoperable


Q & A


Thank you for your time!

SOA-14: Web Services Standards Update Dave Chappell Vice President & Chief Technology Evangelist,...

Documents

Transcript of SOA-14: Web Services Standards Update Dave Chappell Vice President & Chief Technology Evangelist,...