Loading ...
Sorry, an error occurred while loading the content.

WSDL generation

Expand Messages
  • Mike Schroeder
    Is anyone interested in collaborating on improving WSDL generation in SOAP::Lite? Since Perl is dynamically typed, it makes a great SOAP client, but is kind of
    Message 1 of 8 , Nov 9, 2004
    • 0 Attachment
      Is anyone interested in collaborating on improving WSDL generation in
      SOAP::Lite?

      Since Perl is dynamically typed, it makes a great SOAP client, but is
      kind of a pain as a SOAP server. As far as I can tell, to consistently
      generate a WSDL, we need some extra metadata that can not be easily
      discerned just from inspecting the code. The question is where to store
      that metadata.

      The idea I've been looking at is to embed YAML-based metadata in POD
      inside a module. Our company already does this for embedded YAML-based
      test definitions, and we can easily adapt it to defining the data needed
      for a WSDL. The issue for me is that I don't know enough about WSDLs to
      do this by myself. If someone could help me with defining what
      information is needed, and how to apply that information to a template,
      I think the rest is already in place.

      Here is an example of what I am thinking.

      1) In your module called by the handler(), you would have some POD that
      contains a YAML-based definition of your method (this example is loosely
      based on WSDL sample from the WSDL chapter in the O'Reilly Web Services
      with Perl book - my apologies for butchering it):

      <start sample of embedded YAML-based WSDL specs>

      =head2 GetBook()

      =begin wsdl_spec

      - method: GetBook
      action: WishListCustomer
      arguments:
      - isbn: string
      returns:
      BookData:
      isbn: string
      title: string
      url: anyURI
      service:
      location: http://localhost:9000

      =end wsdl_spec

      sub some_method {

      # your actual code here

      }
      <end sample of embedded YAML-based WSDL specs>

      2) we add a custom POD parser to SOAP::Lite based on Pod::Parser that
      can extract the YAML-spec and return the XML. Ideally, something could
      be done on handler() that checks for a WSDL request (looks for a "wsdl"
      ending?) and automagically calls the new WSDL method and returns the
      requested WDSL data rather than calling the given method. This would
      look *something* like:

      my $parser = new MyParser(); # subclassed from Pod::Parser
      $parser->parse_from_file( $filename );

      # let YAML convert to a Perl structure
      my $wsdl = Load $parser->{wsdl_spec};

      # apply the Perl struct to some template
      return generate_wsdl_from_specs( $wsdl); # where I need help

      The $wsdl variable should contain a ref to this structure:

      $VAR1 = [
      {
      'arguments' => [
      {
      'isbn' => 'string'
      }
      ],
      'action' => 'WishListCustomer',
      'service' => {
      'location' => 'http://localhost:9000'
      },
      'method' => 'GetBook',
      'returns' => {
      'BookData' => {
      'url' => 'anyURI',
      'title' => 'string',
      'isbn' => 'string'
      }
      }
      }
      ];

      From that, using some templating tool or *something* we should be able
      to generate a compliant WSDL.

      If I am way off in left field, or this idea is fatally flawed, please
      let me know.

      Thanks in advance to wiser folks than me for any feedback...

      Mike.
    • Issac Goldstand
      I would also take a look at ActiveState s old PerlEx implementation. In their WebServices implementation, they defined something called a UIS (Universal
      Message 2 of 8 , Nov 9, 2004
      • 0 Attachment
        I would also take a look at ActiveState's old PerlEx implementation. In
        their WebServices implementation, they defined something called a "UIS
        (Universal Interface Specification)" which is a simpler (and possibly less
        mature) idea of what you've written below...

        As PerlEx has been discontinued, it may be hard to get the source modules
        (ActiveState has discontinued the project, so it may be easier to get a copy
        of their old libraries - if not, I have a licensed copy sitting by me and
        can try to work out a legal way to use it)

        Anyway, you can still see the old documentation. A good place to start
        might be
        http://aspn.activestate.com/ASPN/docs/PerlEx/WebServices.html

        Issac

        ----- Original Message -----
        From: "Mike Schroeder" <MikeSchroeder@...>
        To: <soaplite@yahoogroups.com>
        Sent: Tuesday, November 09, 2004 9:38 PM
        Subject: [soaplite] WSDL generation


        >
        > Is anyone interested in collaborating on improving WSDL generation in
        > SOAP::Lite?
        >
        > Since Perl is dynamically typed, it makes a great SOAP client, but is
        > kind of a pain as a SOAP server. As far as I can tell, to consistently
        > generate a WSDL, we need some extra metadata that can not be easily
        > discerned just from inspecting the code. The question is where to store
        > that metadata.
        >
        > The idea I've been looking at is to embed YAML-based metadata in POD
        > inside a module. Our company already does this for embedded YAML-based
        > test definitions, and we can easily adapt it to defining the data needed
        > for a WSDL. The issue for me is that I don't know enough about WSDLs to
        > do this by myself. If someone could help me with defining what
        > information is needed, and how to apply that information to a template,
        > I think the rest is already in place.
        >
        > Here is an example of what I am thinking.
        >
        > 1) In your module called by the handler(), you would have some POD that
        > contains a YAML-based definition of your method (this example is loosely
        > based on WSDL sample from the WSDL chapter in the O'Reilly Web Services
        > with Perl book - my apologies for butchering it):
        >
        > <start sample of embedded YAML-based WSDL specs>
        >
        > =head2 GetBook()
        >
        > =begin wsdl_spec
        >
        > - method: GetBook
        > action: WishListCustomer
        > arguments:
        > - isbn: string
        > returns:
        > BookData:
        > isbn: string
        > title: string
        > url: anyURI
        > service:
        > location: http://localhost:9000
        >
        > =end wsdl_spec
        >
        > sub some_method {
        >
        > # your actual code here
        >
        > }
        > <end sample of embedded YAML-based WSDL specs>
        >
        > 2) we add a custom POD parser to SOAP::Lite based on Pod::Parser that
        > can extract the YAML-spec and return the XML. Ideally, something could
        > be done on handler() that checks for a WSDL request (looks for a "wsdl"
        > ending?) and automagically calls the new WSDL method and returns the
        > requested WDSL data rather than calling the given method. This would
        > look *something* like:
        >
        > my $parser = new MyParser(); # subclassed from Pod::Parser
        > $parser->parse_from_file( $filename );
        >
        > # let YAML convert to a Perl structure
        > my $wsdl = Load $parser->{wsdl_spec};
        >
        > # apply the Perl struct to some template
        > return generate_wsdl_from_specs( $wsdl); # where I need help
        >
        > The $wsdl variable should contain a ref to this structure:
        >
        > $VAR1 = [
        > {
        > 'arguments' => [
        > {
        > 'isbn' => 'string'
        > }
        > ],
        > 'action' => 'WishListCustomer',
        > 'service' => {
        > 'location' => 'http://localhost:9000'
        > },
        > 'method' => 'GetBook',
        > 'returns' => {
        > 'BookData' => {
        > 'url' => 'anyURI',
        > 'title' => 'string',
        > 'isbn' => 'string'
        > }
        > }
        > }
        > ];
        >
        > From that, using some templating tool or *something* we should be able
        > to generate a compliant WSDL.
        >
        > If I am way off in left field, or this idea is fatally flawed, please
        > let me know.
        >
        > Thanks in advance to wiser folks than me for any feedback...
        >
        > Mike.
        >
        >
        >
        >
        >
        >
        >
        > Yahoo! Groups Links
        >
        >
        >
        >
        >
        >
        >
      • Byrne Reese
        Your understanding of the problem is spot on. In fact, implementing just what you have specified would be a HUGE leap and would lay the ground work for the
        Message 3 of 8 , Nov 11, 2004
        • 0 Attachment
          Your understanding of the problem is spot on. In fact, implementing just
          what you have specified would be a HUGE leap and would lay the ground
          work for the complete implementation. The YAML parser, and basic WSDL
          generation is the hard part. The rest are just details.

          The only thing missing is how complex types are defined, and how to
          address SOAP encoding vs. Literal encoding styles.

          I might suggest a mean for someone to declare an empty hash containing
          all the element names (no support for attributes to start with) and
          there parent/child relationships. One could easily crawl a HASH to
          generate a complex type. All you would need to do is have somewhere in
          your YAML to say "find the structure of COMPLEXTYPENAME in the hash
          called $HASHVARNAME. Of course that is just an idea. Think along the
          lines of:

          =begin wsdl_spec

          - complextypes:
          namespace: someURI
          name: Contact
          hashref: $VARNAME

          =end wsdl_spec

          $VARNAME = { foo => {
          bar => '123'
          },
          baz => 'abc'
          };

          Thoughts?

          Mike Schroeder wrote:

          > Is anyone interested in collaborating on improving WSDL generation in
          > SOAP::Lite?
          >
          > Since Perl is dynamically typed, it makes a great SOAP client, but is
          > kind of a pain as a SOAP server. As far as I can tell, to consistently
          > generate a WSDL, we need some extra metadata that can not be easily
          > discerned just from inspecting the code. The question is where to store
          > that metadata.
          >
          > The idea I've been looking at is to embed YAML-based metadata in POD
          > inside a module. Our company already does this for embedded YAML-based
          > test definitions, and we can easily adapt it to defining the data needed
          > for a WSDL. The issue for me is that I don't know enough about WSDLs to
          > do this by myself. If someone could help me with defining what
          > information is needed, and how to apply that information to a template,
          > I think the rest is already in place.
          >
          > Here is an example of what I am thinking.
          >
          > 1) In your module called by the handler(), you would have some POD that
          > contains a YAML-based definition of your method (this example is loosely
          > based on WSDL sample from the WSDL chapter in the O'Reilly Web Services
          > with Perl book - my apologies for butchering it):
          >
          > <start sample of embedded YAML-based WSDL specs>
          >
          > =head2 GetBook()
          >
          > =begin wsdl_spec
          >
          > - method: GetBook
          > action: WishListCustomer
          > arguments:
          > - isbn: string
          > returns:
          > BookData:
          > isbn: string
          > title: string
          > url: anyURI
          > service:
          > location: http://localhost:9000
          >
          > =end wsdl_spec
          >
          > sub some_method {
          >
          > # your actual code here
          >
          > }
          > <end sample of embedded YAML-based WSDL specs>
          >
          > 2) we add a custom POD parser to SOAP::Lite based on Pod::Parser that
          > can extract the YAML-spec and return the XML. Ideally, something could
          > be done on handler() that checks for a WSDL request (looks for a "wsdl"
          > ending?) and automagically calls the new WSDL method and returns the
          > requested WDSL data rather than calling the given method. This would
          > look *something* like:
          >
          > my $parser = new MyParser(); # subclassed from Pod::Parser
          > $parser->parse_from_file( $filename );
          >
          > # let YAML convert to a Perl structure
          > my $wsdl = Load $parser->{wsdl_spec};
          >
          > # apply the Perl struct to some template
          > return generate_wsdl_from_specs( $wsdl); # where I need help
          >
          > The $wsdl variable should contain a ref to this structure:
          >
          > $VAR1 = [
          > {
          > 'arguments' => [
          > {
          > 'isbn' => 'string'
          > }
          > ],
          > 'action' => 'WishListCustomer',
          > 'service' => {
          > 'location' => 'http://localhost:9000' <http://localhost:9000%27>
          > },
          > 'method' => 'GetBook',
          > 'returns' => {
          > 'BookData' => {
          > 'url' => 'anyURI',
          > 'title' => 'string',
          > 'isbn' => 'string'
          > }
          > }
          > }
          > ];
          >
          > From that, using some templating tool or *something* we should be able
          > to generate a compliant WSDL.
          >
          > If I am way off in left field, or this idea is fatally flawed, please
          > let me know.
          >
          > Thanks in advance to wiser folks than me for any feedback...
          >
          > Mike.
          >
          >
          >
          >
          > *Yahoo! Groups Sponsor*
          > ADVERTISEMENT
          > click here
          > <http://us.ard.yahoo.com/SIG=129qq89ce/M=294855.5468653.6549235.3001176/D=groups/S=1705701014:HM/EXP=1100115486/A=2376776/R=0/SIG=11ldm1jvc/*http://promotions.yahoo.com/ydomains2004/index.html>
          >
          >
          >
          > ------------------------------------------------------------------------
          > *Yahoo! Groups Links*
          >
          > * To visit your group on the web, go to:
          > http://groups.yahoo.com/group/soaplite/
          >
          > * To unsubscribe from this group, send an email to:
          > soaplite-unsubscribe@yahoogroups.com
          > <mailto:soaplite-unsubscribe@yahoogroups.com?subject=Unsubscribe>
          >
          > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
          > Service <http://docs.yahoo.com/info/terms/>.
          >
          >
        • Mike Schroeder
          ... Great! for the YAML parser is simple, and I ve *started* on the WSDL generation. For me, the rest is the hard part -- sounds like a good partnership! ;)
          Message 4 of 8 , Nov 12, 2004
          • 0 Attachment
            Byrne Reese wrote:

            > Your understanding of the problem is spot on. In fact, implementing
            > just what you have specified would be a HUGE leap and would lay the
            > ground work for the complete implementation. The YAML parser, and
            > basic WSDL generation is the hard part. The rest are just details.

            Great! for the YAML parser is simple, and I've *started* on the WSDL
            generation. For me, the rest is the hard part -- sounds like a good
            partnership! ;)

            >
            > The only thing missing is how complex types are defined, and how to
            > address SOAP encoding vs. Literal encoding styles.
            >
            > I might suggest a mean for someone to declare an empty hash containing
            > all the element names (no support for attributes to start with) and
            > there parent/child relationships. One could easily crawl a HASH to
            > generate a complex type. All you would need to do is have somewhere in
            > your YAML to say "find the structure of COMPLEXTYPENAME in the hash
            > called $HASHVARNAME. Of course that is just an idea. Think along the
            > lines of:

            I don't believe this would work with the POD-YAML parser -- it is just
            reading in the file and parsing out the YAML, so in order for it be able
            see current values/structures concurrently might be a trick - I suspect
            it would come down to how the handler script maintained state during a
            WSDL call versus a method call.

            However, the YAML format is quite flexible, so we could store the
            complex types in YAML as well. However, the values would need to be
            static (just in case you were looking for dynamic values). For example:

            =begin wsdl_spec

            - module: WishListCustomer
            method: GetBook
            arguments:
            isbn: string
            returns:
            BookData:
            isbn: string
            title: string
            url: anyURI
            complextype:
            foo:
            bar: 123
            baz: abc
            service:
            location: http://localhost:9000

            =end wsdl_spec

            generates this:

            $VAR1 = [
            {
            'method' => 'GetBook',
            'module' => 'WishListCustomer',
            'service' => {
            'location' => 'http://localhost:9000'
            },
            'arguments' => {
            'isbn' => 'string'
            },
            'returns' => {
            'BookData' => {
            'url' => 'anyURI',
            'isbn' => 'string',
            'title' => 'string',
            'complextype' => {
            'foo' => {

            'baz' => 'abc',

            'bar' => 123
            }
            }
            }
            }
            }
            ];

            So you can make this as complex as you want.

            Alternatively, we might want a YAML structure like this:

            - module: WishListCustomer
            method: GetBook
            arguments:
            isbn: string
            returns:
            BookData:
            isbn: string
            title: string
            url: anyURI
            ComplexReturn: foo
            customtypes:
            foo:
            bar: 123
            baz: abc
            service:
            location: http://localhost:9000

            where we can define some custom types, and then use one of those custom
            types to define the <types> section of the YAML.

            Again, I think the YAML is flexible enough, the key is to:

            a) start with the WSDL spec,
            b) reverse engineer it back to a finite set of variables needed,
            c) create a YAML format the stores that finite set of variables
            d) write an interpolation routine to apply the YAML-specs to generate
            the WSDL.
            e) hook the resulting WSDL generater into the server handler()

            Steps B and E are where I need the most help. Once that is done, the
            WSDL generater is basically something like:

            my $wsdl = Load $wsdl_spec;
            print start_definitions( $wsdl->[0] );
            print types( $wsdl );
            print message( $wsdl );
            print portType( $wsdl );
            print binding( $wsdl );
            print service( $wsdl );
            print end_definitions( $wsdl );

            Another choice to make here is whether to use something like
            Template::Toolkit (just interpolate variables into predefined XML) or to
            use some XML module to generate the actual XML programmatically.

            Thoughts?
          Your message has been successfully submitted and would be delivered to recipients shortly.