What is a Node?
A Node is a Network Partner’s point of presence on the Exchange Network. A Node is software that securely initiates and responds to requests for information. 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 that can then be consumed in a number of ways (e.g. on websites, mobile apps, etc.). With properly configured Nodes, Network Partners can seamlessly exchange data regardless of hardware, operating system, or programming environment.
Node Client: Some Partners may want to consider using a Node Client as an alternative to a full Node. Like Nodes, Node Clients can submit, request, and receive results from a request on the Network. Network Clients, however, cannot respond to data queries from other Nodes, and therefore cannot publish data on the Exchange Network. Network Clients may be a more cost-effective solution for Partners who do not have a compelling business need to publish their data on the Exchange Network. Review Node or Node Client: To Be or Not To Be to decide which may be the right solution right for your agency.
Node Specifications: In order for Nodes to be able to communicate with one another, they must all comply with the same Node Functional Specifications, a document which outlines the minimum specifications and functionality of an Exchange Network Node. The current Node Specifications is Version 2.1.
What to Consider When Planning to Implement a Node
Using an Existing Solution versus 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 Node solution, most have chosen to implement a Node developed by one of several vendors. These freely available solutions allow new Partners to take advantage of others’ development work and lessons learned, so they are often more cost-effective than building a new Node. Partners should be aware, however, 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 EPA’s Exchange Network Grant Program. For more information on product availability, visit here.
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 the same. First, consider the technical architecture within your organization. Although there are a number of technologies that are commonly used by most 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 EPA’s 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 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.