Exchange Network Node 2'0 Information

1
Exchange Network Node 2.0 Information

• April 29, 2008

2
Presentation Summary/TOC

• Node 2.0 Feature Summary
• Node 2.0 Tools and Services
• Node 2.0 Rollout Summary
• Node 2.0 Flow Migration

3
The journey from Node 1.1 to Node 2.0

• Late summer 2006 NTG begins Node 2.0
  deliberation
• June 2007 Node 2.0 draft v.7 WSDL, Specification
  release to EN for comment
• June Present continued development of WSDL,
  Specification
• October 5, 2007 Node 2.0 draft v.8 WSDL,
  Specification released
• February 11, 2008 Node 2.0 draft v.8 Unit
  Testing completed
• March 4, 2008 Release of draft v.9 WSDL,
  Specification

4
Feature Set Summary
5
Basic changes in Node 2.0

• 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 the Exchange Network 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

6
Whats New in Node 2.0 SOAP 1.2 and Doc/Lit WSDL

• Soap 1.2/MTOM
• SOAP 1.1 is no longer supported by Java or MS
  .NET WS toolkits.
• SOAP 1.2 utilizes MTOM (now a W3C standard) to
  attach binary messages which has a unified
  infoset, is simple to design and implement, and
  is the new standard for WS payloads over SOAP.
• Doc/Literal WSDL
• The Node 1.1 WSDL is RPC/Encoded.
• Standard, but inconsistent implementation due to
  encoding type definitions.
• Doc/Literal allows WSDL types to be defined like
  normal XML schema.

7
Node 2.0 Draft 9 Specific Changes

• Parameters
• Parameters are now defined as an
  element/attribute pair.
• Includes ability to specify unique type for each
  parameter.
• All Nodes are expected to support String and XML
  parameters.
• Additional allowable types are enumerated in the
  WSDL and are optional for Nodes to support.

8
Node 2.0 Draft 9 Specific Changes

• Query Paging
• Expanded from Node 1.1
• Return result set based on rowID, maxRows
• Query paging parameters must always be included
  in the response.
• If a Node is unable to page query results, it
  should return the entire result with values of
• rowID 0
• maxRows 0
• lastSet true

9
Node 2.0 Draft 9 Specific Changes

• Synchronous Status Response
• Response for Submit and Solicit includes
• Status Code Received, Pending, Processed,
  Complete, and Failed.
• Status detail contains free form text.
• These return elements are required, however if a
  Node cannot support granular status reporting, a
  status code of Received may be returned instead
  of actual values.

10
Node 2.0 Draft 9 Specific Changes

• Automatic Email/Node notification
• Ability to supply either a valid email URI or
  Node URI and automatically receive a notification
  message when a transaction status changes
• New notificationURI WSDL construct allows for
  granular notification
• Only receive emails on error, warning, failure,
  etc.
• Nodes should return a non-critical error if this
  feature is unsupported or if the email address is
  unavailable or invalid

11
Automated Data Submissions(Node to Node)

• Node A submits data to Node B with
  NotificationURI.
• Node B returns a transaction ID to Node A and
  processes the data.
• Node B calls Notify method to inform Node A the
  status of the transaction when completed.

12
Node 2.0 Draft 9 Specific Changes

• Dynamic submission routing
• Via the new recipients parameter
• Specify either a Node URI or email URI
• Nodes receive a forwarded submission
• Emails receive transactionID.
• Creates ability to create ad hoc dataflows
  i.e. dynamic submissions
• Optional and should only be used with trusted
  partners
• http//www.exchangenetworkwiki.com/wiki/ for more
  information and Guidance on the use of
  recipients

13
Automated Data Collections(Node to Node)

• Node A invokes the Solicit method on Node B and
  provides its URL as the recipient.
• Node B returns a transaction ID and processes the
  requested data services.
• Node B submits the results to Node A.

14
Node 2.0 Draft 9 Specific Changes

• GetServices method
• GetServices Response will return an XML response
  defined in an outside schema. The current
  version of the GetServices schema will be
  specifically referenced in the Specification as
  the required return.
• A GetServices response is required from all EN
  Nodes.
• Nodes that are not able to dynamically generate a
  GetServices response message should return a
  static description of the services offered by the
  Node as defined in the Specification.
• add link to document on get services

15
Node 2.0 Draft 9 Specific Changes

• Execute method
• Expandable interface for services
• Future EN Services
• Outside Web Services
• Legacy Node 1.1 applications
• This method will be optional for Nodes to
  implement

16
Boost Flexibility and Extensibility

• Business processes can be published as web
  services through the Execute method.
• Node functionality can be extended through data
  services (Query, Solicit) or through business
  services (Execute).
• Executable processes could be synchronous and
  asynchronous.

17
Node 2.0 New Features Summary

• Exchange any data of any format and size.
• Support devices ranging from small handhelds to
  powerful servers.
• Publish any information across the Network using
  Query and Solicit.
• Expose business processes as executable web
  services.
• Leverage public web services and integrate them
  with other web service networks.

18
Node 2.0 Certification Tool

• Tool to validate implementation conformance to
  the final Node 2.0 Protocol and Specification.
• Developed as an EN Shared Service to ensure that
  all Node 2.0 implementations can communicate.
• Will provide a detailed report that can be used
  as verification of a functioning Node.
• Will be available in June 2008.

19
Node Desktop Client

• A new client that can interact with version 1.1
  and version 2.0 nodes.
• Wizard-driven data submissions to any version of
  nodes.
• Capable of Querying node 1.1 and node 2.0 at the
  same time.
• Supports invoking services published through
  Execute dynamically.
• Integrated with ENDS 2.0 for service discovery.

20
NET Node 2.0 Implementation

• Based on the powerful Windows Communication
  Framework (WCF, .NET 3.5)
• Provides an open business process framework
  through Windows Workflow Foundations (BPEL or
  XAML).
• Intuitive web interface for service
  administration, configuration and transaction
  management.
• Powerful data publishing model backed by
  Microsoft Entity Framework (ADO.NET data
  modeling).

21
C/C Node 2.0 Reference Node

• A comprehensive implementation of all of the
  features of Node 2.0 for validating 2.0
  specification and WSDL.
• Supports dual business process model (native and
  workflow foundation, XAML) .
• Dynamic invocation of any web service, binding to
  arbitrary web services.
• Template based data publishing model with generic
  data objects.
• Underlying technology for NAAS, QA server and
  others.

22
Node Client SDK

• Software Developer Kit that simplifies
  integrating Network Services into applications
  running on Windows
• COM based interfaces supporting Node 1.1 and Node
  2.0.
• Accessible in C/C, C, VB and other languages
  in Microsoft platform.
• Capable of invoking other web services, such as
  QA, NAAS and UDDI dynamically.
• Provides basic client-side transaction storage
  and logging.

23
Quality Assurance Services 3.0

• An upgrade version of QA 2.0 services with
  doc/literal and SOAP 1.2 message support
• Provides payload validation services using schema
  and schematron for node 2.0 data flows
• Supports high performance document transformation
  services with XSLT.
• Supports Node 2.0 message verification/validation
  using the 2.0 schema.

24
Node 2.0 Timeline

• February 2008
• Modification/revisions to the WSDL,
  specification, and protocol process
• Task force discussion on any issues that arise
  during testing
• Basic Unit Testing of the WSDL and Specification
• NTG review and acceptance of modification and
  revisions
• March 4, 2008
• Node 2.0 WSDL and Specification Draft 9 made
  available to the user community and for comment
• April 2008
• Modification/revisions to the Node 2.0 WSDL and
  Specification
• NTG review and acceptance of modification and
  revisions
• May 2008
• Finalize Node 2.0 WSDL, Protocol, Specification
  and supporting documentation
• June 2, 2008
• Release all Node 2.0 items (Specification, WSDL,
  and Protocol)
• Start Node 2.0 implementations and operations
• completion of certification tool

25
June 3, 2008 - The Migration to Node 2.0

• EN Partners are encouraged to migrate to Node
  2.0, but are not required to by any set date.
• EN Grant support is available for making the
  transition to Node 2.0.
• EN Governance will work to ensure that all
  current services and data exchanges available are
  available using Node 2.0.

26
Node 2.0 Rollout Timeline

• June 2008 Final Node 2.0 Materials released,
  Certification Tool available
• August 2008 EN Grants awarded (VERIFY DATE)
• November 2008 CDX Node 2.0 endpoint available
  (VERIFY DATE)

27
Node 2.0 Flow Migration Basics

• Data exchange schema can be used by any Node
  (version 1.1 or 2.0) without modification.
• Version 2.0 and version 1.1 Nodes will not be
  able to communicate directly because of
  differences in the messaging protocol.
• To work with Node 2.0, each Flow will need an FCD
  addendum outlining values for new Node 2.0
  parameters.
• For detailed technical information, refer to
  Flow Migration Summary Document

28
Node 2.0 Flow Migration Strategy

• EN Governance will work with Flow owners to
  develop the FCD addendums.
• WQX Pilot Project to assess level of effort
• Goal is to finish creating addendums by August
  2008

29
National System Flow Migration

• Current version of the national system Flows will
  be supported by both Node 2.0 and Node 1.1
  interfaces at CDX.
• There are two paths under consideration for
  migrating the current national system Flows
• Transition Day approach CDX and the EN
  governance create a broker application that
  sits in front of CDX that is able to route v1.1
  and v2.0 Flows appropriately. All Flows are
  upgraded at once.
• Phased approach Identifying an order and
  schedule for CDX readiness for v2.0 National
  System Flows and publishing this for the EN
  community.

30
Migration Path for CDX only User

• CDX will provide both a Node 2.0 and version 1.1
  endpoint for some predictable period of time.
• You may use either version of the Node to submit
  data, however, timely migration to Node 2.0 is
  strongly encouraged when upgrades are made to
  Flows it will only be supported on the Node 2.0
  platform.

31
Migration Path for Advanced EN User

• A user who submits to CDX and another Node
• CDX will provide both a Node 2.0 and version 1.1
  endpoint for some predicable period of time.
• You will need to communicate with the
  administrator of the Node you would like to
  transmit data with to ensure that it is
  compatible with your implementation.

32
Migration Path for Data Publishing Node

• Version 2.0 and version 1.1 Nodes cannot
  communicate with each other.
• If you upgrade your Node to version 2.0, you must
  either
• Ensure that all Nodes who will request data from
  you are running version 2.0, or
• Provide version 1.1 and version 2.0 endpoints for
  your data publishing services until key
  stakeholders have migrated to 2.0.
• Node administrators should work with Flow IPTs to
  assess when to upgrade Flows and Nodes to take
  advantage of Node 2.0 features.

33
Summary

• Node 2.0 changes are minimal but add features
  critical to the success of the EN for the next
  five years.
• The EN Governance is actively supporting the
  transition to Node 2.0 by
• Creating addendums to FCDs
• Providing Documentation and Guidance
• Node 1.1 services will be available for Node 2.0.
• EN Partners can determine individually the right
  time to transition to Node 2.0 based on business
  needs.

34
How do I stay connected?

• Updates on Node 2.0 will be posted to the Node
  page on Exchange Network website
  www.exchangenetwork.net/node and
  www.exchangenetworkwiki.com
• Documents and slides from this session are
  available immediately
• NTG will use Network Alerts to inform you of key
  updates on Node 2.0 and to announce future open
  calls
• Expect the final Node 2.0 materials on June 2,
  2008

35
How to communicate on Node 2.0

• The Exchange Network Message Board has a forum
  set up for you to ask questions and collaborate
  with other Network partners http//www.websitetoo
  lbox.com/tool/post/exnet/vpost?id2212821
• To contact the NTG directly with Questions or
  Comments
• E-mail node2.0_at_exchangenetwork.net
• OR
• Contact the NTG co-chairs