Download Slide 1

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Computer network wikipedia , lookup

Cracking of wireless networks wikipedia , lookup

Distributed operating system wikipedia , lookup

Computer security wikipedia , lookup

Zero-configuration networking wikipedia , lookup

IEEE 802.1aq wikipedia , lookup

Network tap wikipedia , lookup

Recursive InterNetwork Architecture (RINA) wikipedia , lookup

CAN bus wikipedia , lookup

Peer-to-peer wikipedia , lookup

Kademlia wikipedia , lookup

Airborne Networking wikipedia , lookup

Service-oriented architecture implementation framework wikipedia , lookup

Transcript
Data Exchange through XML
Environmental Information
Exchange Network
www.exchangenetwork.net
May 21, 2003
Louis Sweeny
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.
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
Blueprint Team Proposed A
Network With These Components
Network
Administration
Registration, process
support,
communication
Data Standards
Common way to define
shared terms
Technical
Infrastructure
Uses standard
Internet tools
Exchange
Network
Components
Member Infrastructure
Capacity to participate
Data Exchange
Templates
Common way to
package shared data
Trading Partner
Agreement
How information flows
between partners
Traditional Web Services Stack
Discovery
Description
UDDI
WSDL
XML
Messaging
SOAP, XML
Transport
HTTP/HTTPS
Universal Description, Discovery
and Integration
Web Services Description
Language
eXtensible Markup Language
Simple Object Access Protocol
HyperText Transfer Protocol
Security
SSL
Secure Sockets Layer
How this stack is adapted for the
technical infrastructure of the
Network
Network Exchange Business Processes
EN Specific
What are the high level business processes supported e.g. monthly reporting
Flow Configuration Information
Protocol and
Specification WSDL
DET Guidelines
What primitive web services to we share?
How we use XML to format data
SOAP
How payloads are packaged
XML
Use XML to format data
Network Specificity
(including how transactions are configured for system updates)
Generic
Network Overview and
Infrastructure
Registry
NAAS
Information System
WA Information
System
Internet
Schema based
payload
Schema based
payload
Node
Node
Protocol
&
Specification
DET/Schema
Guidelines
Information
Consumer
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.
Protocol Establishes 11 Network
Methods
Interface
Methods
Administration
NodePing, GetServices
Security
Authenticate, Validate
CentralAuth*
Querying
Query, Execute
Sending
Submit, GetStatus
Retrieving
Notify, Download, Solicit
* Currently under development by EPA/CDX
Network/Node Usage Options
Network
Options
Node Operation
E-mail
Periodic/ Occasional
Attachments,
Information sharing with
FTP, Website
a Peer
posting
NA, unless volume
or frequency
increases (see
below)
NA
Routine Information
Sharing with a Peer
(especially secured or
confirmed)
Node to Node, or
use of a hosted
node.
Business Need
Automatic request for
ad-hoc information
Automated collection of
data from multiple peers
Current
Approach
Batch uploads,
email, FTP
Solicit/Download
/Query (Pull)
Submit (Push)
Custom
software
Node to Node, or
client to Node
Query (Pull)
Multiple
Telephone Calls
Node to Node
interactions
Solicit/Query (Pull)
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.
Putting it all Together in an
Exchange: GetFacilityByID
Requestor
NAAS
Provider
Authenticate(userId, credential
authMethod)
security
Token()
GetFacilityByID (securityToken, parameters – State: WA,
State Facility ID: 12345)
GetFacilityByIDResponse()
Facility Information
Node 1.0 Protocol Interoperability
Testbeds: Middleware
State
Middleware
DE
.NET 1.0
ME
Oracle 9iAS
MS
.NET 1.0
NH
BizTalk Server 2000
NM
WebSphere v4.05
NE
XAware XA-Suite
UT
Sybase EASserver
CDX
BEA WebLogic
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)
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 “semiautomated”, moving these to fully automated
requires addressing many additional
details/refinements.
Web Services as a Metaphor for CrossOrganizational Collaboration


The web services metaphor, roles and responsibilities
are as important to an effort like this as the technology
Provides a framework for collaboration


Provides cleaner separation of what is behind and in front
of the firewall


More useful than “cooperate” or “build inter-operable systems”
or “use standards” or all the other euphemisms we use.
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
For More Information
Environmental Exchange Network
www.exchangenetwork.net
Justice XML Initiatives
http://it.ojp.gov/topic.jsp?topic_id=43
Shameless plug: