Web of Services for
Enterprise Computing
David Orchard
BEA Systems
BEA Confidential. | 1
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
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
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
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
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
Ack!! Phhhlllt!
Libraries are *NOT* the answer for the enterprise
Interface Description is the answer
Productivity increase
Lower the barrier to entry for non-large .coms
Scale to large # services, ie “enterprise”
Widgets, Portal & Discovery Use Cases
WSRP provide mechanisms for producing and consuming
presentation oriented web services
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
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
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
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”

WS-* at BEA