1 / 17

Demystifying the Protocol and Specification v1.1

Demystifying the Protocol and Specification v1.1. Prepared for the Node Mentoring Meeting by: Rob Willis, Ross & Associates rob.willis@ross-assoc.com February 09, 2004. Presentation Outline.

nishi
Download Presentation

Demystifying the Protocol and Specification v1.1

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Demystifying the Protocol and Specification v1.1 Prepared for the Node Mentoring Meeting by: Rob Willis, Ross & Associates rob.willis@ross-assoc.com February 09, 2004

  2. Presentation Outline • Network Exchange Protocol (Protocol) and Network Node Functional Specification (Specification) Descriptions and Purpose • Design Assumptions • Out of Scope/Limitations • Extensions • Using the Protocol and Specification for Node Building and Flowing Information • A Gaze into a Crystal Ball

  3. How do you build only ONE Network while balancing the varied needs and capabilities of potential Partners with the efficiencies of standardization?

  4. Network Exchange Protocol (Protocol) The Protocol is the set of rules that govern the generation and use of valid service requests and responses on the Exchange Network.

  5. Network Node Functional Specification (Specification) • The Specification is a detailed description of a Node’s expected behavior. It includes a description of: • the functions the Node will perform • how those functions are to be invoked • the output expected from the Node

  6. Design Assumptions • Simple as possible, even if unable to meet a small number of identified, but advanced needs. • Consistent with all other Network Guidance • Designed to be used for all information exchanges. • Web Services/Web Methods • Used to construct transactions

  7. Design Assumptions • Shelf-life of 18-24 months • Forward-Looking • Infrastructure • Use • Known reliance on immature standards • SOAP 1.1 • WSDL 1.0 • DIME • MUST BE IMPLEMENTABLE!

  8. Submit Download Notify Query Solicit Authenticate NodePing GetStatus GetServices Execute (Optional) Security Methods Web Methods

  9. Network Exchange Business Processes • Simple Submit • Simple Download • Notify for Download • Solicit with Submit Return • Solicit with Download Return • Query

  10. Out of Scope/Limitations • Protocol and Specification only define a “listener.” • Does not fully leverage the standards and tools • Dynamic Binding • SOAP 1.2 • Attachments • Only DIME attachments • Does not define any payload specifications • Defining and handling the common types of “missing,” “unavailable,” or “inapplicable” data.

  11. Extensions • Payload Extensions • Payload Header • Data Request • Naming • Schema • Client • Node Management Interface • Security Layer • Additional Web Services outlined in Security Guidance documents • Orchestration

  12. Going from Building a Node to Flowing Information Exchange Protocol v1.1 Core Reference Model Schema Design Guidelines Functional Specification v 1.1 NEBP Flow Configuration Document Schema Node Node Network WSDL Meanwhile, a Flow is developed by an IPT. The IPT uses the Flow Configuration Document (FCD) Template, Core Reference Model, Schema Design Guidelines, and other resources to develop an FCD and Schema to govern the Flow. The FCD outlines several different Network Exchange Business Process Options Partners can implement for the given Flow. TPA Network Web Methods Partners determine the Flow specifics and formalize them in a TPA and by modifying the Generic FCD for their Flow. A Node is built and is ready to flow by using the Network WSDL and other resources, e.g., DNCs, Test Tool, Help Desk, Mentoring. The Network WSDL file is the canonical, machine- readable description of the Protocol and Specification. Nodes should be built using this as the guide. PARTNERS IMPLEMENT THE FLOW ! NAAS Protocol and Specification identify the minimum technical Node infrastructure. It is the foundation on which the Network is built. The Partner Establishes their Security mechanisms using available security resources, e.g., Security Documents, NAAS. Security Guidelines And Specifications

  13. II. Flow I. Node III. Client 1. Unknown 1. System Development 2. Pre-Planning 1. Obtain/Develop Client 3. Planning 2. Planning 2. Client Install (Configuration) 4. Development 3. Development 4. Testing/Debugging 3. Testing/Initial Use 5. Testing 6. Node Ready to Flow 5. Ready to Flow X Node in Production for Flow X Client in Production for Flow X

  14. Not to worry, the Protocol and Specification will remain stable. Technical operational issues will arise but be handled through the NSB. Seamless, real-time collation of data from disparate Networks, e.g., Health, Homeland Security, Other Federal and State agencies and Other Countries. Partners will publish all their environmental information on Neo-Nodes. Uh Oh! The Crystal Ball is Cloudy! Enterprising individuals will continue to extend the Protocol and Specification. The Network community will greatly benefit and learn from these efforts. Web Service Standards will continue to mature and developers will benefit from more sophisticated toolsets. Network Community will begin thinking about a v2.0 transition plan and identify migration metrics. 1 Year . . . 5 Years . . .

  15. Version 2.0 • Migrate to Document Literal Encoding • Leverage SOAP 1.2 • Leverage WSDL 1.1 • Consider additional attachment methods • Web Service Security Extensions • Orchestration

  16. Take Home Messages • Protocol and Specification are the foundation of the Network and the Network WSDL or DNCs should be used to guide Node development. • Protocol and Specification will remain stable. • Most states will want/need to build Node clients.

  17. Questions? Please feel free to contact me at anytime with questions. rob.willis@ross-assoc.com 206-447-1805

More Related