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

WSDL generation

Expand Messages
  • JuanCrist�fffffffffff3bal Olivares
    I want to generate a WSDL file from a soaplite web service. How can I do that? Juan C. Olivares __________________________________ Do you Yahoo!? Friends.
    Message 1 of 8 , Jun 12, 2004
    • 0 Attachment
      I want to generate a WSDL file from a soaplite
      web service. How can I do that?

      Juan C. Olivares




      __________________________________
      Do you Yahoo!?
      Friends. Fun. Try the all-new Yahoo! Messenger.
      http://messenger.yahoo.com/
    • Byrne Reese
      Unfortunately, you have to write it yourself. Automagic WSDL generation would best be facilitated by some form of reflection, but Perl has no such notion.
      Message 2 of 8 , Jun 13, 2004
      • 0 Attachment
        Unfortunately, you have to write it yourself.

        Automagic WSDL generation would best be facilitated by some form of
        reflection, but Perl has no such notion. Second, perl is pretty
        loosely-typed language, so it is difficult to determine the proper type
        to assign to any given parameter. But these are just challenges.

        The idea being toyed with is to support some kind of POD annotation that
        would tell the WSDL gen tool how to serialize a WSDL.

        Juan Cristÿfffffffffff3bal Olivares wrote:

        > I want to generate a WSDL file from a soaplite
        > web service. How can I do that?
        >
        > Juan C. Olivares
        >
        >
        >
        >
        > __________________________________
        > Do you Yahoo!?
        > Friends. Fun. Try the all-new Yahoo! Messenger.
        > http://messenger.yahoo.com/
        >
        > *Yahoo! Groups Sponsor*
        > ADVERTISEMENT
        > <http://us.ard.yahoo.com/SIG=1292o51ik/M=298184.5022502.6152625.3001176/D=groups/S=1705701014:HM/EXP=1087182386/A=2164331/R=0/SIG=11eaelai9/*http://www.netflix.com/Default?mqso=60183351>
        >
        >
        >
        > ------------------------------------------------------------------------
        > *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
        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 3 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 4 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 5 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 6 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.