Opened 5 years ago

Closed 4 years ago

#270 closed enhancement (duplicate)

Deprecate old servlets in petascope

Reported by: dmisev Owned by: dmisev
Priority: critical Milestone: 9.0
Component: petascope Version: 8.3
Keywords: Cc: pbaumann, pcampalani, abeccati
Complexity: Medium

Description

It's easiest if we maintain one endpoint = /petascope

That means we should check if the other endpoints offer any extra functionality not present at /petascope and integrate them into this one. Then we can announce that /petascope/wcps, /petascope/wcs2, etc. are deprecated and no longer maintained.

Change History (11)

comment:1 Changed 5 years ago by pbaumann

that new unified endpoint should not be named "petascope", but "rasdaman" or something else not so confusing for users.

comment:2 Changed 5 years ago by dmisev

it's not a new unified endpoint, it's what is mostly used now and which already integrates all the functionality. We just need to check for anything missing.

comment:3 Changed 5 years ago by pcampalani

WMS has its own entry point /petascope/wms? as well.
The only matter I see to a unified entry point is that we should make sure that any protocol request is identifiable.
The service value would be used to discern a WCS from a WMS request, some other trick can be used to discern a WCPS incoming request, but there's surely a robust way.

What is currently done is :

  • parse incoming URL;
    • if there is a service key-value pair, then handle in WCS;
    • otherwise, try to parse WCPS paramters;
  • if it fails && there is a body, then parse the body and check the root element;
    • if root = Envelope then is WCS2;
    • if root = ProcessCoveragesRequest then is WCPS;
    • if root = Transaction then is WCS-T;

[from src/main/java/petascope/PetascopeInterface.java]

(PetascopeInterface is quite a mess right now anyway, at some point we might also create new classes in the petascope package to multiplex the request into the different allowed protocols)

Finally, currently available servlets are:

$ cat petascope/src/main/webapp/WEB-INF/web.xml
[...]
    <servlet-mapping>
        <servlet-name>PetaScope Interface</servlet-name>
        <url-pattern>/*</url-pattern>
    </servlet-mapping>
    <servlet-mapping>
        <servlet-name>wcpsServlet</servlet-name>
        <url-pattern>/wcps</url-pattern>
    </servlet-mapping>
    <servlet-mapping>
        <servlet-name>wcstServlet</servlet-name>
        <url-pattern>/wcst</url-pattern>
    </servlet-mapping>
    <servlet-mapping>
        <servlet-name>Wcs2Servlet</servlet-name>
        <url-pattern>/wcs2</url-pattern>
    </servlet-mapping>
    <servlet-mapping>
        <servlet-name>WmsServlet</servlet-name>
        <url-pattern>/wms</url-pattern>
    </servlet-mapping>

comment:4 Changed 5 years ago by abeccati

I'd say to keep endpoints for broad categories, since we are also going to add a new servlet for direct Rasdaman query which is not compatible with coverage service servlets. It could be better to keep an endpoint for coverage services if they have to be unified.

/coverages : serving WCS, WCPS and WCS-T (WPS to be exmined but I'd say it has its own interface root that is different from covs)
/rasdaman : direct rasql
/maps : serving wms (leaving room for other map services)

Common utils like URL decoding should be left to helper classes. draft Dev guide updated

comment:5 Changed 5 years ago by abeccati

The root servlet / should provide an overview of the service instance itself and point to the other endpoints available and services offered.

comment:6 Changed 5 years ago by pbaumann

Agreed that we need a new categorization, but these are three different levels:

  • coverages: a special category of geo data structures
  • rasdaman: a DBMS
  • maps: a special category of geo data structures, but along a different classification

Let's seek to find a proper distinction, then I'm all for it.

comment:7 Changed 5 years ago by abeccati

Probably its better to keep petascope clean of other levels then and let it only implement OGC WebService? interfaces. For rasdaman over web we can go with a different application with its own war and endpoint.
In that way we have a consistent addressing of services (via the service parameter) and can indeed have the single /petascope endpoint.
The existing endpoints can be handled with redirects then.

comment:8 Changed 5 years ago by abeccati

  • Milestone set to 9.0

comment:9 Changed 4 years ago by abeccati

  • Priority changed from major to critical

comment:10 Changed 4 years ago by pbaumann

the service interface should be uniform and with a name of rasdaman (not petascope, that's confusing). We plan to do this in forthcoming version 9.0.

comment:11 Changed 4 years ago by abeccati

  • Complexity set to Medium
  • Resolution set to duplicate
  • Status changed from new to closed

In the end we chose to have separate endpoint but keep the levels, see #307 for further detail.
Resolving as duplicate = superseded

Note: See TracTickets for help on using tickets.