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

soap call - fire and forget

Expand Messages
  • norbu09
    hi, is there any possibility to fire a soap call which returns immediatly, a kind of fire an forget. the point is to trigger an other daemon to do something,
    Message 1 of 9 , Jan 8, 2004
    • 0 Attachment
      hi,

      is there any possibility to fire a soap call which returns immediatly,
      a kind of fire an forget. the point is to trigger an other daemon to
      do something, but if the daemon does not respond or is down or feels
      somehow unconvenient the call has to return right in the moment to the
      caller. some kind of UDP connection therefor would be perfect or is
      there any other aproach to do that?

      thanks for your input
      lenz
    • Tim Wood
      ... This is done at the level of the remote API, by designating it a notification rather than an RPC. How you do that designation at deployment time (in the
      Message 2 of 9 , Jan 8, 2004
      • 0 Attachment
        At 09:08 AM 01/08/04, you wrote:
        >hi,
        >
        >is there any possibility to fire a soap call which returns immediatly,
        >a kind of fire an forget. the point is to trigger an other daemon to
        >do something, but if the daemon does not respond or is down or feels
        >somehow unconvenient the call has to return right in the moment to the
        >caller. some kind of UDP connection therefor would be perfect or is
        >there any other aproach to do that?

        This is done at the level of the remote API, by designating it a "notification" rather than an RPC. How you do that designation at deployment time (in the WSDL) or at runtime is package-dependent and I have no idea how to in SOAP::Lite. But basically, it's a property of your API, not network level 4.
        HTH,
        TW
      • techrg99
        I have been trying to do something similar - in my case I want the end user (thru a GUI) to be able to cancel the SOAP call - or at least ignore what the call
        Message 3 of 9 , Jan 8, 2004
        • 0 Attachment
          I have been trying to do something similar - in my case I want the end
          user (thru a GUI) to be able to cancel the SOAP call - or at least
          ignore what the call returns... I think the issue is that since
          SOAP::Lite is using LWP to perform the HTTP communication, the process
          waits until a return or timeout. Perhaps there is a way to configure
          this??? I am experiementing with Perl 5.8.2 and using a separate
          thread to make the SOAP call. I have also seen ways to spawn another
          process to make the call so the main process is not stuck waiting
          around - for Win32 there is a good example in the O'reilly Programming
          Perl/Tk Book that goes out and gets comics and displays them back in
          the TK UI - this does not use SOAP, but does use LWP and the concepts
          work the same...
        • Byrne Reese
          I apologize to spam the group with something vaguely commercial, but I feel this thread warrants it. Grand Central is a Web Services network (technically, we
          Message 4 of 9 , Jan 8, 2004
          • 0 Attachment
            I apologize to spam the group with something vaguely commercial, but I
            feel this thread warrants it.

            Grand Central is a Web Services network (technically, we call ourselves a
            "Business Services Network" - but I am not going to mince words) - in any
            event, Grand Central offers the ability to turn any SOAP call into an
            asynchronous non-blocking one.

            Most SOAP calls are synchronous in nature: socket opens, request is sent,
            message is processes, response returned, socket closes. However, as this
            threads suggests, not all SOAP calls follow this pattern. Sometimes you
            just want to fire off a notification. Sometimes, the SOAP call is likely
            to take a long time and hanging up a thread, or socket for that long is
            impractical, sometimes you just want to fire and forget... Grand Central's
            asynchronous messaging protocol can be used with any service deployed on
            the network.

            In a very small way you can think of GC as a proxy. In an asynchronous
            scenario a message is posted to a service. The network accepts the
            messages, and immediately returns a tracking number (used for the response
            correlation later) to the sender. Mean while the message traverses the
            system and is delivered to the utlimate destination (in some cases the
            message is sent to multiple services when the service you are sending a
            message to invokes a business process - we all heard of SOAP
            intermediaries, Grand Central actually uses them!). When the response is
            returned, it is held by Grand Central, and the user then polls for it,
            much like you poll a POP3 mail server for email.

            Grand Central is free as long as your bandwidth is less than 25MB per
            month. And you have me as an excellent support resource. I have made sure
            there are lots of Perl/SOAP::Lite examples on the GC developer site. :)

            http://www.grandcentral.com/developers/

            > I have been trying to do something similar - in my case I want the end
            > user (thru a GUI) to be able to cancel the SOAP call - or at least
            > ignore what the call returns... I think the issue is that since
            > SOAP::Lite is using LWP to perform the HTTP communication, the process
            > waits until a return or timeout. Perhaps there is a way to configure
            > this??? I am experiementing with Perl 5.8.2 and using a separate
            > thread to make the SOAP call. I have also seen ways to spawn another
            > process to make the call so the main process is not stuck waiting
            > around - for Win32 there is a good example in the O'reilly Programming
            > Perl/Tk Book that goes out and gets comics and displays them back in
            > the TK UI - this does not use SOAP, but does use LWP and the concepts
            > work the same...
            >
            >
            >
            >
            >
            >
            >
            > 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
            > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
            >
            >
            >
            >
            >
            >
            >


            ^byrne :/
          • Lenz Gschwendtner
            ... thanks for that but we are programming a time critical high volume service so working with grand central in this place is not the thing planned. i know
            Message 5 of 9 , Jan 9, 2004
            • 0 Attachment
              Byrne Reese wrote:

              >Grand Central is free as long as your bandwidth is less than 25MB per
              >month. And you have me as an excellent support resource. I have made sure
              >there are lots of Perl/SOAP::Lite examples on the GC developer site. :)
              >
              >
              >

              thanks for that but we are programming a time critical high volume
              service so working with grand central in this place is not the thing
              planned. i know grand central already but in our situation in the moment
              there is no plan to use the services provided.

              thanks for the info, but it is more essential for us in the moment to
              know how to implement a "notification" in SOAP::Lite

              lenz

              --
              ~
              ~
              ~
              ~
              ".signature" [New] 4L, 8C [w]
            • Aaron Trevena
              ... It sounds like you need ebXML rather than plain SOAP. ebXML Messaging (usually) runs on top of SOAP with Attachments - it supports synchronous and
              Message 6 of 9 , Jan 9, 2004
              • 0 Attachment
                On Fri, 9 Jan 2004, Lenz Gschwendtner wrote:
                > thanks for that but we are programming a time critical high volume
                > service so working with grand central in this place is not the thing
                > planned. i know grand central already but in our situation in the moment
                > there is no plan to use the services provided.
                >
                > thanks for the info, but it is more essential for us in the moment to
                > know how to implement a "notification" in SOAP::Lite

                It sounds like you need ebXML rather than plain SOAP.

                ebXML Messaging (usually) runs on top of SOAP with Attachments - it
                supports synchronous and asynchronous messaging, provides Reliability and
                lots of powerful features that allow it to replace EDI.

                It is a bit heavyweight, but if you are building an application that needs
                those kind of features then it is justified and unavoidable.

                as a side note (who on the list doesn't have something to plug?) :
                I am looking for other perl developers interested in ebXML, we (a company
                I won't name yet) have some perl modules / classes that implement enough
                ebXML to hold brief (and often broken) conversations with the Hermes
                (free) ebXML MSH (a free, compliant ebXML MSH implementation written in
                Java) and hope to collaborate with others on getting it working better,
                sooner.

                cheers,

                A.

                --
                Aaron J Trevena - Perl Hacker, Kung Fu Geek, Internet Consultant
                AutoDia --- Automatic UML and HTML Specifications from Perl, C++
                and Any Datasource with a Handler. http://droogs.org/autodia
              • Alasdair Allan
                ... Well Grand Central is (just?) a broker implementating of something called Contextual Web Services, the project I m currently working on also makes
                Message 7 of 9 , Jan 9, 2004
                • 0 Attachment
                  > thanks for the info, but it is more essential for us in the moment to
                  > know how to implement a "notification" in SOAP::Lite

                  Well Grand Central is (just?) a broker implementating of something called
                  Contextual Web Services, the project I'm currently working on also makes
                  extensive use of them.

                  You should probably look at the WS-Coordination and WS-Transaction specs,
                  to see how transaction contexts are use to establish the scope of a
                  transaction within an operation is executed.

                  Al.
                • Bill Hess
                  Is SOAP::Lite capable of perform asynchronous messages by itself. I assume the default is synchronous? And is this because of the way LWP works? One thing I
                  Message 8 of 9 , Jan 9, 2004
                  • 0 Attachment
                    Is SOAP::Lite capable of perform asynchronous messages by itself. I
                    assume the default is synchronous? And is this because of the way LWP
                    works?

                    One thing I notice in a system we have recently developed is that when
                    using is over a LAN it works great, except for the synchronous
                    interaction. But when I run the system over a corporate VPN the
                    interaction is "choppy" - slower and not as consistent, but any
                    transaction always seems to finish OK. Could this be a result of
                    SOAP::Lite or do you think it is the VPN? I have used other commercial
                    client/sever type programs on this same VPN and some work fine (same as
                    being on the LAN) and others are "choppy" and some are downright
                    unreliable and fail. Could this be a result of some of these systems
                    are synchronous/asynchronous?



                    Byrne Reese wrote:
                    > I apologize to spam the group with something vaguely commercial, but I
                    > feel this thread warrants it.
                    >
                    > Grand Central is a Web Services network (technically, we call ourselves a
                    > "Business Services Network" - but I am not going to mince words) - in any
                    > event, Grand Central offers the ability to turn any SOAP call into an
                    > asynchronous non-blocking one.
                    >
                    > Most SOAP calls are synchronous in nature: socket opens, request is sent,
                    > message is processes, response returned, socket closes. However, as this
                    > threads suggests, not all SOAP calls follow this pattern. Sometimes you
                    > just want to fire off a notification. Sometimes, the SOAP call is likely
                    > to take a long time and hanging up a thread, or socket for that long is
                    > impractical, sometimes you just want to fire and forget... Grand Central's
                    > asynchronous messaging protocol can be used with any service deployed on
                    > the network.
                    >
                    > In a very small way you can think of GC as a proxy. In an asynchronous
                    > scenario a message is posted to a service. The network accepts the
                    > messages, and immediately returns a tracking number (used for the response
                    > correlation later) to the sender. Mean while the message traverses the
                    > system and is delivered to the utlimate destination (in some cases the
                    > message is sent to multiple services when the service you are sending a
                    > message to invokes a business process - we all heard of SOAP
                    > intermediaries, Grand Central actually uses them!). When the response is
                    > returned, it is held by Grand Central, and the user then polls for it,
                    > much like you poll a POP3 mail server for email.
                    >
                    > Grand Central is free as long as your bandwidth is less than 25MB per
                    > month. And you have me as an excellent support resource. I have made sure
                    > there are lots of Perl/SOAP::Lite examples on the GC developer site. :)
                    >
                    > http://www.grandcentral.com/developers/
                    >
                    >
                    >>I have been trying to do something similar - in my case I want the end
                    >>user (thru a GUI) to be able to cancel the SOAP call - or at least
                    >>ignore what the call returns... I think the issue is that since
                    >>SOAP::Lite is using LWP to perform the HTTP communication, the process
                    >>waits until a return or timeout. Perhaps there is a way to configure
                    >>this??? I am experiementing with Perl 5.8.2 and using a separate
                    >>thread to make the SOAP call. I have also seen ways to spawn another
                    >>process to make the call so the main process is not stuck waiting
                    >>around - for Win32 there is a good example in the O'reilly Programming
                    >>Perl/Tk Book that goes out and gets comics and displays them back in
                    >>the TK UI - this does not use SOAP, but does use LWP and the concepts
                    >>work the same...
                    >>
                    >>
                    >>
                    >>
                    >>
                    >>
                    >>
                    >>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
                    >>Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
                    >>
                    >>
                    >>
                    >>
                    >>
                    >>
                    >>
                    >
                    >
                    >
                    > ^byrne :/
                    >
                  • Byrne Reese
                    Ok, so the million dollar question is: Is SOAP::Lite capable of performing asynchronous messaging by itself? The answer is yes, but not natively. There are
                    Message 9 of 9 , Jan 9, 2004
                    • 0 Attachment
                      Ok, so the million dollar question is:

                      "Is SOAP::Lite capable of performing asynchronous messaging by itself?"

                      The answer is yes, but not natively. There are two forms of asynchronous
                      messaging that I have seen:

                      1) A sends message to B. A transmits to B a port/socket (that A opens) for
                      the response to be sent to. When B is done processing the message, they
                      post their response to the port A designated. This port is the means of
                      correlating the response with the initial request. (BEA does something
                      similar to this I believe, but they also use a Conversation ID for
                      correlation as well, and if I am not mistaken, .NET does something like
                      this as well.)

                      This is known as a callback style of asynchronous messaging.

                      2) A sends message to B. B returns to A a Correlation ID. B polls A for
                      response using Correlation ID. (Of course this is the scenario that Grand
                      Central implements through its network because it's implementation it
                      doesn't depend upon the endpoint to actually comprehend ANY asynchronous
                      protocol.)

                      This is known as poll-based style of asynchronous messaging.

                      Here is the problem with 1) both asynch implementations that I know of are
                      proprietary protocols. It therefore requires that the server and client
                      both understand how to exchange messages, and correlate in this manner.

                      If I wanted to implement something like this in SOAP::Lite, I would
                      suggest implementing a CGI that could process returned responses. The
                      client would have to be able to generate a unique ID and trasmit it along
                      with the URL the CGI listens on to the service being called. The service
                      would then have to persist and return the correlation id provided by the
                      client, and post the response to the CGI/port designated by A.

                      I have actually implemented something like this, but again - it is highly
                      proprietary and therefore not very portable.

                      Asynchronous messaging is a highly desired feature enhancement for
                      SOAP::Lite, but I am not sure which standard to turn to for a COMPLETE
                      answer to the problem. WS-Correlation is only part of the problem - what
                      is the HTTP protocol?

                      As you


                      > Is SOAP::Lite capable of perform asynchronous messages by itself. I
                      > assume the default is synchronous? And is this because of the way LWP
                      > works?
                      >
                      > One thing I notice in a system we have recently developed is that when
                      > using is over a LAN it works great, except for the synchronous
                      > interaction. But when I run the system over a corporate VPN the
                      > interaction is "choppy" - slower and not as consistent, but any
                      > transaction always seems to finish OK. Could this be a result of
                      > SOAP::Lite or do you think it is the VPN? I have used other commercial
                      > client/sever type programs on this same VPN and some work fine (same as
                      > being on the LAN) and others are "choppy" and some are downright
                      > unreliable and fail. Could this be a result of some of these systems
                      > are synchronous/asynchronous?
                      >
                      >
                      >
                      > Byrne Reese wrote:
                      >> I apologize to spam the group with something vaguely commercial, but I
                      >> feel this thread warrants it.
                      >>
                      >> Grand Central is a Web Services network (technically, we call ourselves
                      >> a
                      >> "Business Services Network" - but I am not going to mince words) - in
                      >> any
                      >> event, Grand Central offers the ability to turn any SOAP call into an
                      >> asynchronous non-blocking one.
                      >>
                      >> Most SOAP calls are synchronous in nature: socket opens, request is
                      >> sent,
                      >> message is processes, response returned, socket closes. However, as this
                      >> threads suggests, not all SOAP calls follow this pattern. Sometimes you
                      >> just want to fire off a notification. Sometimes, the SOAP call is likely
                      >> to take a long time and hanging up a thread, or socket for that long is
                      >> impractical, sometimes you just want to fire and forget... Grand
                      >> Central's
                      >> asynchronous messaging protocol can be used with any service deployed on
                      >> the network.
                      >>
                      >> In a very small way you can think of GC as a proxy. In an asynchronous
                      >> scenario a message is posted to a service. The network accepts the
                      >> messages, and immediately returns a tracking number (used for the
                      >> response
                      >> correlation later) to the sender. Mean while the message traverses the
                      >> system and is delivered to the utlimate destination (in some cases the
                      >> message is sent to multiple services when the service you are sending a
                      >> message to invokes a business process - we all heard of SOAP
                      >> intermediaries, Grand Central actually uses them!). When the response is
                      >> returned, it is held by Grand Central, and the user then polls for it,
                      >> much like you poll a POP3 mail server for email.
                      >>
                      >> Grand Central is free as long as your bandwidth is less than 25MB per
                      >> month. And you have me as an excellent support resource. I have made
                      >> sure
                      >> there are lots of Perl/SOAP::Lite examples on the GC developer site. :)
                      >>
                      >> http://www.grandcentral.com/developers/
                      >>
                      >>
                      >>>I have been trying to do something similar - in my case I want the end
                      >>>user (thru a GUI) to be able to cancel the SOAP call - or at least
                      >>>ignore what the call returns... I think the issue is that since
                      >>>SOAP::Lite is using LWP to perform the HTTP communication, the process
                      >>>waits until a return or timeout. Perhaps there is a way to configure
                      >>>this??? I am experiementing with Perl 5.8.2 and using a separate
                      >>>thread to make the SOAP call. I have also seen ways to spawn another
                      >>>process to make the call so the main process is not stuck waiting
                      >>>around - for Win32 there is a good example in the O'reilly Programming
                      >>>Perl/Tk Book that goes out and gets comics and displays them back in
                      >>>the TK UI - this does not use SOAP, but does use LWP and the concepts
                      >>>work the same...
                      >>>
                      >>>
                      >>>
                      >>>
                      >>>
                      >>>
                      >>>
                      >>>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
                      >>>Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
                      >>>
                      >>>
                      >>>
                      >>>
                      >>>
                      >>>
                      >>>
                      >>
                      >>
                      >>
                      >> ^byrne :/
                      >>
                      >
                      >


                      ^byrne :/
                    Your message has been successfully submitted and would be delivered to recipients shortly.