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

SOAPVerse - the kernel of an idea for an interoperability test/de mo

Expand Messages
  • Glen Daniels
    Hi folks! This is a quick writeup of an idea that a bunch of folks had last week while discussing interoperability demos and tests. It s a pretty simple
    Message 1 of 4 , Mar 20 8:35 AM
    • 0 Attachment
      Hi folks!

      This is a quick writeup of an idea that a bunch of folks had last week while
      discussing interoperability demos and tests. It's a pretty simple system
      which we thought was a) fun, b) technically interesting, and c) quite a
      compelling demo. I'd like to know what people think of the idea - is this
      too ambitious, is it something you'd be psyched to help design/implement, is
      it cool?

      The SOAPVerse : A long-term SOAP interoperability demo
      ------------------------------------------------------

      [1.0 Introduction - the view from outside]

      I'll start explaining the idea by giving a brief scenario. You connect a
      browser to SOAPVerse.org, which gives you three choices - 1) enter the
      SOAPVerse, 2) look at the map, and 3) learn about joining. You choose #1,
      and are offered a list of available clients and "entry portals" (i.e.
      clients (no, not "IE clients", necessarily...)) on the web. You choose a
      local entry portal, and a Java applet appears, primarily composed of a text
      window:

      --------------
      SOAP Tower

      You stand in the SOAP tower. The floor's a bit slippery here, but you
      suspect you could make it to the exits to the NORTH or EAST if you walked
      slowly.

      There is a briefcase sitting here.

      (this room lives at foo.ibm.com, and is powered by Tomcat/Apache-SOAP 2.1!)
      --------------

      It's a text adventure, much like Zork or Colossal Cave, but a lot simpler.
      The interesting part happens when you move to the East:

      --------------
      [a strange feeling overcomes you for a moment as you pass through the door]

      Campus West

      You stand on the Microsoft campus, near building 33. You may ENTER, or
      travel WEST or SOUTH down the main road.

      Others in this room : KeithB

      There is a rubber ducky sitting here.

      (this room lives at bar.microsoft.com, and is powered by IIS/ASP.NET!)
      ---------------

      What just happened is that you smoothly and transparently moved from one
      SOAP-based server to another. The servers had to interoperate to "pass you
      off", and anyone who wants to go check out the website can see the deeper
      technical explanation of what's going on.

      If you'd selected the "map" option, you'd see a cool graphical depiction of
      the whole graph of rooms currently connected to the SOAPVerse, color-coded
      by host/server technology.

      [2.0 Digging a little deeper]

      That's the basic idea - a totally distributed text adventure game that
      demonstrates SOAP interoperability at a number of levels. The actual APIs
      are pretty simple, and should be implementable in few days at the most.

      So if you go to the "join us" section of the site, you end up with several
      things. First, a description of the structure of the application, in enough
      detail that you could implement it on your own site. This can (and should)
      be in as many forms as possible - english text, WSDL, SDL, IDL, etc....
      So you build the server to the spec, in any language/environment/platform
      you happen to have handy.

      Next, you find a form which allows you to test your server once you've got
      it up. This causes the SOAPVerse server to run a series of tests against
      your endpoint, to see if you can interoperate with it. Assuming that works,
      you can click "hook me up!" and the SOAPVerse server randomly picks a place
      on the graph to add your area, and matchmakes a connection between your
      server and whoever you're connecting to. The tests should get run again
      between you and this new guy, to make sure you two interoperate (you don't
      want to just prove interoperation between the "main" server and your impl),
      and then if everything looks good, you're now a part of the world, and your
      rooms appear on the master map.

      There's some more detail about which kinds of things we're testing with a
      system like this (data serialization, headers, intermediaries?), actual
      APIs,
      etc. but I'll convey my thoughts about that in a design discussion if
      there's
      enough community interest in this project.

      [3.0 Musings]

      This kind of thing serves at least two purposes. First, it can stay up in
      perpetuity, demonstrating SOAP interoperability in a fun way. This should
      be something you can always find, and hook new servers into. Second, it's a
      good demo for tradeshow-type events.

      Obviously there's a lot of opportunity for errors to happen here, so the
      system shouldn't assume too much about robustness, and should gracefully
      fail in the face of problems. It's meant as an interoperability demo,
      not a full-scale game.

      None of this is at all carved in stone, we just liked the basic idea. It
      shouldn't get too complicated, and it shouldn't rely on any particular
      implementation.

      If this could get done by late next month, this could be the actual
      technolgy
      for the "interopathon" demo which has been discussed for NetWorld/Interop
      in May.

      What do you think?

      --Glen
    • Paul Kulchenko
      Hi, Glen! I was excited about the speed of decisions and the level of understanding yesterday and now I m observing the number of political issues around it
      Message 2 of 4 , Mar 20 11:44 AM
      • 0 Attachment
        Hi, Glen!

        I was excited about the speed of decisions and the level of
        understanding yesterday and now I'm observing the number of political
        issues around it today and it makes me ...hm, kind of sick, so I'll
        talk ONLY about technological aspects and I would be the first to
        implement it as soon as we agree on it (and maybe even befor :)).

        --- Glen Daniels <gdaniels@...> wrote:
        > This is a quick writeup of an idea that a bunch of folks had last
        > week while
        > discussing interoperability demos and tests. It's a pretty simple
        > system
        > which we thought was a) fun, b) technically interesting, and c)
        > quite a compelling demo. I'd like to know what people think of the
        > idea - is this too ambitious, is it something you'd be psyched to
        I hope it's not and I agree with goals.
        > help design/implement, is it cool?
        I think it is and here is my view on that.

        Map (A x B rooms)
        Every room is server implementation (server)
        Several crawlers are available to go throuh map (client and server)

        Procedure for participants:
        GET list of crawlers from Map
        choose one
        START with this crawler ([x,y]) and get back information where you
        are (crawler will MOVE_IN into specified room)
        you may GET_LIST of other crawlers in this room, WRITE_NOTE for
        other crawlers, READ_NOTEs posted by others
        now you may MOVE your crawler somewhere (direction) and crawler
        will tell current room MOVE_OUT and new room MOVE_IN. MOVE_OUT
        shouldn't fail (otherwise you're locked in :)), because you already
        succesfully moved in, but MOVE_IN may fail, so you'll be in the same
        room.

        Why do we need crawlers and do not tell directly where we want to go
        (MOVE_OUT to one room/server and MOVE_IN to another one)? First, if
        we really want to test interop both sides should be under some
        control (not political :)) to log in errors and be sure that both
        sides are doing it right. Second, it will let us to test
        interoperability on two levels: from user to crawler and between
        crawlers and servers. It'll let user switch crawler and keep moving,
        so after some time we will have map how crawlers are moving (and
        where) and problem spots on our map. Providing different interfaces
        to crawler (it could be web, GUI or something else) you can drive it
        thru the map, so it becomes accessible to (almost) everybody. Yet
        you're able to call servers directly, but that's your responsibility
        to handle and deal with errors, interfaces, etc.

        Map interface
        add_field(endpoint, details) -- register server to participate
        add_crawler(endpoint, details) -- register crawler
        get_list_of_crawlers
        draw_the_map -- :)

        Room interface
        move_in
        move_out
        write_note
        read_notes
        get_list_of_crawlers_here

        Crawler interface
        start([x,y])
        move(direction) -- does move_out from one and move_in into another
        one
        write_note -- "I was here"
        read_notes
        get_list_of_crawlers_in_this_room
        get_room_information

        In my understanding central point IS required, just because both
        server and crawler implementation should be REALLY simple and DOES
        NOT require any back-end, like persistent storage, databases, etc.,
        not because it difficult or will take time, but just because we'll
        cut implementations that otherwise could participate, like Kafka
        (XSLT) or I don't know, maybe SOAP.py. In my understanding (since we
        have both client and server in crawler) crawler should try to go
        inside the room (different implementation) and then report to server
        result (no one else will be able to do it, current room doesn't care
        about it and new room may not know about it, because message wasn't
        parsed). That's another reason why I think it shouldn't be just
        client to talk to server, but specific crawler that will have little
        bit logic inside. Another important piece is that all reauired
        information going back and forth and is not stored somewhere except
        client's computer (or maybe yet central point for stat) and it'll let
        switch crawler and keep going farther.

        So, the picture is:

        [any client: client, could be browser, applet, application, whatever]

        /----- game borders ----------------------------
        |
        | [crawler: implements both client and server]
        |
        | [room: server only]
        |
        | [map: central point, control the game, server only]
        |
        \----------------------------------------------

        In this picture Map should be MOST interoperable implementation at
        this time, because anyhow crawler and any other client should be able
        to talk to it. Then everybody can write server (interface is simple)
        and see how it goes. More efforts required to write crawler, but it's
        more interesting also, and could be done independently. Anyway, we'll
        be able to check interop between users and crawlers and register
        (hopefully) all issues and problems in interoperability between
        crawlers and rooms.

        Having central point will slightly modify the interface, so let me
        know if you think it IS or ISN'T required. Any thoughs will be
        greatly appreciated.

        Best wishes, Paul.

        >
        > The SOAPVerse : A long-term SOAP interoperability demo
        > ------------------------------------------------------
        >
        > [1.0 Introduction - the view from outside]
        >
        > I'll start explaining the idea by giving a brief scenario. You
        > connect a
        > browser to SOAPVerse.org, which gives you three choices - 1) enter
        > the
        > SOAPVerse, 2) look at the map, and 3) learn about joining. You
        > choose #1,
        > and are offered a list of available clients and "entry portals"
        > (i.e.
        > clients (no, not "IE clients", necessarily...)) on the web. You
        > choose a
        > local entry portal, and a Java applet appears, primarily composed
        > of a text
        > window:
        >
        > --------------
        > SOAP Tower
        >
        > You stand in the SOAP tower. The floor's a bit slippery here, but
        > you
        > suspect you could make it to the exits to the NORTH or EAST if you
        > walked
        > slowly.
        >
        > There is a briefcase sitting here.
        >
        > (this room lives at foo.ibm.com, and is powered by
        > Tomcat/Apache-SOAP 2.1!)
        > --------------
        >
        > It's a text adventure, much like Zork or Colossal Cave, but a lot
        > simpler.
        > The interesting part happens when you move to the East:
        >
        > --------------
        > [a strange feeling overcomes you for a moment as you pass through
        > the door]
        >
        > Campus West
        >
        > You stand on the Microsoft campus, near building 33. You may
        > ENTER, or
        > travel WEST or SOUTH down the main road.
        >
        > Others in this room : KeithB
        >
        > There is a rubber ducky sitting here.
        >
        > (this room lives at bar.microsoft.com, and is powered by
        > IIS/ASP.NET!)
        > ---------------
        >
        > What just happened is that you smoothly and transparently moved
        > from one
        > SOAP-based server to another. The servers had to interoperate to
        > "pass you
        > off", and anyone who wants to go check out the website can see the
        > deeper
        > technical explanation of what's going on.
        >
        > If you'd selected the "map" option, you'd see a cool graphical
        > depiction of
        > the whole graph of rooms currently connected to the SOAPVerse,
        > color-coded
        > by host/server technology.
        >
        > [2.0 Digging a little deeper]
        >
        > That's the basic idea - a totally distributed text adventure game
        > that
        > demonstrates SOAP interoperability at a number of levels. The
        > actual APIs
        > are pretty simple, and should be implementable in few days at the
        > most.
        >
        > So if you go to the "join us" section of the site, you end up with
        > several
        > things. First, a description of the structure of the application,
        > in enough
        > detail that you could implement it on your own site. This can (and
        > should)
        > be in as many forms as possible - english text, WSDL, SDL, IDL,
        > etc....
        > So you build the server to the spec, in any
        > language/environment/platform
        > you happen to have handy.
        >
        > Next, you find a form which allows you to test your server once
        > you've got
        > it up. This causes the SOAPVerse server to run a series of tests
        > against
        > your endpoint, to see if you can interoperate with it. Assuming
        > that works,
        > you can click "hook me up!" and the SOAPVerse server randomly picks
        > a place
        > on the graph to add your area, and matchmakes a connection between
        > your
        > server and whoever you're connecting to. The tests should get run
        > again
        > between you and this new guy, to make sure you two interoperate
        > (you don't
        > want to just prove interoperation between the "main" server and
        > your impl),
        > and then if everything looks good, you're now a part of the world,
        > and your
        > rooms appear on the master map.
        >
        > There's some more detail about which kinds of things we're testing
        > with a
        > system like this (data serialization, headers, intermediaries?),
        > actual
        > APIs,
        > etc. but I'll convey my thoughts about that in a design discussion
        > if
        > there's
        > enough community interest in this project.
        >
        > [3.0 Musings]
        >
        > This kind of thing serves at least two purposes. First, it can
        > stay up in
        > perpetuity, demonstrating SOAP interoperability in a fun way. This
        > should
        > be something you can always find, and hook new servers into.
        > Second, it's a
        > good demo for tradeshow-type events.
        >
        > Obviously there's a lot of opportunity for errors to happen here,
        > so the
        > system shouldn't assume too much about robustness, and should
        > gracefully
        > fail in the face of problems. It's meant as an interoperability
        > demo,
        > not a full-scale game.
        >
        > None of this is at all carved in stone, we just liked the basic
        > idea. It
        > shouldn't get too complicated, and it shouldn't rely on any
        > particular
        > implementation.
        >
        > If this could get done by late next month, this could be the actual
        > technolgy
        > for the "interopathon" demo which has been discussed for
        > NetWorld/Interop
        > in May.
        >
        > What do you think?
        >
        > --Glen
        >
        > ------------------------ Yahoo! Groups Sponsor
        >
        > To unsubscribe from this group, send an email to:
        > soapbuilders-unsubscribe@yahoogroups.com
        >
        >
        >
        > Your use of Yahoo! Groups is subject to
        > http://docs.yahoo.com/info/terms/
        >
        >


        __________________________________________________
        Do You Yahoo!?
        Get email at your own domain with Yahoo! Mail.
        http://personal.mail.yahoo.com/
      • Paul Kulchenko
        Hi, Glen! I was excited about the speed of decisions and the level of understanding yesterday and now I m observing the number of political issues around it
        Message 3 of 4 , Mar 20 11:45 AM
        • 0 Attachment
          Hi, Glen!

          I was excited about the speed of decisions and the level of
          understanding yesterday and now I'm observing the number of political
          issues around it today and it makes me ...hm, kind of sick, so I'll
          talk ONLY about technological aspects and I would be the first to
          implement it as soon as we agree on it (and maybe even befor :)).

          --- Glen Daniels <gdaniels@...> wrote:
          > This is a quick writeup of an idea that a bunch of folks had last
          > week while
          > discussing interoperability demos and tests. It's a pretty simple
          > system
          > which we thought was a) fun, b) technically interesting, and c)
          > quite a compelling demo. I'd like to know what people think of the
          > idea - is this too ambitious, is it something you'd be psyched to
          I hope it's not and I agree with goals.
          > help design/implement, is it cool?
          I think it is and here is my view on that.

          Map (A x B rooms)
          Every room is server implementation (server)
          Several crawlers are available to go throuh map (client and server)

          Procedure for participants:
          GET list of crawlers from Map
          choose one
          START with this crawler ([x,y]) and get back information where you
          are (crawler will MOVE_IN into specified room)
          you may GET_LIST of other crawlers in this room, WRITE_NOTE for
          other crawlers, READ_NOTEs posted by others
          now you may MOVE your crawler somewhere (direction) and crawler
          will tell current room MOVE_OUT and new room MOVE_IN. MOVE_OUT
          shouldn't fail (otherwise you're locked in :)), because you already
          succesfully moved in, but MOVE_IN may fail, so you'll be in the same
          room.

          Why do we need crawlers and do not tell directly where we want to go
          (MOVE_OUT to one room/server and MOVE_IN to another one)? First, if
          we really want to test interop both sides should be under some
          control (not political :)) to log in errors and be sure that both
          sides are doing it right. Second, it will let us to test
          interoperability on two levels: from user to crawler and between
          crawlers and servers. It'll let user switch crawler and keep moving,
          so after some time we will have map how crawlers are moving (and
          where) and problem spots on our map. Providing different interfaces
          to crawler (it could be web, GUI or something else) you can drive it
          thru the map, so it becomes accessible to (almost) everybody. Yet
          you're able to call servers directly, but that's your responsibility
          to handle and deal with errors, interfaces, etc.

          Map interface
          add_field(endpoint, details) -- register server to participate
          add_crawler(endpoint, details) -- register crawler
          get_list_of_crawlers
          draw_the_map -- :)

          Room interface
          move_in
          move_out
          write_note
          read_notes
          get_list_of_crawlers_here

          Crawler interface
          start([x,y])
          move(direction) -- does move_out from one and move_in into another
          one
          write_note -- "I was here"
          read_notes
          get_list_of_crawlers_in_this_room
          get_room_information

          In my understanding central point IS required, just because both
          server and crawler implementation should be REALLY simple and DOES
          NOT require any back-end, like persistent storage, databases, etc.,
          not because it difficult or will take time, but just because we'll
          cut implementations that otherwise could participate, like Kafka
          (XSLT) or I don't know, maybe SOAP.py. In my understanding (since we
          have both client and server in crawler) crawler should try to go
          inside the room (different implementation) and then report to server
          result (no one else will be able to do it, current room doesn't care
          about it and new room may not know about it, because message wasn't
          parsed). That's another reason why I think it shouldn't be just
          client to talk to server, but specific crawler that will have little
          bit logic inside. Another important piece is that all reauired
          information going back and forth and is not stored somewhere except
          client's computer (or maybe yet central point for stat) and it'll let
          switch crawler and keep going farther.

          So, the picture is:

          [any client: client, could be browser, applet, application, whatever]

          /----- game borders ----------------------------
          |
          | [crawler: implements both client and server]
          |
          | [room: server only]
          |
          | [map: central point, control the game, server only]
          |
          \----------------------------------------------

          In this picture Map should be MOST interoperable implementation at
          this time, because anyhow crawler and any other client should be able
          to talk to it. Then everybody can write server (interface is simple)
          and see how it goes. More efforts required to write crawler, but it's
          more interesting also, and could be done independently. Anyway, we'll
          be able to check interop between users and crawlers and register
          (hopefully) all issues and problems in interoperability between
          crawlers and rooms.

          Having central point will slightly modify the interface, so let me
          know if you think it IS or ISN'T required. Any thoughs will be
          greatly appreciated.

          Best wishes, Paul.

          >
          > The SOAPVerse : A long-term SOAP interoperability demo
          > ------------------------------------------------------
          >
          > [1.0 Introduction - the view from outside]
          >
          > I'll start explaining the idea by giving a brief scenario. You
          > connect a
          > browser to SOAPVerse.org, which gives you three choices - 1) enter
          > the
          > SOAPVerse, 2) look at the map, and 3) learn about joining. You
          > choose #1,
          > and are offered a list of available clients and "entry portals"
          > (i.e.
          > clients (no, not "IE clients", necessarily...)) on the web. You
          > choose a
          > local entry portal, and a Java applet appears, primarily composed
          > of a text
          > window:
          >
          > --------------
          > SOAP Tower
          >
          > You stand in the SOAP tower. The floor's a bit slippery here, but
          > you
          > suspect you could make it to the exits to the NORTH or EAST if you
          > walked
          > slowly.
          >
          > There is a briefcase sitting here.
          >
          > (this room lives at foo.ibm.com, and is powered by
          > Tomcat/Apache-SOAP 2.1!)
          > --------------
          >
          > It's a text adventure, much like Zork or Colossal Cave, but a lot
          > simpler.
          > The interesting part happens when you move to the East:
          >
          > --------------
          > [a strange feeling overcomes you for a moment as you pass through
          > the door]
          >
          > Campus West
          >
          > You stand on the Microsoft campus, near building 33. You may
          > ENTER, or
          > travel WEST or SOUTH down the main road.
          >
          > Others in this room : KeithB
          >
          > There is a rubber ducky sitting here.
          >
          > (this room lives at bar.microsoft.com, and is powered by
          > IIS/ASP.NET!)
          > ---------------
          >
          > What just happened is that you smoothly and transparently moved
          > from one
          > SOAP-based server to another. The servers had to interoperate to
          > "pass you
          > off", and anyone who wants to go check out the website can see the
          > deeper
          > technical explanation of what's going on.
          >
          > If you'd selected the "map" option, you'd see a cool graphical
          > depiction of
          > the whole graph of rooms currently connected to the SOAPVerse,
          > color-coded
          > by host/server technology.
          >
          > [2.0 Digging a little deeper]
          >
          > That's the basic idea - a totally distributed text adventure game
          > that
          > demonstrates SOAP interoperability at a number of levels. The
          > actual APIs
          > are pretty simple, and should be implementable in few days at the
          > most.
          >
          > So if you go to the "join us" section of the site, you end up with
          > several
          > things. First, a description of the structure of the application,
          > in enough
          > detail that you could implement it on your own site. This can (and
          > should)
          > be in as many forms as possible - english text, WSDL, SDL, IDL,
          > etc....
          > So you build the server to the spec, in any
          > language/environment/platform
          > you happen to have handy.
          >
          > Next, you find a form which allows you to test your server once
          > you've got
          > it up. This causes the SOAPVerse server to run a series of tests
          > against
          > your endpoint, to see if you can interoperate with it. Assuming
          > that works,
          > you can click "hook me up!" and the SOAPVerse server randomly picks
          > a place
          > on the graph to add your area, and matchmakes a connection between
          > your
          > server and whoever you're connecting to. The tests should get run
          > again
          > between you and this new guy, to make sure you two interoperate
          > (you don't
          > want to just prove interoperation between the "main" server and
          > your impl),
          > and then if everything looks good, you're now a part of the world,
          > and your
          > rooms appear on the master map.
          >
          > There's some more detail about which kinds of things we're testing
          > with a
          > system like this (data serialization, headers, intermediaries?),
          > actual
          > APIs,
          > etc. but I'll convey my thoughts about that in a design discussion
          > if
          > there's
          > enough community interest in this project.
          >
          > [3.0 Musings]
          >
          > This kind of thing serves at least two purposes. First, it can
          > stay up in
          > perpetuity, demonstrating SOAP interoperability in a fun way. This
          > should
          > be something you can always find, and hook new servers into.
          > Second, it's a
          > good demo for tradeshow-type events.
          >
          > Obviously there's a lot of opportunity for errors to happen here,
          > so the
          > system shouldn't assume too much about robustness, and should
          > gracefully
          > fail in the face of problems. It's meant as an interoperability
          > demo,
          > not a full-scale game.
          >
          > None of this is at all carved in stone, we just liked the basic
          > idea. It
          > shouldn't get too complicated, and it shouldn't rely on any
          > particular
          > implementation.
          >
          > If this could get done by late next month, this could be the actual
          > technolgy
          > for the "interopathon" demo which has been discussed for
          > NetWorld/Interop
          > in May.
          >
          > What do you think?
          >
          > --Glen
          >
          > ------------------------ Yahoo! Groups Sponsor
          >
          > To unsubscribe from this group, send an email to:
          > soapbuilders-unsubscribe@yahoogroups.com
          >
          >
          >
          > Your use of Yahoo! Groups is subject to
          > http://docs.yahoo.com/info/terms/
          >
          >


          __________________________________________________
          Do You Yahoo!?
          Get email at your own domain with Yahoo! Mail.
          http://personal.mail.yahoo.com/
        • Steve Graham
          Curious, I was pretty sure foo.ibm.com was powered by WebSphere! I guess I was wrong? ++++++++ Steve Graham sggraham@us.ibm.com (919)254-0615 (T/L 444) Web
          Message 4 of 4 , Mar 20 1:39 PM
          • 0 Attachment
            Curious, I was pretty sure foo.ibm.com was powered by WebSphere! I guess I
            was wrong?

            ++++++++
            Steve Graham
            sggraham@...
            (919)254-0615 (T/L 444)
            Web Services Architect
            Emerging Internet Technologies
            ++++++++


            Glen Daniels <gdaniels@...> on 03/20/2001 11:35:40 AM

            Please respond to soapbuilders@yahoogroups.com

            To: interopathon@yahoogroups.com, Soapbuilders
            <soapbuilders@yahoogroups.com>, "'SOAP@...'"
            <SOAP@...>
            cc:
            Subject: [soapbuilders] SOAPVerse - the kernel of an idea for an
            interoperability test/de mo



            Hi folks!

            This is a quick writeup of an idea that a bunch of folks had last week
            while
            discussing interoperability demos and tests. It's a pretty simple system
            which we thought was a) fun, b) technically interesting, and c) quite a
            compelling demo. I'd like to know what people think of the idea - is this
            too ambitious, is it something you'd be psyched to help design/implement,
            is
            it cool?

            The SOAPVerse : A long-term SOAP interoperability demo
            ------------------------------------------------------

            [1.0 Introduction - the view from outside]

            I'll start explaining the idea by giving a brief scenario. You connect a
            browser to SOAPVerse.org, which gives you three choices - 1) enter the
            SOAPVerse, 2) look at the map, and 3) learn about joining. You choose #1,
            and are offered a list of available clients and "entry portals" (i.e.
            clients (no, not "IE clients", necessarily...)) on the web. You choose a
            local entry portal, and a Java applet appears, primarily composed of a text
            window:

            --------------
            SOAP Tower

            You stand in the SOAP tower. The floor's a bit slippery here, but you
            suspect you could make it to the exits to the NORTH or EAST if you walked
            slowly.

            There is a briefcase sitting here.

            (this room lives at foo.ibm.com, and is powered by Tomcat/Apache-SOAP 2.1!)
            --------------

            It's a text adventure, much like Zork or Colossal Cave, but a lot simpler.
            The interesting part happens when you move to the East:

            --------------
            [a strange feeling overcomes you for a moment as you pass through the door]

            Campus West

            You stand on the Microsoft campus, near building 33. You may ENTER, or
            travel WEST or SOUTH down the main road.

            Others in this room : KeithB

            There is a rubber ducky sitting here.

            (this room lives at bar.microsoft.com, and is powered by IIS/ASP.NET!)
            ---------------

            What just happened is that you smoothly and transparently moved from one
            SOAP-based server to another. The servers had to interoperate to "pass you
            off", and anyone who wants to go check out the website can see the deeper
            technical explanation of what's going on.

            If you'd selected the "map" option, you'd see a cool graphical depiction of
            the whole graph of rooms currently connected to the SOAPVerse, color-coded
            by host/server technology.

            [2.0 Digging a little deeper]

            That's the basic idea - a totally distributed text adventure game that
            demonstrates SOAP interoperability at a number of levels. The actual APIs
            are pretty simple, and should be implementable in few days at the most.

            So if you go to the "join us" section of the site, you end up with several
            things. First, a description of the structure of the application, in
            enough
            detail that you could implement it on your own site. This can (and should)
            be in as many forms as possible - english text, WSDL, SDL, IDL, etc....
            So you build the server to the spec, in any language/environment/platform
            you happen to have handy.

            Next, you find a form which allows you to test your server once you've got
            it up. This causes the SOAPVerse server to run a series of tests against
            your endpoint, to see if you can interoperate with it. Assuming that
            works,
            you can click "hook me up!" and the SOAPVerse server randomly picks a place
            on the graph to add your area, and matchmakes a connection between your
            server and whoever you're connecting to. The tests should get run again
            between you and this new guy, to make sure you two interoperate (you don't
            want to just prove interoperation between the "main" server and your impl),
            and then if everything looks good, you're now a part of the world, and your
            rooms appear on the master map.

            There's some more detail about which kinds of things we're testing with a
            system like this (data serialization, headers, intermediaries?), actual
            APIs,
            etc. but I'll convey my thoughts about that in a design discussion if
            there's
            enough community interest in this project.

            [3.0 Musings]

            This kind of thing serves at least two purposes. First, it can stay up in
            perpetuity, demonstrating SOAP interoperability in a fun way. This should
            be something you can always find, and hook new servers into. Second, it's
            a
            good demo for tradeshow-type events.

            Obviously there's a lot of opportunity for errors to happen here, so the
            system shouldn't assume too much about robustness, and should gracefully
            fail in the face of problems. It's meant as an interoperability demo,
            not a full-scale game.

            None of this is at all carved in stone, we just liked the basic idea. It
            shouldn't get too complicated, and it shouldn't rely on any particular
            implementation.

            If this could get done by late next month, this could be the actual
            technolgy
            for the "interopathon" demo which has been discussed for NetWorld/Interop
            in May.

            What do you think?

            --Glen


            To unsubscribe from this group, send an email to:
            soapbuilders-unsubscribe@yahoogroups.com



            Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
          Your message has been successfully submitted and would be delivered to recipients shortly.