Node Lessons Learned James Hudson Wisconsin Department of Natural Resources

Hudson, 3/1/ Nodes Evolve Phase 1: Getting the Node Working Phase 1: Getting the Node Working Done Phase 2: Making Data Flow Phase 2: Making Data Flow Done Phase 3: Current Phase 3: Current –Reproducible Implementation of Multiple Flows –Incoming Data Flows –Node Management and Administration Phase 4: Future Phase 4: Future –New Standards (attachments, authentication, WSDL changes, BPEL and orchestration) –New Technology (Enterprise Service Bus, etc.)

Hudson, 3/1/ Wisconsin’s Perspective We were Not in the Beta or in Node 1.0 We were Not in the Beta or in Node 1.0 “Early Adopter,” right after those states “Early Adopter,” right after those states Built our own node (there were no DNCs) Built our own node (there were no DNCs) Built our own FRS flow (no FCDs) Built our own FRS flow (no FCDs) Continue to enhance our processing Continue to enhance our processing The node is for our agency and state The node is key technology for our agency and state

Hudson, 3/1/ Challenges Node Management Node Management Environment Changes Environment Changes Designing for a Reproducible Process Designing for a Reproducible Process Being able to implement necessary changes Being able to implement necessary changes Who has the correct data? Who has the correct data?

Hudson, 3/1/ The Node Management Challenge The Node Specification describes the Web Services The Node Specification describes the Web Services The Flow Configurations and schemas describe the Data and Requests The Flow Configurations and schemas describe the Data and Requests But there is no standard for what information to store about your node But there is no standard for what information to store about your node Or how to manage that node Or how to manage that node Solution so far Solution so far –We built our own tools, as have others Can this be Standardized? Can this be Standardized?

Hudson, 3/1/ The Environment Challenge So far, Wisconsin has been through 2 version changes in the Oracle Application Server So far, Wisconsin has been through 2 version changes in the Oracle Application Server We’re moving to Websphere since that seems to be the enterprise choice for the state, and will give us a better service level agreement We’re moving to Websphere since that seems to be the enterprise choice for the state, and will give us a better service level agreement Any change in environment takes time and effort and can get in the way of other work Any change in environment takes time and effort and can get in the way of other work Solution: invest the time Solution: invest the time

Hudson, 3/1/ The New Flows Challenge We have a stable node We have a stable node We want to implement at least 8 flows in the next 2 years. And possibly up to 25. We want to implement at least 8 flows in the next 2 years. And possibly up to 25. How do we make those flows easy to build, easy to change, and high performance? How do we make those flows easy to build, easy to change, and high performance? Our strength is the database Our strength is the database –Data is there already –So are our skills –And our processing horsepower

Hudson, 3/1/ Wisconsin’s Version 1: Java –Configured Node using XML files –Logged to files on the Application Server –HTTP and SSL on the App Server –Used a utility in Java to query Oracle and extract the XML –Converted relational to XML in Java –XSLT in Java –Schema Validation in Java –ZIP in Java –DIME in Java

Hudson, 3/1/ What We Learned from Version 1 Application Server was hard for our staff to administer Application Server was hard for our staff to administer Java performance was slow and required too much memory for large operations (XSLT on 100MB of XML, for example) Java performance was slow and required too much memory for large operations (XSLT on 100MB of XML, for example) Needed Expert Java Developers Needed Expert Java Developers New flows, especially incoming flows, would require writing too much code New flows, especially incoming flows, would require writing too much code

Hudson, 3/1/ Wisconsin’s Version 3 Node functions still in Java Node functions still in Java –Configuration and logging stored in Oracle –SOAP, ZIP, DIME all in Java –May move most validation to CDX’s web services, based on the presentation yesterday Flows nearly all in Oracle Flows nearly all in Oracle –Java program stores the Request and calls a database package –Results come back to the Java program for packaging and shipping (header still built in Java, for now)

Hudson, 3/1/ How Does the Flow Work? For each new flow: For each new flow: –Convert Schema to Oracle Types –Map to existing database tables by Object-Relational Views (the hard part) We use database built-ins to We use database built-ins to –run query and convert to an XML document –parse using Document Object Model –XSLT –store the results

Hudson, 3/1/ What Does This Gain Us? Performance: FRS Solicit, consolidated schema, 40,000 facilities: Performance: FRS Solicit, consolidated schema, 40,000 facilities: 3.5 hours on production server with version hours on production server with version 1 25 minutes on development server, version 2 25 minutes on development server, version 2 Standard Steps for building a new flow Standard Steps for building a new flow Less need to Redeploy the Java app Less need to Redeploy the Java app Better skills match Better skills match Better able to handle two-way flows Better able to handle two-way flows Less dependent on the application servers Less dependent on the application servers

Hudson, 3/1/ “What Data is Best?” Challenge This has been an issue since states started reporting to EPA This has been an issue since states started reporting to EPA –Can users trust the national data? –Can they trust the state date? –How can they tell why the data are different? With the Exchange Network, we may be able to finally deal with this problem With the Exchange Network, we may be able to finally deal with this problem

Hudson, 3/1/ Traditional Flows EPA Wis

Hudson, 3/1/ Using the Network EPA Wis

Hudson, 3/1/ Flows Using the Network Can be just traditional stovepipes Can be just traditional stovepipes But EPA and the States have also tried to integrate information But EPA and the States have also tried to integrate information So that makes it more complex So that makes it more complex Example: Example: –EPA FRS brings together Facility Information –So does Wisconsin Site Register, which we also use for fee billing

Hudson, 3/1/ Flows With Aggregators EPA Wis

Hudson, 3/1/ Example of Inconsistency WI Air changes facility name 1/1/2006 WI Air changes facility name 1/1/2006 WI WW changes facility name 1/15/2006 WI WW changes facility name 1/15/2006 WI ESR accepts the WW change as our enterprise data, 1/20/2006 WI ESR accepts the WW change as our enterprise data, 1/20/2006 WI Node processes solicit from CDX for all changes 2/1/2006 WI Node processes solicit from CDX for all changes 2/1/2006 WW reports to PCS 3/15/2006 WW reports to PCS 3/15/2006 Air report to NEI 9/1/2006 Air report to NEI 9/1/2006 What data should FRS show, and when? What data should FRS show, and when?

Hudson, 3/1/ So Who’s Right? Everybody? Everybody? Nobody? Nobody? The Network should, over time, allow us to resolve that question The Network should, over time, allow us to resolve that question –Less need for copies of data away from the original source –Much less need to edit/clean data after it leaves the original source –Two way processing, where States receive changes made by EPA and vice versa

Hudson, 3/1/ Final Comments The technology is getting much more stable The technology is getting much more stable We’re dealing with data issues, like multi- agency consistency, that we could never address before We’re dealing with data issues, like multi- agency consistency, that we could never address before It won’t be cheap or routine for a while, and you’ll need programmers/contractors It won’t be cheap or routine for a while, and you’ll need programmers/contractors But we’re making a difference But we’re making a difference