100 likes | 273 Views
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
E N D
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.
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
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!)
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?
It’s 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
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 here’s what that looks like: http://216.234.124.208/rest/cdx_test/authenticate/?username=cdx&password=test http://216.234.124.208/rest/cdx_test/GetFacilityByStateID/?USPS=MD&FacilitySiteID=4330&token=
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
SOAP to REST <SOAP Message> <Node> <Flow Operation> <NAAS Token> <Query Params> <….> </Query Params></SOAP Message> http://ross-assoc.net/cdx_test/GetFacilityByStateID/?USPS=MD&FacilitySiteID=4330&token=...
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
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