1. Data Exchange through XML Environmental Information Exchange Network www.exchangenetwork.net May 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) 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) “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.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 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 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 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. Blueprint Team Proposed A Network With These Components Data Standards Common way to define shared terms Member Infrastructure Capacity to participate Data Exchange Templates Common way to package shared data Trading Partner Agreement How information flows between partners Exchange Network Components Network Administration Registration, process support, communication Technical Infrastructure Uses standard Internet tools

5. Traditional Web Services Stack Discovery Description UDDI WSDL XML Messaging SOAP, XML TransportHTTP/HTTPS SecuritySSL Universal Description, Discovery and Integration Web Services Description Language Simple Object Access Protocol eXtensible Markup Language Secure Sockets Layer HyperText Transfer Protocol

6. How this stack is adapted for the technical infrastructure of the Network Network Exchange Business Processes What are the high level business processes supported e.g. monthly reporting Flow Configuration Information (including how transactions are configured for system updates) Protocol and Specification WSDL What primitive web services to we share? DET Guidelines How we use XML to format data SOAP How payloads are packaged XML Use XML to format data Network Specificity EN Specific Generic

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

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 RetrievingNotify, Download, Solicit AdministrationNodePing, GetServices InterfaceMethods SendingSubmit, GetStatus QueryingQuery, Execute * Currently under development by EPA/CDX Authenticate, Validate CentralAuth* Security

10. Network/Node Usage Options Business Need Current Approach Network Options Node Operation Automatic request for ad-hoc information Custom software Node to Node, or client to Node Query (Pull) Automated collection of data from multiple peers Multiple Telephone Calls Node to Node interactions Solicit/Query (Pull) Routine Information Sharing with a Peer (especially secured or confirmed) Batch uploads, email, FTP Node to Node, or use of a hosted node. Solicit/Download /Query (Pull) Submit (Push) Periodic/ Occasional Information sharing with a Peer E-mail Attachments, FTP, Website posting NA, unless volume or frequency increases (see below) NA

11.  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. Network Nodes can be used to:

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

13. Node 1.0 Protocol Interoperability Testbeds: Middleware StateMiddleware DE.NET 1.0 MEOracle 9iAS MS.NET 1.0 NHBizTalk Server 2000 NMWebSphere v4.05 NEXAware XA-Suite UTSybase EASserver CDXBEA WebLogic

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 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. 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) 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!