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

BEA Confidential. | 1

Web of Services for Enterprise Computing

David OrchardBEA 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 thereMore 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?

1.When will we really get multi-vendor interop?

2.Has standardizing @ W3C been useful?

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