home
network basics
network operations
network policy
partner benefits
build a node
data exchanges
develop schema
standards
progress
grants
press room
message board network wiki alerts

 


archivescontactscalendar

  node basics

what is a node?

A Node is a Network partner's point of presence on the Exchange Network. Essentially, a Node is a piece of software that securely initiates and responds to requests for information. Network partners connect their Nodes to databases so that they can securely share their environmental information. Using standards-based web services and eXtensible Markup Language (XML), Nodes can facilitate exchanges of information between partner databases or publish data to a website for public consumption. With properly configured Nodes, Network partners can seamlessly exchange data regardless of hardware, operating system, or programming environment.

a word about node 2.0

The Exchange Network is currently in the midst of a transition in Node technology. The document which outlines the minimum specifications and functionality of an Exchange Network Node has recently been updated. The first version of the functional specification for Exchange Network Nodes (version 1.1) was adopted in 2003. In June of 2008, the Exchange Network governance released the specifications for the next version of the Exchange Network Node--version 2.0. The upgrade is intended to keep the Node specification current with the latest advances in web services technology and also offer some more robust functionality. The implementation of Node 2.0 is just beginning and the Exchange Network will support both versions while partners make the transition. New and potential Network partners should visit the Node 2.0 web page for more information on how and when to consider implementing a Node 2.0-compliant Node.

what to consider when considering a node

If you've read up on some of the basics and benefits of the Network and decided it's for you, here are some things to consider as you plan to implement a Network Node.

Using an Existing Solution vs. Starting from Scratch

Nodes are defined by their specific function rather than what they are in a physical sense, so partners are free to choose their own approach to establishing a Node. The main requirement is that the Node must be capable of performing the functions outlined in the Network Node Functional Specification. While some partners have elected to develop their own Nodes from scratch, most have chosen to implement a Node solution developed by one of several vendors. Either way is perfectly acceptable and it is up to each individual partner to decide which path is right for them. The pre-developed solutions will allow new partners to take advantage of others' development work and lessons learned, so they are often more cost-effective than building a Node from scratch. However, new partners should also be aware that even these solutions typically require some customization to work within an individual organization's technology environment and infrastructure. Funding for this work has been and continues to be made available through the U.S. EPA's Exchange Network Grant Program. For more information on product availability, please see the web pages covering Node 2.0 and Node 1.1.

Determine the Technical Architecture

Regardless of whether the Partner chooses to implement a previously developed solution or develop a custom solution, the basic activities that must be conducted are essentially the same. First off, consider the technical architecture within your organization. Although there are a number of technologies that are commonly used by many partners, each one is unique in some part of its infrastructure, and that infrastructure is rarely static.

The ideal technology used to host a Node may not reflect the existing technology standards at the organization; however the chosen technical architecture should be complementary to, and not at odds with, the existing infrastructure. A Node must be accessible from the outside world via the Internet, and yet it must serve up data that originates from secure, production servers. Therefore, it is best to reach early agreement on the Node's technical architecture with the staff supporting your organization's network, application architecture, and security infrastructure.

There are a variety of technical architecture considerations and decisions that you will need to contemplate before you are able to implement a Node. Some of these are detailed in this document entitled Deciding on Your Technical Architecture.

Determine Network Node Capabilities

The minimum functionality of the Node Web service is specified in the Network Node Functional Specification and Network Node Protocol documents. However, beyond the basic Web service interface, there are other design decisions that should be made related to how the Node operations will be managed, how service requests will be satisfied, and how the Node will be administered. For example, these are some of the capabilities that Partners have supported within the design of their Nodes:

  • The ability to troubleshoot an exchange, for example:
    • Reviewing details of a recently received or submitted XML document. This can be achieved by configuring the Node to store a copy of each payload which passes in or out of the Node.
    • Viewing a log to determine if a request had been correctly submitted by another Partner.
    • Viewing a log to determine if a data service is being used with inappropriate parameters (e.g., use of wildcards not supported).
  • The ability to monitor the overall use of the Node by other Partners, including frequency of access by each Partner, which services are most / least used.
  • The ability to administer security that determines which Partners have access to which services (if used as an alternative to the US EPA’s central NAAS -Network Authentication and Authorization Services).
  • The ability to set up schedules for certain data exchanges (e.g., some exchanges are so large that they should only be supported outside of office hours).
  • The ability to establish email notifications so that agency staff are notified when different Node functions are invoked.
  • The ability to perform costing estimates which can determine an appropriate response to overly-intensive data requests.

Many of the capabilities that early Node implementers have added to their Nodes are not critical for an initial deployment, but as the use of the Node expands are likely to be a growing need, and so should be considered early on to ensure that the Node is designed in such a way to support its future growth.

Funding

The U.S. EPA has been supporting the implementation of the Exchange Network through its Environmental Information Exchange Network Grant Program. The program has been an important source of Node development funding for states, territories, and Federally Recognized Indian tribes.

For more information on current funding opportunities available through the EPA grant program, please visit the Grants section.

 

 
 

 

© 2008 Network Operations Board
Send questions or comments about this site to
Last updated: November 7, 2008