Louis Sweeny

1. Data Exchange through XMLEnvironmental InformationExchange Networkwww.exchangenetwork.netMay 21, 2003 Louis Sweeny

2. Background on the State / EPA Exchange Network • States and EPA need each other’s data • Over past 35 years, EPA and States have developed scores of individual systems • Like everyone else EPA and States are looking at inter and intra organization integration but how? • Data exchange options were: • State use, or double entry into Federal system (terminal, client server or Web) • “Translator” systems with manual batch upload/download (FTP, remote access, email, CD) • But neither sending nor receiving systems were designed with this as their primary function…many difficulties and much manual effort.

3. Background on the State / EPA Exchange Network • Trends indicated a need to do better • Most states were rapidly migrating away from primary use of EPA systems, and re-engineering systems they had • EPA was re-engineering many of its systems • State and EPA needing more data, from more partners, more often, and old approach of individual translators would not scale • State/EPA Information Management Workgroup charged a team to develop a common blueprint/vision for information exchange

4. Exchange Network Components Data Exchange Templates Common way to package shared data Data Standards Common way to define shared terms Trading PartnerAgreement How information flows between partners Member Infrastructure Capacity to participate Blueprint Team Proposed A Network With These Components Network Administration Registration, process support, communication Technical Infrastructure Uses standard Internet tools

5. Traditional Web Services Stack Universal Description, Discovery and Integration Web Services Description Language eXtensible Markup Language Simple Object Access Protocol HyperText Transfer Protocol Secure Sockets Layer

6. How this stack is adapted for the technical infrastructure of the Network EN Specific Network Specificity Generic

7. Network Overview and Infrastructure Registry NAAS Information System WA Information System Internet Schema based payload Schema based payload Node Node Protocol & Specification Information Consumer DET/Schema Guidelines

8. The Network Node Supports Four Basic Operations • Administering: Security and Housekeeping. • Querying: Querying a partner for some data. • Sending: Send a set of data to a partner. • Retrieving : Retrieving from a partner a standard set of data.

9. Protocol Establishes 11 Network Methods Security Authenticate, Validate CentralAuth* * Currently under development by EPA/CDX

10. Network/Node Usage Options

11. Network Nodes can be used to: • Service Other Nodes: support aggregation of data from other Nodes that can then be displayed on a website. • Service Clients: submit retrieval data from a Node using a simple client. • Integrate Applications: where a local application (webpage, model or report) retrieves information from one or more Nodes as needed. • Provide Node Services: use a “hosted” Node, that interacts with other Nodes as a client, but puts data on the Network.

12. Authenticate(userId, credential authMethod) securityToken() GetFacilityByID (securityToken, parameters – State: WA, State Facility ID: 12345) GetFacilityByIDResponse() Facility Information Putting it all Together in an Exchange: GetFacilityByID Requestor NAAS Provider

13. Node 1.0 Protocol Interoperability Testbeds: Middleware

14. First Generation Network Security: Centralized Network Authentication & Authorization Service • Given immaturity of web services a simple, centralized service was implemented • Decided that it easier to start with “locked down” approach and then loosen security as appropriate • Much of this information is public, and on public websites, some partners will likely launch public web services • Finalizing a model for how authorization services will be managed • Nodes will likely implement additional layers of authorization internally (at node, procedure and database levels)

15. Three Quick Lessons Learned • The web services metaphor, roles and responsibilities are as important to an effort like this as the technology. • Immaturity in Web Services Standards and Tools but they are improving rapidly. • Many current reporting processes are “semi-automated”, moving these to fully automated requires addressing many additional details/refinements.

16. Web Services as a Metaphor for Cross-Organizational Collaboration • The web services metaphor, roles and responsibilities are as important to an effort like this as the technology • Provides a framework for collaboration • More useful than “cooperate” or “build inter-operable systems” or “use standards” or all the other euphemisms we use. • Provides cleaner separation of what is behind and in front of the firewall • Allows incremental progress, makes clear EXACTLY what each partner has to do (i.e. consume or produce these messages) • Adoption of cross-organizational web services may be FASTER (!) in government than the market

17. For More Information Environmental Exchange Network www.exchangenetwork.net Justice XML Initiatives http://it.ojp.gov/topic.jsp?topic_id=43 Shameless plug: If your agency deals with data in anyway related to environment/natural resources/health…partner with ecology on a project and/or Network Grant!