Open Standards based for Web Services and Spatial
Some of the services that have been standardized
– location services (routing, mapping, geocoding, directory services)
– catalogue services (discovery, browse, and query against catalog servers)
– map services (request/provide maps and info about the content of a map)
requirements
– access/search/update/delete geo-spatial feature
– access/update securely
– manage feature privs at an instance level
– real-time fransfer of feature instance using standards
approach
– use SOAP for request/response
– XML over HTTP Post method for request/response
– Spatial for feature instance storage/retrieval
– implement OGC filter specification for feature search
– use WSS/LDAP for auth, row level security for instance-level priv mgmt and WSS for secure transfer of feature data
– support publishing feature types from database data source (complex comumns, netsted table, XML types)
– support publishing feature types from external data sources
– implement token based locking to support WFS locking protocol to support long transaction model to artificially lock rows in the database
– implement feature cache in middle tier to reduce spatial data xfer from DB to App server
WFS Operations
– get capabilities
– describe feature
– transactional – getfeaturewithlock
– lockfeature
– insert, update, delete
the transaction and locking can span sessions. The only way to unlock this is through the WFS handler which is integrated into the OC4J/J2EE container. There is an expiration time that is default or specified by the client just in case the client goes away for a long time. This is done with triggers on tables/views to make sure that it is properly locked and the same client comes back with the proper token.
WFS Metadata
– feature types, type tags, type attributes
– complex types
– spatial operators
there are two data sources that are supported – relational data type – PLSQL API and Java API done through XSD data types. The Java API is typically used to register feature types and feature type metadata
There two use cases – type supplier and type consumer
fully compliant with the WFS 1.0 spec
auth is done client -> oc4j using SOAP/WSS. We then use standard oc4j connections to connect to the database. This allows the use of VPD and user views on top of the database.
demo using OEM for App Server to configure the server. We define an application and deploy it using the application administration. When we define the app we also define the security service and the data sources. In this example we use a WFS connection. We also create a web service with the certificate and signature key definitions for security.
the client side is developed using JDeveloper. The feature type/app comes from an xml description of the spatial data type. We create an empty project, add a web server proxy using the WSDL file defined by the spatial service. At this point we have a non-secure connection and need to secure the connection. We go to the proxy and edit the security parameters. In this example we use a digest with no encryption (for demo purposes only) and a public keystore and private key of the client and server. At this point we have a secure proxy and just need a password for the signature key alias. To debug this exchange we run the http analyzer in JDeveloper so that we can see the request coming from the client and the answer from the server.
At this point we have some content that we wanted to publish. We define a JDeveloper client and link the security to that of the server security policies. We then ran a test to look at the connection and verify that it is working properly. At this point we can encrypt the data and turn off the html debugger.
The second demo is to use a relational connection to the data. To do this we use the map builder to load data and push our data into the spatial database. We do this by connecting to the WSL service and looking up the interfaces that we can use. We connect and look at the features, select a spatial column (GEOM) and correlate some element in the data (State Name) to the map. At this point we can create a query and return the map data with the state name placed into the state that the query finds.
OpenLS is a translation service that is done on the back end. This operates as expected according to the standard.
Catalog Services are a little more complex. The catalog request can be spatial or relational in nature. The catalog service server returns metadata associated with the item in question. To implement this it uses SOAP for request/response and XML over HTTP Post method for request/response. The difference is that ResultSet caching will be support to retrieve records from a single query across different web locations. This allows the user to scroll through related material that is close to the search object returned. The cache returned is currently not tunable and is handled by the server. Future releases will give hints to the cache service on what to populate.
web map service supports getcapabilities, getmap, and getfeatureinfo
this was an information packed presentation with lots of technical data. I recommend that you download the presentation once it is available. Unfortunately the best part of it was the demo which was a live demo of developing with JDeveloper and MapViewer.