Web of Services for Enterprise Computing

1. Web of Services for Enterprise Computing David Orchard BEA Systems

2. Where are we in WS-* • Some papers at WS workshop in 2001 suggested: • Variety of messaging, description, discovery specifications • Appear to be more than halfway there • More standardization in the future • Mex, eventing, sml, discovery • Latest process: Fast-track tightly scoped specs

3. Analysis of where are we • Has this process and architecture worked? • When will we really get multi-vendor interop? • Has standardizing @ W3C been useful? • Has fast-tracking building block specs led to coherent architecture? • Is W3C WS-Addressing substantially better than Submission? • Removal of identity and Ref Properties very concerning • What about current/upcoming specs? • What about integration? • WS-RX/WS-A use of anonymous and WS-Metadata in new WS-Policy • High perceived complexity (S is for Simple) • Architecture coherence vs Fast-track • REST vs WS-*, deferred for W3C TAG talk

4. Thin Client Banking Use Case • Trading Service with Enrichment of Quotes • Classic WS-*: SOAP, WSDL • Large amount of enrichment as SOAP headers • Very high performance • “Classic” integration currently: • Java service, .net and Java clients • Want to reach more clients: Ruby, Python, various OSS • Not deployed yet: • Stacks do not publish as REST service easily • Unsure of “real” customer demand

5. Client-Side REST Validation Use Case • Big “.com”s offer XML over HTTP • Sample app: Music Search • Specify artist, album, song, release year, rating, etc. • Human readable description of request in URI parameters & XML Schema returns • This works ok for a large site with “medium” # of combinations • Cycle of creating URIs, hitting “Go”, see what happens • Missing WS-*/WSDL style of generating client side stubs • Validates the data according to schema

6. Client-Side REST Validation Use Case II • Client-side validation enabled with machine description • WSDL 2.0 is too complicated for a REST developer • interface/operations -> Binding/operations ->Endpoints • Many Operations (WS) vs Generic Operations (Web) • Can do site specific client validation • Libraries in multiple languages for each site • C++, Java, C#, Perl, Python,… • Imagine this for the enterprise

7. Versioning Ack!! Phhhlllt!

8. REST DL • Libraries are *NOT* the answer for the enterprise • Interface Description is the answer • REST DL: • Productivity increase • Lower the barrier to entry for non-large .coms • Scale to large # services, ie “enterprise”

9. Widgets, Portal & Discovery Use Cases • WSRP provide mechanisms for producing and consuming presentation oriented web services • Uses WSDL/SOAP • Next Gen remote user-interface seems to be widgets • Directories of Widgets: Konfabulator, widgetbox.com • Composition of Widgets: • Communication, state mgmt, security • Would be “better” to have declarative description of interactions • http://www.w3.org/2001/tag/doc/leastPower

10. Widgets, Portal & Discovery Use Cases II • Use Case: What is DL of widget • ie. ?wsdl • Use Case: Widgets supported by a site • Use Case: Integration of Widget DL into search engines • REST DL would help with every use case

11. Web of Services for Enterprise aspects • Is the Enterprise different than Internet? • State, Security, Network Performance, Schema size, # of operations • How does this affect specifications? • Perhaps can do higher coupled solutions like Atomic Transactions • Two aspects to Enterprise vs Internet: • Make Web technologies more useful for enterprise • Make Web services more useful for Web clients

12. Recommendations • W3C for Web-centric technologies • Descriptions, protocols, formats • Need better Web Description Language than WSDL 2.0 • After that, discovery of Web Description Language • Examine Missing technology for: • Consuming REST from SOAP clients • Consuming SOAP from REST clients • Not sure about “Fast-tracking” • “Mid-tracking”?