Transcript slides
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 2 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 3 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 4 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 5 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 6 Ack!! Phhhlllt! Versioning 7 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” 8 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 9 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 10 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 11 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”? 12