Status on d3 service request beans and parsers refactoring

[Markus Schneider-4]

Fellow core-developers,

as I remember it, it has been discussed for several times now, that the OGC service request beans and XML/KVP adapters
need to be refactored from the d3_services module to the protocol package of the d3_core module.

The primary reasons for this are:

- The security components will need bean representations of the service requests to work on, and maybe re-serialize them
to sent augmented/altered requests to proxied services (OWSProxy mode).
- It can be generally handy to have the possibility to work with service requests outside the deegree service
implementation. A possible use case: read a WMS 1.3 GetMap XML request and sent it out as a WMS 1.1 KVP GetMap request
(yes, I am aware that there are some restrictions, but still)

I think I am also aware of the downsides, most notably: we shouldn't throw OWSExceptions inside the parsers, but more
general ones that are not tied to generating service specific exception reports.

This is the current state for all services. (+ means: beans/adapters are in d3_core not d3_services):

- SOS: -
- WCS: -
- WFS: +
- WMS: -
- WPS: - (only GetCapabilities/DescribeProcess has been moved yet)
- WPVS: -

Although this is not of the highest priority, everybody should remember to refactor his requests/adapters to the
protocol package of d3_core.

Best regards,
Markus

--
Markus Schneider

l a t / l o n  GmbH
Aennchenstrasse 19           53177 Bonn, Germany
phone ++49 [phone]       fax ++49 [phone]
http://www.lat-lon.de        http://www.deegree.org



------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
deegree-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/deegree-devel

[Andreas Schmitz]

Markus Schneider wrote:

Hi,

> as I remember it, it has been discussed for several times now, that the OGC service request beans and XML/KVP adapters
> need to be refactored from the d3_services module to the protocol package of the d3_core module.
>
> The primary reasons for this are:
>
> - The security components will need bean representations of the service requests to work on, and maybe re-serialize them
> to sent augmented/altered requests to proxied services (OWSProxy mode).
> - It can be generally handy to have the possibility to work with service requests outside the deegree service
> implementation. A possible use case: read a WMS 1.3 GetMap XML request and sent it out as a WMS 1.1 KVP GetMap request
> (yes, I am aware that there are some restrictions, but still)
>
> I think I am also aware of the downsides, most notably: we shouldn't throw OWSExceptions inside the parsers, but more
> general ones that are not tied to generating service specific exception reports.
>
> This is the current state for all services. (+ means: beans/adapters are in d3_core not d3_services):
>
> - SOS: -
> - WCS: -
> - WFS: +
> - WMS: -

well, for WMS the situation is not so simple. Parsing the requests
relies on the version specific controller classes, so moving the request
stuff to core means

a) split the version specific controller classes and move some of the
stuff to core (along with the requests itself)
or
b) move the whole version specific controller classes to core (and thus
move service controller specific stuff that has nothing to do with core
functionality)

So I thought as long as nobody really needs this, I'd just leave it as
it is. Especially since no exporting is available yet for WMS request
beans anyway.

BTW: Your use case above (converting an SLD GetMap XML request to a WMS
KVP request) really crosses specifications. WMS does not have XML
requests ;-)

Best regards, Andreas
--
l a t / l o n  GmbH
Aennchenstrasse 19           53177 Bonn, Germany
phone ++49 [phone]      fax ++49 [phone]
http://www.lat-lon.de        http://www.deegree.org


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
deegree-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/deegree-devel

[Markus Schneider-4]

Hi,

Andreas Schmitz wrote:

>> This is the current state for all services. (+ means: beans/adapters are in d3_core not d3_services):
>>
>> - SOS: -
>> - WCS: -
>> - WFS: +
>> - WMS: -
>
> well, for WMS the situation is not so simple. Parsing the requests
> relies on the version specific controller classes, so moving the request
> stuff to core means
>
> a) split the version specific controller classes and move some of the
> stuff to core (along with the requests itself)

In what way? I found that for the WFS it was possible (although a bit cumbersome) to eliminate any dependencies on
controllers or configuration from the request parsers / requests.

Of course, this implies a strict separation of request parsing and resource lookup/context-based validation. E.g. in the
GetFeature request adapters, the typeName attributes cannot be checked against the offered featuretypes, but must be
represented as simple QNames. The lookup if the featuretype really exists must happen in a later stage in the
controller/service in order to make this usable outside the controller context.

So basically the parsing / bean representation boils down to a syntactic analysis that cannot be dependent on any context.

Or am I missing something specific to the WMS here?

> or
> b) move the whole version specific controller classes to core (and thus
> move service controller specific stuff that has nothing to do with core
> functionality)
>
> So I thought as long as nobody really needs this, I'd just leave it as
> it is. Especially since no exporting is available yet for WMS request
> beans anyway.
>
> BTW: Your use case above (converting an SLD GetMap XML request to a WMS
> KVP request) really crosses specifications. WMS does not have XML
> requests ;-)

Oops :-) So does the WMS support any XML requests at all?

Best regards,
Markus

--
Markus Schneider

l a t / l o n  GmbH
Aennchenstrasse 19           53177 Bonn, Germany
phone ++49 [phone]       fax ++49 [phone]
http://www.lat-lon.de        http://www.deegree.org



------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
deegree-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/deegree-devel

[Andreas Schmitz]

Markus Schneider wrote:


Hi,

> >> This is the current state for all services. (+ means: beans/adapters are in d3_core not d3_services):
> >>
> >> - SOS: -
> >> - WCS: -
> >> - WFS: +
> >> - WMS: -
> >
> > well, for WMS the situation is not so simple. Parsing the requests
> > relies on the version specific controller classes, so moving the request
> > stuff to core means
> >
> > a) split the version specific controller classes and move some of the
> > stuff to core (along with the requests itself)
>
> In what way? I found that for the WFS it was possible (although a bit cumbersome) to eliminate any dependencies on
> controllers or configuration from the request parsers / requests.
>
> Of course, this implies a strict separation of request parsing and resource lookup/context-based validation. E.g. in the
> GetFeature request adapters, the typeName attributes cannot be checked against the offered featuretypes, but must be
> represented as simple QNames. The lookup if the featuretype really exists must happen in a later stage in the
> controller/service in order to make this usable outside the controller context.
>
> So basically the parsing / bean representation boils down to a syntactic analysis that cannot be dependent on any context.
>
> Or am I missing something specific to the WMS here?

yes, well, I partly agree with you. The problem I'm having is the
parsing of the bboxes together with the CRS. In order to create version
independent beans, I have to check the axis order for WMS 1.3.0
requests, in order to generate correct Envelope instances. Just doing a
syntactic analysis and storing an array of doubles is not an option for
me ;-)

Of course it would be possible/easy to refactor that out to some common
WMSRequest/-Helper class or so, but as I said, I don't see any benefit
as long as no exporter is available. And since WMS is still under heavy
development, I don't really feel like cleaning up already anyway.

> > BTW: Your use case above (converting an SLD GetMap XML request to a WMS
> > KVP request) really crosses specifications. WMS does not have XML
> > requests ;-)
>
> Oops :-) So does the WMS support any XML requests at all?

Nope. Although I guess that WMS 1.4/2.0 will support all kinds of fancy
encodings ;-)

Best regards, Andreas
--
l a t / l o n  GmbH
Aennchenstrasse 19           53177 Bonn, Germany
phone ++49 [phone]      fax ++49 [phone]
http://www.lat-lon.de        http://www.deegree.org


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
deegree-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/deegree-devel

[Markus Schneider-4]

>> Of course, this implies a strict separation of request parsing and resource lookup/context-based validation. E.g. in the

>> GetFeature request adapters, the typeName attributes cannot be checked against the offered featuretypes, but must be
>> represented as simple QNames. The lookup if the featuretype really exists must happen in a later stage in the
>> controller/service in order to make this usable outside the controller context.
>>
>> So basically the parsing / bean representation boils down to a syntactic analysis that cannot be dependent on any context.
>>
>> Or am I missing something specific to the WMS here?
>
> yes, well, I partly agree with you. The problem I'm having is the
> parsing of the bboxes together with the CRS. In order to create version
> independent beans, I have to check the axis order for WMS 1.3.0
> requests, in order to generate correct Envelope instances. Just doing a
> syntactic analysis and storing an array of doubles is not an option for
> me ;-)
>
> Of course it would be possible/easy to refactor that out to some common
> WMSRequest/-Helper class or so, but as I said, I don't see any benefit
> as long as no exporter is available. And since WMS is still under heavy
> development, I don't really feel like cleaning up already anyway.

Well, as I wrote it's not of very high priority at the moment, but I think it's important to keep in mind, that we must
be able to use the adapters/beans without a context *in the end*. If we cannot do that, then we cannot use them for the
use-cases I pointed out (OWSProxy). And if we cannot use the same classes in services and core, then we will end up
having to re-write adapters/beans for the protocol package...

Base line is that you can do it now or do it later, but every service developer will have to provide adapters/beans at
some point that are usable outside the context of his controller/service.

Best regards,
Markus

--
Markus Schneider

l a t / l o n  GmbH
Aennchenstrasse 19           53177 Bonn, Germany
phone ++49 [phone]       fax ++49 [phone]
http://www.lat-lon.de        http://www.deegree.org



------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
deegree-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/deegree-devel