XML::Compile::WSDL11 - accessing the transport layer

[Mark Overmeer]

* Toby Corkindale (tjc at wintrmute.net) [080414 07:30]:
> > > > my $wsdl = slurp('service.wsdl');
> > > > my $service = XML::Compile::WSDL11->new($wsdl);

> On Fri, Apr 11, 2008 at 10:37:17AM +0200, Mark Overmeer wrote:
> >     my $service = XML::Compile::WSDL11->new('service.wsdl');

> Ah, I'd forgotten. In my real-life case I'm actually pulling the WSDL out
> via a
> configuration stage so as to allow for testing vs production versions, and
> replaced it all with slurp() to simplify the example :)

You can also use a variable with filename or string ;-b

> It might be nice if there was an intermediate stage between the WSDL11() call
> and the $wsdl->compileClient() call, where one could adjust options. I say this
> because it is a pity that compileClient()'s result is a function pointer and
> thus rather immutable.

The basic idea behind "compilation" is that the result is immutable.
When translating a programming-language like thing (like a schema is)
you can translate this into an object tree, to a virtual machine like
thing, or into an other language.

SOAP::WSDL translates into objects.  Disadvantage: lot of run-time
(while message parsing) method call's because you do not know when the
object changes.  Big advantage: easy to debug.

Perl5 use the second approach: compile into nodes which do the work.
The way to get this to work for XML::Compile is the use of closures.
As downsides, Perl5 closures do not support introspection...

The third way is used by Perl6 and Java: they generate some other
(binary?) language, which on its own is translated into one of these
three options (recusively).  It is possible to write XML::Compile
back-ends which produces Perl in stead of code references (next to
the existing XmlReader, XmlWriter, Template back-ends), however I do
not prefer that.

> my $service = XML::Compile::WSDL11->new($wsdl);
> my $callObj = $service->prepareClient('stock_price');
> my $transport = $callObj->transport;
> ie. This would be useful to me.. and possibly no-one else :)

There are five components in the implementation, which I really like
to keep as separate as possible:  XML, XML-Schemas, SOAP, WSDL, HTTP.
In the general case, you do not need to see more thatn the WSDL
layer, but if you want to interfere with lower-level interfaces, you
only have to create them in "lowest-level first" order.  As I showed
in the previous mail.

The decission about how to connect the various components are made
in the compile routines, not in the object.  It directly results in
closure captured variables which are used in the code reference
returned.  For each compiled client, these decissions can result in
different settings, and therefore it cannot be provided on the
encapsulating object.  I.e., the object which is the result of
prepareClient() will decide differently when the compiled for
SOAP11 or SOAP12...

It is very simple to make all kinds of assumptions about what can be
found in WSDL files in general.  But the situation is really complex
(and badly documented in the specs).

> >    my $http  = $transporter->compileClient(soap => 'SOAP11', ...);
> >    my $call  = $wsdl->compileClient('myport', transport => $http);
> > 
> AH, thanks for the alternates; I'll try those out too, although it seems
> confusing that you're calling compileClient twice in the chain.

One is a transporter client (HTTP, in this case), the other is a soap
client.  Overload of the term "client".  Internally, there are even
more compileClients :(

> I found it tricky to determine that I was allowed to pass the transport
> object through, or that it was even a good idea.
> Might I suggest that XML::Compile::WSDL11's document is modified to mention
> how to pass through transport options, as an example, like the transport_hook
> examples?

There is never sufficient documentation...  Besides, again in the WSDL
case, there are different options depending on the actual transport
protocol being used and the implementation of the transporter.
The text would become very long, too long for the manual page... probably
there should be a FAQ page as well.  The best you get for the moment is in
the example scripts.

It would be nice if there were a mailinglist, because the number of
users grows fast, and now support consumes my development time.
-- 
Regards,

               MarkOv

------------------------------------------------------------------------
       Mark Overmeer MSc                                MARKOV Solutions
       Mark at Overmeer.net                          solutions at overmeer.net
http://Mark.Overmeer.net                   http://solutions.overmeer.net