[Xml-compile] Help with compiling serializers and de-serializers

[Bill Moseley]

On Thu, May 26, 2011 at 5:47 AM, Mark Overmeer <mark at overmeer.net> wrote:

> * Bill Moseley (moseley at hank.org) [110525 13:02]:
> > On Tue, May 24, 2011 at 11:40 PM, Mark Overmeer <mark at overmeer.net>
> wrote:
> > Still needs work and docs.  And I'm sure there's code that could be done
> > more efficiently (suggestions welcome).
> >
> > Here's the controller Role:
> >    http://hank.org/CatalystX/TraitFor/Controller/SOAP.pm
>
> Taaadaaa... merging fake Perl (Moose) and real Perl OO does complicate
> things.
>

We should not debate Moose here.  I've used a number of class building tools
and used to use Rose::Object extensively.  But, once I started using Moose
(and understood it better) it's really quite nice.  Just have to close your
eyes and survive the installation/upgrade issues at times.  The danger, of
course, is that after using it for a while everything starts looking like a
Job for Moose... ;)



>
> As your question was already answered in my previous email: there
> is no need for you to produce low-level faults. It is already there
> and tested. Method XML::Compile::Daemon::process() handles all
> errors on XML level.  On the transport level, you cannot reply with
> XML so you do not need your soap_fault().
>

Ok, It was not clear to me when to return a fault vs. just a text/plain
message with a non-200 status.

XML::Compile::SOAP::Daemon::CGI always returns content-type text/xml but
sometimes the $xmlout is not XML.  For example:

sub faultInvalidXML($)
{   my ($self, $error) =3D @_;
    ( RC_UNPROCESSABLE_ENTITY, 'XML syntax error'
    , __x("The XML cannot be parsed: {error}", error =3D> $error));
}


Which is called when the body cannot be parsed by XML::LibXML.  That makes
sense, that just a client err.


This case is less clear to me:

     my $proto  =3D XML::Compile::SOAP::Operation->fromEnvelope($envns)
        or return $self->faultUnsupportedSoapVersion($envns);

which calls:

sub faultUnsupportedSoapVersion($)
{   my ($self, $envns) =3D @_;
    ( RC_NOT_IMPLEMENTED, 'SOAP version not supported'
    , __x("The soap version `{envns}' is not supported", envns =3D> $envns)=
);
}

I'm not sure what fromEnvelope() does -- I failed to find the docs on that
method -- but that's after the request was parsed and, I assume, checks the
name space.  Would it not be appropriate to return a SOAP fault in that
case?

http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383510 has
"VersionMismatch".



> process() will call the handler for you, so there is no need for your
> code to produce these errors.  Sometimes SOAPAction is used, maybe
> WSA is used, etc.  Do not try to be smarter ;-)
>

Well, as you saw, I'm not using XML::Compile::SOAP::Daemon.  I tried
subclassing at first but ran into a few issues -- and I think it was
Log::Report that was causing the most headache while trying to make the code
work within Catalyst.


>
> If you accidentally do have a SOAPAction in your transport protocol,
> then pass it as fourth parameter to process().  But it may be undef
> and still work ;-)  According to the SOAP "specification", the
> SOAPAction is only for proxies to be able to route. The selection
> of the handler should be based on the name of the body elements.
> (Very poor design: that can be very expensive to discover)
>

I think my WDSL is the "wrapped" style of document/literal -- which I
thought used the SOAPAction header (incorrectly) for determining the
operation.


>
> > What would you write for that soap_fault method to have it build
> > a SOAP XML fault response?
>
> In stead of returning structural values to have XML produced for you,
> you can also always provide a fully prepared XML::LibXML::Element node.
>

Ok.  I was not clear at what point to return a soap fault response vs. just
a non-200 text/plain "something broke" response.  I assumed most of the time
would want to respond with a fault.

As for building the fault using XML::LibXML I assumed that XML::Compile was
doing that anyway (on invalid callback response), so I thought there might
be an existing method I could use to build my own faults directly.  It's not
hard to build the XML response, but wanted to use existing code in
XML::Compile, if I could.

Thanks again for all your time.


-- =

Bill Moseley
moseley at hank.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/xml-compile/attachments/20110526/ea=
5b9e63/attachment.htm