1 Node 2.0 Technical Specifics Three major changes to Node technologies –SOAP 1.2 –Doc/Literal WSDL –MTOM Changes primarily driven by vendor support issues These changes will be mostly transparent but are important for other reasons: –Bring EN up-to-date with current standards for web services This means that the same platform (e.g. SOAP 1.2 handler) that runs Node 2.0 can easily be adapted to inter-operate with other Web services networks.

2 SOAP 1.2 and the WSDL SOAP 1.1 no longer supported in many standard toolkits. –SOAP 1.2 provides small enhancements: NodeFault Doc/Literal WSDL –Node 1.1 WSDL = RPC/Encoded Standard, but inconsistent implementation due to enc. type definitions –Doc/Literal allows WSDL types to be defined and validated like normal XML schema

3 MTOM Node 1.1 used DIME for payloads –Functional –Never an integrated solution –No longer supported by Java or MS.NET WS toolkits MTOM –Is a W3C standard! DIME never made it –MTOM creates unified infoset –Simple to design and implement –New standard for WS payloads over SOAP –Small performance gains (but no worse than DIME!)

4 Now a Demo Node 2.0 discussion includes more than the Protocol and Specification Our Question: What interesting things can we do with the Node technology and roll out with Node 2.0?

5 Its About the Data Data publishing –Chris Clark/others making putting data on the network simple… –How do we simplify getting data off the network (through Query)? Current Node technology (SOAP) necessary for transactions, but –Query is transaction-less –SOAP = unneeded high coordination costs

6 Simplifying Data Consumption A simple solution is putting EN query into a common, simple, and standard interface… Also known as a Uniform Resource Locator (URL)… And heres what that looks like:

7 EN Data as a URL The REST architecture –All data is a resource –We can represent any query as a unique URL –Return is genuine, dynamic EN data from an EN Node –Operates over the Exchange Network, but does not replace it Benefits of REST –Lower development costs –Low coordination/transaction costs –Technology agnostic – goal is to provide data in a neutral way without reliance on SOAP –Uses current EN NAAS security features

8 SOAP to REST

9 Uses of REST Broker RESTful publishing allows any program that can open a URL to perform a Query This means: –MS Word, Excel, Access, PowerPoint, XMLspy, Internet Explorer, Firefox… –or almost any program that uses a File->Open dialogue box. And (for Query) you can do this all without ever needing an EN client

10 Time to REST… Two possibilities for RESTful Query interface –Broker Node (shared service) –Include as a Node plug-in each node operates a RESTful endpoint